iOS 人机交互指南

Apple 官方iOS人机交互文档,目前还没有官方的中文版,因此尝试翻译成中文,让中文世界的设计者也能一睹Apple的设计理念,翻译过程中我尽量保证中文含义保持和英文原文相同,尽可能的原汁原味的还原Apple的本意。

iOS设计主题(iOS Design Themes)

作为一名应用程序设计师,你将有机会打造一款能够荣登 App Store 排行榜首的非凡产品。为了达到这一点,你需要满足用户对应用质量和功能的高期望值。

iOS 与其他平台不同的三个主题:

  • 清晰(Clarity):在整个系统中,文本在各种尺寸上都清晰可辨,图标精确而清晰,装饰的元素微妙且恰当,并且设计灵感的激发完全来自于对功能的敏锐关注。负空间,颜色,字体,图形和界面元素巧妙地突出重要内容并传达其包含的交互性。

  • 遵从(Deference):流畅的动效和清晰美观的界面可以在不干扰用户的情况下,帮助人们理解应用的内容并与之互动。内容通常填满整个屏幕,而半透明和模糊通常暗示着在视图之下有更多的内容。最小程度的使用边框、渐变和阴影可以使界面轻盈通透,同时可以确保内容处在首要位置。

  • 深度(Depth):明晰的视觉层和逼真的动效传达内容的层次结构,赋予其活力,并促进用户对其的理解。易于发现和触发的入口提高了用户使用过程中的愉悦感,并且能够在不丢失上下文的情况下开启新的功能或进入更深层次的内容,让用户清晰的知道自己所处的位置。因此在用户浏览内容时,清晰流畅的过渡效果可以提供一种深度感。

设计原则(Design Principles)

为了最大限度地提高用户影响力和覆盖面,请在考虑应用特性时牢记以下原则。

美学完整性(Aesthetic integrity)

美学完整性代表了应用程序的外观、行为与其功能结合的完美程度。例如,一个帮助人们执行严肃任务的应用程序可以通过使用微妙且不显眼的图形,标准的控件和可预测的行为来保持用户的专注。另一方面,沉浸式应用程序,例如游戏,可以设计一套令用户感受到乐趣和兴奋感的迷人外观,并同时鼓励用户在应用中探索和发现。

一致性(Consistency)

一款遵循一致性原则的应用程序可以使用系统提供的标准界面元素,使用易于理解的图标、标准的文本样式和统一的措辞等方式来实现的标准化和规范化。该应用程序以用户期望的方式整合了功能和行为。

直接操作(Direct Manipulation)

对屏幕内容的直接操作可以有效地吸引用户的注意力并且能够帮助用户理解自己的行为。用户在旋转设备或使用手势影响屏幕内容时就会需要对内容进行直接操作。通过这些操作,他们就可以直观的了解行为带来的反馈结果。

及时反馈(Feedback)

及时的反馈能够确认用户的行为并且显示行为后的结果,以使得用户能够了解当下的情况。内置的iOS应用程序可以响应每个用户操作并提供可以被感知的反馈。轻触点击时应用会突出显示参与交互的元素,进度指示器传达了一些需要长时间运行的任务的实时状态,动画和声音则有助于阐明操作的结果。

隐喻(Metaphors)

当应用程序中的虚拟对象和操作逻辑所表示的含义与用户以往所熟知的经验一致时(不论是来自真实还是数字世界的经验),学习这款应用程序往往变得更快速和简单。隐喻在iOS系统中起到了至关重要的作用,因为人们需要通过物理的方式来和屏幕进行交互。用户可以将某个视图移开以浏览该视图下面的内容,也可以拖动或者滑动内容,同时还能够切换开关,移动滑块,并滚动选择器的值,甚至可以像翻阅纸质书一样翻阅书籍和杂志。

用户控制权(User Control)

在整个iOS系统中,用户(而不是应用程序)拥有最高控制权。应用程序可以对一个用户行为给出建议方案或者对其即将造成的危险后果进行警告,但是替用户做决策通常是不可取的。一款优质的应用程序能够在用户控制和避免出错之间找到完美的平衡。应用程序可以提供易于理解的交互元素,可预测的交互结果,为具有破坏性的用户行为提供二次确认以及允许用户轻松取消操作(即使它们已经在进行中)等方式来让用户感觉到应用程序始终在他们的掌控之中。

用户界面基本要素(Interface Essentials)

大多数iOS应用程序都是利用UIKit的组件构建的,UIKit是一个定义通用界面元素的编程框架。这种框架使得应用程序在整个系统中实现一致的外观,同时允许开发者进行高水平的自定义。UIKit元素是灵活且被人熟知的。它们具有适应性,使您能够在任何iOS设备上设计出看起来很棒的应用程序,并在系统引入外观更改时自动更新。 UIKit提供的界面元素分为三大类:

:告诉用户当下所处的应用程序中的位置,提供导航,并可能包含用于启动操作和传递信息的按钮或其他元素。

视图:包含用户在应用程序中所看到的主要内容,例如文本,图形,动画和交互元素。视图可以启用滚动,插入,删除和排列等行为。

控件:触发行为并传递信息的工具,例如:按钮,开关,文本字段和进度指示器。

除了定义iOS界面外,UIKit还定义了您的应用程序可以采用的功能。例如,通过此框架,您的应用可以响应触摸屏上的手势并启用绘图,辅助功能和打印等功能。

iOS也与其他编程框架和技术紧密集成,如Apple Pay,HealthKit和ResearchKit,使您能够设计出功能非常强大的应用程序。


应用框架(App Architecture)

辅助功能(Accessibility)

iOS为视力丧失,听力损失和其他残疾的用户提供广泛的辅助功能。大多数基于UIKit的应用程序都可以轻松访问,帮助更多人使用你的应用程序,同时为所有人提供同样引人入胜的体验。

为图像,图标和界面元素提供替代文本标签。替代文字标签在屏幕上不可见,但它们让VoiceOver可以直观地描述屏幕上的内容,使视力障碍人士更容易使用导航。

