(转)iOS7界面设计规范(13) - UI基础

突然就到了周日傍晚。你永远不会知道自己的生活在接下来的一周当中能够发生多少变化；各种不可预知性所带来的更多是快感还是焦虑与不安，冷暖自知。相比之下，白天工作当中那些需求列表与排期文档就显得那么可爱了，哪怕有各种临时任务或需求变更，也最多只是让人在身体上疲劳一些而已。但有些事就远没这么简单了。

无名无状的话说到这里。今天的这篇更新是iOS7界面设计规范预发布版本第一章的最后一个小节了；我这边的汉化工程暂时告一段落。正如之前提到的，接下来会有我现在的一些同事参与进来，大家一起贡献更多的力量。届时，相关内容可能会首发到团队博客当中。那，眼下先感谢各位最近两周的鼓励与支持呗；从下周开始，没有意外的话，Beforweb会继续回到各种UX文章的更新上来。

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

译文最后更新时间：2013-06-30

使用标准UI元素

尽可能使用UIKit框架定义的各种标准UI元素。使用标准UI控件而非自定义元素，你和你的用户都会受益：

如果iOS本身经过重新设计，那么标准的UI元素在系统更新时可以随之自动更新，而自定义的UI元素不会。
人们会立刻了解怎样使用你的应用，因为他们已经习惯于标准的UI元素。

为了充分发挥系统标准UI元素的价值，你必须：

在使用任何一个标准UI元素的时候都要依照设计规范的指导。当一个UI元素无论看上去还是用起来都符合用户的期待时，他们就可以依靠已有的经验来更快更容易的使用你的应用了。你可以在UI元素一章中找到各类UI元素的规范。

通常，不要为标准的交互行为创建自定义UI控件。首先问问自己，为什么要创建一个行为方式与标准UI控件完全相同的自定义控件？如果你只是想要一种订制化的外观，可以考虑通过UIKit框架当中用来订制外观的API来改变标准UI元素的样式，或是改变元素的配色风格。如果你想得到的行为与标准控件的行为有些许区别，那么首先要确认能否通过属性的调整来使标准元素完成同样的目标。如果你需要的是彻头彻尾的订制化交互行为，那么在设计自定义控件的时候，要确保它看上去不会与标准控件相似。

技巧：Interface Builder可以帮你很轻松的创建标准UI元素、使用订制外观的API、设置外观属性、向控件中添加系统预设或自定义图标等等。可以参考Xcode用户指南了解更多详情。

不要为系统预设的按钮和图标赋予其他的含义。iOS提供了很多按钮与图标，你要读懂相关的文档，了解这些按钮与图标在语义上的含义，不要单纯依靠自己对它们外观的理解。如果你发现预设的按钮或图标无法准确的代表你想要表达的功能含义，那么可以自己创建。你可以在栏按钮图标一节当中找到相关规范，帮你更好的设计自定义图标。

如果你的应用可以带来沉浸型的体验，那么打造完全自定义的控件是合理的做法。因为你在创建一种独特的体验环境，对于用户来说，探索与该环境进行互动的方式也是他们所期待的体验之一。

对横竖屏切换的响应

人们通常会希望能够在任何定向方式下使用iOS设备，所以最好让你的应用可以在这些情况下做出恰当的响应。

让用户在横竖屏状态下都能聚焦于最重要的内容。这个目标具有最高优先级。人们需要在应用当中查看他们所关注的内容，并与之交互；如果横竖屏切换会使用户失掉焦点，他们便会感到迷失，并觉得丧失了对应用的控制权。

通常，要让应用能够运行在各种定向模式当中。人们可能会期望在任何定向方式下使用你的应用，能满足他们的期望是最好的。特别是iPad用户，他们会希望你的应用能够运行在他们当前所使用的任何持机方式下。当然，有些应用确实只能运行在竖屏或横屏当中；如果你的应用是这样，那么你应该参考以下几点原则：

