精简版 | iOS人机交互指南 —— 交互规范

1.3D Touch

3D Touch为基于触摸的交互提供另外一个维度。通过不同的屏幕压感来触发多种功能。

首页屏幕的交互

在系统屏幕上按下支持3D Touch应用的图标触发动作菜单，这个菜单可以展示应用定义的通用任务和展示有趣的信息。关于设计指导可参考Home Screen和Widgets

Peek和Pop

Peek让用户可以通过3D Touch来预览项目，例如一个页面、链接或文件。如果要打开项目或查看跟过信息，可再原来基础上重按来Pop（弹出）出页面。在某些Peek的菜单中可以通过上划来显示相关的操作。

• 通过Peek来提供生动的内容预览。理想状态下，Peek提供足够的信息来表述当前任务，或者帮助用户是否需要全屏打开这个项目。
• 设计足够大的Peek视图。主要为用户提供足够的信息来决定是否要查看项目。
• 采用一致的Peek和Pop操作。如果你在一些地方使用这些操作，但另外一些地方没有使用的话，可能会对用户造成迷惑，没有遵循一致性原则。
• 允许每个Peek都Pop出页面。Pop出的页面内容应该和Peek展示的内容保持一致。
• 在Peek页面中避免使用类按钮元素。因为用户离开屏幕去点击按钮时，Peek就会消失了。
• 不要同时出现Peek和编辑菜单。因为这样会让用户搞清具体的意图。相关的知道可参考Edit Menus
• 在合适的时候提供操作按钮。
• 避免提供一个打开Peek项目的操作按钮，因为用户可以通过深压来打开他们正在预览的项目。
• 不要把Peek作为展示项目操作的唯一方式。因为不是每个设备都支持Peek和Pop，而且有些用户可能会关掉3D Touch。应该提供其他的方式来触发这些操作。

2.辅助功能

iOS为视觉缺失、听觉缺失或其他残疾的用户提供可扩展的辅助功能。

• 为图片、图标和界面元素提供可供代替的文本。可供代替的文本不会显示在屏幕上，但可以让VoiceOver为用户描述屏幕上的内容。
• 响应辅助中的偏好设置。如果你的应用使用UIKit来实现界面、文本和界面元素的话，应该自动能响应辅助中的偏好设置，例如粗体或更大的字体。
• 测试你的应用对于辅助功能的支持程度。当用户打开了辅助功能之后，测试下你的应用长什么样或操作起来怎么样。
• 包括匹配的字幕和声音描述。匹配的字幕可以让失聪人士或听力障碍者了解对话你饿哦热那个。而声音则为视觉缺失的人提供更多的信息。

** 3.声音**

不管声音是不是你应用的重要组成部分，你都应该了解用户对于声音行为的预期。用户可以通过音量按钮、静音开关、耳机操作和屏幕上的音量滑块来操作声音。声音可以通过内置或外置的扬声器、耳机万甚至支持AirPlay或蓝牙的设备进行播放。

• 如果需要的话，可以自动调节音量。但不要影响全局的音量。应用内可以自信调节音量来组成印个混合的声音输出。
• 允许更改声音输出设备。
• 通过系统自带的音量调节视图来调节音量。这个视图是可定制的，包括一个音量控制滑条甚至可以更高声音的输出设备。更多实现细节可参考MPVolumeView
• 通过系统声音服务来处理短声音和振动。实现细节可参考System Sound Services
• 对声音进行分类。根据用途、设备声音的状态来挑选合适的种类，并加入到声音队列中。一般来说，在应用运行的过程中，最好不要改变类型。更多实现细节可参考Audio Session Programming Guide
• 种类包括：Solo ambient、Ambient、Playback、Record、Play and record。
• 一个打断事件结束后应该恢复声音的播放状态。有时当前应用的播放状态可能会被其他应用打断。临时的打断例如来电。
• 当你的app播放完临时的声音时，应该让其他应用知道。更多实现细节可参考AVFoundation中的AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation
• 只要当必要时才响应声音控制。用户可以在应用外控制声音的播放，例如控制中心或耳机的控制。
• 不要自定义声音控制的内容。用户期望声音控制的行为应该与所有应用保持一致。不要重新定义声音控制的用途。

** 4.验证**

只有在涉及重要内容时才向用户请求验证，例如定制界面、接入额外的功能、购买内容或者同步数据。如果你的应用需要验证，应该确保整个过程是快速简
单。