响应辅助功能的偏好设置。如果你的应用程序使用UIKit实现其用户界面,则文本和界面元素会自动适应某些辅助功能的偏好设置,例如粗体和大文本。应用程序还应该在适当的时候检查并响应辅助功能的偏好设置,例如系统开启减弱动态效果选项时。采用自定义字体的应用程序应该尽量匹配系统字体的辅助功能偏好设置。

使用辅助功能测试你的应用。除了文本和动效更改外,辅助功能选项还可以更改对比度,反转颜色,降低透明度等。启用这些设置,然后观察应用程序的外观和功能行为能否良好的运行。

包含隐藏式字幕和口述影像。隐藏式字幕允许失聪和听力障碍者在视频中获取对话内容和其他声音内容。口述影像为视障人士提供一些对视频的重要内容的语音解说。

使用足够的颜色对比度。应用程序中的对比度不足会让每个人都难以阅读内容。例如,图标和文本可能与背景混合在一起。在线颜色对比度计算器可帮助您准确分析应用中的颜色对比度,以确保其符合最佳标准。力争最小对比度为4.5:1,尽管7:1是首选,因为它符合更严格的无障碍功能标准。

加载状态(Loading)

当内容加载时,空白或静态屏幕可能会使应用程序看起来像卡顿或者出故障了,从而导致用户会容易误会和感到沮丧,并可能导致人们放弃使用你的应用。

在应用进行加载时提供明确的加载说明。至少,要显示一个能够传达正在加载含义的加载器。如果想要做到更进一步,那么可以显示加载的精确进度,以便用户可以判断他们需要等待多长时间。

尽可能快显示出内容。不要再还没有跳转到用户期望的目标页面之前就提示正在加载内容。应该立刻跳转到目标页面,并在该页面使用占位符文本、图形或者动画来告诉用户内容还未加载完成。并且在内容加载完毕时,用说加载出来的内容来替换当前的占位符。如果可以,应该尽可能的在后台预加载即将展示的内容,例如在播放动画时或者用户正在跳转导航或者菜单时。

通过给用户提供指导或者娱乐来消磨加载时间。可以考虑在加载过程中加入有关于游戏的玩法,娱乐视频或是有趣的占位图等元素。

自定义加载状态。虽然系统提供的标准加载空间通常是能够正常运行的,但是它们有时候会显得和你的应用程序格格不入。因此,为了使得加载控件能够完美的与应用程序融为一体,我们通常需要自定义一个外观符合该应用的加载控件。从而使得用户在使用中能够拥有更加和谐的体验。

模态视图(Modality)

模态视图对话通过阻止用户在完成当前任务或关闭消息和视图之前进行其他操作来达到创建焦点的目的。操作列表、警告弹窗和活动视图会触发模态视图。当模态视图出现在屏幕上时,用户必须通过点击按钮或者其他方式来作出选择以退出模态视图。某些应用程序会需要使用模态视图,比如,在日历中编辑事件或者在Safari中选择书签。而模态视图通常可以占据整个屏幕或者整个父视图,例如弹出窗口或者屏幕的一部分。模态视图通常包括完成和取消按钮,点击这些按钮能够退出视图。

尽量减少使用模态。通常,用户更喜欢以非线性方式与应用程序互动。只有在需要获得用户的注意时,某个任务必须被完成或放弃才能继续使用该应用程序时,或者需要保存重要数据时,才能考虑使用模态视图来聚焦。

为模态任务提供明显且安全的退出方法。确保用户在退出模态视图是,能够清楚的明白退出带来的结果。

保证模态任务足够简单、简练且突出重点。不要在你的应用程序中再创建一个应用。如果一个模态任务被设计的过于复杂的话,用户可能会因为这个模态任务的打断而忘记他们先前正在做什么。要特别谨慎的使用包含层次结构视图的模态任务,因为用户容易迷失在复杂的层次结构中而无法回溯到之前的步骤。如果某个模态任务必须包含子视图,那么就应该提供一个唯一的路径来完成该任务并且需保证这个路径足够明晰。同时,只有在完成任务的界面才能够使用“完成”按钮。

如有必要,显示说明模态任务的标题。你还可以在模态视图的其他位置更为全面的描述任务或者为用户提供指导。

只有在需要提供有必要的且值得推送的信息时,才应该使用警告框。警告框会打断用户的沉浸式体验,并且需要点击才能关闭,所以,当你准备使用警告框时,重要的是要让用户觉得打断是合理的。

尊重系统通知偏好设置。在系统设置中,用户可以单独设置应用程序的通知接受方式。遵守这些偏好设置,不然用户可能会完全拒绝接收来自你的应用程序的通知。

不要在弹出框上再显示一个模态视图。除了警告框之外,弹出窗口之上不应该再次出现任何的内容。在极少数情况下,如果在执行弹出窗口操作时必须要再次使用一个模态视图,那么请在模态视图出现之前,先关闭弹出窗口。

为你的永远程序统一模态视图的外观。例如,某些模态视图可能会包含导航栏,那么在这种情况下,你需要使模态视图的导航栏与应用程序其他地方的导航栏的外观保持一致。

选择适用于当前环境的模式视图样式。你可以使用以下任何一种样式:

页面模块(Page sheet)。部分覆盖了以横向方式显示的大屏设备上的底层内容。所有未覆盖的区域均显示半透明的黑色,以防止与底层内容进行交互。在较小的屏幕上或者纵向显示时,覆盖整个屏幕。用于某些能够根据模态视图的上下文来完成的可能会比较复杂的任务。

全屏(Full screen)。涵盖整个屏幕。用于某些能够根据模态视图的上下文来完成的可能会比较复杂的任务。

表单模块(Form sheet)。出现在屏幕中心,但如果需要使用键盘,则会重新调整位置。所有未覆盖的区域均显示半透明的黑色,以防止与底层内容进行交互。在较小的屏幕上覆盖整个屏幕。用于收集信息。

相同位置(Current context)。显示与其父视图相同的大小。用于在拆分视图窗格,弹出窗口或者其他非全屏视图中显示模态内容。

