iOS 9人机界面指南(三)：iOS 技术 (下)

2016-04-10 18:28:00

文章索引

3.12 HealthKit
3.13 应用内购买服务(In-App Purchase)
3.14 游戏中心(Game Center)
3.15 iAd富媒体广告(iAd Rich Media Ads)
3.16 无线打印 (AirPrint)
3.17 访问用户数据(Accessing User Data)
3.18 快速查看(Quick Look)
3.19 声音(Sound)
3.19.1 理解用户期望(Understand User Expectations)
3.19.2 定义应用的音频行为(Define the Audio Behavior of Your App)
3.19.3 管理音频中断(Manage Audio Interruptions)
3.19.4 适时处理媒体远程控制事件(Handle Media Remote Control Events, if Appropriate)
3.20 VoiceOver
3.21 路线选择(Routing)
3.22 编辑菜单(Edit Menu)
3.23 撤销与重做(Undo and Redo)
3.24 键盘和输入页面(Keyboards and Input Views)

译者注：本文译自苹果官方人机界面指南 iOS Human Interface Guidelines (2015年10 月21日)，由腾讯ISUX设计师翻译整理，非发文者一人之作。译文首发于ISUX博客，如在阅读过程中发现错误与疏漏之处，欢迎不吝指出。后续章节会陆续更新，敬请期待。

3.12 HealthKit
在iOS 8及之后的版本中，使用HealthKit构建的应用可以利用从健康应用中获取的数据为用户提供更强大、更完整的健康及健身服务。在用户允许的情况下，应用可以通过HealthKit来读写健康应用(用户健康相关数据的存储中心)中的数据。

举例来说，用户可以允许营养应用从健康应用中获取体重及活动数据，用于告诉他们为了达到既定目标一天应该消耗多少卡路里。这个营养应用还可以通过 HealthKit更新健康应用上实际消耗的卡路里数据，让用户能更容易地跟踪他们的健康计划的进展。想要了解如何将HealthKit整合进你的应用中，请参阅HealthKit Framework Reference.

下面的指南能够帮助你设计出让人信任且喜爱的健康类应用：

当且仅当你有令人信服的理由时才去访问健康应用中的数据。HealthKit是为了专注于健康及健身服务的应用而设计的。如果一个应用请求获取与其不相关的健康信息，用户不太可能会放心地将个人数据提供给这个应用。因此，你需要确保用户能够理解你的应用需要获取他们某些具体的个人健康数据的原因，并告诉他们共享这些数据的好处。

避免在用户还不知道用途前就向他们请求访问私人健康数据。当用户能够看到当前的任务和你需要访问的数据的关联性时，会更乐意给予你访问权限。举例来说，当用户在给一个减肥应用填写资料时，让他允许你访问健康应用中储存的体重数据是合理的。但如果那个减肥应用在启动时就立即提出访问体重数据的请求，用户更可能会选择拒绝分享该个人数据。

使用系统提供的用户界面来请求访问用户的数据。当用户想要向应用授予访问他们的数据的权限时，一般会期望看到如下图所示的系统权限许可列表。为了确保给用户提供良好的用户体验，应避免在应用的其他页面中重复使用权限许可列表上的信息。而是应该在权限列表中添加些自定义信息来说明为什么你的应用需要访问特定的数据(参阅HKHealthStore Class Feference可获取更多信息)的原因。确保这些信息简洁且能清晰地说明你的应用是如何利用健康应用中的数据，以及收集这些数据的好处。

当用户体验存在中断时请使用模态视图来展示全屏横幅广告。如果你的应用中有自然中断或情景转换，用模态样式来展示会更合适。当你使用模态样式来展示全屏横幅时(通过用presentFromViewController实现)，用户要么进入广告，要么关闭它。出于这个原因，当用户有做出转变的预期时 (比如完成了一个任务后) 用模态视图的形式来展示比较好。将中等矩形横幅广告视图放置在不会干扰内容的地方。和标准横幅一样，中等矩形横幅也最好放置在屏幕底部或底部附近。放在底部附近也能减少干扰用户的可能性。

