文章索引

• 2. 交互（Interaction）

• 2.1 3D 触摸（3D Touch）

• 2.1.1 主屏幕交互（Home Screen Interaction）

• 2.1.2 轻压（Peek）和重压（Pop）

• 2.1.3 Live Photos

• 2.2 辅助功能（Accessibility）

• 2.3 音频（Audio）

• 2.4 身份验证（Authentication）

• 2.5 数据输入（Data Entry）

• 2.6 反馈（Feedback）

• 2.7 文件处理（File Handling）

• 2.8 启动初体验（First Launch Experience）

• 2.9 手势（Gestures）

• 2.10 加载（Loading）

• 2.11 模态（Modality）

• 2.12 导航（Navigation）

• 2.13 请求许可（Requesting Permission）

• 2.14 设置（Settings）

• 2.15 用辞（Terminology）

• 2.16 撤销和重做（Undo and Redo）

2. 交互（Interaction）

2.1 3D 触摸（3D Touch）

3D Touch 为触碰式交互增加了一个维度。在支持3D Touch 的设备上，用户通过对触摸屏施加不同的力度来实现更多的功能，譬如触发菜单、显示更多的内容或是播放动画。用户无需学习新的手势来使用3D Touch。当他们轻压屏幕并且获得应答的时候就能立即发现这一新的交互维度。

2.1.1 主屏幕交互（Home Screen Interaction）

在支持3D Touch的设备的主屏按压应用图标会触发相应的操作视图。该视图让你能够快速地执行常用的应用任务和预览有趣的信息，譬如日历应用，它能够提供创建新事件的快捷操作，同时显示日程表上的下一个事件。了解相关设计指导，请参阅Home Screen Action和Widgets。

2.1.2 轻压（Peek）和重压（Pop）

轻压允许用户使用3D Touch在当前环境上预览一个临时视图内的对象，譬如一个页面、链接或者文件。要想在支持该功能的设备上实现预览，只需用手指对应用施加一点压力，而抬起手指就能退出预览。要想打开对象来浏览更多的内容，请更重地按压屏幕直到对象放大到填满屏幕。在一些轻压视图上，你可以通过上滑来显示相应的操作按钮。譬如，在Safari打开了某个链接的轻压视图时，你可以通过上滑展开相应的操作按钮——打开链接，添加至阅读列表和复制链接。

利用轻压视图提供实时的，内容丰富的预览。理想情况下，轻压视图为该项提供足够的信息以补充说明当前任务，或者帮助你决定是否完全地打开该项。例如，预览邮件（Mail）信息中的链接，从而决定是否在Safari浏览器中打开或者分享给朋友。轻压视图一般被利用于表单视图中,提供一个行项的详细信息，从而决定是否选择该项。

设计足够大的轻压视图。设计一个足够大的轻压视图从而保证手指不会遮挡到内容。确保轻压视图能够提供足够详细的信息，以便用户决定是否按得更重来完全地打开该项。

统一使用轻压和重压功能。如果你只在某些地方使用轻压和重压，而不在另一些地方使用，用户就不会知道到底哪里可以使用这个功能，而且可能会认为你的应用或是他们的设备出了问题。

允许每个轻压视图都能够被重压。虽然轻按视图能够提供给用户他们所需的大部分信息，但如果他们想离开当前任务并转移注意力至该项时，应该允许他们过渡到重压。

避免在轻压视图中呈现按钮式元素。如果用户抬起手指去点击类似按钮的元素，轻压就会消失。

不要让同一项具备轻压和编辑菜单（Edit menu）两个功能。当一个项目同时启用两个功能时，不但会让用户感到困惑，也会让系统难以判断用户目的。了解更多指导，请参阅Edit Menus。

适当时提供操作按钮。不是每个一轻压都需要操作按钮，但这是一个为常用任务提供快捷操作的好方式。如果你的应用已经为项目提供了自定义的点击并长按（touch-and-hold）动作，那么最好在轻压里包含同样的操作。

避免为打开被轻压的项目提供操作按钮。用户一般都通过更重的按压来打开他们轻压的项目。所以，没有必要再提供一个明显的打开按钮。

不要让轻压成为唯一的执行项目操作的操作。并不是所有设备都支持轻压和重压，甚至有的用户会关闭3D触摸功能。你的应用为这些情况考虑其它触发项目操作的方式。譬如，你的应用可以将轻压的快捷操作映射到一个视图中，该视图会在点击和长按时出现。

2.1.3 Live Photos

应用可以通过支持Live Photos，并在照片中加入压感用来查看动态回忆。当你按压它们时，Live Photos死而复生，通过动作和声音再现拍照的前后时刻。了解相关设计指导，请参阅Live Photos。