为你的应用程序选择一个合适的模态过渡方式。使用与你的应用程序相协调的过渡方式,并且增强模态内容在整个任务流程中的上下文连贯意识。默认的过渡方式是垂直滑动,模态视图从屏幕底部向上滑动,并且在被关闭的时候向下滑动消失。翻转式的过渡方式会水平翻转当前的视图以显示模态视图,并在关闭模态视图的时候翻转回原来的视图。在这种方式中,模态视图就像是原本视图的背面。值得注意的是,你需要保证在同一个应用程序中使用相同的模态视图过渡方式。

导航(Navigation)

用户在没有遇到不符合他们期望的问题之前,几乎不会去关注应用程序的导航。你的工作就是设计一套符合应用程序本身结构和目的的导航系统,而不是让导航系统引起用户太多的关注。导航系统应该是自然且符合用户熟知的习惯的,而不应该主要界面内容或者吸引焦点。在iOS中,有三种主要的导航样式。

分层导航(Hierarchical Navigation)

每个页面做一个导航选择,直到到达目的页面。如果要前往另一个目的页面,你必须回溯你的步骤或从头开始并做出不同的选择。设置和邮件使用的就是这种导航方式。

平行导航(Flat Navigation)

在多个内容类别之间切换。音乐和App Store使用的就是这种导航方式。

内容驱动或体验驱动的导航(Content-Driven or Experience-Driven Navigation)

通过内容自由移动,或内容本身定义导航。游戏,书籍和其他沉浸式应用通常使用这种导航方式。

一些应用结合了多种导航样式例如,使用平面导航的应用可以在每个类别中实现分层导航。

始终提供明确的路径。用户需要时刻明确他在应用程序中所处的位置,并且应该能够轻松的跳转到下一个目的页面。无论导航的方式如何,联通内容的路径都必须是符合逻辑的,并且要可以预期和易于掌握。一般来说,你需要为用户提供通往每一个页面的入口路径。如果用户需要在多个内容之间跳转屏幕,那么可以参考使用操作列表、警告弹窗、弹出窗口或者模态视图。

设计一种信息结构,使其快速,轻松地获取内容。通过使用最少的点击和滑动次数,以及最少的屏数来组织信息结构。

使用触摸手势创造流动性。以最小的阻力轻松移动界面。例如,你可以让用户从屏幕侧面滑动以返回上一个屏幕。

使用标准导航控件。尽可能使用标准导航控件,例如页面控件,选项卡栏,分段控件,表视图,集合视图和拆分视图。用户已经对这些控件非常熟悉,并且清楚的知道如何在你的应用程序中随意游走。

使用导航栏贯穿数据层次结构。导航栏的标题可以显示层次结构中的当前位置,后退按钮可以轻松返回到先前的位置。

使用标签栏来显示同等类别的内容或功能。标签栏可让人们快速轻松地在不同类别之间切换,无论当前位置如何。

当你的应用程序有多个相同类型内容的页面时,请使用页面控件。页面控件清楚地传达可用页面数和当前活动页面数。 Weather应用程序就使用页面控件来显示不同位置的天气页面。

1
2
提示:
分段控件和工具栏不启用导航。使用分段控件将信息组织到不同的类别中。使用工具栏提供与当前上下文交互的控件。

新手引导页(Onboarding)

应用程序启动时间是一次俘获新用户或者重连回归用户的绝佳机会。所以,请为应用启动时间设计快速、有趣且具有指导意义的体验。

提供启动页面。应用程序在启动过程中会出现启动页面,这可以给用户一种应用程序能够快速启动以及响应的感觉,并且预留了初始内容的加载时间。启动页面很快就会被应用程序的首页所代替,所以,除了可本地化文本和交互元素外,在设计启动页时应该尽量使其与应用的首页在视觉上保持和谐统一。

以适当的方向启动。如果你的应用程序同时支持纵向和横向模式,那么启动应用时,应该选择当前设备所处的方向。如果你的应用程序只支持一个方向,那么无论何时,都应该始终保持同一方向,并且在必要时允许用户倒转设备。除了某些特殊的情况外,横屏模式的应用应该根据设备的倒转而正确的转换应用的方向,不论设备朝左转还是朝右转。

迅速采取行动。应该尽量避免在启动页面加入复杂的启动画面、菜单和说明,因为这样会使得内容加载的时间变长,并且减慢了用户使用该应用的速度。如果你的应用必须要在启动也加入教程或说明,那么你应该提供跳过这些教程的方法,并且自在用户首次启动应用时才显示。

预测用户需要的时刻。积极的去寻找用户可能会需要帮助的时间点。例如,游戏遇到暂停或者角色长时间没有进展时,可以为用户显示一些提示。为了防止用户第一次时,错过了某些重要内容,应用程序应该允许用户回顾教程内容。

坚持本指南中的设计要点。为用户提供指导是有必要的,但是指导并不能替代优秀的应用程序设计。首先你需要保证你的应用程序是直观易用的。如果应用程序中需要太多的指导,那么你应该重新审视你的设计。

让学习过程变得有趣且显而易见。边做边学比阅读教程指令要跟有趣,更有效。使用动画和交互元素来进行逐步的,结合上下文的教学。避免食用一些看似可以互动的屏幕截图。

避免过早的要求用户设置各种信息。用户通常会希望应用程序在不需要任何设置的情况下就能够正常的运行。让你的设计符合大多数用户的需求,并且允许少部分想要不同配置的用户调整应用的设置,已满足他们的需求。尽可能的通过系统设置,提供默认值或者同步服务(如iCloud)等方式来设置信息。如果应用程序必须要求用户提供信息,请在第一次时用户,并允许用户稍后在应用设置中进行修改。

避免在应用内显示许可协议和免责声明。在下载应用程序之前,应该在 App Store 里显示许可协议和免责声明。如果你的应用程序必须包含这些项目,那么请为它们设计一种和谐平衡的展现方式,而避免破坏用户体验。