应用的界面视图进行转场切换时不要使用模态样式展示全屏横幅。如果用户在使用你的应用时会频繁的进行屏幕切换操作，例如杂志翻页或翻阅一些画册图片合集，此时使用非模态的形式会更合适。当你使用非模态来显示全屏横幅时(通过使用presentInView实现)，可以在用户界面中保留栏 (bar) 使得用户可以通过应用中的控件进入或退出广告。同其他横幅广告一样，点击全屏横幅广告也会触发iAd体验，但是如果条件允许的话，你的应用也可以对横幅广告区域支持其他手势操作 (比如拖动或滑动)。

确保使用合适的动画效果来显示和隐藏非模态的全屏横幅视图。例如，杂志阅读应用可以用和杂志翻页一样的动画效果。

确保横幅广告在应用中出现的时间和位置是合理的。用户只有在不觉得广告会打扰他们正常的工作流程时才有可能去体验iAd.这点对于游戏这样的沉浸式应用尤其重要：你肯定不想将横幅放置在影响用户玩游戏的位置。

避免将横幅放置在用户只会一扫而过的页面。最好不要将横幅广告放置在用户会快速略过的页面，比如用户正要深入挖掘或前往他们所关注的内容。通常用户在一个页面停留至少1、2秒后才有可能会点击广告。

尽可能的支持双向展示横幅广告。最好让用户在使用应用时不必旋转设备就能浏览广告。当然，支持双向也能给你的广告提供更大的展示区域。想要了解如何确保转换方向时横幅广告能正常响应，请查看iAd Programming Guide.

不要让标准或中等矩形横幅广告滚出屏幕。如果你的应用需要滚动来展示更多内容，确保横幅广告一直固定在它的位置上。

当用户浏览或与广告进行交互时，暂停那些吸引用户注意力或需要操作的活动。当用户选择浏览广告时，他们不想因此错过应用中正发生的事件，也同样不想让应用打断广告体验。一个好的经验方法是像应用程序转入后台运行那样暂停当前活动。

除非有特殊情况，否则不要中断广告。一般情况下，当用户浏览并与广告进行交互时，应用还是会继续运行并接收事件，所以也有可能突然出现一个事件需要获得用户的注意力。然而，需要打断广告的场景其实非常少。有一种情景是有的应用会提供互联网语音协议服务 (VoIP).在这种应用中，有电话接入时可能会取消正在运行的广告。

注意:取消广告可能会对应用能接受的广告类型以及能获取的收益有不好的影响。

3.16 无线打印 (AirPrint)
用户可以通过AirPrint无线打印应用中的内容，还可以使用打印中心应用检查打印任务。

*如果你选择音频处理类目并且你希望在后台运行音频进程，你需要在完成音频处理之前防止你的应用被暂停。欲了解如何实现这一功能，参见《iOS应用编程指南》中的执行长时间运行的后台任务。

以下是一些示例情境，其中指示了如何选择音频会话类目以提供用户喜欢的音频体验。

情境1：一个帮助人们学习新语言的教育类应用。你需要提供：

用户点击特定控件时播放反馈音效
当用户想听到正确发音的示例时播放字词的录音

在这个应用中，声音对于主要功能是十分重要的。人们使用这个应用来听他们正学习的语言的词语与短语，因此即使当设备锁定或者被调至静音时也要能播放声音。因为用户需要清晰地听到声音，他们会期望其他他们可能播放的音频都被静音。

为了满足用户对于该应用所期望的音频体验，你应该使用播放(Playback )类目。虽然这一类目可以被定义为与其他音频混合，但该应用应该使用默认的行为以确保其他的音频不会干扰那些用户明确选择听到的教育性内容。

场景2：网络协议电话(VoIP)应用。你需要提供：