• 尽可能延迟登录。如果在用户还没做任何事之前就强迫用户进行登录，可能会导致用户流失。应该用户尽早了解你的商品，当他们决定要购买的时候才要求登录验证。
• 解释验证的用处以及如何登录服务。在登录界面现实友好简短的描述。另外不是所有用户都有账号，确保能告诉用户如何获得新账号和登录。
• 通过现实合适的键盘来减少数据的输入。

** 5.数据录入**

• 尽可能地提供选项。采用列表或拨轮取代输入框
• 尽可能从系统中获取信息。尽可能降低对用户输入的要求。
• 提供合理的默认值。减少用户数据录入的过程。
• 收集到指定数据后才允许进行下一步操作。通过按钮的状态来标识可用性。
• 动态校验数据的合法性。在用户输入内容之后马上进行校验，方便用户进行修改。
• 必要时才要求输入内容。
• 使用数据列表提供导航式选择。通过字母或其他方式排列数据，方便用户快速找到对应的选项。

** 6.反馈**

注意把握反馈的有效性，关键在于用好反馈，而不是滥用反馈
反馈让用户了解应用当前在进行什么操作，发现他们接下来可以进行什么操作，以及理解操作的结果。

• 不打扰地地整合状态和其他类型的反馈到你的界面。
• 避免无必要的警告（框）。合理的使用警告框，不然当应用需要给用户提醒重要信息时，将会被忽略。

触觉反馈

• 通知。变体：成功、警告和失败。用途：指示任务或动作的完成情况，已完成、失败、警告等。
• 碰撞。变体：轻、中等、重。用途：提供物理的借喻来补充视觉内容。
• 选中。用途：指示出选中项的动态改变。

使用视觉反馈之外的，触觉或听觉反馈

• 谨慎使用触觉反馈。过度使用会削弱有意义反馈的效果。警告框的使用也符合这个规则。
• 一般来说，对用户发起的操作提供触觉反馈。
• 不要重新定义反馈的类型。遵循一致性原则。
• 合理地结合视觉效果和触觉反馈。在动作与结果之间提供两者更深层次的联系。动画切实符合用户的感受。
• 不要依赖于单一的交流模式。同时使用视觉和听觉的暗示来确保用户不会错过重要信息。多元化触觉反馈的方式。
• 当视觉反馈阻塞时使用触觉反馈。
• 开始反馈之前准备一切。触觉反馈之前需预先准备好系统，否侧可能会出现延迟情况，无法与用户的操作进行关联。
• 使用触觉反馈和声音进行同步。

7.文件处理

应用应该让用户在无需思考的情况下就可以进行文件的创作、阅读、管理等操作。

• 经常保存文件，除非用户取消或删除。不要用用户明确地进行保存，而应该提供固定间隔的自动保存。
• 不要提供创建本地文件的选项。如果可能的话，提供基于文件云存储服务。
• 提供直观和图形浏览文件的界面。最好使用跟系统类似的文件管理界面。
• 让用户无需离开你的app也可以进行文件预览。你可以通过Quick Look在自己的应用内预览Keynote/Numbers/PDFs/图片等
• 如果可以的话，允许分型文件到其他app。可通过Document provider extension分享自己的文件到其他应用。可通过其他应用来打开文件，参考这里

** 8.首次加载的体验**

设计一个快速、有趣和教育性的启动页。

• 提供启动页。应该给用户留有印象——应用是快速和热情的，应该尽快地进入到应用的首页。Launch Screen
• 在合适的方向上加载。为不同的旋转方向提供不同的启动界面方案。更多可参考Layout
• 快速进入到操作界面。避免让用户等待太久。
• 预料到可能需要的帮助。当暂停或角色创建过程中，不时为用户提供有用的建议。让用户可以回放整个过程去检阅他们第一次漏掉的信息。
• 辅导中提供必要的说明。最重要的是让你的应用符合用户直觉的认识。如果需要太多的引导，那么应该重新审视下你的应用设计。
• 让学习变得有趣和可被发现。做一些有趣和高效的事情比阅读输入要有效。通过动画和互动来逐步教育用户。
• 避免要求用户提供安装信息。用户可以通过设置来满足他们的需求。可以考虑从iCloud中同步过来。如果真有必要让用户选择，应该在首次加载时询问用户，并可以在设置中进行修改。
• 必要在应用内显示许可证明和免责声明。应该在应用下载之前就在AppStore中显示。
• 重启应用时应该恢复之前的数据。不要让用户一步步操作回到之前的位置。恢复到用户离开应用时的状态。
• 不用过于快或频繁地要求用户去评价应用。不要强迫用户去评价你的应用。
• 不要鼓励重启应用。