重新启动应用程序时,应该恢复其关闭前的状态。不要让用户手动回溯到应用程序的先前位置。应该在应用程序关闭之前保存当前状态,并在重新启动时恢复到原先的状态,以便于用户能够从中断处继续执行先前的任务。

不要过快或者过于频繁的要求用户为你的应用评分。过快或过于频繁的要求用户评分是令人讨厌的,因此反而会减少你收到的用户反馈的数量。为了鼓励一些思虑周全的反馈,在要求评级之前,让用户拥有足够的时间来思考对你的应用程序的意见。要始终提供突出评级的方法,并且永远不要强迫用户为你的应用评分。

不要鼓励重启。重新启动需要时间,这会使你的应用看起来不可靠甚至不可用。如果你的应用程序存在内存或者其他问题导致难以运行,除非是系统刚刚启动时,否则你应该需要解决这些问题。

请求许可(Requesting Permission)

用户在一些情况下必须授权应用程序访问自己的个人信息,包括当前的位置、日历信息、通讯录、提醒事项和照片。虽然用户会欣赏因为获取了这些信息而带来的便利性,但是他们也同样重视个人数据的隐私权。例如,某些用户喜欢能够使用自己的实际位置自动标记照片或者找到附近的朋友,但是他们也有可能希望禁用此类功能。

仅在您的应用明确需要时才请求个人数据。用户对个人信息的请求持怀疑态度是很自然的,特别是在没有明显需要的情况下。确保仅在用户用到明确需要个人数据的功能时才会发出权限请求。例如,应用可能仅在激活位置跟踪功能时请求访问当前位置。

示例1:

示例2:

示例3:

给出应用程序需要获取个人信息的原因。提供自定义文本(称为目的字符串或用法说明字符串)以显示在系统的权限请求弹窗中,并包含一个示例。保持文字简短且具体,注意格式,并且要保持礼貌,这样才不会是用户感到有压力。不需要在自定义文本中加入你的应用程序的名称,因为系统会自动识别并帮你添加。

正确示例:
该应用程序会在夜间检测并记录你的打鼾声。

错误示例:
需要访问麦克风才能获得更好的体验。

错误示例:
请打开麦克风权限。

只有在必须时,才在应用启动时就请求用户权限。如果你的应用程序很明显需要请求用户的个人信息才能实现功能,那么用户就不会怀疑这些请求的必要性。

请勿在非必要的情况下请求用户的位置信息。在访问位置信息之前,请检查系统设置,确认你的应用程序是否已启用位置服务。获得这些信息后,应用程序就可以在功能真正需要的时候才启动请求,如果已经获得权限,则完全不需要请求。

使用系统提供的请求弹窗控件。你可以在系统提供的标准请求弹窗控件中自定义文本内容,但是应该避免

使用系统提供的警报。您可以在标准权限警报中自定义文本,但是应该避免使用与标准请求控件的功能和外观类似的自定义请求控件。

设置(Settings)

某些应用程序可能会给用户提供一些方式来进行偏好设置或者配置选择,但是大多数应用其实不需要或者不需要马上就让用户进行偏好设置。一款成功的应用程序应该要能够满足大多数用户的需求,并且允许用户通过一些方便的操作来设置自己的偏好。如果你的应用程序是为了大多数用户而设计的,那么你应该减少对个性化设置的依赖。

主动判断系统能够提供所少信息。如果你的应用程序需要有关用户、设备或者环境的信息,请尽可能的向系统查询,而不是向用户询问。例如,如果你的应用程序需要提供本地选项,那么应该获取系统的当前定位权限,而不是向用户索取邮政编码。如果用户拒绝提供定位权限,则应该优雅的退回到手动输入。

仔细的考虑应用程序中的配置选项的优先级。应用程序中设置页面的主页应该用来显示必要的或者经常会变动的配置选项,而内页则更适合放置不经常修改的配置选项。

只将不经常更改的配置选项放到系统设置中。系统设置应用是整个iOS系统中进行配置选项更改的核心位置,但是用户必须离开你的应用程序才能到达设置应用。在你的应用程序中直接调整偏好设置会更方便。

在适当的时候提供设置的快捷方式。如果您的应用包含将用户定向到“设置”的文本,例如“转到设置> MyApp>隐私>位置服务”,则会提供一个自动打开该位置的按钮。


用户交互(User Interaction)

3D Touch

3D Touch为基于触摸的交互添加了额外的维度。在支持3D Touch的设备上,人们可以通过对触摸屏施加不同程度的压力来访问其他功能。应用可以通过显示菜单,显示其他内容或播放动画来做出响应。人们不需要学习新的手势来与3D Touch交互。当他们轻轻按下屏幕并获得响应时,他们会快速发现额外的互动维度。

主屏幕交互(Home Screen Interaction)

在主屏幕上,按压支持3D Touch的应用程序的图标,则会显示操作视图。此视图可以使用户快速便捷的执行常用的应用程序操作并且查看有趣的信息。例如,日历提供了创建事件的快捷方式。并且还会显示用户日常安排的下一个活动。

轻压与重压(Peek and Pop)

通过轻压,用户可以通过 3D Touch 在弹出的视图中预览例如页面、链接或文件等项目内容。利用手指对支持3D Touch 的目标项目施加一些压力既可以查看项目内容。抬起手指即可以退出 3D Touch 视图。要打开目标项目并查看更多细节,用户可以稍微用力按压屏幕直到目标弹出并填满整个屏幕。在某些轻压预览视图中,用户可以向上滑动视图以显示相关的操作按钮。例如,在轻压Safari中的链接时,用户可以向上滑动以显示用户在后台打开链接,将连接添加到阅读列表以及复制链接等功能的按钮。

使用轻压提供实时的、内容丰富的预览。理想情况下,轻压会提供相关项目的足够信息来扩充当前任务,或者帮助用户判断是否需要完全打开该项目。例如,决定在Safari中打开或者分享给朋友之前,可以先在邮件中预览链接内容。在表格中,往往会在选择一行内容之前,利用轻压来仔细检查该行的信息。