接收音频输入的能力
播放音频的能力

在该应用中，声音对于主要功能是十分重要的。人们经常会在使用另一个应用时使用该应用与他人进行交流。用户期望能在他们将设备调至静音或设备被锁定时接听电话，他们希望在来电期间其他音频被静音。他们也希望应用在后台运行时也能继续打电话。

为了满足用户对于该应用所期望的音频体验，你应该使用播放和录音(Play and Record)类目，并且你要确保只有在你需要时才会激活你的音频会话，以便用户可以在打电话过程中使用其他音频。

场景3：允许用户在不同任务中操作角色的游戏。你需要提供：

不同的游戏运行音效
配乐

在该应用中，声音会在很大程度上提升用户体验，但对于主任务并没有那么重要。而且，用户可能会希望能在玩游戏时静音或听他们乐单中的歌曲而不听游戏配乐。

最好的策略是在你的应用启动时确定用户是否在收听其他音频。不要要求用户选择他们是要收听其他音频或是你的音效。而应该使用音频会话功能中的AudioSessionGetProperty来请求kAudioSessionProperty_OtherAudioIsPlaying属性的状态。依据所请求的答案，你可以选择环境(Ambient)或是个人环境(Solo Ambient)类目(这两种类目都允许用户静音玩游戏)：

如果用户正在听其他音频，你应该假设他们想要继续听并且不想被强迫收听游戏音效。在这种情境下，你最好选择环境(Ambient)类目。
如果用户在你的应用启动时没有在收听其他音效，你最好选择个人环境(SoloAmbient)类目。

情境4：一个为用户到达目的地提供准确、实时导航指示的应用。你需要提供：

路途中每一步的语音指示
一些反馈音效
支持用户继续收听他们自己的音频的能力

在该应用中，无论应用是否是在后台运行，语音导航指示都表现为主要任务。基于这一原因，你最好使用播放(Playback)类目，它允许你的音频在设备被锁定、静音或是在后台运行时仍可以播放。

你可以通过添加kAudioSessionProperty_OverrideCategoryMixWithOthers属性来实现允许人们在使用你的应用时收听其他音频。但是你也想要确保用户在他们正在播放其他音频时能听到语音提示。你可以为音频会话添加kAudioSessionProperty_OtherMixableAudioShouldDuck属性来确保你的音频比其他音频的声音更大( iPhone上的电话音频除外)。这些设置允许应用在后台运行时也可以恢复音频会话，可以确保用户能获得实时更新的导航。

情境5：一个允许用户上传文本和图片到网站上的博客应用。你需要提供：

简短的启动音效文件
伴随用户行为产生的各式各样的短音效(例如当邮件被上传后播放的音效)
发送失败时播放的提示音

在该应用中，声音提升了用户体验，但也不是必需的。主任务与音频并没有关系，用户也不是必须要通过收听声音才能成功使用应用。在这一情境中，你最好使用系统声音服务来产生声音。这是因为这个应用中所有声音的音频情境都符合本技术想要达到的目的，也就是说应制作符合用户所期待的、能通过设备和铃声/静音(或静音)开关来调节的界面音效和提示音。

3.19.3 管理音频中断(Manage Audio Interruptions)
有时候，当前播放的音频会被来自于不同应用的音频所打断。举个例子，在iPhone上，来电会持续中断当前应用的音频。在多任务情境中，这种音频中断的频率可能会很高。

为了提供用户喜欢的音频体验，iOS系统依赖于你能做到下面几点：

识别可能会引起应用中断的音频类型
当应用在音频中断结束后继续运行时进行合理地反馈

每个应用需要识别会引起音频中断的类型，但不是每个应用都需要决定如何在音频中断结束后进行反馈。这是因为多数类型的应用应在音频中断结束后恢复音频。只有那些主要或部分由媒体播放组成(以及提供媒体播放控制)的应用，才必须用额外的步骤来决定什么是合适的反馈。