** 9.手势**

用户希望在系统和每个应用中使用一直的手势。遵循一致性原则

• Tap: 触发一个控制或选择一个项目
• Drag:将一个元素从一边移动到另一边，或者在屏幕上拖拽一个元素
• Flick：滚动或快速的Pan
• Swipe: 一只手横划出现操作菜单，或者在ipad上四只手同时滑动切换应用。
• Double tap: 缩放和居中内容或图片，或者还原。
• Pin: 双指张开放大，合拢缩小。
• Touch and hold: 在文本输入框中通过放大镜显示鼠标的位置。
• Shake: 开始撤销或重做。

原则：

• 作为一般原则，使用标准的手势。游戏或沉浸式引用使用自定义手势可以增加乐趣。而其他应用应该使用标准的手势。
• 不要阻塞系统级手势。例如呼出控制中心或通知中心。
• 避免使用标准手势来触发非标准的操作。滥用会妨碍用户的理解。
• 提供更便捷的手势来补充，而不是取代，基于界面的导航和动作。如从屏幕边缘横划可以返回上一页，或者在iPad上通过四指聚拢手势回到系统界面。
• 使用多指手势来增加某些app的体验。不一定适合所有app。不过在类似游戏中可以通过多指操作提供更为方便的操作。

10.加载

当内容加载的时候，空白或静态的页面会让应用看起来像是冻结，会让用户感到迷惑甚至离开应用。

• 加载时候要更加清晰地现实出来。至少提供活动标识来告诉事情正在发生。更好的方式是，提供明确的进度条告诉用户还需要等待多久。
• 利用加载时间来教育用户或提供有趣的内容。可以考虑提供操作提示、视频或者有趣的图画。
• 定制加载页面。通过自定义的动画或元素来给用户更好的体验，不过前提是要匹配你的应用。
• 尽可能显示内容。不要再界面显示出来前就加载数据，相反应该马上显示界面，然后通过文本、图像、动画来告诉用户内容正在加载。

可参考Progress Indicators

** 11.模态**

模态视图会停止用户当前做的事情，除非他们完成任务。Action sheets、alerts、activity view 提供了模态的使用。模态视图可以覆盖屏幕一部分或全部。

原则：

• 尽可能少的使用模态视图。用户更愿意非线性地操作应用。尽可能在非常有必要的时候使用模态视图，例如需要用户关注某系信息、必须完成某个任务、或者保存重要的数据。注意平衡
• 提供明显和安全的方式退出模态任务。确保用户了解取消模态视图的结果。把重要信息用用户可以接受的方式传到给他，首要注意的是不要滥用
• 让模态任务尽可能地简单、简短和聚焦。模态视图可以让用户无需记住原路返回的路径。除了完成任务外，避免使用Done按钮。
• 如果可以的话，通过标题来阐述当前任务。你也可以通过文本来进行更详细的描述。
• 保留警告（框）用于传达重要和具有争议的信息。让用户感觉通过警告框打扰他们是合适的。参考Alerts
• 服从通知的偏好。用户通过系统的设置里面来统一管理接收的通知。
• 不要在popover视图上现实模态视图。更正确的做法是关掉popover视图后再显示模态视图。
• 让模态视图跟你的应用协调一致。如采用一致的导航栏结构。
• 选择一种合适的模态样式：
  • 全屏：承载相对复杂的任务。
  • 页面（Page sheet）：一般用于在较大设备横屏的情况中，例如iPad。用于处理相对复杂的任务。
  • 表格（Form sheet）：屏幕居中显示。但要确保键盘出现后依然可用。一般用于手机用户信息。
  • 当前上下文：覆盖父视图
• 选择合适的切换效果来展示模态视图。在应用内对模态视图采用一致的切换方式。更多实现可参考UIViewController、UIPresentationController

12.导航

导航应该是自然和熟悉的。但不要让用户脱离内容本身。

有三种导航的类型

• 层级导航。每屏做出一个选择，知道你到达目的地。系统中的设置和邮件就是采用这种导航类型的。
• 平级导航。在多个内容目录下进行切换。Music和AppStore就是采用这种导航类型的。
• 内容驱动或实例驱动导航。内容自由的切换，内容本省定义自己的导航。游戏、书籍和其他沉浸式应用采用这种导航类型。
  一些应用会综合使用多种导航类型，例如在平级导航中的每个内容使用层级导航。