设计足够大的视图。设计一个足够大的轻压视图,使手指不会遮挡其内容。让人们仔细观察,以便人们决定是否要更深一点地完全打开(弹出)项目。

保持统一的轻压和重压功能。如果你在应用程序的某些地方支持轻压和重压功能,而在其他地方不支持,那么用户会无法分辨该功能的使用场景,并且会觉得你的应用程序或者他们的设备出现了问题。

避免在轻压视图中显示类似按钮的元素。如果用户抬起手指点击看起来像按钮的元素,则轻压视图会消失。

允许每一次的轻压视图通过重压打开。即使轻压预览视图能够给用户提供大部分的信息,但是当用户决定从当前任务完全切换到目标任务时,应用程序应该允许用户通过重压来打开目标视图。重压打开的内容应该和轻点打开的内容是一致的。

不要为同一个项目同时启用预览和编辑菜单。用户可能会感到困惑,并且当一个操作触发两个功能时,系统也很难检测用户的意图。

适当时提供操作按钮。不是每个人都需要操作按钮,但是它们是提供常见任务快捷方式的好方法。如果你的应用程序已经为项目提供了自定义的点击长按操作,那么最好在轻压预览视图下面也包含同样的操作按钮。

避免提供打开轻压预览项目的操作按钮。用户通常会通过更重的按压来打开轻压预览视图,所以不用额外的提起提供打开预览视图的按钮。

不要让轻压预览成为唯一的打开方式。并非所有设备都支持 3D Touch 功能,而且有些用户也会关闭设备的 3D Touch 功能。在这种情况下,你的应用程序应该提供其他方法来触发操作。例如,你的应用程序可以通过点击长按来提供一个包含和轻压预览视图一样的视图。

Live Photos

应用程序可以通过对Live Photos的支持来利用压感增强照片的观感体验。当你按下它们时,Live Photos 会通过动态和声音来显示拍摄照片之前和之后的瞬间,就像回到了当时的场景一样。

Apple Pencil

Apple Pencil是一款多功能,直观的工具,可以在iPad应用程序中记笔记,做草图,绘画,标记文档等时提供像素级精度的操作。

支持预期行为。 Apple Pencil专为标记制作而设计 - 它不是指针或选择工具。为你的应用程序考虑有些且意想不到的启用Apple Pencil的方式。例如,你的应用程序可以允许用户在特定区域通过手写的输入方式来代替通常的键盘输入,或者让那个用户可以在文档边缘记笔记。

提供一致的Apple Pencil和手指体验。不要让用户在与控件交互时,从 Apple Pencil 到使用手指来回切换。如果你的应用程序支持使用 Apple Pencil 进行标记操作,则应用程序的其他控件也应该响应Apple Pencil。如果控件不响应,则容易造成混淆,用户会觉得应用程序出错了或者 Apple Pencil 电量不足了。同样的,支持 Apple Pencil 的操作,例如绘图和书写,也应该支持直接用手指交互。

让用户在 Apple Pencil 接触到屏幕的那一刻,立刻作出标记。利用Apple Pencil在屏幕上书写的体验应该与利用传统铅笔在纸张上书写的体验保持一致。在使用 Apple Pencil 之前,不应该额外要求用户点击按钮或者进入特殊模式。

囊括丰富的表达方式。 Apple Pencil可以感知倾斜(高度),力度(压力)和方向(方位角)。你的应用程序应该利用这些特性来影响 Apple Pencil 所作出的笔划,例如通过改变厚度和强度来改变笔触。在对压力作出反应时,保持简单直观—例如,为了使变化过渡自然,用户可以通过改变压力来影响笔触的连续性(例如油墨的不透明度变化和笔刷的大小变化)。

使用视觉反馈来指示 Apple Pencil 与内容的直接连接。Apple Pencil 应该直接显示并且立即操纵它在屏幕上触摸的内容。它不应该以用一种看似不连贯的操作,也不应该影响到屏幕其他部分的内容。

设计出优秀的左手和右手体验。避免将控件放在可能被任何一只手遮挡的位置。如果控制可能会变得被遮挡,请考虑重新安排控件在屏幕上的位置。

尽可能尊重用户双击手势的系统偏好设置。 Apple Pencil 通过直接(更改工具)或间接(显示颜色选项)更改绘制方式来响应双击手势。虽然默认情况下双击可以在当前工具和橡皮擦之间切换,当用户可以在系统设置应用中设置在当前工具和上一个工具之间切换,显示和隐藏颜色选择器,或者根本不执行操作。如果你的应用程序支持这些行为,那么请尊重用户的系统偏好设置以保证双击动作的体验保持一致,并且不要指望用户为相同的行为学习新的手势。如果系统偏好设置的动作在你的应用程序中没有意义,你仍然可以使用手势来改变 Apple Pencil的模式。例如,在使用具有网格编辑工具的3D应用程序时,用户可以通过双击在工具的加高和降低模式之间切换。

如有必要,为用户提供启用自定义双击行为的方法。当你的应用支持部分或全部Apple Pencil双击行为,且还支持自定义双击行为时,请提供一个控件,允许用户启用自定义行为。如果用户没有明确的方法来启用自定义行为,那么当您的应用无法响应系统范围的双击设置时,他们可能会感到困惑。在这种情况下,请确保用户可以轻松发现应用支持的替代行为,但默认情况下不启用它们。

切勿使用双击手势执行修改内容的操作。用户可能会意外地双击,这意味着他们可能甚至不知道您的应用已经执行了该操作。当双击在工具模式之间切换时,用户只需再次双击即可轻松扭转意外的模式更改。但是,在使用手势执行操作的应用中,用户必须中断其工作流以找到撤消操作的方法。更糟糕的是使用双击执行潜在破坏性操作的应用程序:如果用户不知道操作已经发生,他们可能会丢失数据。

音频(Audio)