应用在启动时只按照默认支持的定向方式进行加载，忽略当前设备的屏幕方向。如果一款游戏或媒体浏览类型的应用只能运行在横屏下，那么就直接以横屏模式启动，即使设备本身是处于竖屏状态的；这种时候人们会明白需要调转屏幕才能正常浏览内容。
避免在界面中通过UI元素提示人们调转设备屏幕。直接按照默认支持的定向方式启动应用，这就已经清楚的告诉用户需要旋转设备了，不需要再增加多余的UI元素进行引导。
同时支持两种子状态。譬如，如果你的应用只能运行在横屏当中，那么无论当前横屏的方式是Home键在左手边还是右手边，人们都可以正常使用；如果人们在使用过程中将设备调转180度，那么应用最好也可以进行响应，自动调转180度。

如果对于你的应用来说，调转屏幕方向是用户输入方式的一部分，那么你可以通过特定的方式进行订制化的处理。例如，在一款游戏当中，人们需要通过旋转屏幕来产生相应的行为，那么游戏本身就不可以再响应横竖屏切换的规则了。这种情况下，你可以允许用户在进入主线流程之前仍然能够切换子状态(Home键在左手边或右手边)，而一旦进入主线流程，那么旋转屏幕就只能用来触发游戏当中的特定行为。

在iPhone上，判断用户在调转屏幕方向时的需求所在，并进行响应。人们从竖屏切换到横屏时，通常是因为想要“看到更多”。如果你只是简单的将内容尺寸放大，那么未必能满足用户的期望。试着调整每一行文字显示的字数，如果需要，甚至是重新调整UI布局，使其能够呈现更多的内容。

在iPad上，尽量支持所有的定向方式，满足用户的期望。由于iPad自身屏幕规格较大，所以上一条中提到的“用户旋转屏幕以便看到更多”的需求是相对较弱的。相比于iPhone，人们不太关注于iPad的设备框架限制，以及Home键的位置，所以在很多时候，人们不会将iPad看做一种有默认定向方式的设备。如果可以，尽量让人们在任何持机状态下都能在iPad中与你的应用进行互动。

在为iPad应用设计横竖屏响应规则的时候，遵守以下几点规范：

考虑改变辅助信息或功能的展示方式。虽然你必须确保重要内容始终能够获取用户注意力的焦点，但对于次要信息或功能，可以考虑随着横竖屏切换而改变呈现方式。以iPad内置的邮件应用为例，账户和邮箱列表就属于次要信息(当前选中邮件的详情是主要内容)。在横屏时，次要信息被放置在左侧面板中，而竖屏时，则是呈现在弹出面板里的。对于某些游戏，在横屏状态时的界面边界到了竖屏当中也许需要进行重绘，这就有可能导致边界上下留出额外的空余空间。这种情况下，可以考虑在这些空余空间当中展示一些游戏辅助信息或对象。
避免无意义的布局变化。尽量在所有定向方式下都提供具有一致性的体验。具有相似性的体验可以让用户通过已经掌握的使用模式在横竖屏当中轻松操作。如果你的iPad应用会在横屏时以网格的形式展示图片，那么在竖屏时，就没有必要一定更改为列表形式。
如果可能，在切换横竖屏时尽量避免对信息内容样式的重新定义。尽量保持内容具有相似的格式样式，特别是对于文字内容来说，不要让用户因为切换横竖屏所导致的版式变化而无法找到之前阅读到的地方。如果有些内容样式必须发生变化，那么要通过动画过渡效果来帮助人们更好的跟随这些变化。例如，当横竖屏切换时，内容当中必须增加或减少一行文字，那么可以考虑在增加和减少的过程里使用渐入和淡出的动画效果。为了让自己设计出更好的横竖屏切换方案，可以想象一下，如果你是在现实世界当中与这些内容进行物理性的互动，那么它们有可能表现出怎样的行为规律。
为横竖屏各提供一张单独的启动图片。这样，无论人们在那种持机方式下打开应用，都可以感受到平滑的启动体验。与iPhone当中的系统首屏不同，iPad的系统首屏是支持横竖屏切换的，人们有可能在任何方式下退出前面一个应用，并继续打开你的应用。

弱化文件和文档的处理过程

