iOS 7人机交互指南-UI Elements-Temporary Views

iOS 7人机交互指南-UI Elements-Temporary Views



重要：这是针对于正在开发中的API或技术的预备文档(预发布版本)。虽然该文档在技术精确度上经过了严格的审核，但并非最终版本，仅供苹果开发者计划的注册会员使用。苹果提供这份机要文档的目的，是帮助你按照文中描述的方式对技术的选择及界面的设计开发进行规划。这些信息有可能发生变化，届时，你的设计开发方式需要基于最终版本的操作系统及文档进行相应的调整和测试。该文档或许会随着API或相关技术在未来的发展而进行更新。（其中一些重要变化，我们也会进行更新。译文如有纰漏，敬请指正）
警告（Alert）警告可以提示用户影响他们设备或者app使用的重要信息。



学习如何在代码中定义警告，可参看“UIAlertView Class Reference”。

外观和行为

警告会在app屏幕中间位置弹出，并悬浮在视图上。警告以其独立的外观来强调app或者设备上发生了改变的事实，而不一定是用户最近操作的造成的结果。用户在继续使用当前运行的app前必须解除掉警告。


警告通常至少包含一个按钮，用户点击按钮来解除警告。默认情况下，警告展示一个标题，并可能展示提供额外信息的消息。警告可以包含一个或者两个文本域，其中一个可以是安全的文本输入域。警告的背景外观是系统指定的，不能更改。



注意：本地通知或者推送通知可能会使用警告来与用户交流，但很少见。学习本地和推送通知相关内容，可查看“Notification Center”。



使用指南

很少有警告能让用户重视他们。确定最小化警告在app出现的次数，保证每个警告都能提供关键的信息和有用的选择。


避免创建不必要的警告。一般来说，如果是以下几种情况，则不需要警告：

1.仅仅增加一些信息的可见度，尤其是与app标准功能相关的信息。相反，设计一个引人注目的方式来展现与应用风格相协调的信息。

2.更新用户正常进行的任务。相反，可以考虑使用进程条或者活动指示器给用户提供进程反馈。（“Progress View”和“ActivityIndicator”中已经对这些方法有所描述）

3.向用户确认他们触发的操作。为了确认用户触发的操作-即便是存在潜在风险的动作（比如删除联系人）--你应该使用操作列表（参看“Action Sheet”）。

4.告知用户他们无可奈何错误或者问题。虽然有必要使用警告来告诉用户他们修复不了的重要问题，但更好的方法是把这些问题整合在UI中，如何可能的话。比如，不是每次服务器连接失败都要告诉用户，可以显示上次连接成功的时间。



你可以指定需要的标题文本和可选信息、按钮的数量以及警告视图中按钮的内容。你不能自定义警告视图本身的宽度或者背景外观，或者文本对齐（它是居中对齐的）。



当你阅读警告文本设计指南时，了解以下定义也很有帮助：

1.标题大写意味着每个字母都要大写，除了冠词、并列连词以及少于四个字母的介词，当“它们”不是首字母的时候。

2.句子大写意味着首字母要大写，其他字母则是小写，除非它们是专有名字或者专有形容词。


简单描述现状和解释用户可以对此做些什么。理想情况下，你写的文本可以为用户提供足够的语境上下文来理解为什么出现警告，以及决定点击哪个按钮。



如果可能，尽量用一行显示足够短的标题。一个长警告标题不利于用户阅读，并且可能会迫于信息滚动而截断标题。



避免使用一个词的标题，这不能提供任何有用的信息，比如展示“Error”或者“Warning”。



可能的话，使用句子片段。一个简短的，大信息量的陈述比一个完整的句子更容易理解。



用户理解大部分警告提示他们的问题或危险状态。“消极”和直接要好过积极但间接的方式。



尽可能地避免使用“you” “your” “me”以及“my”这类词。有时候，直接识别用户的文本是模棱两可的，甚至会被误认为是一种侮辱。



使用大写字母和标点符号，特别是：

1.当标题是句子片段或者由单个句子（不是问题）组成时，标题要大写，并且不使用句末结束标点符号。
2.如果标题由描述问题的单个句子组成，使用句子大写（ps：首字母大写），并且句末使用问号。一般来说，如果可以让你避免添加信息，考虑使用问题句子作为警告标题。

3.如果标题由两个以上句子组成，那么使用句子大写（ps：首字母大写）类型，并在每个句子末尾添加适当的结束标点符号。两句话标题应该很少需要，即便你会考虑，它可以让你避免添加信息。

如果你提供了可选的警告信息，创建一个短的完整的句子。使用句子大写类型和适当的结句标签。

避免创建过长的警告信息。如果可能，保持用一行或者两行来展示足够短的信息。如果信息太长，它就会在视图上滚动，这不是一个很好的用户体验。


避免因描述点击哪个按钮而延长警告文本，比如“点击视图查看信息”。理想情况下，清晰的警告文本和逻辑上的按钮标签组合在一起可以给用户更多信息，从而方便用户理解当前的状态和他们的选择。但是，如果你必须提供详细的指引，可遵循以下指南：

1.确定使用“tap”（而不是“touch”或者“click”或者“choose”）来描述选择动作。

2.不要为按钮标题附上引号，但要保证其大写。