用户通过音量按钮,静音开关,耳机控制和屏幕音量滑块操纵声音。许多第三方配件也包含声音控制。音频可通过内置或外置扬声器,耳机输出,甚至可通过支持AirPlay或蓝牙的设备进行无线输出。无论声音是应用程序体验的主要方面还是点缀,您都需要了解人们期望声音如何表现并满足这些期望。

静音(Silence)

人们将设备切换为静音,以避免被意外声音打断,例如铃声和传入的消息声音。他们还希望禁用非必要声音,包括键盘声音,声音效果,游戏音轨和其他声音反馈。当设备设置为静音时,仅仅应该播放明确需要的音频内容,例如媒体播放期间的音频,警报和音频/视频消息。

音量(Volume)

无论是使用物理设备按钮还是屏幕滑块,用户都希望音量的变化能够影响整个系统的声音,包括音乐和应用内音效。唯一的例外是铃声音量,当音频没有主动播放时,铃声音量总是可以单独调节。

耳机(Headphones)

用户使用耳机可以在私密状态下收听声音,并且解放了双手。通常情况下,插入耳机时,用户希望设备能够自动切换到耳机播放路径而不是中断声音。拔下耳机时,用户则通常希望播放立即停止。

设计出色的音频体验(Designing a Great Audio Experience)

必要时自动调整音量大小,但不是整体音量。您的应用可以调整相对的独立音量级别,以实现音频的完美组合。但是,最终输出应始终由系统音量控制。

允许在适当时重新选择音频输出路径。用户经常想要选择不同的音频输出设备。例如,他们可能希望通过客厅的立体声音箱,汽车收音机或者 Apple TV 来收听音乐。除非你有令人信服的理由不这样做,不然你应该让你的应用程序支持切换音频输出设备。

使用系统提供的音量调整视图来调节音频。提供音量控制界面控件的最佳方式就是使用系统音量视图。此视图是可自定义的,包括音量大小控制滑块,甚至包括用于重新设定音频输出设备的控件。

使用系统的声音服务来获得短促的声音和振动。

如果声音对您的应用至关重要,请对音频进行分类。不同的音频类别可以允许设备使用物理静音开关来控制静音,可以于其他音频混合播放,或者在应用程序处于后台时播放。根据音频的实际用途以及设备当前的音频状态选择一个类别,并将其分配给你的音频组。例如,如无必要,不要中断用户正在从其他应用程序中收听的音乐。一般情况下,尽量避免在应用程序运行时更改音频类别,但在不同时间录制和播放音频的应用程序除外。

  1. 类别:单独环境音频(Solo ambient)
    含义:声音不是必不可少的,但它会使其他音频静音。例如,带有音轨的游戏。
    行为:响应静音开关。不与其他声音混合。不在后台播放。

  2. 类别:环境音频(Ambient)
    含义:声音不是必不可少的,它不会使其他音频静音。例如,一种游戏,允许人们在游戏过程中播放来自其他应用程序的音乐,代替游戏的音轨。
    行为:响应静音开关。与其他声音混合。不在后台播放。

  3. 类别:播放音频(Playback)
    含义:声音是必不可少的,可能与其他音频混合。例如,教授外语的有声读物或教育应用程序,人们可能希望在离开应用程序后听取。
    行为:不响应静音开关。可能会或可能不会与其他声音混合。可以在后台播放。

  4. 类别:录制音频(Record)
    含义:声音被录制。例如,提供录音模式的笔记记录应用程序。如果它允许人们播放录制的音符,这种性质的应用可能会将其类别切换为播放。
    行为:不响应静音开关。不与其他声音混合。可以在后台录制。

  5. 类别:录播音频(Play and record)
    含义:可能同时录制和播放声音。例如,音频消息或视频通话应用。
    行为:不响应静音开关。可能会或可能不会与其他声音混合。可以在后台录制和播放。

在中断发生后适当时恢复音频播放。有时,当前播放的音频会被来自其他应用的音频中断。诸如来电之类的临时中断被认为是可恢复的。永久中断,例如由Siri发起的音乐播放列表,被认为是不可恢复的。当发生可恢复中断时,如果在中断开始时音频正在正在播放,则应用程序应在中断结束时恢复播放。例如,播放音轨的游戏应用和正在播放音频的媒体应用都应该恢复音频播放。

让其他应用知道你的应用何时播放临时音频。如果你的应用可能暂时中断其他应用的音频,它应该适当地标记音频类型,以便在可以安全恢复时通知其他应用。

仅在有意义时才响应音频控件。无论你的应用是在前台还是在后台,用户都可以从应用界面外部控制音频播放,例如在控制中心或耳机上的控件。如果你的应用需要在一个明确与声音相关的播放环境下主动播放音频,或者连接到了支持AirPlay的设备,则对音频控件作出响应是合理的。否则,你的应用程序不应该中断控件激活时可能正在播放的其他应用程序的音频。

不要重新定义音频控件。用户希望音频控件在所有应用中都能保持一致。永远不要重新定义音频控件的功能含义。如果您的应用不支持某些控件功能,那么不对这些功能做响应即可。

身份认证(Authentication)

仅在用户需要进行价值交换时才进行身份验证,例如个性化体验、访问更多功能,购买内容或同步数据。如果你的应用程序需要身份验证,请让整个验证过程快速、轻松且不引人注目,这样就不会影响整个应用程序的乐趣体验。

在所有注册和登录流程中使用密码自动填充。此功能可自动生成并填写密码和安全代码,以便人们在验证过程上花费的时间更少。所有应用都应支持此功能。

尽可能延迟登录。如果在没有做任何有意义的事情之前就要求登陆,用户往往会放弃这个应用程序。所以,让用户对你的应用程序作出承诺之情,请先给他们一个机会爱上你的应用。在一款购物应用中,应该允许用户已经打开就可以浏览商品,而只在用户决定购买商品时才要求其进行登陆操作。在流媒体应用中,应该让用户在登陆之前就可以浏览查看你所能提供的内容。

说明身份验证的好处以及如何注册你的服务。如果你的应用需要身份验证,请在登录屏幕上显示简短,友好的说明,说明需求的原因及其好处。此外,请记住,并非每个使用你的应用的人都从一开始就拥有一个帐户。请务必说明如何获取,或提供简单的应用内注册方式。