从概念上讲，基于中断当前音频的音频类型以及中断结束后用户所期望的特定的应用反馈方式，有两种类型的音频中断：

可恢复性中断是(resumable interruption)被用户视为临时穿插在他们的主要聆听体验中的音频引起的。

在可恢复性中断结束后，有媒体播放控件的应用应该恢复它被中断前的任务，无论是继续播放音频还是保持暂停。没有媒体播放控件的应用则应该恢复播放音频。

举个例子，试想用户在iPhone上使用应用播放音乐时，在播一首歌的中间来了一个网络电话。用户接起了电话，期望在他们通话时播放的应用能静音。在通话结束后，用户希望播放的应用自动恢复播放歌曲，因为音乐而非电话才是他们的主要聆听体验，而他们在电话接入前也没有暂停音乐。另一方面，如果用户在电话接入前暂停了音乐播放，他们会希望电话结束后音乐仍保持暂停。

其他能引起可恢复性中断的应用的例子还有那些具备闹钟、音频提示(例如语音方向指示)或其他间歇性音频功能的应用。

不可恢复中断(nonresumable interruption)是由那些被用户视为首要听觉体验的音频所引起的，比如媒体播放产生的音频。在不可恢复中断结束后，显示媒体播放控件的应用不应该恢复播放原来的音频。而没有媒体播放控件的应用应该恢复播放音频。例如，假设用户正在收听一个音乐播放应用(音乐应用1)，此时另一个音乐播放应用(音乐应用2)打断了它。用户终止后决定收听音乐应用2一段时间。在退出音乐应用2之后，用户不想要音乐应用1自动恢复播放，因为此时他们主动将音乐应用2作为首要的听觉体验。

下面的指南可以帮助你决定当一个音频中断后如何继续以及提供什么信息:

确定由你的应用引起的音频中断的类型。在你的音频结束时，你可以通过以下任意一种方式去禁用你的音频会话来做到这一点：

如果你的应用引起了一个可恢复性中断，使用AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation标识禁用你的音频会话。
如果你的应用引起了一个不可恢复中断，不用任何标识就可以禁用你的音频会话。

无论提供与否，标识会在适宜的情况下允许iOS系统赋予被中断的应用自动恢复播放它们的音频的能力。

决定是否应该在一个音频中断结束后恢复音频。你应依据你应用中所提供的音频体验来做这一决断。

如果你的应用给用户呈现了用于播放或暂停音频的媒体播放控件，你需要在一个音频中断结束后检查AVAudioSessionInterruptionFlags_ShouldResume标识，如果你的应用接受应该恢复(Should Resume)标识，你的应用应该：
恢复播放音频(你的应用被打断时在主动播放音频)[br]
·不恢复播放音频(你的应用被打断时没有在主动播放音频)
如果你的应用没有呈现任何用户可用于播放或暂停音频的媒体播放控件，你的应用无论是否有“应该恢复”标识，都始终应在音频中断结束后恢复之前播放的音频。例如，播放配乐的游戏应该在被中断后自动恢复播放配乐。

3.19.4 适时处理媒体远程控制事件(Handle Media Remote Control Events, if Appropriate)
当人们使用iOS媒体控制器或辅助控制器(如耳机线控)时，应用要能响应远程控制。使你的应用能接收来自于你的用户界面之外的输入，无论你的应用当前是在前台还是后台播放音频。

应用可以在播放媒体的过程中，通过后台向支持Airplay的硬件(如Apple TV)发送视频。这样的应用可以接收通过远程控制事件实现的用户输入行为，因此用户可以控制处于后台运行状态的应用中的视频播放。除此之外，这类应用在后台运行时也能恢复被中断的音频。

当一个媒体播放应用在后台播放音频或视频时，尤其需要合理响应媒体远程控制事件。

当你的应用在后台运行时，为了满足与播放媒体特权相关的责任，要确保遵循以下这些原则：

