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