通过显示适当的键盘类型来最小化数据输入。例如,在询问电子邮件地址时,请显示电子邮件键盘屏幕,其中包含有用的数据输入快捷方式。

避免使用特定的密码。用来解锁iOS设备的密码或者当设备未开启生物识别身份验证功能时用于支付 Apple Pay 的密码。

面容ID 和 触控ID(Face ID and Touch ID)

尽可能支持生物识别身份验证。 面容ID和触控ID是人们信任的安全、熟悉的身份验证方法。如果用户启用了生物识别身份验证,你可以假设他们了解其工作原理,了解其便利性,并且希望尽可能使用它。请记住,人们可能会选择在其设备上禁用生物识别身份验证,因此你的应用应准备好处理此情况。

通过单一方式对人员进行身份验证。最直观的方法就是不要让用户选择身份验证方式。只需要给用户提供一个默认选项,比如 面容ID 。并且提供替代的身份验证方案,例如要求用户输入用户名和密码,仅在初始方法失败时才启用备用方案。

仅在响应用户操作时启动身份验证。明确的操作(如点击按钮)可以确保用户此刻需要进行身份验证,在启用面容ID的情况下,还需要判断用户是否面对着相机。

始终明确身份验证方法。例如,使用面容ID登录你的应用程序,登录按钮标题应该为“使用面容ID登录”而不是“登录”。

准确参考认证方法。请勿在支持面容 ID的设备上引用触控ID。相反,请勿在支持触控ID的设备上引用面容ID。检查设备的功能并使用适当的术语。

通常情况下,避免在应用程序中提供是否进行生物识别身份验证的设置。如果用户在系统级别启用了生物识别身份验证,则只需假设用户想要使用它。如果你在应用中提供特定的设置,则用户可能会进入这样一种状态:生物识别身份验证在系统层级上被禁用但是在你的应用程序中却显示已经开启。

请勿使用图标来标识系统身份验证功能。当用户看见看起来像系统触控ID(指纹)和面容ID图标的图标时,他们会认为需要进行身份验证。使用图标来标识身份验证功能会造成不一致并且导致混淆,尤其是当图标是彩色的,大尺寸显示,并且出现在内容之外时。

数据输入(Data Entry)

无论是点击界面元素还是使用键盘,输入信息都是一个繁琐的过程。当一个应用程序通过在做任何有用的事情之前要求大量输入来减慢这个过程时,人们可能会很快气馁,甚至可能完全放弃应用程序。

如果可能,提供选择。使数据输入尽可能高效。例如,考虑使用选择器或数据表而不是文本字段,因为从预定义选项列表中选择比键盘输入数据更容易。

尽可能从系统获取信息。不要强迫用户提供可以自动或经用户许可收集的信息,例如联系人或日历信息。

提供合理的默认值。在可能的范围内,预填充具有最可能值的字段。提供良好的默认值可以最大限度地减少决策制定并加快流程。

仅在收集所需信息后才允许用户进行下一步操作。在启用“下一个”或“继续”按钮之前,请确保所有必填字段都有数据。利用按钮的可点击状态来作为一个诱导用户点击的视觉线索,告诉用户一切就绪可以点击下一步了。

动态验证字段值。填写冗长的表格后,如果必须返回并纠正错误,那将是令人沮丧的。只要有可能,请在输入后立即检查字段值,以便用户立即纠正它们。

仅在必要时才需要字段值。仅将必填字段用于真正需要继续操作的信息。

给列表数据设置简明的导航。选择想要的数据应该是一件容易的事情,尤其是在列表或者选择器中。可以考虑按照字母顺序或者另一种逻辑对数据列表进行排序,以便于用户快速检索和选取。

在文本字段中显示提示以帮助沟通目的。当文本字段输入框中没有其他文本时,可以包含占位符文本 - 例如“电子邮件”或“密码” 。当占位符文本足够表明含义时,请勿再额外使用单独的标签来描述文本之短。

拖放功能(Drag and Drop)

使用单个手指,用户可以通过将内容从一个位置拖动到另一个位置来移动或复制所选照片,文本或其他内容,然后抬起手指以放下它。

触摸并保持所选内容使其看起来上升并且粘附到用户的手指上。在拖动内容时,动画和视觉提示识别可能的目的地。系统还会显示一个标志,指示何时无法删除,或者会导致重复内容而不是移动内容。

源和目标(Sources and Destinations)

拖和放涉及将所选内容从源位置移动到目标位置。这些位置可以位于同一容器中,如文本视图,也可以位于不同的容器中,例如拆分视图两侧的文本视图。例如,在Notes中,用户可以将所选文本拖动到同一笔记中的新位置。在“提醒”中,用户可以将单个提醒拖出一个列表并将其放入另一个列表中。

在iPad上,源位置和目标位置也可以存在于不同的应用程序中,从而实现跨应用程序交互,例如将照片从Safari中的网页拖动到Mail中的新邮件。在拖动内容时,用户可以通过多任务处理访问另一个应用程序,退出到主屏幕,或从屏幕底部向上滑动以显示Dock栏。

备注:在应用程序之间拖放内容一定是导致内容的重复,而不是移动。

支持拖放功能(Supporting Drag and Drop)

拖放是一种高效,直观的功能,用户希望在整个系统中普遍实现。如果你的应用包含或生成用户可能想要移动,复制或插入的文本,照片,视频,音频或其他内容,你的应用应支持拖放功能。

为所有可选择和可编辑的内容提供拖放功能。可选内容应该是可拖动的,可编辑内容应该接受拖放的内容。另外,请确保你的应用支持在这些区域中进行复制和粘贴。

允许在适用时拖放控件上的内容。通常,配置允许数据输入或选择的控件(如文本字段)接受可以拖放的内容。

尽可能使用标准文本视图和文本字段。这些系统提供的元素本身就包括了内置的拖放支持功能。