限制你的应用接收远程控制事件的次数。例如，当你的应用可以帮助用户阅读内容、搜索信息或是收听音频时，它只有在用户处于音频场景中时才应该接收远程控制事件。当用户脱离音频情境时，你应该放弃接收事件的能力。如果你的应用允许用户在支持AirPlay的设备上播放音视频，它应该在媒体播放期间都可以接收远程控制事件。遵循这些原则能使用户在你的应用中处于非媒体情境中时，通过耳机控制获得另一个应用的媒体体验。

尽可能地使用系统原生的控件以提供AirPlay支持。当你使用MPMoviePlayerController类实现AirPlay播放功能时，你可以利用标准的控件使用户可以选择当前范围内支持AirPlay的硬件。或者你可以使用MPVolumeView类来显示用户可选择的支持AirPlay的音频或视频设备。用户习惯于这些标准控件的外观和行为，因此他们可以理解如何在你的应用中使用它们。

不要改变事件的用途，即使这个事件在你的应用中没有意义。用户期望iOS系统的所有应用媒体控制和辅助控制能有功能上的统一。你不必实现你的应用所不需要的那些事件，但你所实现的事件必须产生符合用户期望的结果。如果你重新定义一个事件的意义，你会使用户困惑并冒险把他们带入一个未知的状态，他们只能通过退出你的应用来逃离。

3.20 VoiceOver
VoiceOver增加了对盲人、弱视用户以及一些有特定学习困难的用户的可用性。

为了确保VocieOver的用户能使用你的应用，你需要在你的用户界面中提供一些有关视图和控件的描述信息。对VoiceOver的支持不需要你改变你用户界面内的任何视觉设计。

当你完全遵照标准的方式使用标准的用户界面元素时，几乎不(即使有也很少)需要增加额外的工作。你的用户界面越趋向定制化，你就越需要提供更多的信息来保证VoiceOver能准确的描述你的应用。

增加你的iOS应用对VoiceOver用户的可用性，可以扩大你的用户基础并帮助你进入新的市场。支持VoiceOver也可以帮助你遵守由主流群体所制定的可用性指导准则。

3.21 路线选择(Routing)
地图可以显示到达用户目的地的可选路线：

当人们想要获得关于某条路线的更多交通信息时，地图也可以显示能提供路线选择的应用列表(包括安装在设备上的应用也包括应用商店中的应用)。

路线选择应用可以提供当前选择的路线有关的信息。人们希望路线选择应用能够快捷、易用，特别是保证准确性。依据本章提供的指导原则能帮你为用户提供他们可信任的交通信息和他们期望的用户体验。

重要：地图能依据人们选择的路线给他们提供驾车和步行的指示。路线选择应用可以提供交通信息，它着重于使用交通工具(如公交车、火车、地铁、渡船、自行车、行人、穿梭巴士等)的模型替代实物逐步地指示方向。

如果你的应用不能提供用户指定的路线的交通信息，那么不要将你的应用定位为路线选择应用。

实现你的应用所承诺的功能。当人们在交通列表里看到你的应用时，他们认为它可以帮助其到达目的地。但是如果你的应用不能提供所选路线的信息，或者它没能涵盖它看似应该涵盖的那些种类的交通信息，人们就不会愿意给它第二次机会。准确的表达出你的应用的能力是十分重要的；否则，你的应用会看起来像是在故意误导用户。

在你的路线选择应用中，有两种主要的方式可以给用户信心：

尽可能准确的定义你所支持的地理区域。例如，如果你的应用能帮助人们获得巴黎的公交线路的信息，那你所支持的地区应该是巴黎，不是法兰西岛，也不是法国。
明确你所支持的交通信息类型。举个例子，如果你专攻于地铁信息，不要暗示你仿佛支持所有的轨道交通类型

注意：虽然准确的报告你所支持的地区可能意味着会减少你的应用在交通信息列表里的出现次数，但这么做却可以帮助用户更加信任它。