确保在两个屏幕方向（横屏和竖屏）对警告外观进行了测试。由于警告视图的高度在横屏模式下受到了约束，它与竖屏模式上的警告看起来可能不大一样。推荐你优化警告文本的长度，这样看起来会更好些，并且能避免在两个屏幕方向上的文本滚动。
通常，使用两个按钮的警告。两个按钮的警告最有用，因为它最便于用户在两个选项之间进行选择。单按钮的警告很少有用，因为它没有给用户任何该状态下的控制。包含两个或者三个以上按钮的警告明显比两个按钮的警告复杂很多，可能的话应该尽量避免使用。事实上，如果你发现需要为用户提供两个以上的选择，你应该考虑使用action sheet--操作列表（更多内容可参看“Action Sheet”）。


给警告按钮赋予一个简短的，符合逻辑的标题。最好的标题由1-2个在警告文本上下文中有意义的词组成。当你为按钮创建标题时，可遵循以下指南：

1.像其他按钮标题一样，使用标题大写的展示类型，不使用句末标点。

2.使用动词和动词词组，比如“Cancel”、 “Allow”、“Reply”以及“Ignore”等与警告文本有直接关系的词。

3.如果没有更好的选择，使用“OK”表示简单的接受选项。避免使用“Yes”或“No”。

4.尽量避免使用“you”、“your”、“me”以及“my”。按钮标题使用的文字常常是清晰和屈尊俯就的。

操作列表（Action Sheet）

操作列表用以展示用户触发的跟任务相关的选择。



学习如何在代码中定义操作列表，可参看“Action Sheets”。


外观和行为

在iPhone上，一个操作列表常常会展示屏幕上的按钮。但操作列表可用时，iOS会让屏幕上其他内容变得模糊。


一个操作列表常常至少包含两个按钮-可以让用户选择如何完成他们的任务。当用户点击一个按钮，操作列表就会消失。操作列表不包括标题或者说明性文本，因为它是对用户操作的快速反馈。
使用指南

操作列表可以用来：
1.提供可选择的任务完成方式。操作列表可以让你提供一系列的选项--在当前任务上下文环境中有意义的选择，而不是在UI中为这些选项提供固定的位置。



2.在完成有潜在风险的任务前获得用户的确认。操作列表提示用户思考他们即将进行的，有潜在风险的任务操作，并给用户更多选择。在iOS设备上，这种交流非常重要，因为有时候用户点击了控件但不明白是什么意思。



在iPhone上，包含一个取消按钮，这样用户就能简单安全地放弃任务。取消按钮被放置在操作列表的底部，鼓励用户在做选择前浏览所有的替代选择。



不管是iPhone上还是iPad上，用红色按钮表示可能执行的，带有潜在破坏性的操作。在操作列表的顶部展示红色按钮，因为红色按钮越靠近操作页面的顶端，就越能引人注目。在iPhone上，当用户瞄准home键时，红色按钮离操作列表顶端越远，用户越不可能点击它。


避免让用户滚动操作列表。如果你在操作列表中包含了过多按钮，用户必须滚动查看所有操作。对用户而言，这是令人不安的用户体验，因为他们必须花费额外时间来考虑每个选项。另外，在不触及任何按钮的前提下，让用户翻看操作列表并不容易。
模态视图（Modal View）

模态视图在当前任务上下文或者工作流程中提供了更完备的功能。



学习如何在代码中定义模态视图，可参看“UIViewController Class Reference”。


外观和行为

模态视图占据了整个屏幕，这可以增强用户对进入一个独立的过渡模式（用户可在其中完成某件事）的体验。在iPad上，一个模态视图可能也占据父视图的整个区域，比如popover。


适当的情况下，模态视图可以展示文本，并包含用来执行任务的必要控件。模态视图一般会显示一个用以完成任务或者关闭窗口的按钮，还会显示一个点击即可放弃任务的取消按钮。



使用指南

当需要完成与app主功能相关的、独立的任务时，可使用模态视图。莫要视图尤其适合多级子任务（需要不属于app主界面的UI元素）。


在iPhone上，要协调模态视图外观和app的外观。比如，模态视图通常包含一个导航栏（导航栏包括标题，任务完成或者取消按钮）。这种情况下，模态视图的导航栏和app的导航栏应该使用相同的外观。



在所有设备上，如果合适，可展示用以确定任务的标题。你也可能在视图的其他区域（充分描述任务或者提供一些指南）展示文本。



不管在iPhone上还是iPad上，要选择一个合适的过渡样式来显示模态视图。使用与app一致的过渡样式，并提高用户对临时上下文环境转换（展示模态视图）的意识。你可以指定以下过渡样式的其中之一：

1.纵向。模态视图从屏幕底部边缘向上滑出，解除后向下从底部边缘退出。（这是默认的过渡类型）

2.翻转（Flip）。从右至左水平翻转当前视图以展示模态视图。视觉上看起来模态视图好像是在当前视图的背面。当模态视图解除，从左至右水平翻转以展示先前的视图。


如果你决定改变app中模态视图的过渡样式，要避免这么做仅仅是为了多样化的利益。用户很快会注意到其中的变化，并假设它们意味着什么。因为这个原因，你最好创建一个符合逻辑的，始终如一的模式，这样用户可以很容易地察觉并牢记，并且没有很好理由的时候要避免改变过渡样式。