为了提高效率,请考虑支持多项拖放。在许多应用中,用户可以用一根手指拖动单个项目,在拖动时,可以通过另一个手指点击选择其他项目。所选的项目会一起移动并且堆叠显示在拖动原始项目的手指下方。然后,用户可以将这些项目作为一组拖放,并将它们放在所需的目标位置上。例如,主屏幕允许选择多个应用程序图标并作一次拖动到一个文件夹中。某些应用程序(如“照片”)提供了一种选择模式,可以在拖动之前选择多个项目。

判断在你的应用程序中拖放内容需要移动还是复制。通常情况下,当源容器和目标容器相同(拖放文档中的文本)时,会选择移动源项目。而当源容器和目标容器不相同(在文档之间或应用程序之间拖动)时,会选择复制源项目。但是,情况也并非总是如此。最重要的是,拖放操作应该尽量直观。在“提醒”应用中,提醒列表之间的拖动会移动而不是复制它们,因为这是符合用户期望的。在应用程序之间拖放内容始终会生成副本。

只要有可能,请允许用户撤消拖放操作。通常,当用户无意中将内容拖放到错误的目标位置时,他们应该能够使用“撤消”将应用程序恢复到之前的状态。也就是说,应删除已拖放的内容,如果已从应用中的其他位置移动,则会将其恢复到原始位置。

考虑启用延迟加载。通过延迟加载,用户能够利用拖动选定的内容来激活某些控件(如按钮和分段控件),并暂停而不会丢弃内容。例如,在“邮件”应用中,可以将选定的邮件拖到导航栏的“返回”按钮上,以访问邮箱层次结构中的其他位置。切勿将延迟加载作为激活控件的唯一方法。它应该是一种可被用户发现的点缀手段。在大多数情况下,响应延迟加载的控件也应该响应轻点手势。

提供拖动的内容(Providing Dragged Content)

如有必要,自定义拖动项预览。通常情况下,应该在用户的手指下用半透明的内容来表示被拖动的内容。此样式提供逻辑联系,指示正在进行拖动,并且使用户能够查看拖动内容下方的目标。

尽可能的提供多种拖放数据类型,按照保真度从高到低排序。例如,在提供艺术线条时,你可以按顺序提供矢量的PDF图像,具有透明度的无损PNG图像以及无透明度的有损JPEG图像。这样,目标位置就可以选择它所能接收的最高质量的图像。

如果适用,将自定义对象的本地版本作为最丰富的数据形式。例如,允许用户拖动图表的应用程序首先应该显示本地图表对象。然后,它应该提供一份图表的图像代替版本-用于不支持图表对象的应用程序。

当应用程序内容传输需要消耗大量时间或资源密集时,应该实施文件提供程序扩展。即使你的应用程序不再运行,文件提供程序扩展也会管理传输过程并确保其完成。请注意,在用户拖放内容之前,传输过程是不会开始的。

应用程序的内容传输需要较长时间时,提供进度信息。如果内容必须被下载或者大文件需要时间复制时,请提供进度信息。至少提供内容的总大小,以便目标位置可以计算剩余时间并显示适当的进度指示器。

接收拖入的内容(Accepting Dropped Content)

使用视觉提示标识潜在的目标位置并预览拖入内容的效果。突出显示,插入点指示符和动画都是识别可能的目标位置的好方法。当内容被拖过时,视图可以巧妙​​地闪烁并改变颜色,或者段落可以移开以为拖动的图像腾出空间。如果屏幕上有多个可能的目标位置,请一次只识别一个目标位置。如果源容器和目标容器相同,则可能不需要突出显示,除非将内容完全拖出源,然后重新进入。确保内容被拖动或不再位于目标上方时突出显示。

适当时自动滚动目标的内容。当内容被拖动到目标位置的边界之外时,你的应用可能需要确定是否滚动目标的内容或允许用户继续拖动到完全不同的目标位置。如果您的应用允许用户继续拖动,请考虑定义一个区域,当拖动的项目位于其上方时,该区域会导致自动滚动。例如,当内容被拖动到正文区域的顶部或底部时,Mail中的冗长草稿消息会自动滚动。系统的标准文本视图和文本字段自动采用此行为。

提取被拖动内容的最丰富表示形式,并加以显示。例如,你的应用程序可能会提供图表的多种表示形式。如果你的应用程序程序支持图表,则可以提取并显示原始的图表对象。如果你的应用程序不支持图表,则可以提取并显示图表的图像版本。

适用时,仅提取被拖动内容的相关部分。例如,如果用户将联系人从“联系人”拖动到“邮件”中的收件人字段,则仅使用名称和电子邮件地址,而不是联系人的地址信息。

拖动内容后,在表视图和集合视图中显示占位符。占位符会临时指明在完成转移后内容将驻留的位置。

被拖动内容需要时间转移时显示进度。默认情况下,当应用程序之间发生耗时的传输时,系统会显示应用程序模态弹窗警告。考虑自定义显示进度的方式 - 例如在表视图或集合视图中的占位符上显示进度指示器 - 这样就不会阻碍到用户使用你的应用程序。请注意,在用户拖入内容之前,传输过程不会开始。

被拖动的内容启动进程时提供反馈。如果用户将内容放到启动任务的控件上(例如,将视频上传到共享站点),则应该表明该任务已经开始,并让用户了解其进度。

拖入失败时通知用户。如果无法插入拖入的内容,可能是因为文件传输被中断,请通知用户拖入不成功。

对拖入的文本应用适当的样式。当源和目标支持相同的样式文本属性时,被拖入的文本应保持其原始字重,字体,大小和其他属性。否则,被拖入的文本应采用目标应用样式。

当用户无法立即撤消拖放时,请考虑提供一种细微,直观的退出方式。例如,共享应用程序可能会在发布已拖入的内容之前显示中间共享表。此共享表可以提供一种方式来提供状态消息等附加内容,同时还提供取消按钮。将照片拖入共享照片流时,照片会出现此行为。


文章由:葱葱葱翻译,转载请注明出处,谢谢!