[ISUX译]iOS 9人机界面指南(三)：iOS 技术
[ISUX译]iOS 9人机界面指南(三)：iOS 技术
本文译自苹果官方人机界面指南 iOS Human Interface Guidelines ，由腾讯ISUX设计师翻译整理，非发文者一人之做。html
文章索引ios
- 3.1 3D触摸(3D Touch)
- 3.1.1 轻压和重压(Peek and Pop)
- 3.1.2 主屏幕快捷操做(Home Screen Quick Actions)
- 3.2 Live Photos
- 3.3 钱包(Wallet)
- 3.4 苹果的移动支付平台(Apple Pay)
- 3.5 研究型应用程序(Research Apps)
- 3.6 应用扩展(App Extensions)
- 3.6.1 今天部件(Today Widgets)
- 3.6.2 分享和动做扩展(Share and Action Extensions)
- 3.6.3 图片编辑扩展(Photo Editing Extensions)
- 3.6.4 文档提供者扩展(Document Provider Extensions)
- 3.6.5 自定义输入法(Custom Keyboards)
- 3.7 HomeKit
- 3.8 多任务处理(Multitasking)
- 3.9 通知(Notifications)
- 3.10 社交媒体(Social Media)
- 3.11 iCloud
译者注：本文译自苹果官方人机界面指南 iOS Human Interface Guidelines (2015年10 月21日)，由腾讯ISUX设计师翻译整理，非发文者一人之做。译文首发于ISUX博客，如在阅读过程当中发现错误与疏漏之处，欢迎不吝指出。后续章节会陆续更新，敬请期待。编程
3.1 3D触摸(3D Touch)api
3D Touch 给 iOS 9 用户提供了一个新的交互维度。在所支持3DTouch的设备上，人们能够经过按压应用的图标去快速选择应用定制的操做。在应用内，人们能够使用多种按压操做去获取一个项目的预览，能够在独立的视图里打开一个项获取相关操做。(了解更多在你的代码中如何添加3D Touch支持，参阅 Adopting 3D Touch on iPhone .)缓存
3.1.1 轻压和重压(Peek and Pop)安全
轻压让用户能够在不离开他们当前环境的状况下预览一个项和执行相关操做。支持轻压的该项会在轻压后给出一个小矩形视图做为反馈。服务器
在Safari中的一个轻压视图markdown
在Safari轻压中的快速操做app
轻压(Peek)：框架
- 当用户按压在一个支持轻压的项上时出现轻压，用户手指抬起后会消失
- 当用户在轻压视图下再更加剧一点的按压称之为重压，重压能够查看该项的详细视图
- 当用户在轻压视图中向上滑动，能够提供与该项相关的快速操做
当用户轻轻按压在屏幕，支持轻压的这个项会展现一个你提供的矩形视图，示意能够进行下一步交互操做。那个视图应该够大，这样才能让用户手指不会混淆内容，这个视图应该足够细节，这样可让用户选择是否去更加剧一点按压从而转换到轻压视图。
重要
你在应用中始终如一提供轻压和重压的体验是相当重要的。若是你在有些地方支持轻压和重压，在某些地方不支持，用户有可能认为你的应用或者他们的设备出现了问题。
使用轻压去为该项提供一个生动的，内容丰富的预览。当轻压可以给用户提供关于该项的足够信息，从而帮助他们扩展当前的任务，这样作是最好的。例如，在用户决定好是在Safari中打开信息中的网页仍是分享这个连接给朋友以前，用户能够使用轻压预览信息中URL的页面。在表单视图中，轻压能够给用户提供一个行项的详细内容。
为每一个轻压提供重压。虽然一个轻压能够提供给用户所须要的大部分信息，可是你应该可让用户过渡到重压，从而让用户放开当前正在进行的任务，转移专一力到该项上来。重压的内容应该与用户点击该项后的内容一致。
不要为一样一个项授予轻压和编辑菜单(Edit menu)两个功能。当同一个项的这两个功能都启用的时会很混乱。(获取更多编辑菜单信息，参看 Edit Menu.)
在轻压操做里，避免展示相似按钮的界面元素。若是用户抬起手指去点击像按钮的元素，轻压会消失。
若是可能，提供轻压快捷操做。 在轻压里，用户能够向上滑动去显示该项的相关操做。例如，Mail里的轻压快捷操做包括回复所有，转发和删除信息。并非每一个轻压都须要快捷操做，可是若是你已经为该项提供定制的点击并长按的操做，那么最好在轻压里提供相同的操做从而替代点击并长按操做。(注意在网页视图中，轻压快速操做是自动提供的。)
不要将轻压做为惟一开启该项的指定操做的方式。不是每个设备都支持轻压和重压，一些用户可能选择关掉3D Touch, 所以在你的应用中去寻找其余方式实现轻压的功能是很是重要的。当你的应用在较旧的设备上运行时，能够把轻压的快捷操做映射到一个视图里，让用户经过点击并长按得到。
3.1.2 主屏幕快捷操做(Home Screen Quick Actions)
主屏幕快捷操做能够在主屏幕给用户呈现方便的、有用的、应用特定的操做。
Camara的主屏幕快捷操做
Mail的主屏幕快捷操做
主屏幕快捷操做：
- 当用户在主屏幕采用比点击且长按更重的按压，按压在应用图片上时，出现屏幕快捷操做
- 它会显示一个你提供的短标题，一个图标和可选的副标题
- 它不支持其余定制的内容
- 它能够随着你应用的更新，更新显示的信息
使用主屏幕快捷操做去开启引人注目的、高价值的任务。例如，Maps可让用户不须要打开Maps，经过在当前位置附近搜索就能够得到回家的方向。一个应用至少须要把一个有用的任务放在主屏幕快捷操做里；你能够提供最多四个快捷操做。
避免使用主屏幕快捷操做去减小应用里导航的内容。若是用户访问你应用的重要区域很是困难和耗时，那么首先去修改你的应用的导航，这样作是可让全部用户都获益的。接着，能够去为有用的深层次连接提供主屏幕快捷操做，从而开启这些有用的、创造性的任务。
不要把主屏幕快捷操做做为通知用户的一种方式。iOS用户指望以其余方式接收应用中的信息(更多信息参看 Notifications)。
为主屏快捷操做提供一个简洁的标题(可有副标题)和一个模板的图标。标题应该直接传达这个操做的结果；例如，“回家的方向”，“新建联系人”，和“新建信息”。你也能够提供一个副标题给用户更多上下文信息。例如，Mail使用一个副标题在主屏快捷操做的重要位置去告诉用户有未读信息。 不要把你的应用名字或者无关的信息放在标题和副标题里，同时要考虑到使用本地化的用语。
保持标题的简洁不会被切断从而帮助用户快速理解操做是很是重要的。若是你提供的副标题一行显示不全，系统会截断；若是你没有副标题，系统会把一行展现不彻底的长标题以两行展示。
你能够从不少系统提供的模板图标中选择图标，你也能够创做定制的模板图标。更多关于图标尺寸、内边距和定位的详细引导信息，能够下载主屏快速操图标模板 https://developer.apple.com/design/downloads/Quick-Action-Guides.zip。更多关于设计模板图标的信息，参看Template Icons。
系统会自动安排图标在快速操做列表中的位置是在左侧或者在右侧，这依赖于你的应用的图标在用户主屏幕的位置。(摒除图标在列表中的位置，在自左向右的语言中文字老是左对齐。)这里有主屏快捷操做的多种展示方式的例子。
3.2 Live PhotosLive Photos
让用户在丰富的声音和动做环境下，捕捉和再现他们喜好的回忆。从iOS 9开始，相机(Camera)应用能够捕捉附加的内容(拍照以前和结束后的声音和额外的画面)为传统的、静止的图片增长生活气息。
在iOS9.1及以后的版本中，你的应用可让用户享受和分享Live Photos。这个指引能够帮助你给用户提供更好的体验。
在不支持Live Photo的环境中，把Live Photo像传统照片同样展现。不要在支持Live Photos的环境中，自定一种与Live Photo类似的体验。
不要分开展示Live Photo的附加画面和声音。要让用户在不一样的应用中体验Live Photos时，有一致的视觉呈现和交互方式。把Live Photo拆分开展示是一个很坏的体验。
确保用户能够区分Live Photo 和传统静止图片。在用户分享照片时，帮助他们作好区分是特别重要的。最好在用户查看一个LivePhoto的时候，展示一点移动做为提示。万一这个提示没有起到做用，你能够在LivePhoto上展现一个系统提供的标记。LivePhoto不要展示一个像视频里回放按钮的界面元素。
注意
上图这种状况，不支持像照片应用里全屏浏览滑动切换照片时的显示的
把用户所作的调整应用到Live Photo的全部帧中。若是你的应用可让用户为照片添加滤镜或者调整，应确保它能够做用于整个LivePhoto中。若是你不支持调整用户想分享的
LivePhoto的全部内容，要让他们知道能够以传统照片的方式分享。 让用户在决定分享前，能够预览这个Live Photo的全部内容。若是你的应用UI可让用户选择照片分享，要为他们提供一个把Live Photo做为传统照片分享的方式。 若是你使用系统提供的标记，应该把它放在每一个LivePhoto上一样的位置。标记能够放在一个不会影响用户查看照片的角落。确保在你的应用中采用一致的方式添加标记，这样可让用户依靠它去识别LivePhoto。iOS有两种方式提供标记：
- 覆盖。这种覆盖的方式包含一个阴影，适合覆盖在照片上
- 纯色。这种纯色的方式(无阴影)能够被用来建立一个可调色的图片模板
- iOS也提供了不少纯色标记，其中，图片上一个删除线表明如今的LivePhoto被当作是一个传统的照片
在用户下载一个Live Photo的时候给他们一个好的体验。尤为重要的是，用户须要知道他们正在下载的是一个LivePhoto，他们须要知道何时能够播放它。若是你为一个Live Photo展现一个未播放的进度指示器，确保这个指示器与你的应用中其余的下载体验一致。
3.3 钱包(Wallet)
Wallet应用是帮助用户查看和管理各类数字化票券的，他们是一些物理个体的数字展示，例如登机牌、优惠券、会员卡、奖励卡和各类票。Wallet也可让人们添加他们的信用卡、借记卡和储值卡结合Apple Pay使用。你能够在应用中建立一个票券，分发给用户，而且在有更改时进行更新。
使用PassKit框架能够方便地用自定义内容来收集一个票券和使用户票券库中的票券。(想要学习Passbook技术的核心概念和PassKit接口的使用方法，请参考Passbook Programming Guide。)如下几点能够帮助你建立一个用户乐意保留并使用的票券。
设计一个在各个设备上呈现很好票券。当你选择一个票券的样式——好比登机牌，优惠券，票据，奖励卡或者通用的票券——你会得到一个特别的布局和一系列区域去处理(更加详细关于不一样票券的样式，参看Pass Style Sets the Overall Visual Appearance)。这个系统在各个设备上合理展现你的票券，因此正确使用票券的区域是很是重要的。例如，在Apple Watch上，条状图(strip)和缩略图(thumbnail)图片是不显示的，因此你不但愿把基本的信息放到这些元素里。更多Apple Watch票券的布局，参看Designing Passes for Apple Watch.
使用合适的票券区域展示文本。在你的票券中使用容许VoiceOver的用户获取票券中的全部信息的区域，保持你的票券外观的一致性。避免将文本嵌入图片或使用自定义的字体也是一个很好的方法，由于不是全部的图标会展现到全部的设备上，这样对用户来讲阅读这样的文字会有困难。
避免使用识别一个设备的语言。你不能预料到哪些用户将会查看你的票据的设备，所以你不想使用可能在一个特别设备上不起做用的语言。好比，文字告诉用户“滑动去查看”内容，当这个发生在Apple Watch上将会不起做用。
尽量，不要只是简单复制已有的物理票券。Wallet 已经创建了有美感的设计，票券也都配合这种设计以看起来更好。因此不要只是复制物理票券的外观，抓住此次机会设计一个符合Wallet 组成和功能的干净简洁的票券样式。
对放在票券正面的信息精挑细选。用户指望扫一眼票券就能快速得到他们须要的信息，因此票券正面的信息应该是整洁且易读的。若是有用户可能会须要的额外信息，将它们放到票券的背面要比挤在正面好得多。注意，Apple Watch上的票券没有背面。
一般状况下，避免使用纯白色背景。一般，一个好看的票券应该使用鲜艳的纯色背景或者使用强烈的，充满活力的图片做为背景。固然，在设计背景时还要确保内容的可读性。
在商标文本区域显示你的公司名称。全部票券的商标文本区域的文字都使用了统一的字体。为了不和其余票券发生冲突，仍是建议您在商标文本区域输入文字，不要使用自定义字体。
使用白色的公司商标。商标图片放置在票券左上角公司名称的旁边。最好提供一个白色的，单色的，不包含文字的商标。若是你想要加强商标的效果，又想要与文字风格匹配的话，能够增长一个在y轴方向上有1像素偏移，有1像素模糊和透明度为35%的黑色阴影效果。
若是能够的话，使用矩形的条形码。相似于PDF417这样的长方形条形码比正方形二维码更适合票券的布局。以下右图所示，正方形的二维码会使两边有空白区域而且会在垂直方向上使上下方内容变得拥挤。
为性能去优化图片。由于用户一般会经过电子邮件或者Safari接收票券，因此让下载的越快越好是很是重要的。为了提升用户体验，使用能知足视觉效果的最小的图片文件。
在合适的时候更新票券以加强其效用。即便一个票券表明的是一个并不会改变的物理实体，数字的票券也能够经过映射真实世界的一些事件来提供更好的用户体验。例如，当某个航班延误时你能够更新登机牌上的信息，这样用户就可以经过查看电子登机牌来得到当前的信息。
3.4 苹果的移动支付平台(Apple Pay)
Apple Pay是苹果公司面向iOS移动设备推出的一种简单、安全、我的的移动支付方式。当用户在购买实体商品和服务时时，能够使用Apple Pay快速、安全地提供我的联系方式、收货地址以及付款信息。
经过用Apple Pay支付，用户无需每次购物都要建立帐号或填一遍我的信息。Apple Pay显著加快了支付流程，有助于消除前期的各类信息登记，进而为用户的“无障碍”选购过程提供更好的体验。欲了解更多信息，请参阅 Apple Pay Programming Guide. Apple Pay的用户界面很是清晰、简洁高效、低调。它包含三个界面元素，各出如今不一样的上下文情境中。
按钮。Apple Pay的按钮用来告诉用户，他们能够在当前的情境下(好比商品页面)完成购买。当用户点击了Apple Pay的按钮，当即显示支付上拉菜单(见下文) 开始帮助用户完成支付流程。用户经过“设置Apple Pay”的选项Apple Pay的相关银行卡信息绑定操做。经过调用PKPaymentButton API口能够找到这两个按钮(想要了解更多信息，请查阅PKPaymentButton Class Reference)。有关使用Apple Pay支付按钮的更多详情，请参阅Identity Guidelines.
Apple Pay支付标识。当用户须要在受权支付以前选择付款方式并敲定其余信息时，他们指望看到Apple Pay的支付标识。Apple Pay的支付标识应该同其余付款方式以相同或相似的格式显示。
支付上拉菜单。在用户提交订单以及完成相关支付以前，Apple Pay会显示一个包含了联系方式、收货地址以及与结帐相关付款信息的支付上拉菜单。尽管用户依然能够在支付上拉菜单里作些微调，好比选择不一样的送货方式，但他们不用作出重大改变或输入其余信息。当用户看到该支付上拉菜单，他们应该可以当即完成交易并受权付款。
对于能够使用Apple Pay付费的用户，Apple Pay的用户界面应当始终显示。若是用户的移动设备支持Apple Pay，而且他们已经激活了相关可用的银行卡所以能够经过将Apple Pay设为默认支付方式来知足用户的指望。
若是用户没法使用Apple Pay服务，就不要显示任何Apple Pay的用户界面。若是用户使用的设备不支持Apple Pay，仍强行将其做为一个支付方式选项，可能会对用户形成混淆。可是，若是用户使用的设备是支持Apple Pay，但没有绑定任何信用卡或借记卡，你能够在界面中显示“设置Apple Pay”的按钮。
当用户点击了Apple Pay的按钮，当即显示支付上拉菜单。当用户决定使用Apple Pay来结帐时，若是还要迫使用户经历额外步骤，会使支付流程显得复杂，增长没必要要的矛盾，并可能会让用户感到沮丧受挫。当用户点击了Apple Pay按钮，不要显示其余警告或模态对话框视图。若是用户能够提供像打折或促销代码之类的信息，请在用户点击Apple Pay按钮以前找到一种方式来接收该信息。
Apple Pay按钮与其余可见的支付按钮应保持相同的尺寸大小或更大。将Apple Pay按钮放置在醒目的位置，能够帮助用户轻松找到它。
使用Handoff功能帮助用户完成在Apple Watch上发起的购买。 Apple Watch佩戴者能够在商店完成支付，但他们没法完成由Apple Watch第三方应用程序调用的支付行为。当Apple Watch佩戴者发起了由第三方应用程序调用的支付行为，则显示一条消息告诉他们请在iPhone上完成支付。为了更好的用户体验，还能够使用Handoff功能深层连接到你的iOS应用程序上，并当即显示包含预设好的相应付款信息的支付上拉菜单。
有关使用Apple Pay支付按钮以及Apple Pay支付标识的更多信息指南，请参阅 Apple Pay Identity Guidelines.
3.4.1 自定义支付上拉菜单 (Customizing the Payment Sheet)
根据完成交易付款所须要了解的信息，以及所要传达给用户关于本次购物的信息，来自定义Apple Pay支付上拉菜单所要显示的内容。
支付上拉菜单仅显示对完成交易付款有必要的信息。若是Apple Pay支付上拉菜单显示了些无关的信息，用户可能会感到困惑或焦虑。举个例子，若是商品是在线交付或经过电子方式完成，须要联系人的电子邮件地址是有意义的，而不是收货地址。在这种状况下，要求收货地址可能给用户产生会有什么东西将意外被派件到家中或公司的错觉，或许还可能致使他们对我的隐私被访问产生没必要要的担心。
支付上拉菜单容许用户能够选择更换送件或取件方式。用户能够从你在支付上拉菜单中设定的几种交付方式中随意选择一种。经过用文本标签控件、报价以及可选的第二行预计到达日期，来具体描述一种收货方式。另外，你还能够设定交付方式为“派件”或“取件”，让用户指定一个可接收快递送货上门或须要运输服务取件的位置。
使用并排项来描述周期性付款和一些购买费用的小计。 并排项包含了一个标签文本和花费数值。并排项被用来：
- 代表用户受权一个按期付款项目，好比“每个月订阅 $19.99”
- 告知用户关于额外费用，好比“礼品包装 $5.00”和“税费 $4.53”
- 显示优惠券或折扣信息带来的减价，好比“周五特价 -$2.00”
- 描述某个项目须要按实际计费，好比运输服务“时间&距离 …”
不要用并排项来显示所要购买的商品的构成清单。
建立并排项标签时，尽量显示在同一行。并排项标签应该具体、容易理解。若是行条目标签字符数过长，那么很难让你的用户一看就懂。
商户名称须要牢牢跟随在同一行的“Pay”字符后面做为一个总体。确保所使用的商户名称以及相应的开销支出，必须与用户检查本身的信用卡或银行对帐单时的数据保持一致。这一点很重要，由于它有助于用户确信他们的开销支出是无误的。若是你的应用程序只是做为中间媒介，而不是最终的商户支付，请明确向用户代表这个具体说明“付款给 最终的商户名称(经过 你的应用程序名称)。
若是总价花费在支付受权时还不明确，请向用户传达有可能会有额外费用的信息。举个例子，一次汽车旅程从支付受权时刻起到驶向最终目的地，它的开销报价可能会受行车距离或时间的影响变化。或者，一个客户可能想要给点小费在商品已派件以后。对于这样的状况，在支付上拉菜单中给予一个很是明确的解释说明是颇有必要的。当你使用一个并排项来配置最终总价的更新信息时，总价金额会自动显示为“总价待定”。另外，若是你是预受权支付一个具体金额的订单，确保支付上拉菜单准确地反映了这一信息。
3.4.2 简化结帐流程(Streamlining the Checkout Process)
Apple Pay使得购物变得快速、简单，对此人们会欣然接受的。更少的步骤和更少的须要用户手动输入的信息，使得整个结帐流程更好。
始终使用Apple Pay的最新数据信息。假设用户一直保持Apple Pay我的信息的完整性和时刻更新，那么不要依赖于任何先前收集的信息。即便你之前已收集过用户的联系方式、交付方式和支付信息，也要在结帐时获取来自Apple Pay的最新信息。在结帐环节，尽可能避免用户输入本能够从Apple Pay获取的任何信息。
使用Apple Pay加快购买。对于单个商品项目的购买，让用户只需经过点击商品页面上的Apple Pay支付按钮，便可显示支付上拉菜单并进行即时结算。购买单个商品时，无需采起额外的步骤，也无需将商品添加到购物车，用户喜欢在应用程序中体验到这种便利性。对于多个商品被添加到购物车中会使用相同的交付方式被送到相同地址的状况，一旦用户有意向支付时，会经过显示支付上拉菜单的快速结帐流程来支持。
在显示支付上拉菜单前需提早收集好赎回代码或促销代码。由于在Apple Pay支付上拉菜单中没有办法输入这些代码，请务必在显示支付上拉菜单以前收集好相关代码。
若是人们能够将购买的商品派送到不一样地方，或以不一样的速度发货，请在显示支付上拉菜单以前提早收集好该信息。对于这种极端状况，你须要在显示支付上拉菜单以前获得发货信息，由于在支付上拉菜单中没有办法来指定多种交付方式和地址。通常状况下，在支付上拉菜单中务必收集到交付方式和地址信息。
显示订单确认页面或致谢页面。在交易完成时，经过使用订单确认页，以这种直接的用户体验来显示关于商品能派送到的预计时间以及用户如何跟进订单状态的信息。
若是合适的话，请在你的订单确认页上提到Apple Pay。尽管在你的确认页面上提到Apple Pay不是必要的，若是你愿意选，能够使用其中的一种格式：
- “Visa 1234(Apple Pay)”
- “用Apple Pay已完成付款”
3.5 研究型应用程序(Research Apps)
研究型应用程序可让苹果用户充分利用iOS移动设备的便利性，参与到各类研究性学习中来。经过调用开源代码ResearchKit，使用预设的几种界面视图和转场动画，能够很轻易为你的研究和参与者自定义一个美观易用的研究型应用程序，这些资源均可以在苹果的开源代码ResearchKit项目中调用。要想了解如何使用ResearchKit来为你的研究开发一个研究型应用程序，请查阅researchkit.org.
重要
这些规范准则仅供参考之用，并不构成任何法律意见。对于与你的研究型应用程序发展以及任何法律适用的相关建议，你应该向律师咨询。
一般状况下，一个研究型应用程序是由ResearchKit定制化的界面视图以及应用程序自己具体设定的界面视图组成，可概括为三种主要的体验：
- 参与者的就位培训(Onboarding)
- 研究性调查(Study-specific investigation)
- 管理条目信息(Management items)
设计你的研究型应用程序时务必要遵循如下每一个部分的规范准则，将有助于你的用户参与者感到舒服和保持参与感。
3.5.1 参与者的就位培训(Onboarding)
就位培训的体验包含了一系列向潜在参与者介绍研究内容以及征询他们赞成的环节。完成这些之后，参与者一般不会再从新访问这些就位培训的内容环节：
你应该按如图所示的这个顺序呈现就位培训的各个体验环节，也就是按介绍指引、适任、知情赞成，以及受权访问数据。
建立一个具备号召性用语的介绍指引。指引环节应该帮助人们了解更多关于你的研究以及告诉他们如何成为一名参与者。指引环节最好也能向那些现有的参与者提供快捷登陆的入口以便继续正在进行的研究。
尽快确认招募的用户是否合格。适任环节呈如今指引环节以后、知情赞成环节以前(若是参与者并不适合该研究则没有必要让其查看知情赞成环节)。请确认所呈现的适任资质要求对于你的研究来讲是必要的。请使用简单、直白的语言描述这些要求，并让用户能够很容易就输入相关信息。
在获得参与者的赞成以前，确保他们已充分了解你的研究内容。ResearchKit有助于让知情赞成流程显得简洁、友好，同时还容许将你赞成的任何法律规定或由机构审查委员会和伦理审查委员会所设定的规定归入其中。(若是你的应用程序涉及到进行人体生物学相关的研究，必须确保你的应用程序符合现有的苹果应用商店规范指南，并得到参与者的许可。)一般状况下，知情赞成环节包含了：
- 说明这项研究是如何工做的
- 确保参与者了解研究内容以及各自的责任
- 得到参与者的许可
将冗长的赞成书分解成易理解消化的小节。每一个小节能够只覆盖研究内容的一个方面，好比数据采集、数据应用、潜在好处、可能的风险、时间承诺、如何撤出等等。每一个小节请使用简洁、直白的语言来讲明一个高度归纳的内容。若是有必要，提供一个查看详情的按钮便于参与者了解该小节更详细的解释。应该让他们在赞成参与以前，就查看彻底部知情赞成内容。
经过一个小测验来测试参与者的理解状况是有意义的。在得到参与者容许的状况下，你能够选择向每一个参与者询问相同的问题。
你的研究必须得到参与者的赞成，若是合适，还能够收集一些联系人信息。参与者赞成参与研究后，他们须要提供我的签名以及联系方式，最后会收到一个确认对话框。对于这些信息记录，大多数的研究型应用程序会向参与者电邮一份PDF格式的赞成书。
参与者须要对这个确认自愿参与研究的告警对话框给予响应
参与者能够提供他们的我的签名在知情赞成流程中
若是你须要访问参与者的设备或数据必须获得他们的许可。必须解释清楚你的研究型应用程序为何须要访问他们的位置信息、健康应用程序或其余数据，而且确保避免向参与者索要对你研究并不是相当重要的数据。一样地，若是你须要向参与者发送通知提醒也要得到参与者的许可。
让参与者准备受权访问数据，好比健康应用程序的数据
让参与者本身选择他们愿意与你共享的数据
3.5.2 具体研究的调查(Study-Specific Investigation)
为了从参加者得到数据输入，你的研究可能会使用状况调查、活动任务，或二者的组合。根据你的研究的体系结构，参与者可能会在每一个环节屡次或仅需完成一次交互便可。
问卷调查的设计应该能让参与者专一参与其中。 ResearchKit能够很容易就呈现多种答案类型的调查问题，好比对错、多选、日期和时间、比例计算，以及开放式文本填写。当你使用ResearchKit的界面视图来建立一项调查，请遵循如下准则，来保证好的用户体验：
告诉参与者总共有多少道问题，以及完成调查预计须要花费的时间
- 每屏只呈现一道问题
- 显示给参与者当前调查的进度
- 调查应该尽量简短。几个简短的调查每每好于一个冗长的调查
- 对于须要额外解释的问题，问题描述请用标准字体大小，而后解释文字用略小的字体大小
- 调查结束时要告知参与者
ResearchKit提供了许多用于调查环节的可自定义界面视图。这里有一些样例。
使得活动任务容易理解。活动任务须要参与者参与到一次活动中来，好比对着麦克风语音、手指在屏幕上完成点击、行走散步，以及执行一次记忆力测试。请按照如下几点准则来鼓励参与者执行活动任务，并给与他们成功的绝佳机会：
- 请用简洁易懂的语言来描述如何执行本次任务。
- 若是任务必须在特定的时间或特定状况下进行，请务必明示。
- 确保参与者能够分辨出任务什么时候结束。
如下是ResearchKit所支持的两个活动任务样例。
3.5.3 管理条目信息(Management Items)
ResearchKit提供了我的档案的界面视图来让参与者能够管理他们的我的信息。此外，建立一个能够激励用户并能让他们追踪他们在研究中的进度的界面视图是个不错的选择。在大多数状况下，参加者应该可以随时访问这两个模块。
使用我的档案来帮助参与者管理我的信息和与你研究相关的数据。我的档案界面视图容许参与者在研究进程期间能够编辑相应数据，好比体重或睡眠习惯，而且能够提醒他们即将到来的活动任务。你一样能够在我的档案中给予参与者一种简单的方式离开该研究、查看知情赞成书，以及查看该应用程序的隐私政策。
使用仪表盘概览视图来激励参与者，并呈现进度。一个概览视图可让你与参与者对信息尽收眼底并鼓励他们继续参与。若是你的研究内容合适的话，你能够使用该概览视图给予参与者丰富的反馈，好比每日进度、每周评估、具体活动的结果，以及同其余参与者的汇总结果进行对比。
3.6 应用扩展(App Extensions)
应用扩展能够延伸应用的使用范围。当用户使用其余应用时，应用扩展使得用户仍能使用你应用的核心功能。举个例子，当人们在Safari中浏览网页时，他们能够使用你的分享扩展来发送一张图片或一篇文章到你的社交网站上。或者当使用Photos(照片)应用时，人们可能会使用你的图片编辑扩展来为一张图片加上一个滤镜效果。(在这些场景中，Safari和照片应用承载用户使用扩展的场景，于是被称为宿主应用(host apps)。)
你须要提交包含应用扩展的完整iOS应用到App Store(包含扩展的应用被称为容器应用(containing app))。在你的容器应用中启用扩展以后，人们就能够在使用其余应用时，使用扩展来执行快速任务。例如，在邮件中浏览某个商品时，人们能够不用离开邮件应用就使用你的动做扩展来把商品添加到购物清单中。 表 22-1 列举了能够多个建立的iOS应用扩展类型。
如下指南适用于全部类型的应用扩展，针对特定类型应用扩展的指南请参阅后续章节。(若是想了解如何开发、调试和发布一个扩展，请参阅App Extension Programming Guide.)
确保是单任务。应用扩展并非应用的精简版，它帮助用户在有全局目标的上下文中完成狭义范围内的有限任务。例如，动做扩展能够为用户提供一种不一样的方式来查看当前内容。
保证用户的交互是有限和流畅的。好的应用扩展应该只需几步点击就能够帮助人们完成任务，这样他们就能尽快回到以前的场景中。例如，分享扩展只需一次点击便可完成一张图片的分享。
将容器应用及其应用扩展的名称保持一致。一个容器应用中若是有多个扩展，须要使用不一样的名称，你须要确保用户可以理解你的扩展和应用之间的关系。人们会在不少不一样的状况下遇到扩展，若是他们当下没有认出来，那么他们就未必会信任这些扩展。
大部分状况下，复用容器应用的图标。显示用户熟悉的图标是得到用户信任的另外一种方式。请注意，对于动做扩展来讲，你应该使用单色版本的容器应用图标(详见分享和动做扩展)。
重要：和设计图标和图形同样，不要重复使用iOS的图标和图片，不要为苹果的产品和设计再设计一套图片。
避免在扩展上显示模态视图。不少扩展默认以模态视图来显示，因此应避免再叠加模态视图。尽管有时候用户可能会在扩展上遇到警告框，可是在设计扩展的流程时，应避免出现模态视图。
3.6.1 今天部件(Today Widgets)
人们会在通知中心的今天区域中查看今天部件(Today widgets)。由于人们会设置今天区域以显示他们最关注的信息，因此在此进行设计能够有效帮助你的部件在这些用户最重要的信息中占据一席之地。
设计与通知中心风格一致的外观。当使用通知中心的默认边距和背景时，你的今天部件就会给用户以统一的体验。为得到最佳的结果，你应该重点关注你的内容而不是背景或者其余的，尤为应该避免绘制一片纯色背景。
注意：iOS会自动在自定义的部件内容上方显示应用的图标和标题(图标会显示在标题前面的空白处)。
将部件内容与标题对齐。当你的部件内容与标题对齐时，人们就能够很简单地浏览今天视图中他们想要的部件。遵照今天视图中的边距规范，并将内容约束在如图的部件内容区内。
通常状况下，使用白色的系统字体来显示文本。在通知中心默认背景下白色文字会看起来较好。对于二级文本，能够使用系统提供的vibrant外观样式(查看notificationCenterVibrancyEffect了解更多)。
提供通知中心式的体验。人们访问通知中心来获取简要的更新或者执行一个很是简单的任务，因此今天部件最好只显示适量的信息和进行有限的互动，特别是：
- 避免用户在部件中须要滚动或纵向移动来查看所有的信息。部件能够经过纵向扩展来显示更多的信息，但若部件的高度超过通知中心的高度就不是一种好的体验了，由于这样会干扰其余部件的查看
- 避免使用横向扫动或拖曳，由于这会干扰在通知中心进行导航
- 尽量使用户只需一步操做就完成任务或打开你的应用(注意，在今天部件中键盘是不可用的)
- 优化性能以便人们能够即刻得到有用的信息。能够考虑在本地缓存信息，以便当有更新时就可显示最近信息。人们只但愿在今天视图中花不多的时间，若是部件使用内存不当，iOS就可能会终止它
在适当状况下，让人们点击你的今天部件来打开你的应用。由于今天部件提供了专注的体验，因此就能有效引导人们去到你的应用以获取更多信息或功能。最好不要显示“打开应用”按钮，而是应该让你的整个今天部件均可被点击来打开应用。你也可让用户点击部件中的UI对象，以打开你的应用并跳转到关于此UI对象的视图中。举个例子，日历部件显示了今天的事件，若是用户想要得到某个事件的更多信息，他们能够点击部件中的事件来打开日历应用进行查看。
注意：虽然从部件打开应用的方式对用户来讲还不错，但继续在部件中提供有用且及时的信息依然是很重要的。人们可不必定会欣赏一个功能只是打开应用的今天部件。
若是可能，在今天部件中让人们知道他们须要登陆来获取有用的信息。若是你的今天不见须要人们登陆查看信息，展现一个信息去鼓励他们登陆和解释什么样的内容将会被呈现。例如，若是你的时间部件即将到来的预定是用户登陆后展示的，你可能须要让用户“登陆个人应用去查看即将到来的预定”。
不要制做一个今天不见须要打开除了你本身应用外的应用。一个模拟iOS主屏的行为的时间部件不会为你的用户提供有用的功能。
3.6.2 分享和动做扩展(Share and Action Extensions)
人们经过点击应用中的动做按钮(Action button)来使用分享和动做扩展。在经过动做按钮显示的动做视图控制器(activity view controller)中，动做扩展被列在底部，分享扩展被列在动做扩展之上。人们能够使用更多（More）按钮来管理显示在动做视图控制器中的分享和动做扩展。
分享或动做扩展一般被认为是在当前用户场景下用来输入内容之用。例如，当在Safari中阅读一篇文章时，用户可能会点击动做按钮并使用一个分享扩展来发送这篇文章到分享网站上，也可能会使用一个动做扩展来查看这篇文章的翻译。
注意：在动做视图控制器中，iOS只会显示支持当前内容类型的动做扩展。例如，当用户当前内容是视频时，iOS就不会显示支持文本的动做扩展。
尽量在分享扩展中使用系统提供的UI。系统所提供的撰写视图控制器 (compose view controller) 提供给用户一种一致的体验，并能自动支持一些经常使用任务，例如预览和确认标准项，同步内容，查看动画，以及完成一封邮件。欲知更多关于使用系统提供的撰写视图控制器，请参见 App Extension Programming Guide中的Share.
若是上传须要必定时间，那就应考虑在分享扩展的容器应用中显示上传进度。不管分享的文件有多大，人们都期待在点击扩展中的发送或分享按钮后，能当即返回他们以前的场景。你须要让进度状态随时更新，可是人们不想每次上传完毕后都收到通知，而且也没法自动重启扩展。在这种场景下，在容器应用中显示上传进度是一种解决方案，这样容器应用就能够在后台处理任务，并在遇到问题时发送通知。
动做扩展使用单色的应用图标。( 不一样的是，分享扩展则应该使用其容器应用的彩色应用图标。) 要为动做扩展设计图标时，你可能须要从建立一个应用图标的模版开始着手。若有须要，能够专一图标所特有的元素来进行简化设计。
若是你在容器应用中提供了多个动做扩展，那么最好为他们设计一套图标，且确保这套图标中的每个看起来都与容器应用的图标是有关联的。
3.6.3 图片编辑扩展(Photo Editing Extensions)
当人们在照片(Photos)中查看图片或视频时，能够使用图片编辑扩展。通常来讲，图片编辑扩展能帮助用户筛选图片或进行一些其余的图片或视频编辑。在用户确认以后，编辑后的内容就会出如今照片应用中。
照片应用提供了一个模态视图来显示图片编辑扩展的自定义UI。当用户在确认对图片或视频的编辑时选择了取消(你必需要在代码上保证存在这个行为)，照片应用还能够显示一个确认视图。
避免在图片编辑扩展中使用导航栏。如图所示，承载扩展的模态视图已经包含了导航栏，若再增长另外一个导航栏，既会占据更多你的界面空间，还会使用户产生困扰。(照片应用默认会以全屏高度来显示你的视图，因此你的内容会出如今内建的导航栏之下。)
若是能够，让用户可以预览编辑结果。尽量让用户在关闭扩展返回照片应用以前看到他们编辑的成果。
3.6.4 文档提供者扩展(Document Provider Extensions)
文档提供者扩展帮助人们在其余各类应用中查阅你的应用所管理的文档。在宿主应用(host app)中，文档采集视图控制器(document picker view controller)会显示你的扩展所提供的UI(想要了解更多有关文档采集视图控制器的内容，请查阅UIDocumentPickerViewController Class Reference).
注意：文档提供者扩展由两个不一样的部分组成：文档采集视图控制器扩展和文件提供者扩展。文档采集视图控制器扩展包括了你的自定义UI，文件提供者扩展实现对文件的访问。为了简单起见，本节所使用的术语文档提供者扩展(Document Provider extension)是为了表述扩展中文档采集视图控制器部分的UI和体验。
避免在文档提供者扩展中使用导航栏。iOS会显示扩展的自定义UI，而自定义UI又包含在文档采集视图控制器中基于导航栏的界面之中。因此，在内建导航栏之下再显示第二个导航栏会使用户感到困惑，而且还会占据本来你的内容区域。(文档采集视图控制器默认会以全屏高度来显示你的视图，因此你的内容会出如今内建的导航栏之下。)
3.6.5 自定义输入法(Custom Keyboards)
人们在整个系统中使用带有自定义输入法的输入法扩展来替换iOS的自带输入法。在启用输入法扩展以后，除了受保护的文本区域(例如密码输入区)和手机键盘区(例如联系人中的电话号码区)外，当人们点击任何文本输入区域后就能使用自定义输入法。
为用户提供明显的方式来切换输入法。人们对于iOS的输入法切换按钮很熟悉，他们会指望在你的输入法中也有相似的体验。
若是可能，在你的容器应用中包括一个教程。若是必要，使用你的自定义键盘的容器应用去给人们讲解如何启用和使用你的键盘。不要把这个信息直接放在键盘自己，由于它可能让人们尝试使用这个键盘时感到困惑。
3.7 HomeKit
经过HomeKit，用户可以方便地在家中使用iOS设备上的智能家居应用来操控家中相关联的设备(不管这些设备制造商是谁)。最好的智能家居应用集成HomeKit和iOS系统来帮助用户：
- 建立家居环境、房间和区域
- 添加、寻找和移动家居设备(如灯泡或温度调节装置)
- 定义可以使一组多个家居设备响应的行为
- 管理用户
- 用Siri来操控他们的家居设施
想要了解如何在你的应用中使用HomeKit，可参阅HomeKIt Developer Guide。下面的指南能够帮助你作出一个容易上手、使人愉悦的智能家居程序。
不要想固然地认为你的设备会是用户所设置的首个设备。你的应用除了能让用户很容易就能建立家居环境、房间和区域，还须要让用户能方便地将你的设备接入以前已经设置好了的区域中。
让添加新设备变得简单。不要强迫用户在添加设备以前注册帐号。最好让你的应用能自动发现新的设备并将他们显著地展现在用户界面上。确保所展现的信息足够充分让用户能够轻易辨识出该家居设备。
帮助用户辨认他们正在调节的设备。给用户一个可以帮助他们从物理属性辨认设备的控制器。例如，你可让用户经过闪一下灯泡来确认他们正在调节的是他们想要调节的那个。
让用户可以经过多种方式来搜寻设备。当天的时间、季节和用户当前的位置会在特定的时刻成为判别某些设备是否重要的影响因素。所以，你的应用应该容许用户能在家中按类型、名称、或者位置的方式来搜寻设备。
为家中已接入的设备提供推荐的操做集。操做集容许用户设定在某种情景下让多个家居设备按照特定的方式行动。例如，一个“离开”操做集能够将房屋内的温度调低、关闭电灯和锁上全部房门。你的应用能够向用户推荐一些已经设定好了的操做集或者让用户建立自定义操做集。当用户可以基于房间或区域去建立自定义操做集时，让用户能够从你推荐的设备列表中进行选择，一般能使用户得到更好的体验。
使用友好的交谈式语言让你的应用平易近人、易于使用。智能家居概念可能会懵到用户，应避免使用他们可能不理解的缩写和技术术语。例如，HomeKit是指代API的专用技术术语，它就不该该在你的应用中使用。
注意：若是你是苹果MFi认证许可商，请访问MFi门户网站查看设备包装的命名及消息通知的规则。
与Siri互动。经过Siri，使用一个简单的陈述句就能控制执行复杂的操做。Siri可以识别操做集、房屋、房间和区域的名称，而且可以理解像“Siri，把前门关了”、“Siri，把楼上的灯关了”和“Siri，把多媒体房的温度调高一点”这样的陈述。遵循如下准则能帮助你为用户提供使用Siri操控设备时的良好体验：
- 使用Siri可以识别的功能名称，而非设备名称。一个设备可能提供多种功能(例如，一个既有风扇功能又有照明功能的风扇吊灯)，所以，帮助用户区分这些功能是很重要的。最佳方案是让用户在一系列不包含公司名称及型号的限定的名称中进行选择，而且容许他们之后编辑。你所推荐的名称应该使用规范的、容易理解的词语来描述功能，并可选择是否包含家中的位置信息，例如“客厅灯”或者“车库门”。你还可让用户指定一种控制插座开关的通用口令，例如“Siri，把灯关了”，来控制全部的灯具和其相关的设备
- 当用户配置操做集的时候，告诉用户如何经过Siri去操控它。举个例子，当“电影”这个操做已经确认配置完毕时，让用户知道他能够经过跟Siri说“Siri，把家调成电影模式”这样的话来激活这个操做。 注意，当用户单独对Siri说出某操做的名称时，一样也能激活那个操做。Siri可以识别系统预置以及用户自定义的操做集，这些已配置的操做集至少包含一项操做
帮助用户设置触发机制。在iOS9中，HomeKit支持触发机制：当知足特定的时间、地点或其余设备的行为的条件时激活操做的方式。好比用户能够设置一个当太阳落山且车库门打开时，就打开厨房灯操做的触发机制。设置一个包含多个项目的条件关系容易令人感到混乱，所以，将你的设置界面作得简单易用相当重要。举例来讲，使用与人们日常说话同样的表达方式来展现项目、属性和逻辑，就更容易令人理解。
3.8 多任务处理(Multitasking)
多任务处理让人们在屏幕上(在合适的iPad模式上)查看多个应用，能够在最近使用的应用之间进行快速切换。在iOS9,中，人们能够使用多任务处理UI(下图所示)去选择最近使用的应用。
可否在多任务处理中处理好取决于可否在设备中与其余应用和谐共存。从更高的层面来讲，这意味着全部的应用都应：
- 仔细调整资源使用避免占用太多CPU，内存，屏幕空间和其余资源
- 处理好中断或来自其余应用的声音
- 中止和重启，即快速平滑地从后台切换到前台
- 不在前台时应恪守己任
下述指南细则能够帮助你的应用在专一应用切换的多任务处理中取得成功。更多合格的iPad模式下关于多任务环境中运行的信息，参阅 Adopting Multitasking Enhancements on iPad.
准备好被打断，并恢复。多任务处理增长了后台应用中断你的应用的可能性。其余特性，诸如广告出现和更快的应用切换，也会形成更频繁地打断。越快速和越精确地保存应用当前状态，人们就能够越快地从新运行应用，并从以前离开的页面继续使用。你能够经过利用UIKit的状态保存和恢复来为用户提供无缝的从新开始的体验(查看Preserving Your App’s Visual Appearance Across Launches了解更多信息)。
确保你的UI能够处理两倍高度的状态栏。两倍高度的状态栏会在诸如通话、录音和共享等过程当中出现。在未做处理的应用中，状态栏的额外高度会引发布局问题，如UI被向下挤压或者被遮住。在多任务处理环境中，使两倍高状态栏显示正常是格外重要的，由于它可能会出如今更多的应用当中。
准备好暂停须要人们注意或主动参与的活动。例如，若是你的应用是一款游戏或媒体观看应用，你须要确保你的用户从应用切换走时，不会丢失任何内容或事件。当人们切换回游戏或媒体播放器时，他们但愿能继续以前的体验，就好像他们从未离开过应用。
确保音频行为合适。当你的应用正在运行时，多任务处理会使得其余媒体活动更可能地同时进行，也会有更多可能性使你的音频不得不暂停，并恢复处理中断。查看声音来帮助你确保你的音频能知足人们的指望，并与设备中的其余音频和平共处。
适度使用本地通知。应用能够在特定时间发送本地通知，不管应用是在暂停中仍是运行中亦或是根本就没有运行。为了达到最好的用户体验，应避免用过多的通知来骚扰人们，并遵循通知中建立通知内容的指南。
必要时，在后台完成用户的任务。当人们开始一个任务时，他们一般会指望即便已经从应用中切换走了任务仍可以完成。若是你的应用在执行用户任务途中，而且这个任务不须要额外的用户交互，那么你就应该在应用挂起以前就在后台完成任务。
3.9 通知(Notifications)
通知为人们提供即时的重要信息和功能。人们能在多种状况下收到通知，例如在锁屏界面中，或者在使用应用时，或者访问通知中心时。 通知中心有两种视图：通知(Notifications )和今天(Today)。
今天视图显示了一组可编辑的部件。今天部件是一个应用扩展，显示了少许及时和重要的信息或功能，这些信息或功能则是由用户所关注的应用所提供。举例来讲，日历部件只显示了今天的事件。点击日历部件中的一个事件能够唤起日历应用，并打开该事件，用户接下来能够编辑该事件或管理其余的事件。想要了解更多关于设计今天部件的内容，请参见今天部件。
通知视图会显示用户感兴趣的应用所发出的最近通知。用户能够在设置(Settings)中来设置是否在通知中心显示该应用的通知。 iOS应用能够使用通知来让人们知道一些有趣的事情是何时发生的，例如：
- 收到一条消息
- 事件即将发生
- 有新的数据可下载了
- 某些状态发生了变化
在iOS8及以后的版本中，应用能够定义用户在通知中的操做。例如，用户能够在待办事项应用的通知中就标记该事项已完成，而无需额外打开应用。 iOS定义了两种类型的通知。
- 本地通知(local notification)由应用安排待发送，最终经过iOS发送到同一设备中，不管该应用当前是否正在后台运行。例如，日历或待办事项应用能够安排一条本地通知来提醒人们一个即将到来的会议或者日期。
- 远程通知(remote notification)(也称为推送通知(push notification))是由应用的远程服务器经过苹果推送通知服务来发送的，这类通知最终会被推送到全部安装了该应用的设备。例如，一款在线竞技类的游戏，用户能够和其余玩家竞赛的，能够更新全部玩家的最新状态。
注意：应用扩展可能会要求远程通知必须发送到它的容器应用。在这种场景下，容器应用经常会在后台运行来处理通知。想要了解更多关于应用扩展的内容，请参见应用扩展。
若是当你的应用正在后台运行时收到了本地或远程的通知，你就应该以你的应用所特有的方式将信息传达给你的用户。 为了确保用户可以自定义他们的通知体验，你应该尽量多地支持如下的通知类型：
- 横幅(Banner)
- 警告框(Alert)
- 小气泡(Badge)
- 声音(Sound)
注意：在iOS8及以后的版本中，你必须对全部你想发送给用户的通知类型进行注册。当你第一次进行注册动做时，用户会遇到一个警告框，他们能够在其中操做来决定容许或拒绝全部来自你的应用的通知。无论用户选择的结果是什么，他们应始终能访问应用的设置来更改此项设置，或者设置他们想要接收的通知类型。
横幅(banner)是一个小而透明的视图，会出如今屏幕顶部并在几秒后消失。用户还能够看到在锁屏当中的横幅以及在通知中心中以通知形式出现的横幅。在横幅中，iOS会显示通知的内容和应用的小图标(欲了解更多关于小图标的内容，请参见 App Icon)。用户点击横幅来隐藏显示并切换到发送通知的应用。
除了默认的点击动做以外，当用户轻扫横幅时,你还能够定义两个动做按钮。点击通知动做按钮来隐藏横幅的显示并启动你的应用(多是在后台)来执行动做。
通知警告框是显示在屏幕上的标准警告框视图，须要用户操做后才会隐藏。当用户点击Options按钮后，你须要提供并显示通知消息以及任何一个默认动做，或最多四个特定动做。警告框的背景样式不能作修改。 当用户点击警告框中的一个默认或自定义动做按钮时，iOS会同时隐藏警告框并运行你的应用(多是在后台)。点击关闭或肯定按钮会隐藏警告框而不打开应用。
小气泡(badge)是一个显示未读通知数量的红色小圆(小气泡显示在应用图标的右上角)。小气泡的大小和颜色不能作修改。 横幅、警告框和小气泡这三种通知均可以使用自定义或系统提供的声音。
在通知中谨慎使用具破坏性的动做。要肯定用户有足够的上下文来避免意想不到的后果。为了帮助用户区分你所定义的破坏性动做，iOS会用红色来显示它。有时候，在应用执行破坏性动做以前，应该请求用户进行确认。举个例子，若是在锁屏的横幅(banner)中提供了一个破坏性动做，那么就应确保只有设备的主人才能执行该动做(你须要在代码上实现这一需求)。
为每一个动做按钮提供自定义标题。建立一个简短的标题来描述清楚将要发生的动做。例如，游戏可能会使用“Play”做为标题来代表，点击这个按钮会打开应用来进行游戏。确保标题：
- 使用标题样式的大小写(title-style capitalization)
- 足够简短，能不被截断地显示在按钮内(也应确保测试各类语言文字的标题显示正常)
不要为同一个事件重复发送通知。用户能够选择处理通知项；通知项在用户未处理前会一直显示。若是为同一事件重复发送通知，通知中心列表中会尽是通知，用户就有可能会关闭你的应用的通知
不要在通知消息中包含你的应用名称。自定义信息会在警告框和横幅中显示，也会在通知中心中以通知的形式显示。你无需在自定义信息中显示你的应用名称，由于iOS会在显示信息的同时自动显示应用名称。 为了使本地或远程通知信息更有做用，你应该：
- 专一于信息而不是用户的行为。避免告诉人们点击哪一个按钮或如何打开你的应用
- 足够简短，一两行就能够显示完整。较长的信息对于用户来讲很难进行快速阅读，也会形成在警告框中须要滚动才能查看完整
- 使用句式大小写(sentence-style capitalization)，并配以合适的结束语句符号。可能的时候，能够使用一个整句
注意：若有必要，iOS会缩短你的消息以便能在各类通知发送样式下显示；为了最好的效果，你不该主动缩减你的消息。
保持小气泡的内容是最新的。当用户注意到新信息时，即时更新小气泡很是重要，这样用户就不会以为收到了额外的通知。注意，当小气泡为0时也会移除通知中心中全部对应的通知项。
重要：不要使用小气泡作通知之外的用途。记住，用户可以关闭应用的小气泡，因此你没法肯定他们必定能看到小气泡中的内容。
当收到通知时，提供用户能够选择听到的音效。当人们没有在看屏幕的时候，能够经过音效获取他们的注意。例如，日历应用可能会在显示警告框的同时播放一个音效来提醒人们一个即将到来的事件。再如，协做任务管理应用可能会在小气泡更新时播放一个音效来告知某个远程协同的同事已经完成了某个任务。
你能够提供自定义的音效，或者使用内置的警告音。若是你建立了自定义音效，请确保它是简短的、有特点的而且是经由专业制做的。(想要了解更多关于音效的技术需求，请参阅Local and Remote Notification Programming Guide中的Preparing Custom Alert Sounds。)注意，当通知发送后，你没法以编程方式来触发设备的震动，由于用户对于警告框是否伴随震动拥有支配权。
3.10 社交媒体(Social Media)
人们会指望在任何场景下均可以使用他们喜好的社交媒体账号。iOS以人们喜欢的方式将社交媒体的交互与你的应用进行了整合。
注意：当用户点击动做按钮时，他们会获得一个如上图的动做视图控制器。想要了解更多关于这个视图控制器的内容，请参见Activity View Controller。
动做视图控制器的中间一行显示了用户启用的和系统提供的分享应唨扩展。想要了解更多关于设计分享扩展的内容，请参见 Share and Action Extensions。
考虑在你的应用中为用户提供一种简便的方式来撰写邮件。用户有可能会启用分享扩展以便能在任何地方均可以发送内容。可是你也能够使用系统提供的撰写视图控制器来呈现给用户，他们能够在其中进行编辑操做。你能够在显示给用户进行编辑以前，预先加载具备自定义内容的撰写视图(在你呈现给用户以后，只有用户能够编辑这些自定义内容)。想要了解更多关于社交框架(Social framework)的编程界面，包括SLComposeViewController类，请参见 Social Framework Reference.
若是可能，避免要求用户登陆进入一个社交媒体帐户。社交框架(Social framework)会和账号框架(Accounts framework)一块儿来支持一个单点登陆模式，因此你能够得到受权来访问用户的账号，而无须要求他们来从新受权。若是用户尚未登陆进入一个账号，你能够显示UI来让他们进行登陆。
3.11 iCloudiCloud
可让用户随时随地用不一样的设备访问他们想要的内容。将iCloud集成到应用中，用户不用进行同步操做就能够在不一样场景下使用不一样的设备访问并编辑私人信息。
为了提供这种体验，你可能须要从新检查你的应用中现有的信息，尤为是用户自建内容的存储、访问和展现方式。想要了解如何使用iCloud，请参考iCloud Design Guide.
iCloud用户体验的一个基本方向是透明性：理想状况下，用户不须要知道他们的信息存储在什么地方，也不须要去思考当前浏览的信息是哪一个版本的。如下几点能够帮助你建立用户指望的iCloud体验。
若是可能，让用户方便地在你的应用中启用iCloud。在iOS设备上，用户能够在设置中登陆iCloud帐户，所以多半用户会指望应用能够自动启用iCloud。可是若是你以为用户可能须要自主选择是否使用你应用的云服务，你能够在用户第一次进入应用时提供一个简单的选项来进行设置。大多数状况下，这个选项应该为：是否将全部内容上传到云端。
尊重用户的iCloud空间。必定要记住iCloud空间是用户花钱买来的有限资源。你应该使用iCloud来存储用户本身建立和可理解的信息，避免将可再生的应用资源和内容存储在云端。一样要记住，当用户登陆了iCloud帐户时，你的应用的文件夹内容也会自动备份到云端。因此为了节省用户云端空间，你最好只挑选必要的信息存储于文件夹中。
避免让用户本身选择在iCloud上存储哪些文件。通常地，用户会指望他们在乎的全部信息都可以经过iCloud访问到。实际上大多数用户都不须要进行我的文件存储的管理，因此你的应用也能够不用考虑这个问题。为了提供更好的用户体验，你可能想要从新构建处理和展现内容的方式，这样就能够给用户提供更多的文件管理功能。
决定哪一种类型的信息须要存储在云端。除了存储用户自建的文件和内容，你还能够存储少许的其余信息在云端，例如用户当前的状态，用户的偏好设置等等。你能够使用iCloud的关键值存储来保存这类信息。例如，用户使用你的应用看了一个杂志，你能够使用iCloud的关键值存储来保存用户浏览到的位置，这样用户在别的设备上从新打开这个杂志时就能从上次离开的地方继续浏览了。
若是你使用iCloud的关键值存储来保存用户的偏好设置，确保用户在每一个设备上都是想这样设置的。例如，有些偏好设置在工做环境中比在家里要更好用。在某些状况下，将偏好设置保存在应用服务器上要比保存在云端更合理，这样偏好设置就不会受iCloud的限制。
确保iCloud没法使用时应用的行为是合理的。例如，用户退出iCloud帐户，关闭应用的iCloud或者进入飞行模式时，iCloud都是没法使用的。在这些状况下，用户都进行了某些操做来禁止iCloud服务，因此你的应用能够不用再进行提醒。可是，须要告诉用户在打开iCloud以前，当前作的修改在其余设备上都没法看到。
避免给用户建立“本地”文件的选项。无论你的应用是否支持iCloud，都不该该给用户提供因设备而区分的文件系统。相反，你应该但愿用户关注经过iCloud访问文件的普适性。
在合适的时候自动更新信息。最好不须要用户来确认他们正在访问的是最新的内容。可是，也须要在用户设备存储空间和带宽限制之间作出平衡。若是你的用户要使用很是大的文件，那么让他们本身选择是否要从云端下载一个更新的文件可能更合适。若是须要这样作的话，能够设计一种方式来指出当前在云端有一个该文件的最新版本。当用户选择更新时，若是下载时间较长最好给用户明显的反馈。
告知用户删除某文件的后果。当用户从有iCloud服务的应用上删除文件的时候，这个文件一样会从用户的iCloud帐号和其余设备上删除。因此最好在执行删除操做以前告知用户删除的后果，让用户进行确认。
必要时尽量早地告知用户冲突问题。使用iCloud编程接口，你须要在不打扰到用户的状况下解决大多数不一样版本之间的冲突问题。但在有些状况下，你须要尽量早地检测出冲突问题来避免用户在错误版本上浪费太多时间。你须要设计一种天然的方式来告诉用户有冲突存在，接着给用户提供方便的方式来区分不一样版本以及作出决策。
确保在搜索中包括用户在云端的信息。使用iCloud的用户趋向于认为云端的信息是广泛可访问的，因此他们会指望搜索结果中也有云端的信息。若是你的应用容许用户搜索他们的信息，确保你使用了将搜索扩展到iCloud帐户的接口。
本章英文原文访问地址：iOS Human Interface Guidelines
译文地址：腾讯ISUX
转载请注明：学ui网 » [ISUX译]iOS 9人机界面指南(三)：iOS 技术