iOS可以帮助人们创建和管理文件，但这不意味着人们在使用iOS设备时必须思考文件系统方面的问题。

在iOS当中，不存在类似OS X系统中的Finder这样的应用，用户也不应该被要求与文件直接打交道，特别是不该去面对任何会让他们联想到文件源数据或存储位置一类信息的东西，例如：

确认打开或保存文件的对话框。
关于文件访问权限的信息。

尽量让人们在不需要打开桌面端iTunes的情况下管理各种文档。考虑使用iCloud来帮助用户访问他们在不同设备上的内容。要为用户提供更好的iCould体验，可以参考iCould一节。

如果你的应用提供创建及编辑文档的功能，那么可以尝试提供某种“文档选择器”，帮助用户打开已有文档或创建新文档。理想情况下，这样的文档选择器应该：

具有高度的图形化外观。让人们可以轻松的通过图形化的界面外观来识别出他们想要的文档。
让人们使用最少量的手势来完成目标操作。例如，通过封面流或网格的形式组织文档，让用户通过滑动手势进行浏览，并通过点击来打开。
提供新建文档的功能。不要让用户必须到其他地方创建新文档，而是直接在文档选择器当中点击文档图形上的某种默认占位图片来直接创建。

提示：你可以使用Quick Look预览功能让用户在你的应用中对文档进行预览，即使你的应用并不支持这类文档的打开操作。参考Quick Look一节了解更多。

给用户一种安全感，让他们知道自己的工作成果始终会被保存，除非他们主动取消保存或进行删除。如果你的应用提供创建及编辑文档的功能，要确保这些数据无需用户手动执行也可以得到保存。iOS应用应该承担起帮助用户保存输入内容的责任，无论是他们在当前文档仍然处于打开状态的时候去查看另外一个文档还是切换到其他应用。

不过，如果你的应用的主要功能并不是创造内容，但你需要让人们可以在查看信息与编辑信息在两种模式间进行切换，那么在这种情况下你可以提醒用户对信息变更进行保存。通常，可以在查看信息的视图界面中提供“编辑”按钮，当用户点击了这个按钮之后，就会进入编辑状态，同时原来的“编辑”按钮变为“保存”和“取消”这两个按钮。这种变化可以提醒人们，他们现在正处于编辑模式，可能需要执行保存操作，而“取消”按钮则为他们提供了在不保存变更的情况下直接退出编辑模式的出口。

必要的时候提供设置方式

有些应用可能需要向用户提供安装或设置选项，不过多数应用是不需要的，或是可以推迟必须进行设置的环节。成功的应用可以让多数用户立刻上手使用，而且会在UI当中提供一些可以调整体验模式的方法。

尽量避免将用户打发到系统的“设置”当中进行操作。要记得，用户必须首先离开你的应用才能进入系统的设置，你不会希望鼓励用户这样做的。

如果你能按照目标用户群当中大多数用户的期望来设计产品，就可以减少这种设置方面的需求。如果你需要用户的某些信息，可以首先试着从系统当中存储的用户信息当中进行查询，而不是让用户再次进行输入。如果你决定必须在应用中提供设置功能，可以参考iOS应用编程指南当中的“The Settings Bundle”一节了解更多信息。

如果有必要，让用户尽量在你的应用内部进行设置。在应用内提供设置选项，可以让相应的变更可以直接体现出来，让用户即时的看到变更结果，而无需在你的应用与iOS的“设置”之间进行切换。

如果需要，尽量在应用的主界面中提供设置选项。特别是当设置选项对应着应用的主要任务，或是用户可能频繁的变更设置的时候，最好将相关的设置选项直接放置在主界面当中。如果你要提供的设置功能对用户来说只是偶尔才会用到，那么就尽量将它们放在单独的界面当中。

译文代表原作者观点。欢迎发表评论，或到译者微博进一步交流探讨。

本站原创编译文章。如需转载，请注明：本文来自Be For Web

英文原文:

https://developer.apple.com/library/prerelease/ios/documentation/UserE...

译者信息: c7210 - UX玩家、交互设计师、曾经的视觉与前端、猫奴、guitar fucker...现就职于携程无线事业部。