iOS 10设计规范(二):交互 Part 1

3D Touch

3D Touch提供了一种新的基于按压的交互方式。在支持的3D Touch的设备上,用户可以通过用力按压来获得新的功能。这时候,App会给出一个展现更多内容的菜单,或者播放一段动画。

桌面上的交互

在桌面上,对着APP的图标重按时会出现一个操作列表,让用户可以快速进入APP中的常用功能或者浏览有用的信息。比如说,在日历图标上重按后,可以快捷地新建日程,也可以显示日程中的下一个事项。

轻压和重压(Peek and Pop)

Peek(轻压)能让用户通过当前环境之上的临时窗口来预览一个对象,比如预览页面、链接、文件。用手指稍微重按某个对象,就可以实现Peek功能(在该对象支持Peek功能的前提下)。抬起手指,则退出Peek界面。

如果想要打开这个对象浏览更多细节,稍微加重按压该对象的力度,就会弹出全屏窗口,这个动作称为Pop(重压)。

在某些Peek窗口中,用户上滑后可以看到更多的相关操作。比如,当用户在Peek某个Safari中的链接时做了上滑动作,则可以看到「在新标签页中打开」、「加入阅读列表」、「拷贝」三个选项。

  • 使用Peek功能提供实时、丰富的预览。理论上,Peek可以提供足够的信息辅助完成当前目标,或者帮助用户决定是否要完整地浏览这个对象。比如,在邮件中先预览某个链接,再决定是否要在浏览器中打开,或者要不要分享给朋友。Peek常被用于表格中,这可以提供一个行项的详细内容。
  • 预览窗口要设计得足够大。这样手指才不会挡住内容,且内容应当有丰富的细节,这样用户才能决定是不是要更用力按,打开全屏浏览(Pop)
  • APP应该始终提供Peek和Pop功能。如果你在某些地方支持,某些地方不支持,用户可能认为你的APP或者他们的手机出了毛病。
  • 让每一个Peek操作后都可以Pop。虽然Peek可以提供用户需要的大部分信息,但一旦他们决定专注浏览这个对象时,你应该让用户执行Pop操作。Pop操作后打开的页面,应该要跟普通点击打开的页面一致。
  • 在Peek操作中,尽量避免使用类似按钮的的界面元素。如果用户抬起手指去点击这个像按钮的元素,Peek界面就会消失。
  • 不要为同一个对象同时提供「Peek」和「长按进入编辑状态」两个功能。因为这会让用户混乱,系统也很难判断用户的意图。
  • 在合适的时候,为Peek提供「上滑后展现更多操作项」功能。并非所有Peek都适用,但这是个缩短操作路径的好办法。如果你的APP已经有了长按某个对象后弹出操作项的功能,不妨试试在Peek的时候提供同样的操作项。
  • 不要在上滑后的操作项中提供「打开」功能。用户更用力按压就可以进入了,不需要多此一举。
  • 不要把Peek作为操作项的唯一触发方式。因为并非所有硬件都支持Peek and Pop,一些用户也可能关闭3D Touch功能,所以应该在长按后也提供相同的操作项。

辅助功能

iOS为视觉、听觉和其他方面的残障人士提供了大范围的无障碍辅助功能。大多数基于官方组件库的APP可以低成本实现辅助功能,让更多人在使用你APP时获得无差别的体验。

为照片、图标和其他交互元素提供可替代的文本标签。这些替代标签在屏幕上是不可见的,但是他们可以通过VoiceOver(设置 - 通用 - 辅助功能)描述出屏幕上的内容,让视觉障碍人士使用。

应该响应系统的辅助功能设置项。如果你APP界面是使用官方组件库制作的,文本和UI元素会自动响应系统设置(如加粗、大字号等)。APP还应该在特定的时候检查并响应系统设置,比如「减弱动态效果」。APP中的自定义字体也应该遵从辅助功能的设置项。

测试时要试试辅助功能。除了文本和动效的变化,辅助功能还可以设置对比度、反转颜色、降低透明度等。尝试打开这些设置项看看你的APP用起来如何。

视频中别忘了字幕和语音描述。字幕可以让失聪和听力障碍人士了解视频里的对话和其他音频信息。语音描述让视障人士也能了解关键的视频内容。

声音