为易用性合理组织界面。易用性对于路线规划应用来说特别重要，因为用户常常会在极具挑战性的情况下使用它们——例如在明亮的阳光下、在昏暗的车厢内抑或是在颠簸的旅程中，或在非常紧急的情况下。要确保你的文字在任何光照条件下都能容易的阅读，确保按钮即使在并不平稳的旅程中也能易于准确点击。

专注于路线。虽然辅助信息会很有用，但你的应用应该专注于为用户提供逐步的指示以便他们能据此到达目的地。特别要强调的是，你要让用户知道他们处于哪一步，并知道如何到达下一步。你可以提供额外的数据(比如时间表或系统地图)，但不要让这些数据比交通信息还重要。

为路线的每一步提供信息。永远不要让用户感觉被你的应用所遗弃。即使在可以准确的报道你所支持的地区时，你也不能假定用户已经抵达的路线中的第一个交通节点或是最后一个交通节点就是他们目的地点。为了控制这一情况，首先就是测量起点到终点距离。如果距离足够短，要提供从用户当前位置到第一个交通节点及从最后一个交通节点到用户目的地的步行方向指示。如果步行不是一个合理的选择，尝试描绘用户的其他选项。如果必要的话，你可以给用户提供打开地图，获取这部分路线的步行或驾车方向指示的方式。

当用户从地图应用切回你的应用时，不要要求他们重复输入信息。如果用户从地图应用切入(你的应用)时，你已经获知了他们中意的起点与终点，因此你可以在应用打开时直接呈现适合的交通信息。如果用户从主屏幕中开启你的应用，要为他们提供简洁的方式用以输入路线详情。

显示图文并茂的交通信息。地图页面可以帮助人们以更大的、实物性的视角查阅他们完整的线路；清晰的步骤可以帮助人们专注于他们抵达目的地所需采取的必要行动。最好可以同时支持这两个任务并能让用户便捷地进行切换。

注意：无论以什么格式，最重要的是显示与用户线路相关的相同的交通信息。例如，如果路线中包含五个步骤，在地图和路线列表页中必须描绘相同的五步。

当你的应用被从交通列表中选中时，需要以显示完整的线路做为良好的开始(包括在地图页面中显示始于或抵达交通节点的步行路线)。地图页面可以为用户提供他们旅途的多步骤的总览，并能展示适于周遭地理环境的路线。

用附加信息丰富地图页面。人们期望你的应用中的地图可以表现的与他们使用过的其他地图相似。除了用户能放大和缩小以外，你还应该显示用户所需的那些注释信息。例如，你应该显示图钉用以代表用户当前的位置、目的地以及沿路的转乘点或重要的节点。

确保避免只显示一个单独的图钉，因为对用户来说，如果没有额外的背景，很难理解它代表什么。欲了解在你的应用中使用地图页面的更多信息，请参阅Map View.

尽可能地整合静态地图页面，例如在地图视图中加入地铁系统地图等。一个很好的实现方法就是在地图页面覆盖静态图片，以便用户可以看到他们的路线及他们的当前位置是如何与更大的交通系统相关联的。

注意：如果你决定让应用显示一个静态的地图图片，要确保使用高分辨率的图片以保证用户在缩放时维持高质量的显示。

给用户提供不同的方案来挑选多样的交通选择。很多因素会影响人们交通的选择，例如不同的时间段，天气以及他们携带东西的多少，所以提供简洁的不同交通方式的对比是十分重要的。例如，你要能让用户可以依据开始或结束的时间、需要步行的数量、沿途停下的次数抑或转乘的次数或所需的不同的交通类型等来挑选交通方式。不管你显示多种交通选择的顺序如何，确保用户能立即分辨出这些选项的不同之处。