2.2 辅助功能（Accessibility）

iOS 提供了大量的辅助功能来帮助失明、失聪以及其他残疾群体。大部分以UI Kit为基础的应用能够轻易地具有辅助性，让更多的用户来使用你的应用，因为你为所大众提供了平等的使用体验。

为图片、图标和界面元素提供可选择的文字标签。可选择的文字标签在屏幕上是不可见的，但是他们让VoiceOver能够通过声音描述屏幕上有什么，让失明用户能够轻易地使用导航。

相应辅助功能的偏好设置。如果你的应用使用UI Kit来实现用户界面，文字、界面元素就会自动调整至相应辅助功能的偏好设置，譬如加粗并且更大的文字。你的应用也应当在适当的时候检查并相应辅助功能的偏好设置，譬如当减弱动态效果（reduce motion）的开关被打开时。采用自定义字体的应用应该力图和系统字体的辅助特性保持一致。

测试应用的辅助功能。除了文字和动态效果的变化，辅助功能选项还能改变对比度，反转颜色，降低透明度以及更多。为那些需要这些功能的用户启用设置并观察你的应用将会变成什么样并且如何运作。

包含隐藏式字幕和口述影像。隐藏式字母帮助失聪以及重听用户明白视频中的对话和其它音频内容。口述影像为视觉受损的用户提供了关键视频内容的口头解说。

了解更多信息，请查阅iOS Accessibilty和Accessibility Programming Guide for iOS。

2.3 音频（Audio）

无论声音是你应用体验的要素或只是一个点缀，你都应该知道用户对声音有什么要求并且满足他们的期待。

用户通过音量键、静音键、耳机声控和屏幕上的音量调节滑块控制声音。非常多的第三方配件也包含声控功能。音频可以通过内部和外部的扬声器、耳机输出，甚至通过支持AirPlay或是蓝牙设备无线输出。

• 静音：用户将他们的设备调节至静音来避免被意外的声音（比如电话铃声和短信提示声）打扰。他们也想要关闭没有意义的声音，包括按键声、音效、游戏配乐以及其它音频反馈。当设备被设置成静音，只能出现被明确被打开的声音，比如媒体播放中的声音、闹铃和音频/视频信息。

• 音量：无论是使用物理的设备按键或是屏幕上的滑块，用户都希望系统的所有音量都能够被改变，包括音乐声和应用内的音效。但是铃声音量是唯一例外，它只能在没有任何声音播放的情况下被单独调节。

• 耳机：用户使用耳机来私密地听声音并且能够释放他们的双手。当用户插入耳机时，他们希望声音能够自动继续播放而不被打断。当拔掉耳机时，他们希望播放能够立即停止。

必要时自动调节不同层级的声音，但不是整体音量。为了达到更好的混合音效，你的应用可以单独调节不同层级音频间的相对音量。但是，最终的音量输出应该由系统音量决定。

恰当的时候允许音频重选路由(rerouting)。用户会经常想要选择一个不同的音频输出设备。比如，他们会想要通过客厅的立体音响、车载收音机或是苹果电视来听音乐。请支持这个功能除非你有令人信服的理由不这么做。

使用系统提供的音量视图来调节音量。音量视图（volume view）是最好的能提供调节音量的界面控件。这个视图是自定义的，包含一个音量调节滑块，甚至包含一个用来替音频输出重选路由的控件。了解实现方法，请参阅MPVolumeView Class Reference。

短音和振动请使用系统声音服务。了解实现方法，请参阅System Sound Services Reference。

如果声音对你的应用十分重要请设置音频类别。不同的音频类别允许声音被静音按钮静音、与其它声音混响、或是当你的应用在后台时播放。根据类别的含义和当前设备的音频播放情况来选择一个类别，然后将其分配给你音频对话（audio sessions）。比如，非必要情况下，请不要打断用户正在收听的来自其它应用的音乐。总的来说，尽量不要在你的应用运行时更改所属的音频类别，除非应用需要经常地录制然后播放音频。了解实现方法，请参阅Audio Session Programming Guide。

在适当时候继续播放被干扰打断的音频。正在播放的音频有时会受来自其它应用的声音干扰。暂时性干扰（比如来电铃声）被认为是可恢复的。永久性干扰（比如被Siri打开的播放列表）被视为不可恢复的。当一个可恢复的干扰出现时，你的应用应该在干扰结束时恢复音频播放（假设音频在干扰出现之前就已经开始播放了）。比如，一个在播放配乐的游戏和一个在播放音频的媒体应用都应该恢复声音的播放。当干扰发生时应用没有在播放任何音频，那么它也就不需要恢复任何对象。