无论声音在你APP中是重要部分还是锦上添花的部分,你都需要知道用户对声音的预期是什么。

用户常常通过音量按钮、静音开关、耳机控制器和屏幕上的音量滑块来控制声音。很多第三方配件也有了声音控制功能。声音会通过内置听筒、扬声器、耳机和AirPlay/蓝牙设备输出。

  • 静音状态。为了避免被铃声、新消息提示音等打扰,用户会把设备置为静音,被静音的也包括按键音、音效、游戏内声音等辅助音。当设备被置为静音的时候,只有几种明确要播放的场景可以发出声音,比如音视频播放器、闹钟、语音/视频消息。
  • 音量。无论用户是用设备上的物理按键还是屏幕上的滑块来调整音量,他们预期的是整个声音系统统一变化,包括音乐、APP内音效等。唯一例外的是铃声音量,它是单独调节的。
  • 耳机。使用耳机,用户可以比较隐私地听声音,也可以解放双手。当用户把耳机插好,就预期着声音自动地无缝切换到耳机中。当拔掉插头,用户预期音频和视频立即暂停。

你的APP可以独立调整跟自己相关的音量,但最终的输出音量永远还是受系统控制。

用户经常想使用不同的设备(比如客厅里的立体声设备、汽车音响,或者Apple TV)来输出声音。除非有特别原因,应该支持这种切换能力。

最好使用系统提供的音量控制组件让用户调整音量,这个组件支持自定义,可使用音量控制滑块、声道选择等。

短音和振动等功能,建议使用系统自带的声音服务。

如果声音是APP中的必要元素,给声音分到某个特定类别中。不同种类的声音中:有的可以被静音键静音,有的可以跟其他声音混在一起,有的可以在后台继续播放。比如说,一般情况下不要让其他APP打断用户正在听的音乐。另外,除非APP要先录音、再回放,否则最好避免在APP运行中改变声音的类别。

恰当的情况下,当声音在播放中被打断后应自动恢复。有时候,正在播放的声音被其他APP打断了。一些临时的打断(比如来电),用户期望打断结束后会恢复到打断前的音频状态;一些永久的打断(比如siri开始播放音乐),用户就不期望要恢复。需要强调的是,只有在打断发生时,正在播放的音频才会被恢复。比如用户正在玩的游戏和正在听的音乐,在打断结束后应该恢复,而当时没有使用的APP不会变化。

如果你的APP有可能临时打断其他APP,当打断结束后,要让其他APP知道,以便于恢复。

只有在有意义的情况下响应声音控制命令。用户可以在你APP界面之外的地方对声音发起控制,比如用耳机、控制中心。无论你的APP是在前台还是后台,只要它正在播放声音(也包括用AirPlay连接其他设备在播放),都应该响应。此外,若用户操作其他APP播放声音,你的APP不能阻止。

不用赋予声音控制功能新的用途。用户预期是通过声音控制模块在所有APP中控制声音。永远不要给用户的声音控制行为做出其他定义。如果你的APP不需要在声音层面响应用户的控制操作,那就不要响应。

账号验证

只有在你能提供价值的情况下,才要求用户做账号验证操作,比如个性化体验、使用高级功能、购买内容、同步数据。如果你的APP需要用户验证账号,要保证登录过程简单快捷,这样才不会破坏用户体验。

尽可能把登录模块置后。当用户还没开始做有用的事情前就被强迫要求登录,用户往往会放弃。先要给用户爱上你APP的机会,再让他对你付出承诺。在电商APP类中,让用户先浏览你的商品,只有在他们要支付的时候再要求登录。在信息消费类APP中,先让用户浏览内容,让他们知道登录后你能提供什么东西。

解释清楚账号验证这步操作的好处,在也告诉用户怎么才能注册。如果你的APP需要做账号验证,在登录界面用一段简短而友好的内容告诉用户照做的好处。另外,要记住并不是每个用户一开始就有你的账号,要记得解释清楚怎么获取新账号,或者在APP内给一个简单的方法登录。

要给出合适的键盘,降低输入成本。比如说,当你要求用户填写邮箱时,应该选择包含了快捷输入键的邮箱键盘。

来源:

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证

本文首发于Why·Liam·Blog (https://blog.naaln.com),版权所有,侵权必究。

本文永久链接:https://blog.naaln.com/2016/07/ios-10-design-2/