考虑使用推送通知为人们提供与路线相关的重要信息。尽可能的让人们了解交通情况信息的变化，以便他们可以据此调节自己的计划。例如，如果火车晚点或者巴士路线临时停滞，人们可能会需要选择不同的交通路线到达目的地。而在一条不同步骤的站点之间相隔很长距离的交通路线中，人们会希望在他们的交通工具将要抵达行程中的下一部分时能获得通知。

3.22 编辑菜单(Edit Menu)
用户能呼出一个编辑菜单来完成诸如在文本视图、网页或图片视图中的剪切、粘贴以及选择操作。

你可以通过调整一些菜单的行为使用户对你应用中的内容有更多的控制权。举个例子，你可以：

列举出适用于当前情境的标准菜单的命令
在菜单显示前判定菜单的位置，以避免你应用的用户界面中的重要信息被遮盖
定义当用户双击展开菜单时会被默认选中的对象

你不能改变菜单本身的颜色和形状。

欲了解如何在代码中实现这些行为的相关信息，请参阅Copy, Cut, and Paste Operations.

为了确保编辑菜单在你的应用中的表现符合用户期望，你应该：

显示在当前情境下合理的命令。例如，当没有对象被选择的时候，菜单中不应该包括复制或剪切(命令)，因为这些命令是针对选择(的内容)而操作的。相似地，如果有对象被选择的时候，菜单中不应该包括选择(命令)。如果你在自定义页面中支持编辑菜单，你就有责任确保菜单中显示的命令切合当前的情境。
依据你的页面布局调节菜单显示。iOS依据可获得的空间大小选择在插入点的上方或下方来放置菜单指针以显示编辑菜单，这样用户就能看到菜单命令是如何与内容相关的。在必要的情况下，你可以通过程序在菜单显示之前决定它的位置，这样可以避免用户界面中的重要信息被遮挡。
支持两种手势来调用菜单。虽然点击和长按手势是用户呼起编辑菜单的首选方式，但他们也可以在文本页面中通过双击一个单词来选择该单词并同时呼起菜单。如果你在自定义页面中支持菜单，确保它能支持两种手势。除此之外，你可以定义用户双击时默认的选择对象。
避免在你的用户界面中创建和编辑菜单中功能相同的按钮。例如，使用编辑菜单让用户进行复制操作远比提供一个复制按钮要好，因为用户将会想知道为什么在你的应用中会有两种方法做同样的事。
如果静态文本的选择对用户来说是有用的，那么可以考虑使用它。用户可能想要复制图片的标题，但他们不可能想复制选项卡的标签或是屏幕的标题，比如“账户(Account)”。在文本页面内，文字的选择应该是默认设置的。
不要使按钮标题可选择。如果按钮的标题是可选择的，用户很难在不激活按钮的情况下呼出编辑菜单。通常来说，像按钮这样操作的元素不需要是可选择的。
将对撤销与重做的支持与对复制与粘贴的支持组合到一起。人们经常希望在他们改变主意的时候能撤销最近的操作。由于编辑菜单在它操作执行的时候是不需要确认的，你应该给用户提供撤销或重做这些操作的机会。

如果你需要创建自定义的编辑菜单项，需要像下面展示的这个例子一样遵循这些指导原则：

创建直接作用于用户选择的包含编辑、修改或其他操作的编辑菜单。人们期望在当前的情境内用标准的编辑菜单项操作文本或对象，那么你的自定义菜单项最好能有相似的表现。

将自定义项列在所有系统提供的项的后面。不要将你的自定义项与系统提供的项混置在一起。

保持自定义菜单项的数量在合理的范围内。你不应该用太多选择迷惑你的用户。

使用简洁的名称命名你的自定义菜单项并确保名称能准确的描述命令的作用。通常，项的名字应该是一个可以描述行为如何执行的动词。虽然你通常会使用单个的大写单词作为名字，但如果你必须使用一个短语(作为名字)时，就应使用标题式大写短语。(简洁的、标题性的大写词就是将除了文章、四字及四字以下的并列连词与介词之外的单词都大写。)