让其它应用知道何时你的应用将停止播放暂时性的音频。如果你的应用可能会暂时性地干扰到其它应用的音频，那么就应该恰当地标明声音片段，从而让其它应用知道确切的恢复时间。了解实现方法，请参阅AVFoundation Framework Reference 中的AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation。

只有在有意义时才对声音控件作出反应。无论你的应用在前台还是后台，用户都能够通过应用界面以外的东西控制音频的播放，比如在控制中心（Control Center）中，或者耳机声控。如果你的应用正在一个明确与声音相关的环境下播放音频，或是连接到一个支持AirPlay的设备上，那么对声音控件作出反应是合理的。但是，你的应用不应该混淆其它应用的音频，因为它们可能会在控件被激活时播放。

不要重新定义声音控件。用户希望声音控制在任何应用都保持一致性。永远不要重新定义声音控件。如果你的应用不支持某些控件，那么只需不对它们作出反应即可。

2.4 身份验证（Authentication）

要求用户进行身份验证时应该用有价值的东西交换，比如个人化体验、获得更多功能、购买内容或者同步数据。如果你的应用要求身份验证，请保证登录流程快速简单并且低调，这样就不会减少应用的乐趣。

尽可能地延后登陆。用户经常遗弃应用因为他们在做一些有用的事前被强制登录。在强制用户前给他们一个爱上你的应用的机会。在购物应用内，允许用户启动应用后能马上浏览你的商品，然后在他们决定购买时才要求登录。在流媒体应用内，允许用户先探索和了解你能够提供的内容，然后在他们播放时让他们登录。

解释身份认证的优势以及如何注册。如果你的应用要求身份认证，在登录界面简要友好地介绍之所以要登录的原因及其优势。并且请牢记不是每个人在开始使用应用时都拥有一个账号。请确认你解释了如何得到账号，或者提供一个简单的应用内的注册方式。

展示适合的键盘来减少数据输入。比如，当要求填写一个邮箱地址时，请展示包含信息输入所需快捷键的邮件键盘窗口。

2.5 数据输入（Data Entry）

无论是点击界面元素还是使用键盘，信息输入都是一个冗长的流程。当一个应用在做一些有用的事情前要求用户一连串的输入，进而拖慢了流程，那么用户会很快感到失望，甚至会彻底地抛弃这个应用。

可能时展示选项。尽可能地提高信息输入的效率。比如，考虑使用选择器或是列表来替代输入栏，因为从一列提前设定好的选项中选择一个比打字容易。

可能时从系统中获取信息。不要强迫用户提供那些可以自动或是在用户许可内就能获取的信息，比如联系人或是日历信息。

提供可靠的默认值。尽可能地预填最可能的信息值。提供一个可靠的默认值缩短了做决定的时间从而加快了流程。

只有在收集完必需信息之后才能进行下一步。在允许“下一步”或“继续”按钮前，确保所有必要的输入框都有信息。尽可能地在用户输入之后就立马检查输入值，这样他们就能立即改正。

只要求必要的信息。只有系统运行真正必需的信息才使用必填栏。

简化值列表的导航。尤其是在列表和选择器中，必需能够简单地选择值。考虑通过将值列表按首字母排序或是其它逻辑排列，从而加快浏览和选择的速度。

在输入栏显示提示以辅助说明。当输入栏没有其它文字时，可以包含占位符文字——比如“邮件”或“密码”。当占位符文字已经足够说明时不要再单独使用标签来描述。

2.6 反馈（Feedback）

反馈让用户知道应用现在在做什么，发现下一步他们应该做什么，并且理解操作的结果。

悄悄地在你的界面中加入状态或其它类型的反馈。理想中，用户能够在不采取任何操作或是被打扰的情况下得到重要的信息。比如，当用户在邮件应用中查看邮时，状态信息被巧妙显示在工具栏上。这个信息不会和屏幕上的主要内容抢风头，但是用户在任何时候快速一瞥就能查看。

避免不必要的警告。警告是一种有威力的反馈机制，所以它应该只被用于传递重要的并且最好是需要操作的信息。如果用户看到太多包含无关紧要信息的警告框，他们很快就会学会忽略之后的警告。了解更多帮助，请参阅Alerts。

2.7 文件处理（File Handling）

用户在创建、查看和操作文件时无需思考文件系统。如果你的应用需要运行文件时，尽可能地淡化文件处理。

