WatchKit app毕竟是Watch应用的主要表现形式，从各类UI控件的使用到布局、字体、配色原则、动效实现等等，有太多需要去了解，本文也不会深入到如此细化的层面。建议各位道上的兄弟姐妹花些时间完整阅读官方的界面设计规范 – Apple Watch Human Interface Guidelines，我做的中文版在这里，如有需要也可参考，不作为首选推荐，因为时效性欠佳，官方更新过的一些内容没有做。另外如果情况允许，也可以同时读下同样来自官方的Apple Watch Programming Guide，过于技术性的话题不属于我们的范畴，但那些解释UI元素定制方法的内容对于设计师来说还是有些参考价值的。
Glance自从 19 世纪手表诞生以来，瞥一眼手腕查看时间，已经成了人们的习惯动作，有了 Apple Watch，这个习惯性的一瞥可以给你更多讯息。我们开发了Glance，这个功能可以将你查看最频繁的讯息提炼出来，使你常用的 app 更加适合在手腕上浏览操作。要查看相关讯息时，你只需用手指向上轻扫一下，就能立即浏览天气预报、查看日历上的下一步安排，或在地图上查找当前位置。你可以通过左右轻扫来翻阅不同的 Glance，或轻点其中一个，即可打开相应的 app 查看详情。即使没有实际上手，官方的简介也足够帮我们结合有可能的实境进行脑补了。
Glance是WatchKit app的一种可选性附加组件，从屏幕下边缘向上轻扫即可唤出，用于快速查看对应app中的即时信息，类似于iPhone通知中心里的Widget。既然是可选组件，就意味着只有某些特定形式的产品才有必要去使用，譬如对日历应用来说，可以使用Glance来显示用户接下来的安排；航旅方面的应用可以在Glance当中显示用户所要搭乘航班的登机信息；而to-do类产品则可通过Glance帮用户快速查看待办事项。
每个应用最多只能拥有一个Glance视图，所以对于航旅应用来说，无法将用户近期的所有航程各自放到一个Glance里；to-do类产品也不能同时利用多个Glance来展示多个待办清单。所有应用的Glance会以分页的形式排列，在屏幕上左右轻扫即可切换查看，就像我们在Apple的演示当中看到的那样。
在为产品设计Glance视图之前，要对其在样式与行为方面的特性有所了解：
样式每个Glance都相当于一张尺寸固定、容量有限的卡片，其中的内容是无法滚动的。如果你的app当中有太多信息需要即时呈现给用户，那么面对如此狭小且无法扩展的空间，展示哪些，舍弃哪些？优先级的判断尤其重要 – 你要确保将那些与用户查看Glance时的行为目标最为相关的信息以最简短的形式呈现出来。
确定了要呈现哪些信息之后，内容的布局同样要体现出层级。在1.5寸的屏幕空间当中，通过不同的字号、字色及分组关系来呈现出信息的优先级与逻辑关系，这也是对设计师基本功的考量。不过好消息是，Apple官方为我们准备了一整套Glance布局模板用来参考，38mm和42mm两款规格都有包括在内，并提供Sketch格式。
Glance不承载任何交互控件，例如按钮、切换、滑块等等；轻点Glance当中的任何地方都会打开相应的app。为了避免这一特性被滥用，设计规范当中特别强调Glance必须向用户提供即时的、有用的信息，不要只是为了给你的应用增加一个快速启动入口而提供Glance视图。
Notification由于与你的 iPhone 相连，Apple Watch不仅能告知时间，还能依照你的生活和日程安排，给你贴心的提醒。收到邮件、信息和来电时，你会收到即时通知，以便第一时间选择回应或者忽略。Apple Watch 时刻紧贴你的手腕，因此这种提醒及时而亲密。它会轻触你的手腕，悄悄提醒你下一个会议的时间和地点、当前的交通状况，甚至建议你何时出发。你随时可以向下轻扫进入通知中心，查看你可能错过的内容。Watch上的Notification类似于iPhone当中的通知。如果你的iPhone应用支持通知功能，那么在Watch端也会天然支持Notification。有消息进来时，系统会通过Taptic引擎的触觉反馈提示到你，如果你抬起手腕查看，系统便会将消息呈现在屏幕上。
Notification分为“普通”与“可交互”两种模式，类似于iPhone会在屏幕顶端默认呈现“普通”的通知横幅，下拉后便会将其切换至可交互模式，提供回复一类的操作，不过在Watch端，这两种模式分别叫做“Short Look”与“Long Look”。
Short Look的界面简单至极，我们无需（也无法）动手设计，形式完全由系统模板定义，包括应用图标、消息标题以及应用名称三个组成部分，全部在一屏当中显示，不支持滚动。整个Short Look只提供最少量的必要信息，以便用户在最短的时间内做出判断；而系统则会根据用户在完成判断之后做出的自然反应来进行下一步动作。如果用户认为通知信息在当前对自己不重要，最符合直觉的做法就是将手放下，不去理会，此时Watch会感知到用户的动作，并忽略掉这条信息（仍可在Watch的通知中心当中回顾）；如果用户认为通知信息是重要的，那么一时之间不会把手放下，系统会将这种“保持姿态”的行为判定为“用户产生了了解更多信息的动机”，进而自动将Short Look转换为Long Look模式，以提供更加详细的内容，包括一些相关的互动功能。
从系统收到通知，到呈现Long Look的整个流程，在我个人看来是Apple Watch在人机交互方面相当精彩的一笔，充分利用传感器的能力，根据用户的自然行为来判断在什么时候以怎样的形式展示信息，使界面与内容更加情境化的服务于用户当下的动机，而无需用户针对界面或设备本身付出认知及交互成本，这才是“智能”的味道。
回过头来继续说Long Look。相比于Short Look，内容形式自然丰富了一些，通常也会更long，所以支持滚屏了呢。虽然内容相对丰富，但仍要遵循系统提供的标准框架：顶部栏由系统提供，用于显示app的图标及名称（可自定义背景色）；最底部的Dismiss按钮同样由系统输出，用来关闭Notification；而这两者之间的区域则可以由app自己来定义，包括内容和互动功能两部分。
其中的内容部分，默认用来呈现完整的通知信息；你可以对其形式进行订制，用来显示一些静态的、辅助性的UI元素（Static Interface，静态化订制）或是更加详细和结构化的信息（Dynamic Interface，动态化订制），而不止是默认的一段文本内容。
在互动功能部分，你最多可以放置4个定制化的功能按钮。别忽视这里，它们不像我们一直以来习惯的那样给某些弹出层添加“确认”和“取消”按钮那么简单 – 在充分思考了基于怎样的情境以怎样的形式为用户提供有价值的信息之后，我们同样要考虑怎样帮助用户在这里直接完成与信息的互动，避免将操作负荷转移到iPhone当中；如果只做提醒而不提供有用的互动功能，致使用户必须频繁的拿出手机完成所有任务 – 从某种程度上讲这反而是在加重用户的负担，这样的“生态圈”还不如iPhone一个设备来的方便些。
产品形态决定设计模式在本文第二部分（“探索产品形态”）当中，我们从双向共生的角度将产品大致分为了两种模式，包括：
Watch是主互动设备，iPhone作为附属。iPhone是主互动设备，Watch作为附属。第一类产品在Watch端的姿态更加独立。用户通常会保持在Watch当中进行操作，直到完成主要任务；WatchKit app作为产品与用户的主要接口，承载着绝大部分的人机交互。对于这种模式的产品，设计重点将聚焦于WatchKit app本身（甚至可能无需为其配备Glance与Notification） – 基于产品自身在信息架构和任务流程方面的特性，结合将来有可能随着硬件演进而产生的扩展性需求，选择最合理的导航模式，尽量确保用户进入app之后通过最少量的步骤即可来到主交互界面。
在主交互界面，尝试将最核心的操作集约到一屏范围当中；对于那些与当前界面内容相关，但权重次于核心功能的操作，也不要强行追求通过当前屏幕呈现，如果空间的局限实在难以突破，我们甚至无需像在手机上那样至少提供一个“更多”作为入口。别忘记，我们可以通过Force Touch来“凭空”唤出情境化菜单。从设计的角度讲，Apple在Watch这款“极小屏”设备当中首先推出这项技术是有原因的：当x与y轴所构成的平面难以提供更多空间时，就到z轴上去找；对交互动作来说也是同理，为作用于平面的“轻点”手势增加一个纵深维度，新的可能性便随之而来。
而对于第二类产品来说，为Watch与iPhone之间的连接机制塑造即时、简约、高效的体验就成了重中之重。正如前文所述，连接机制分为两类：用户主动发起的，以及被动接受的；对应到设计模式上，则分别由Glance和Notification负责承载。对于这类产品，用户最终需要基于iPhone来实现完整的体验，所以WatchKit app的存在感会相对弱化，对某些产品而言，只提供某种最适于快速访问的内容形式以及最轻量的互动功能即可 。
这些最小化的内容及功能的存在目的是什么？我个人看来，意义就在于当用户主动发起“连接”，希望通过Glance快速了解状态信息，并发现有进一步行动的需求，但当前所处情境未必允许用户通过最适合的平台（iPhone）来完成，那么至少可以退而求其次的在附属设备上快速进行，只要功能和体验方面的削减度是在可承受范围之内。同理，我们在前文中也强调过，作为“被动连接”载体的Notifcation，在互动方面的能力也是不可忽视的，我们要确保通过Long Look视图提供与通知内容最为相关的若干基本操作，使用户在认为有必要对信息进行反馈时可以在Watch上以最小化的方式来完成，而不是无论何时都必须从口袋中掏出iPhone、解锁、找到图标并进入app才能执行。
说到这里，大家或许也会发现，就WatchKit app、Glance和Notification这三者的定位关系来看，一个特定的产品究竟属于哪种模式其实并非绝对；我们在前文当中也有提到，在某些情况下，模式很可能发生互换。理论上的框架最终还是要以特定情境中的特定产品作为依托。对于我们来说，最重要的是确保在任何一个接口模式当中提供最适于快速获取的信息以及最适于在Watch上进行的互动功能；至于用户究竟选择通过Watch完成目标，还是转移到iPhone来获取更完整的体验，则由他根据自己的目标以及所处的特定情境加以判断。
结束语本文到此也该画上一个句号了，但关于Apple Watch产品设计的话题才刚刚进入破土阶段。很快，Watch就会正式进入我们的生活，我们也将有机会在实际当中体验这款新设备。希望届时我能和大家分享更多关于Watch产品设计的实战经验，同时希望与各位就更多的相关话题进行探讨交流。