3.23 撤销与重做(Undo and Redo)
用户通过摇晃设备触发撤销操作，显示提醒框让他们可以：

撤销他们刚才输入的内容
重做先前撤销的输入
取消撤销操作

你可以通过在你的应用中定义出更通用的方式来支持撤销操作：

允许用户撤销或重做的行为
在你的应用的哪种情形下晃动手势是用于撤销操作的
支持多少步的撤销

欲了解如何用代码实现这一行为，请参阅Undo Architecture.如果在你的应用中支持撤销和重做，请遵循以下准则以提供好的用户体验:

为用户提供简洁的描述性短语使其能准确的获知他们正在撤销或重做的内容。iOS系统自动提供了“撤销”和“重做”的字符串(包括词语后面的空格)作为撤销警示按钮的标题，但你需要提供一或两个词语用于辅助描述用户的重做或撤销操作。例如，你可能提供文本的“命名”或“地址更改”之类的词语用以创建像“撤销命名”或“重新更改地址”这样的按钮标题。(要注意，在提醒框中，“取消”按钮是不能改变或移除的)。

避免提供的文本过长。太长的按钮标题容易被断章取义并且很难被用户解读。由于这个文本用于按钮的标题中的，要使用标题样式的大写形式并且不能添加标点。

避免过度使用摇晃手势。即使你能程式化地设定你的应用将摇晃事件作为用户激活撤销操作的途径，你也在冒着混淆用户视听的风险，因为他们也可能使用摇晃执行另一个不同的操作。分析你应用中的人机交互以避免创建那些用户无法可靠地预测摇晃手势结果的场景。

如果撤销和重做在你的应用中是基础性的任务，尽量使用系统原生的撤销与重做按钮。记住摇晃手势是用户触发撤销与重做操作的主要方式，而如果提供两种不同方式完成同样的任务则会使用户困惑。如果你认为很有必要提供直观专有的撤销与重做操作，你可以在导航栏中放置系统原生的按钮。(欲了解更多关于这些按钮的信息，参见Toolbar and Navigation Bar Buttons).

将撤销与重做能力与用户当下的情境进行清晰地关联，而非过早地介入情境。仔细考虑你允许进行撤销与重做操作的情境。通常来说，用户期望他们的改变和操作可以立即被有效的执行。

3.24 键盘和输入页面(Keyboards and Input Views)
在iOS8与之后的系统中，你可以创建自定义的键盘扩展内容来替代系统的原生键盘。欲了解更多关于管理应用内扩展(包括键盘)的信息，请参阅APP Extensions；欲了解如何开发自定义的键盘扩展内容的信息，请参阅Custom Keyboard.

在合适的情况下，你9也可以在你的应用内设计自定义的输入页面来替代系统原生的屏幕键盘。例如，Numbers(译者注：iWork中的电子表单应用程序)中提供了多种输入页面，这些页面设计使数量、日期和其他值的输入能简单高效地完成。

如果你提供自定义输入页面，确保它的功能对于来用户来说是清晰易懂的。

你也可以提供自定义的输入辅助视图，这种视图通常表现为显示在键盘(或你的自定义输入页面)上方的一个独立元素。例如，在某些情境中，Numbers会显示一个输入辅助视图用以帮助用户执行针对电子表格中的值的标准或自定义计算。

当用户在你的输入页面中敲击自定义控件时，使用标准的键盘敲击声提供声音反馈。欲了解在代码中如何使用这一声音，请参阅UIDevice Class Reference中的playInputClick章节

注意：标准的敲击音效只适用于当前屏幕上的自定义输入页面。人们可以在设置-声音中关闭所有的键盘音效(包括你的自定义输入页面中的那些)。

本章英文原文访问地址：iOS Human Interface Guidelines

本章中文翻译PDF下载：点此下载

iOS 9人机界面指南(三)：iOS 技术 (下)

相关阅读：

相关文章