严肃地说，智能手表的“微粒化”设计是一种怎样的体验？

按：本文来自百度MUX。百度MUX智能硬件团队从去年年初开始接手百度智能手表OS的设计工作，认为相对于智能手机的“碎片化”场景，智能手表在信息和任务维度更加轻量，呈现“微粒化”的点状用。本文将展示百度智能手表的OS创新设计。

| 背景与挑战

2015年Google、Apple、阿里、华为均推出了智能手表或其操作系统，同时来自研究公司Strategy Analytics的最新数据显示，Apple Watch 2015年的全球出货量达到1500万支，可以说2015年是智能手表的元年。

由于早期Android Wear 的部分服务无法在国内使用，各大互联网公司设计的智能手表操作系统更是风起云涌，如出门问问、YunOS、TencentOS等等。但是由于业内对智能手表的形态尚处于探索阶段，多数产品对于手表平台所要承载的任务和信息并没有进行清晰的定义。

百度MUX智能硬件团队从去年年初开始接手百度智能手表OS的设计工作，认为相对于智能手机的“碎片化”场景，智能手表在信息和任务维度更加轻量，呈现“微粒化”的点状用户体验。需要重新设计承载他们的容器。本文希望严肃地说，智能手表的“微粒化”设计是一种怎样的体验？

定义新操作系统的第一步是定义设备属性，我们分别从智能手表适合执行的任务和适合显示的信息两个维度进行定义。

智能手表有着极佳的便携性和极低的输入效率（输入效率由精准度和速率两方面决定），因此它只适合执行轻量的任务，比如收到一个推送后简单执行附带的操作，P图这类需要长时间连续操作的任务显然不适合在手表上进行。在信息维度，经测试智能手表一次使用舒适时长为15秒左右（从抬起手腕到手臂有疲劳感，看文章的你请可以自行测试），屏幕展现尺寸极小所以智能手表必须在繁杂信息中做出抉择，把重点放在高频的短信息上。

综上分析我们将目前技术所能实现的智能手表属性定义为“轻任务，短信息”的承载设备。如果说手机让我们利用生活中的碎片化时间执任务和查看信息，那么智能手表就是利用我们的“微粒化”时间执行更轻的任务和查看更短的信息。

智能手表展现尺寸十分有限，因此有必要将短信息和任务按使用频率细分，以便设计不同的“容器”承载它们。

将长线任务集成为轻轻一点

适合放在手表上执行的任务应该是能在很短时间内完成的，这意味手表的使用场景被限制！我们怎样解决这一问题？我们发现将一些在手机上总是被重复的长线任务进行自动化处理后放在手表上能有效加快效率和扩展使用场景。比如打车这个任务我们用手机时的操作是“拿出手机 – 解锁 – 打开App – 输入地址 – 发出订单”，在设计手表时我们把这个流程内最常用的一些任务（比如从家到公司）提取出来，利用智能手表用户可以一键发出从家到公司的订单，而不是单纯的把手机的操作照搬一遍。

承载任务和信息的“容器”

如前文所述我们将手表定义为“轻任务，短信息”的承载设备，由于手表屏幕展现尺寸的限制我们不得不将信息和任务分级以便用不同容器承载，那么我们设计什么样的容器来承载这些短信息和轻任务呢？

表盘 - 智能手表首先应该是手表，因此表盘是用户最常使用的页面，除了显示时间之外，我们用它承载最高频的任务和信息。

快捷卡片 - 表盘的空间毕竟有限，而一些中任务和信息常常需要更大的空间，因此我们设计了快捷卡片，类似于安卓系统的Widght。

Laucher -是App集合，即长尾的信息和任务

不同于手机的App Laucher，手表的Lancher不是被最常使用的模块，但是却要承载大量的Icon，且由于手表屏幕尺寸的限制，给如何设计出足够高效启动器带来很大的挑战（后文将会讲述设计和验证的方法）。

Notification – 智能手表作为用户抬手既得的屏幕，可以主动推动一些任务和信息，可以在不打断当前任务的情况下让用户利用微粒化时间快速处理，而Notification适合承载这些被动任务和即时信息。

从“容器”到立体的交互框架

如果容器是承载着信息和任务一个个的房间，那下一步要做的就是将这些房间建立起联系，以此建立Duwaer系统的骨骼-交互架构。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!