让用户相信除非主动取消或删除，文件会随时被保存。总而言之，不要让用户去即时保存文件。反之，在文件被打开、关闭，或是跳转至其它应用时，应该自动定时地替用户保存文件。但在某些情况，比如正在编辑一个已被创建的文件时，保存和取消的选项也是有意义的，因为它们帮助确认何时编辑的内容应该被保存。

不要提供创建本地文件的选项。用户总是希望他们全部的文件都能在任何设备上读取。如果可能，你的应用应该支持文件云储存，比如通过与iCloud类似的服务。

设计一个直观并且图像化的文件浏览界面。理想情况下，使用用户熟悉的系统文档选择器来浏览文件。如果你想设计一个自定义的文件浏览器，请确保它是直观且高效的。最好的文件浏览器应该是高度图像化的，提供了文档的视觉再现。要想加快导航速度，减少手势的使用，并且考虑提供一个添加新文件的按钮，这样用户就无需再到其它地方去创建新文档。

让用户在你的应用内就能预览文件。你可以使用Quick Look 功能让用户查看来自Keynote、Numbers和Pages的内容，以及PDF文档、图片以及某些其它格式的文件，即使你的应用并没有真正打开它们。请参阅Quick Look。

合适时，与其它应用共享文件。如果有意义，你的应用可以通过document provider extension与其它应用共享文件。你的应用也可以让用户浏览和打开来自其它应用的文件。了解实现方法，请查阅Document Picker Programming Guide。

2.8 启动初体验（First Launch Experience）

应用的启动时间是你接触新用户并与老用户再次连接的第一个时机。请设计一个快速、有趣并有教育意义的启动体验。

提供启动画面。启动画面在应用打开时出现，在加载应用初始内容的同时，让人感觉你的应用的响应速度很快。因为这个画面很快就会被应用的首屏替代，所以它应该尽量与首屏相似，除非出现可定位的文字和可交互的元素。了解更多，请参阅Launch Screen。

选择合适的方向启动。如果你的应用同时支持竖屏和横屏模式，那么应该以设备目前的方向启动。如果你的应用只在一个方向运行，那它只能在相同方向启动并在需要时允许用户旋转设备。除非有迫不得已的原因，否则处于横屏模式的应用正确地选择方向，无论Home键是在左侧还是右侧。了解更多信息，请参阅Layout。

快速使用。避免出现延迟用户使用应用时间的启动画面、菜单和说明。反之，允许用户快速进入应用内。如果你的应用需要教学或是介绍步骤，为用户提供一个跳过的选项并且不要对老用户展示这些。

提前设想用户可能会需要的帮助。经常主动地考虑用户何时会遇到麻烦。比如，一个游戏，能够在暂停或是角色很难升级时提供一些诀窍。当用户错过启动画面的内容时，允许他们之后重新观看教程。

只在教程中展示最关键的内容。虽然为新用户提供引导没错，但是教学不能成为优秀的应用设计的代替品。更重要的是，确保你的应用是直观的。如果你的应用需要过多的引导，那么请重新审视你的设计。

让学习变得有趣而且易于学习。通过操作来学习比阅读一长串说明来的更有趣和有效。 在上下文环境中，通过动画和可交互性循序渐进地教导。避免展示看起来似乎可交互的屏幕截图。

避免在最开始要求用户设置信息。用户期待应用马上工作。为大多数人设计你的应用，然后让余下少部分需要不同配置的人自己调整参数来满足他们的需求。尽可能地，从设备设置和默认中获取设置信息，或者通过同步服务，比如iCloud。如果应用一定要求设置信息，那么在最初在应用内提示用户，然后允许用户稍后在应用设置中修改。

避免展示应用内的接受许可协议和免责声明。在你的应用被下载之前直接在苹果商店展示接受许可协议和免责声明。如果你必须将这些东西放在你的应用里，那么以和谐融入它们，以避免干扰用户体验。

在你的应用重新启动时恢复之前的状态。不要让用户重新操作来回到之前的应用定位。保存并且复原应用的状态，这样用户就能从他们上次离开的位置继续。

不要太快或是太频繁地要求用户对你的应用评分。太快或是太频繁地要求评分会让用户恼怒，并且减少最终收到的有用反馈的数量。为了鼓励考虑周到的反馈，在要求评分之前，给用户足够的时间直到他们形成对应用的看法。总是提供跳出评分提示的选项，并且永远都不要强迫用户对你的应用评分。

不要鼓励重启。重新启动耗费时间并且让你的应用看起来即不可靠又不可用。如果你的应用出现储存或者其它问题，导致它无法运行只能系统重启，那么你应该解决这些问题。

2.9 手势（Gestures

亲！小编正在上传资源中，请稍等。