原则：

• 总是提供清晰的路径。应该让用户知道当前在应用的什么位置，以及如何到达目的地。让用户觉得是可控的。不管采用什么样的导航类型，重要的是要符合逻辑、可预知和容易理解。一般来说，每个页面提供给用户一种路径。如果需要提供多种内容，可考虑通过Action Sheets、Alerts、Popovers和Modality来承载。
  • 设计的信息结构可以快速和容易到底用户想要的内容。这样的信息结构要求尽可能少的点击、滑动和屏幕的切换。
  • 使用触摸手势来时得操作更加流畅。
  • 使用标准的导航元素。遵循一致性原则。根本原因在于降低用户的学习门槛。除非能提供更好的体验就另当别论。
  • 通过导航栏来承载层级结构的数据。详细的说明参考Navigation Bars
  • 通过Tab bar来承载不同内容或功能的目录。Tab bar可以让用户在不同内容之前进行快速切换。详细的说明参考Tab Bars
  • 当你需要多个页面来承载相同类型的内容时，使用Page Control。系统内的天气app就是通过page control来现实不同地方的天气情况。详细的说明可参考Page Controls

注意：Segmented Controls和Toolbars没法使用导航。可以使用Segmented control来组织不同类型的信息。可以使用Toolbar来对当前内容提供不同的交互操作。

** 13.向用户请求许可**

授权之后应用才能获取到用户的私人信息，包括当前的位置、日历、联系人信息、提醒和照片.
询问的内容包括：是否接收通知、是否使用数据、使用定位功能许可等。

• 只有当你的应用确实需要时才向用户要求个人数据。例如当使用到位置跟踪功能时才询问用户。
• 如果没有明显标记在哪里使用的话，解释为什么需要这些信息。尽量以简短和友好的方式。
• 当需要用到时，在加载过程中询问许可。
• 不要就非必要的情况下，询问位置许可。接入位置服务时线检查系统地位置服务是否可用。尽可能延迟对用户的请求和警告。关于定位的实现可参考Location and Maps Programming Guide

** 14.设置 **

成功的app都是对用户友好的同事，提供更方便的方式去调整内容。当你设计的应用符合大多数用户的预期，可以减少对设置的依赖。

• 通过系统来获取你想要的信息。当涉及到用户、设备、环境等信息时应通过系统来获取这些信息而不是询问用户。
• 仔细考虑设置选项的优先级。首页可以放置经常改变的选项。二级页面可以放偶尔变化的选项。
• 如果合适的话，提供具体的路径来设置。通过按钮自动跳转到相应的位置。可参考Settings Launch URL和UIApplication
• 在设置里面放置不常变化的选项。参考Implementing an iOS Settings Bundle在Preference and Setting Programming Guide

** 15.术语**

• 使用熟悉的，可理解的单词和句子。避免使用缩略词或技术术语。
• 保持界面上的文本清晰简洁。
• 避免使用类似第一人称的写法。避免使用我、我们、我们的工作等。
• 争取使用轻松友好的基调。可以偶尔使用下你或你们来称呼用户。
• 小心地使用幽默手法。幽默在不同文化中的效果可能不一致，要谨慎使用。
• 使用关联和一致的语法和意境。使用与平台一致的语言，避免在iPad上现实iPhone的字样。
• 准确地引用日期。一般来说日期应该反映不同的时区。
• 辨认出交互元素。用户应该可以快速的了解到元素是干什么用的。对按钮等交互元素进行命名时，使用动词，例如联系、发送、增加等。

** 16.撤销和重做**

很多应用允许用户通过摇一摇设备来进行撤销或重做的操作。

• 简单明了地描述撤销和重做操作。文本里面应该描述哪些内容被撤销或重做。可以通过“撤销XXX”来进行描述。
• 如果你使用摇动手势来进行撤销和重做，那避免使用这个手势来进行其他操作。虽然该你可以为一个摇动的手势提供多种用途，当你可能会造成用户的迷惑。
• 节俭地提供撤销和重做阿牛。提供多种方式来处理同样的操作可能会迷惑用户。
• 只在当前上下文提供撤销和重做的操作。应该针对的是当前的内容，而不是其他。

实现的细节可参考Undo Architecture