IOS平台UI规范(一） - 游天堂X游聚社区

使用iOS 的设备拥有一些共性，这些特点会影响其程序的使用体验。与这些特性相适应的程序会更加成功，与设备一起为用户提供超凡的使用体验。

iOS 设备的屏幕是用户体验的核心。用户不仅在上面浏览优美的文字、图片和视频，还要和多点触摸屏进行交互（即使有时候用户甚至看不到屏幕）。

注：像素适用于谈论设备屏幕的尺寸，或在编辑素材的程序中定义图标的大小。点则用来描述一块区域在屏幕上会显示多大。

用户可能在任何时间由于多种原因旋转屏幕。例如，有时用户觉得当前的任务将屏幕竖起来更自然，有时用户觉得横过来放置能看到更多内容。无论原因怎样，用户希望旋转后屏幕依然重点显示此程序的主功能区。

用户经常在桌面上打开程序，所以他们期望程序以与桌面相同的方向打开。由于iPhone和Ipad 在展示“Home screen”时的差异，这种期望也有所不同。

在Iphone 和Itouch 上，桌面只会以竖直的方向展示，Home 键在底部。这使得用户期待程序也以这个角度打开。在Ipad 上，Home screen 可以以任何角度展示。所以用户会期望程序以与桌面相同的方向打开。

用户使用特定的手指运动，我们称之为手势，来操作iOS 设备的多点触摸界面。例如，轻敲可以激活按钮，拖动可以滚动长表单，两指分开可以放大图像。

多点触摸界面给用户一种与设备直连，直接操纵屏幕上物体的感觉。由于内置程序对手势的使用遵从标准原则，所以用户在使用标准手势的时候更加舒适。使用内置程序的经历帮助用户学会了适用于大多数程序的手势词典。

iPhone 和iPad 都支持多点手势。虽然较大的屏幕也给了更多手指触摸的空间，但这并不意味着多点手势总是最佳选择。

在iOS4 之前，退出程序意味着其在内存中的数据即刻被清空。而在iOS4 之后，退出的程序会隐藏到后台，等待再次被调用的机会。这种特性被称为“多任务”，可以将程序保留在后台，直到被再次调用或终结。

大多数程序在转移到后台的时候，会被挂起。被挂起的程序会展示在“多任务选择器（multitasking UI）”中，这帮助用户快速找到近期使用的程序。多任务选择器会出现在屏幕底部，位于当前运行的程序界面或Home screen 的下侧。

用户会偏爱在运行其他程序时把某些程序保持在后台。例如，用户在看电影时又突然想去查看日程表、邮件时，会希望能快速继续中断的播放。

用户需在iOS 的“Setting”中修改偏好。但若想修改偏好，他们必须退出当前的应用。偏好往往在设定后很少会改变。虽然有些程序自己内置了“设置”，当并不意味着所有的应用都需要。

在体验一个程序前，移动设备用户不会去读一大段帮助，既没有时间也没这个欲望。而且，帮助内容会占用宝贵的空间来显示和存储。

基于iOS 的设备和内置的应用都很符合直觉，易于使用。所以用户并不需要屏幕上展示帮助。这种经验驱使用户期待所有的iOS 应用都是这些易用。

无论什么样的程序，都只有一个窗口。这个窗口用于放置程序的内容和功能。但是用户不会意识到这个窗口。在iOS 设备中，用户觉得程序就是依次呈现的一屏又一屏图像（acollection of screens）。

你可以把一屏图像想象成一个离散的视觉状态或者模态。一个程序拥有的屏数或多或少，每一屏都是各种素材和控件的组合（various combinations of views andcontrols）。

用户会觉得程序的屏与设备的屏没什么区别，但是程序的屏却可以远远超过设备屏幕的限制。例如，在iPhone 的“联系人”中，联系人列表只展示了一屏，即使列表的实际长度足够填满好多屏。

iOS 程序是用iOS SDK 编制的，可以直接运行与iOS 设备上。就像内置的程序一样，这些iOS 程序驻留在设备上，可以调用iOS 设备的资源。用户将这些程序安装在设备上，像“Photos，Calender，Mail”等内置程序一样使用它们。

网页有时候会把safari 工具栏隐藏，这样看起来更像是本地程序。使用web clip 功能的网页还可以在桌面上建立图标。这样用户就能像运行程序一样打开这些web 应用。

优化后网页会更适合iOS 设备的显示和操作。而且，优化后的网页能为iOS 显示设备进行适当的缩放，并且检测用户是通过什么样的设备浏览，以便对展示的内容进行调节。

有些网页与safari 和iOS 设备的显示和操作兼容。兼容的网页不会为了使用iOS 设备做更多的优化，但往往safari 对这些网页的显示也是合适的。

有些应用会将部分区域划拨出来，用于展示web 内容。这种程序看起来像是本地应用，但其实依赖于网络信息源。

iOS 上的Safari 提供了浏览网页的界面。虽然iOS 上的Safari 与电脑上的Safari 有很多相似之处，但也有很多差异值得注意。

最明显的差异是用户无法改变可视范围（viewport，或译作观察口、视口、视埠）。在电脑上，当用户改变浏览器窗口大小时，可视范围的尺寸也会改变。而在iOS 上，除非设备的方向旋转了，可视范围才会改变尺寸。iOS 用户可以通过缩放来改变viewport的显示范围。iPad 用户缩放网页的需求会比iPhone 用户少。

iOS 上的Safari 支持cookies。Cookies 可以通过保存用户的环境（context）、偏好以及曾输入的数据让用户和网页内容的交互更加流畅。

iOS 上的Safari 不支持Flash 和Java,或者其他第三方插件。作为弥补，Safari 支持HTML5 的<audio>和<video>标记，用以播放音频和视频的流媒体。此外还有JavaScript和CSS3 的变形，透明和运动效果，用以展示动态内容。

iOS 上的Safari 将手势解释为对“如何展示内容”的操控，而非对内容本身。轻敲可以触发Sagari 给网页发送一个onclick 事件，这与鼠标单击相似。但是很多鼠标动作没有相匹配的姿势，比如说hover。

iOS 上的Safari 容许网络应用以全屏模式运行。网络应用可以通过“Web Clip”的图标来登录，这样能隐藏Safari 的界面控件，看起来就更像是一个本地的应用。

伟大的用户界面会遵从用户界面设计原则，这些原则基于用户思考和工作的方式，而非基于设备的能力。一个费解的、逻辑混乱的、不诱人的界面会让原本很伟大的程序变成一团浆糊。但是一个优美的、符合直觉的界面能够与程序的功能相辅相成，给用户留下良好的印象。

美不是一个衡量程序好不好看，而是程序的外观和与其功能是否相衬。比如说，一个用来产生内容的程序（译者按：比如word、ppt）往往把它的装饰性元素处理得很低调，并通过使用标准的控件和动作来突显任务。这可以帮助用户获得有关该程序目的和特性的信息。反过来讲，如果这个程序采用了某种鬼灵精怪的界面风格，用户就会陷入冲突的迷雾。

类似地，在那些娱乐性应用的界面上，用户期待界面能够非常漂亮，充满探索趣味。虽然用户不希望在游戏中完成严谨的任务，他们仍然期待游戏的外观可以与体验一致。

界面一致性能够让人们沿用以往学会的知识和技能。保持一致性不是说要盲目地抄袭其他程序。相反，它应当利用那些用户已经熟识的标准和范式。为了鉴别一个程序是否遵从一致性原则，可以思考如下问题：

l 该程序是否与iOS 的标准一致？它是否正确地使用了系统提供的控件，外观和图标？它是否将程序与设备的特性有机地结合在一起？

l 该程序是否保持了充分的内部一致性？文案是否使用了统一的术语和样式？同一个图标是否始终代表一种含义？用户是否能预测他在不能地方进行同一种操作的结果？定制的UI 组件的外观和行为在程序内部是否表现一致？

当用户直接控制屏幕上的物体，而非通过各种控件时，他们会更深地沉浸在任务中，也更清楚地理解他们行为的结果。iOS 用户很享受在多点触摸屏上直接控制的感觉。手势使得用户对屏幕上的物体拥有更强的操纵感。因为他们可以不再通过鼠标等中介设备控制物体。

例如，用户可以用手指姿势直接缩放一块内容区域，而非通过放大缩小按钮。在一个游戏中，玩家可以直接移动或操纵物体。再例如，游戏里会出现一只锁，用户可以旋转钥匙来打开它。

反馈告知用户他们的行为有何结果，使用户确信程序正在运行中。人们操纵控件时期待即刻的反馈，也期待在较长的流程中能提供状态提示。

内置的程序会为用户的每一个动作提供可觉察的反馈。例如，当用户点击列表项时，该项的背景会变成高光。在那些会持续很多秒的长流程里，一个控件会展示已完成的进度，并在可能的时候提供解释信息。

顺滑的动画会给用户提供有意义的反馈，帮助用户了解动作的结果。例如，列表在添加新项时会向下滚动，帮助用户发现这个显著的变化。

声音同样能为用户提供有用的反馈，但是它不应是唯一的或主要的反馈方式。因为用户的使用场景可能会迫使他们关掉声音。

当虚拟的物体和动作是真实世界中物体和动作的暗喻时，用户会立刻明白该如何使用这个程序。经典的例子是文件夹：在真实世界里，用户将东西放在文件夹里，所以他们立刻明白电脑上可以把文件放在文件夹里。

合适的暗喻应该即暗示了使用方法，又避免与它模仿的现实世界里的物体和动作面临同样的限制。例如，用户需要放海量的东西才能把文件夹塞满，而这在现实世界里是不可能的。

iOS 为暗喻提供了充足的空间，因为它支持丰富的动作和图片。用户与屏幕上的物体进行交互，就像在现实世界中操纵同样的物体一样。iOS 系统中的暗喻包括：

一般而言，暗喻在没有做过多引申时效果会比较好。例如，如果在操作系统里文件夹必须放在书柜里，它就用起来没那么灵光了。

应该由用户出发和控制操作，而非程序。虽然程序可以建议某种流程、操作，也可以警示危险的结果，但抛开用户由程序来做决策未免太过荒诞。优秀的程序能够平衡用户的操作权并帮助用户避免犯错。

用户在控件和行为都很熟悉、可以预测结果的时候最有操控感。而且，当动作非常简单直白时，用户可以很容易地理解并记住它。

用户希望在进程开始执行前有足够的机会取消它。而且他们希望能在执行破坏性动作前有再次确认的机会。最后，用户希望能优雅地终止运行中的进程。

所以伟大的程序都起源于一个伟大的想法。但这不意味着将想法孕育成成功的程序是件轻松的事。这一章将介绍一些能用于精炼想法、回顾设计选择（design options）的策略，帮助你设计出人见人爱的程序。

在开发早期就完成对程序的定义，能够帮你将一堆想法和属性凝聚一个成用户梦寐以求的产品。在开发过程中，可以以该定义为标准判断潜在的功能点和行为是否靠谱。创建程序定义可以通过以下步骤来完成：

可以使用头脑风暴。此时你应该找出所有与产品创意相关的任务。不用担心单子列的太长，待会儿还要再做精简。

例如，想象你最初的想法是做一个帮用户采购食物的程序。想象一下，脑袋里就会出现一系列用户感兴趣的任务。例如：创建购物清单，获取食谱，比较价格，寻找商店位置，标注食谱，获得和使用优惠券，浏览烹饪教程，探索不同的烹饪方法，查找可替代的食材

你的用户除了在使用移动设备，期待精致的图片，简洁的交互方式，出色的表现以外，还具备什么样的特性呢？以食材采购为例，你可以判断下列描述是否适合你的用户：

考虑完这些问题，挑选三条最符合你目标用户的特性：喜欢实验新菜谱，采购很仓促，尽量节约（在不必花费太多精力时）。

如果在确定了目标用户的特性后，功能点只剩下寥寥数条，你就得到了它：伟大的程序应该像激光一样准确聚焦在用户想完成的任务上。

比如说，想想在第一步里你为购物程序列数的大量潜在功能点。虽然这些功能点都很有用，但并不意味着每个功能点对用户同样有用。最重要的是，第二步中的目标用户对这些功能点的喜爱程度也不一样。

心里装着目标用户，再来检视功能点清单，最后能将程序聚焦在三个功能点上：创建列表、获得和使用打折券、获得菜谱。

现在可以定义你的程序了，精确地概括程序的功能以及目标用户。好的定义应该是这样的：“一个帮助喜欢烹饪、主张节俭的用户创建购物清单的工具”

当考虑是否要添加一个功能点时，问问自己它对于你的程序以及目标用户来说是否足够核心。如果不是的话，把它放在一边，它可能是另一个程序的核心组成。例如，你已经确定你的用户喜欢发掘新菜谱，所以强调打包好的蛋糕和菜肴就有失妥当。

你应该知道这个程序能做什么、目标用户是谁。现在，你要确定此程序能给人“为苹果iOS 设备而设计”的感觉。这很关键，因为用户对行将安装在iOS 设备上的程序有很高的期待。如果你的程序让人觉得是为其他设备、或者web 而设计，用户就不会太珍视它。

iOS 用户已经很熟悉内置应用的外观和行为，所以他们期待这些下载来的程序能带来相似的体验。你不会想模仿内置程序的每一个细节，但理解它们所遵循的设计规范会很有帮助。首先要了解iOS 设备以及运行于其上的程序所具有的特性（详见“平台特点”这一章）。然后，将以下几点铭记于心：

程序的框架应该简明、易于导航。iOS 为浏览层级内容提供了导航栏，为展示不同组的内容或功能提供了tab 页签。

反馈应该是微妙且清晰的。iOS 应用使用精确流畅的运动来反馈用户的操作。iOS 程序还可以使用进度条、活动指示器（activity indicator）来指示状态，使用警告给用户以提醒、呈现关键信息。

如果你正计划为iPad 和iPhone 设计程序，要确保该设计方案可以适用两种设备。以下指南可以给你一些帮助：

为设备量身定做程序界面。大多数界面元素在两种设备上通用，但通常布局会有很大差异.为屏幕尺寸调整图片。用户期待在ipad 上见到比iPhone 上更加精致的图片。不建议仅仅将iPhone 上的程序放大到iPad 的屏幕上。

无论在哪种设备上使用，都要保住主功能。虽然一种版本会为任务提供比另一版更加深入或更具交互性的展示，但不要让用户觉得他们是在使用两个完全不同的程序。

超越“默认”。没有优化过的iPhone 程序会在iPad 上默认以兼容模式运行。虽然这种模式使得用户可以在iPad 上使用现有的iPhone 程序，但却没能给用户提供他们期待的iPad 体验。

如果你的程序移植自web，那么需要确保你的程序能摆脱网页的感觉，给人iOS 程序的体验。记住，人们可能会在iOS 设备上使用Safari 来浏览你的网页。

关注你的程序。网页经常给访客一堆任务或选项，让他们来挑选，但是这种体验并不适合iOS 应用。iOS 用户希望程序能像宣称的那样有用，希望能立刻看到有用的内容。

为触摸而设计。不要尝试在iOS 应用中复用网页设计模式。熟悉iOS 的界面元素和模式，并用它们来展现你的内容。菜单、基于hover 的交互、链接等web 元素需要重新考虑。

让用户翻页（scroll）。大多数网页在第一时间将重要的内容认真的展现出来（Mostwebsites take care to display the most important information “above thefold”）。因为让用户在顶部区域附近没找到想要的内容，就会离开。但在iOS 设备上，

翻页是很容易的，也是意料中。如果为了把所有内容挤在一屏里而缩小字体、压缩空间尺寸，最终可能内容都变得看不清，布局也没法用。

重置主页图标。网页经常在每个页面的顶部放置回主页的图标。iOS 程序不包括主页，所以不必多此一举了。另外，iOS 程序容许人们通过点击状态栏快速回到列表的顶部。如果你在屏幕顶部塞进一个主页图标，想按状态栏就没那么容易了。

顶级的iOS 程序能够用清晰的意图和易用性去平衡界面设计。为了在程序中达成平衡，一定要在开发初期将设计考虑进去。因为对品牌化、原创性和市场推广的考虑经常会影响设计决策。始终保持对用户体验的关注是极大的挑战。

使用iOS SDK 可以随意选择定制界面的程度。由于对定制的程度没有限制，你需要考虑这些定制的界面会怎样影响用户完成任务。当你把任务纳入考虑范围时，想一想用户执行这些任务的频率和环境。

例如，想象一个打电话的软件。这个界面没有使用键盘，而是呈现了一个漂亮、逼真的拨盘。这个拨盘制作精良，所以用户既非常喜爱，也立刻就知道如何去使用它。这个拨盘表现逼真，所以用户在做出拨号动作、听到与众不同的拨号音时会非常开心。但当需经常拨打没在通讯录中保存的号码时，最初的喜悦很快会被沮丧替代。因为转盘拨号的效率太低了。对于一个帮助用户打电话的程序来讲，这个优美的界面是一个累赘。

另一方面，考虑一下泡泡水平线取样仪，这上面会呈现一个逼真的水平测量管。用户知道如何使用真实的仪器，所以也能立刻知道如何使用它。这个程序即便没有那个漂亮的气泡也能展示水平角度信息，但是这会让程序变得不符合直觉，难以理解。在这种情况

定制一定要是有据可循的。理想情况下，定制界面能帮助用户完成任务，增强体验。应该让用户的任务来引导界面设计。例如：

如果你的程序是个游戏，提供即时的、有情节的体验，人们会期望进入一个充满漂亮图片、交互新颖的奇特世界。

尽可能少的给用户增加认知负担。用户喜欢了标准化控件的使用方法和行为，所以他们不必停下来思考该怎么使用它。当面对那些看起来、用起来不符合标准的控件时，用户之前的经验就失效了。除非你那极富个性的控件能让任务变得很容易，否则用户会讨厌被迫学习只能在此程序中使用的新技能。

保持内部一致性。你的界面越个性，在程序内保持这些控件外观和行为一致性就越重要。如果用户花时间学会使用这些不熟悉的新控件，他们希望这些经验能在整个程序里通用。

在控件和内容间保持差异。因为用户很熟悉标准控件，它们不和内容抢用户的注意。当你设计界面时，要确保它不会和用户关注的内容抢风头。例如，如果你的程序容许人们观看视频，你可能选择自己设计一套播放控件。但是，是否采用标准控件是次要的，更重要的是这些控件是否会在用户开始观看视频时渐隐，在用户轻触屏幕时重现。

在重新设计标准控件前要三思。如果你计划重新制作标准控件，要确保你的控件提供与标准控件同样多的信息。例如，如果你设计的按钮不是用户印象中那种方方的样子，用户甚至可能看不出它能点。或者，如果你创建一个切换控件，却不能显示两极状态，用户可能不会意识到它是一个双态控件。

确保对定制界面元素进行充分的用户测试。在测试中，观察用户是否能预测控件的功能，使用它是否很简单。例如，如果你的控件尺寸小于40×40 像素，用户点击它就有困难。或者，如果你的控件对水平滑动（swipe）和轻触（tap）的响应不同，要确保此控件的功能值得用户花费额外精力去留意这些差别。

在你调用庞大的开发资源去实现你的程序前，最好做一个用于用户测试的原型。即使只能让一些同事参与测试原型，你也能从他们对程序功能的新视角和体验中获益良多。

在设计初期，你可以使用纸面原型或者线框图来表现主要的信息展示区和控件（viewsand control），绘制画面间的切换流程。虽然你能从测试线框图中获得有用的反馈，但有采样不足带来的偏差也会误导测试员。这是因为让用户凭想象获得的体验会与使用细节完善的程序时不同。

如果你的原型能在设备上运行，那么获得的反馈会更加有价值。当用户能与你的程序交互时，他们能在程序中发现那些与预期不一样的地方，或者那些设计的太过复杂。

设计可信原型最简单的方法是选一个Xcode 的模板，改成一个基本的程序，填充一些合适的内容用以占位。然后，在设备上安装它，以便用户能够尽可能真实的体验。你不需要提供大量的内容，或者让每个控件都有功能。只要测试员能通过点击屏幕上某区域跳转到下一个逻辑关联的页面，或者能完成主要的任务，就足以给用户提供反馈。想学Xcode，详见“A Tour of Xcode”。当基于Xcode 模板开发你的原型时，你免费获得了很多功能，并能基于反馈对设计作出调整。只需要很短的时间，你就能在定稿并投入资源开发前迭代很多次原型。

你很可能准备把一个现有的软件移植到iOS 平台，而非创建全新的程序。从某些方面来说，从网页或其他平台移植应用要比从草图搭建全新应用更具挑战性。

用户使用iOS 设备的方式与使用桌上或膝上电脑非常不同，对用户体验的期待也完全不同。将软件从电脑移植到iOS 设备的征途绝非一马平川。

用户经常在走动中或是在嘈杂的环境中使用iOS 设备。你的工作就是创建爽快的使用体验，把用户拉进来，尽可能又快又简单地把他们想要的内容提供出来。

记住二八原则：通常，大多数用户（至少80%）只使用程序中很少一部分功能。只有很少用户会使用全部功能（少于20%）。iOS 程序很少需要提供只有资深用户才用得到的功能。

Mail 是Mac 上的一个曝光度很高，很好用，也很受好评的程序。也是一个容许用户方便地创建、接收、排序和存储邮件，跟踪事件，创建便签和邀请的强大程序。电脑上的Mail 通过大量窗口来实现如此强大的功能。

iPhone 版Mail 只关注电脑版Mail 的核心功能，帮助用户接收、创建、发送和管理邮件。iPhone 版Mail 需要把功能浓缩到为如下情景量身定做的界面：

需要留意的是，iPhone 版Mail 不比电脑版的Mail 好用。想反，这是专为移动设备用户重新设计的Mail。通过只关注一部分功能点，并把它们用简洁却诱人的界面展现出来，iPhone 版Mail 满足了移动用户最核心的需求。

直白的、高度聚焦的屏幕。每一屏展示一类邮件体验：账户列表、邮件列表、消息列表、消息视图、书写视图。在一屏内，用户通过滚动浏览全部内容。

简单、可预测的导航。通过在屏幕上轻击，用户可以从宏观进入微观。每一屏上都会展示标题，告知用户所在的位置，以及一个返回按钮，方便用户找回浏览足迹。

简单、可触摸的控件，一有需要时就出现。因为书写新信息以及检查新邮件可能是用户在任何环境中都想进行的主要操作，iPhone 版Mail 通过多点触摸屏幕来实现它。当人们浏览信息时，回复、移动、删除等可对信息进行的操作就会出现。

Keynote 是用于创建世界顶级展示的应用，它非常强大、灵活。用户非常热爱能将易用与细节极其精致的木纹控件融为一体的keynote。

由于Keynote 使用iPad 规范提供了用户期待的功能，用户立刻理解如何在iPad 上使用它。因为可以直接很简单自然地操控内容，新的用户也能很容易学会如何在iPad 上使用Keynote。

从电脑版向iPad 版的移植基于无数事无巨细的修改和重新设计。最明显的改动有这些：简洁的工具栏。工具栏数的项目屈指可数。但是这给了用户获得所有创建内容所需工具的一致通道。

听从用户召唤的简洁检视窗口。Keynote 的检视窗口自动包含与用户所选内容相关的工具和属性调节控件。通常，用户可以在检视窗口的第一屏内完成所有对选中对象的调整。

很多预置的样式模板。用户可以利用预置样式很方便地修改图示、表格等的外观和感觉。除了颜色主题外，每一套预置样式还包括表格标题、勾号标记等，用以协调整套主题的风格。

直接控制内容，添加有意义的动画。在iPad 版Keynote 上，用户可以拖动一张幻灯片到新位置，扭动物体以旋转它，轻触一张图片以选中它。动画反馈加强了直接控制的印象。例如，幻灯片在移动时会轻轻搏动，当把它放在新位置时周围的幻灯片四散开来为它腾出位置。

iPad 版Mail 实现类相同的核心功能。它有更多的屏幕空间为用户展示消息，有意义的触摸动作，以及时刻可见但又不过分招摇的管理编辑工具。简洁屏幕的视觉稳定性在一屏上呈现了用户需要的信息，尽可能地减少了环境改变。

虽然iPad 版Mail 的用户体验是为该设备量身定做的，但它没有改变用户使用的核心功能，也没有改变某个功能的位置或是效果。iPhone 版Mail 用户很容易发现iPad 版工具栏上的项目以及收件箱结构，也因两者不变的本质而立刻懂得如何使用它。

为设备的各种方向优化了支持。用户可以在四种方向中使用iPad 应用。虽然横屏视图（译者按：老外习惯叫风景模式）与竖屏视图（译者按：老外习惯叫肖像模式）的布局略有差异，界面的焦点总维持在用户关注的功能和内容上。

增加对消息内容的关注。iPad 版Mail 在各个方向上都预留了主要空间用于呈现消息。这包括将工具栏移动到消息的顶部，以增加展示消息的垂直空间。有了这些额外的空间，用户不必翻页就能阅读更多信息。当用户想用竖屏模式浏览信息时，他们仍然能看到当前消息的绝大部分。

扁平化的层级。iPad 版Mail 通过将所有高于邮件的层级划分到独立的界面元素有效地将邮件层级扁平化了（账户>邮件箱>邮件列表>邮件）。在横屏模式下，这块区域就是分栏的左半侧。在竖屏模式下，这个元素是一个弹出层。

极大地减少了全屏转场。因为大多数层级可以通过独立的那部分元素来浏览，用户可以在一屏上获得大多数他想要的的信息。当用户沿层级下行时，只是独立的这部分页面在转场，而非整个屏幕。

具有真实感的邮件。当用户为删除一封邮件而标记它时，这封邮件会在右侧展示，就像一张真的纸。当勾选了更多邮件后，这些邮件会堆叠成一摞纸，摆放的略有参差。

iOS 版Safari 为在iOS 设备上浏览网页提供了卓越的体验。用户钟爱平滑的文字和细腻的图片，以及通过旋转设备、轻敲平铺以及分开手指去改变观看方式。

标准的网站在iOS 设备上可以很好显示。能检测浏览设备、没有flash 等插件的网站无论在iPhone 还是iPad 上都看起来很棒，但也可能会稍被调整。

使用基于触摸的界面，而非依赖基于指针的交互。有时，其他的修正也是恰当的。例如：web 程序总是将显示范围设置的比较合适，并隐藏Safari 的界面。欲知更多，且看“控制显示区域（Configuring the Viewport）”和“调整网络程序（Configuring Web Applications）”

使用定制CSS 来提供可适应的界面。不同的界面元素适合不同的环境。例如，苹果的网站包括一个页面，展示用户可以观看的视频。当在电脑上用Safari 浏览时，用户可以点击上一页、下一页或者页码来查看其他片段。

将Safari 与iOS 键盘相匹配。当键盘以及表单辅助按钮可见时，Safari 在URL 地址栏下、键盘和表单辅助按钮以上的空间里展示网页。

当没有键盘和表单辅助按钮时，会多出216 像素的垂直空间来展示网页。在横屏模式下，值有两处不同，键盘高162 像素，表单辅助按钮高32 像素。

设计了新的下拉菜单控件。在电脑版Safari 上，下拉菜单的表现方式与Mac 系统中的应用程序一致，菜单打开，展示所有的项目，甚至在必要的时候超过窗口边缘。iOS 版Safari，下拉菜单采用新的样式，提供更好的用户体验。例如，在iPhone 上，下拉菜单显示在一个拾取器里。

使用列表展示iPhone 网络应用中的数据。iOS 用户习惯了内置程序的列表，所以当在web 程序中看到列表时，他们更有可能将web 内容视作程序。在iPhone 上，表单展示在圆角矩形里，或者边贴边。每种样式都有不同的韵律。