正如在移动信息流程中所看到的，完成一个目标的最好方式就是预设好一条从当前位置到目标所在地的路径。设计阶段并没有像信息架构流程那样细分成9个阶段，但仍然有一个系统的方法用以专注于目标路径和优化整个工作流。 设计时别忘了两个重要的阶段：可访问性与可用性。可访问性和可用性联系相当紧密，但更重要的是首先需要保证所有用户都能访问到网站或Web应用，而后才应设计和优化其可用性。 2.2.1 苹果设备的可访问性 根据W3C的定义，Web可访问性指的是使各个能力级别的用户都能访问网站和Web应用。移动Web最佳实践标准（MWBP）和Web最佳实践标准（WBP）有一些重叠，因为大多数情形下它们有着类似的障碍和类似的解决方案。而移动Web可访问性所致力于解决的两个最重要的需求则是视觉与听觉需求。 说明 2008年12月11日，“Web可访问性倡议”（WAI）推出了“Web内容可访问性指南2.0版”（WCAG20），并作为推荐标准。“Web内容可访问性指南”包含了一套使内容更便于访问的指导方针，主要针对残障人士，但也针对所有其他用户设备，包括资源非常有限的设备，例如移动电话和智能手机。 至少解决了视觉和听觉需求后，将能使网站或Web应用对于大多数潜在用户都是可访问的，就像在图2-16上看到的。但是不幸的是，这一目标并不总是那么容易达成，有时候甚至很多著名和成功的产品也有一些可访问性方面的缺陷。 图2-16 三项可访问性服务：缩放（图左）、语音控制（图中）以及黑底白字（图右） W3C的“网页内容无障碍指南2.0版”（WCAG2.0）提供了使网站或Web应用更便于访问的指南。可惜的是，这一指南在撰写时并没有考虑到触屏设备，但下列大部分要点背后的思想对于iPhone和iPad来说也适用。 正确使用标准技术。 提供一个针对手指操作优化过的导航结构。 在每一个页面上都提供浏览路径信息。 让用户自己控制字体大小。 提供的文本、图片和背景要形成良好的对比。 额外提供一个高对比度版的网页。 提供一个可以被朗读出来的网页版本，如图2-17所示。 iPhone和iPad带有一些新的功能，可以为残障人士提供辅助功能，帮助他们访问网站。例如，这些用户不用记住长长的键盘指令去寻找他们需要的东西：要选择并打开某个项目，用户只需轻触一次或两次。为了使用户能够从这些辅助功能中受益，设计者和开发者都应该了解这些功能，才能有针对性的去优化内容和服务。 1. VoiceOver 这一功能将iPhone或iPad变成了世界上首台基于手势的屏幕阅读器，使得用户可以单凭触觉与屏幕上的元素进行交互。VoiceOver借助iPhone和iPad的触摸屏使用户能直接与屏幕上的物体交互，如此一来即便有视觉障碍的用户也可以访问内容并在站点地图中确定自己的当前位置。 图2-17 可访问性辅助功能：VoiceOver VoiceOver是一项设备特性，与具体的网站或Web应用无关，用户无需额外处理即可从中受益。但也需要实现良好的用户界面，以避免给用户带来糟糕的导航体验。在后文中很快就可以看到优秀的用户界面实践。 2. 语音控制 除了手势以外，还可以使用语音命令来播放音乐或打电话。要做的只是长按住home键，在听到语音提示之后，读出通讯录里朋友的名字，或是iTunes播放列表里艺术家的名字。 3. 缩放 凭借这一功能（如图2-18所示），用户可以放大整个Spotlight搜索页或是锁屏界面，甚至屏幕上的任意应用，无论是原有的还是购买的。 图2-18 可访问性辅助功能：缩放 一旦开启这一功能，只需使用三个手指双击一下屏幕，即可马上放大一倍，再次双击则还原。用户也可以在使用三个手指双击屏幕后按住不松开，通过上下拖动手指动态地调整放大倍率（100%至500%）。 4. 白底黑字 需要高对比度的用户可以使用这一选项来将屏幕显示改为白底黑字，如图2-19所示。这一反转极性的效果对于所有应用都有效，包括主屏、解锁以及Spotlight搜索。 图2-19 可访问性辅助功能：白底黑字 iPhone和iPad的菜单配色能很好地适应这种颜色反转，但如果网站或Web应用的配色对比度不够，则最终显示情况会很难让人满意。因此在设计用户界面的时候应尽量使用对比强烈的配色板，以避免这一负面效果。 5. 字幕 iPhone和iPad都支持公开字幕（open captions）、隐式可关闭字幕（closed captions）和字幕翻译（subtitling）的回放。字幕会显示在屏幕上，就像用户在电视上看到的隐式可关闭字幕一样。你可以通过使用合适的工具来创建自己的字幕。 6. 听觉、视觉和震动警示 这些选项会向用户同时发起听觉和视觉上的警示。用户可以对电话呼叫、新来短信、收发邮件或是日历事件设置这些警示。 7. 可访问性软件特性 从iOS 5开始，苹果对于iOS设备的可访问性引入了一些重大改进。这些新的特性为行动、听力、视力或认知方面有障碍的人提供了便利，使他们能从iOS设备上获取到大部分信息。首先，多了使用这些功能的一种新方法，即用户可以通过轻触屏幕上特定的一个点来快速呼出菜单。通过这个新的菜单，用户能访问某些设置功能，甚至直接返回主屏而无需按下Home键。 还有一个很重要的功能是给来电设定LED闪灯和自定义的震动。当有人呼叫你时，LED灯会开始闪烁，手机也开始以自定义的方式震动。新的辅助触摸特性（Assistive Touch）使用户能把手势定义为某种快捷方式。苹果还添加了一个“朗读所选项”的特性，可以按照用户设定的速率来读出用户当前选择的文本。即便是已有的老功能也有所改进，例如VoiceOver现在可包含自定义元素标签。 2.2.2 iOS设备的可用性 可用性专家Jakob Nielsen如是说：“可用性是用来评估界面有多简单好用的质量属性。”可访问性主要影响一部分用户，而可用性则几乎影响所有的用户。 信息调研阶段如果小心细致一些，可以减少潜在的可用性问题，例如图2-20中展示的那个。2008年，有一项来自Create with Context网站的关于iPhone可用性的有趣调查，名为“人们实际是如何使用iPhone的”。它揭示了对于设计者和开发者而言，有时候真的很难预测用户的行为。 图2-20 可用性调查：人们实际是如何使用iPhone的（图片来源：Create with Context） Create with Context的研究得出了8个关于iPhone设计与开发的一般原则，也适用于iPad。这些原则如下。 多利用用户已有的使用习惯。 “噢，这个用起来像日历” 避免交互上的不便。 “很奇怪，这里一般是‘取消’按钮的位置” 组件间应提供清晰的概念上的联系。 “这个按钮肯定和那个对话框有关，因为它们挨在一起” 在响应用户操作的组件之间应放置足够的空间。 “天哪，我不是想要把这条短信发出去的！” 要考虑到用户可能产生的频繁滑动操作。 “我老是莫名其妙地滑到一个奇怪的页面” 不要完全依赖多点触控。 “当我另一只手里拿着东西的时候，很难去使用多个手指来触控” 用户点击时提供视觉反馈。 “我点中那个按钮了吗？有吗？没有吗？” 提供交互的可见性。 “很显然你应该从左往右滑” 说明 可以在Slideshare上下载到这项研究的完整文档： http://www.slideshare.net/createwithcontext/how-people-really-use-the-iphone-presentation。 如果需要下载PDF版本，则请访问： http://www.createwithcontext.com/how-people-really-use-the-iphone.html。 这些问题对于产品可用性来说关系重大，但同时又不那么容易解决。因为知道的越多，就越难从一个初级用户的角度去思考问题。据说这也是优秀的教授为何如此稀少的原因之一。 1. 何时开始在可用性上下工夫 看到这里应该已经有所了解，为了向尽可能多的用户提供良好的用户体验，可访问性与可用性在项目中有多么重要。然而此时最重要的问题却是：应该从何时开始在可用性上下工夫呢？ 在一些关键的时间点上，致力于可用性工作能够提升项目整体的质量。这些时间点如下。 (1) 项目开始之前 需要收集竞争对手的信息，了解他们如何解决特定的应用问题以达到项目目标。 同时需要了解用户的应用场景，并准备相应的优化方案。 (2) 设计开始之前 如果是在改造一个现有的桌面网站或是Web应用，则需要在网页结构中敲定保留（即可以在移动场景中使用的部分）和舍弃的部分（无法使用的部分）。制作一个站点导航图来测试和分析网站或是Web应用的内容架构。 (3) 设计阶段中 为所有网页内容的优先级排序。 使用线框图、纸面原型图以及电子版原型来描绘站点导航图。 (4) 测试阶段中 使用原型来测试用户体验的等级。 从中你可以看到可用性原则是如何在项目流的各个阶段中得到应用的。在后面的章节中会介绍一个检查列表，帮助你在项目中实现一种高级用户体验。 2. iPhone与iPad在可用性上的区别 iPhone和iPad运行的操作系统都是iOS，因此它们有着同样的导航风格，但又使用了不同大小的显示屏和不同尺寸的元素，所以在某种程度上改变了用户界面的观感，进而导致可用性和用户体验质量上的歧化。 这一情况引入了一个iPad上存在的新的问题：字体在阅读和触碰功用上的不对称性。在所有的iPhone网站或Web应用上，如果一个字体小到难以阅读，那么它同样也是难以触碰的。 说明 本书中提到“字体”的时候，包括了所有基于字体的结构体，例如导航栏、侧边菜单、表单、简单的段落，等等。 对于iPad而言，情况就并非一直如此了。有时候某个字体大到足以看清，但对于触碰的需求来说仍然太小。我们把这种字体称为“对手指不友好”的字体。本书中会介绍如何通过使用CSS3样式表来解决这一问题。 从可用性的角度来看，这为针对iPhone和iPad制作的页面画下了重要的分水岭。另一个重要的区别就是，在iPad的视口（viewport，即浏览器的可视区域）中没有iPhone的底部工具栏。 没有底部工具栏，用户体验质量就会有一些降低，因为导航结构的部分功能会因此而缺失。用户有一个替代方案，就是点击顶部的状态栏快速上翻到页面顶部，使用Safari顶部栏的导航结构。遗憾的是，并非所有的用户都知道iOS的这一特性，而他们经常会试着去滑动到顶部寻找导航结构。 这是在考虑iPhone和iPad网页的应用场景时需要记住的两个要点。接下来将介绍应在项目流中的何时何处应用可用性原则。 3. 移动可访问性和可用性检查列表 下面是在设计项目时应检查的列表，包含了一般的可访问性和可用性条目。 (1) 可访问性 合理的站点加载时间 文本和背景间应有足够的对比度 易于阅读的字体大小和间距 尽量少用额外的JavaScript脚本 给图片加上Alt标签属性 自定义“404错误页” 优化的适于打印的样式表 优化的设备原生服务整合 针对不同的iPhone型号优化的布局 同时针对横竖屏优化的布局 同时针对横竖屏优化的图片 提供转向标准站点的链接 (2) 可用性：导航 主导航一目了然 导航标签简洁明了 按钮与链接的数量合理 公司的logo链接到首页 “对手指友好”的链接和图标 一致且易于辨识的链接 高亮显示当前所处位置 在页面头部提供返回按钮 文本自描述性的链接 在spotlight搜索页中显示自定义的图标 返回相关的错误信息 便于访问的站内搜索 (3) 可用性：内容 水平式站点内容结构 页面设计中使用负空间 清晰直观的页面层级 重点突出的内容 非常重要的内容位置要明显 有一定描述性的HTML页面标题 主标题清楚达意 样式与配色风格一致 尽量少用强调文本 使用有意义及对用户友好的URL 重要的一点是，做下个项目时，要以这个一般性的列表为基础，基于项目中最重要的东西，提取出自己的可用性检查列表。 2.2.3 iPhone页面模型 iPhone页面模型指的是每个iPhone页面的基础构建块。所有的网站、Web应用，甚至原生应用都基于这一概念，因此iPhone上的所有内容都呈现为一个单列线性结构。 利用页面模型，iPhone可以很好地支持各种分辨率下的横竖屏展现（163ppi的iPhone 2G、iPhone 3G和iPhone 3GS的分辨率为320×480和480×320，326ppi的iPhone 4和iPhone 4S的分辨率则为640×960和960×640，326ppi的iPhone 5的分辨率为1136×640和640×1136）。屏幕的每一种朝向都有自己的优势。一般而言，竖屏更适合显示列表，而横屏更便于阅读大部分内容。 页面模型是网站或Web应用内容共有的概念性结构，展示在屏幕上的可视区域内，如图2-21所示。 iPhone页面模型基于五个区块： 品牌区 主导航区 内容区 副导航区 站点信息区 说明 在原生应用（使用Objective-C和苹果SDK开发的应用）以及模拟原生iPhone用户界面的Web应用中，品牌区和导航区常常融合在一个头部中，并没有单独的导航存在。 每次用户和链接发生交互时，一个新的页面就会在屏幕上的可视区域内（参见2.2.4节）加载，而之前的页面会被整个替换。这在横屏及竖屏视图下都会发生。 图2-21 iPhone页面模型的缩略图形式（左图）和有语义标记的全屏视图（右图） iPhone页面结构是持久性的，意味着用户在横竖屏间切换时也会保持不变。这听起来似乎理所当然，但在分析iPad块模型时就会发现这并不是个不变的准则。 现在已经了解了iPhone的页面模型，下面分析一下它的用户界面。 2.2.4 iPhone用户界面 iPhone用户界面是图形化的、基于触摸的软件，工作于电容触摸屏上。这一界面由两大逻辑部分组成： 原生用户界面 可视区域 原生用户界面和可视区域一起占据了所有可用的屏幕区域。自顶向下，iPhone的屏幕区域则由四个不同的部分组成： 状态栏（属于原生用户界面） 地址栏（属于原生用户界面） 可视区域 底部工具栏（属于原生用户界面） 原生用户界面包含了那些显示在iPhone页面顶部和尾部的元素。在不同的原生或Web应用中，使用了不同类型的原生用户界面，但对于Mobile Safari网页浏览器而言，只有如表2-1中总结的 三种。 表2-1 iPhone原生用户界面中的元素和功能 原生用户界面元素 功 能 尺寸（以像素为单位） 状态栏 显示iPhone的整体状态：网络连通性、电池电量以及当前的时间 竖屏下：高20px 横屏下：高20px 地址栏 显示网页标题和主要的浏览功能：地址栏、搜索框和刷新按钮 竖屏下：高60px 横屏下：高60px 底部工具栏 显示网页的导航功能：后退和前进、书签按钮及选项卡式页面间导航 竖屏下：高44px 横屏下：高32px 状态栏和地址栏的尺寸不会在横竖屏模式切换时改变，但底部工具栏从竖屏模式切换到横屏模式时，高度从44px变成了32px，如图2-22所示。这意味着可用的可视区域并没有一个固定的 尺寸。 正如前面所说，每一个iPhone页面都显示在屏幕的所谓的可视区域内，而可视区域并没有占据100%的可用屏幕，因为原生用户界面在竖屏和横屏视图下分别占据了124px和112px。 说明 在iPhone上，用户还可以选择始终在地址栏下显示调试控制台，从可视区域中进一步“偷取”50个像素。 图2-22 在伴有地址栏的情况下，可视区域分别在竖屏和横屏视图下的可用尺寸 这一事实至关重要，因为根据iPhone的朝向不同，能用的屏幕尺寸也并不一样。iPhone 4/4S除了配备的Retina显示屏具有更高的分辨率外，其显示区域内的用户界面元素间（例如状态栏、地址栏和底部工具栏等）有着相同的显示比例和相对尺寸。从用户的角度来看，除了屏幕有更好的分辨率和更佳的阅读性以外，在和iPhone 4的交互操作上没有什么别的变化。在图2-23中，我们能看到新的Retina显示屏所带来的清晰度和锐利度的巨大提升。 图2-23 Retina显示屏带来的高清分辨率 表2-2展示了所有的iPhone型号中，3.5英寸显示屏在各种朝向下的可用显示面积占比。 表2-2 横屏和竖屏视图下，iPhone的可用显示面积占比 （上为iPhone 2g/3g/3gs，下为iPhone 4/4S） 模 式 附带地址栏的可视面积 不带地址栏的可视面积 竖屏 74% 87% 横屏 65% 84% 2.2.5 iPad块模型 iPad的内容结构基于块模型的概念。一整个页面不再是内容构建的基石，而是基于内容页面内的各个区块。在iPhone上，信息是线性展示的，而iPad的内容却主要基于各种不同的两栏布局。 iPhone和iPad都支持两种类型的朝向，但对于iPad而言，无论是竖屏下的768×1024还是横屏下的1024×768（像素密度都是132ppi），和163ppi的旧款iPhone显示屏以及328ppi的iPhone 4的Retina显示屏相比，都显得不够清晰。 仅就iPhone而言，每种朝向都有其优势，但这里并非指空间上的优势，因为无论在哪种视图下，实际的屏幕可视区域都足够应付绝大部分需求了。 iPad令人兴奋的新东西莫过于两种朝向与新的屏幕分辨率，使我们能设计两种不同类型的布局。而这两种布局可以分别针对不同的分辨率优化，并能添加或移除组件。 就在2007年第一台iPhone问世的时候，苹果的设计师便发布了一个优秀的范例，同时也是一个隐式的指南。在图2-24中，我们能看到原生的“备忘录”应用是如何利用块模型来呈现两种不同类的布局的。用户在横屏模式下会与基于两大区块的布局交互，左区块是一个待办事项列表，而当前选择的具体待办事项内容则显示在右侧的主区块中。 图2-24 一个双区块模型应用的例子：iPad的备忘录应用 正如前面所介绍的，iPad的信息结构并不像iPhone那样严格一致。就目前所了解的情况来看，这并不算是个问题，反而是一个令人兴奋的机遇。 说明 在上面这个例子里，两个区块以两栏的形式存在，但并不表示一直如此。在其他的例子里，被添加或移除的区块（在横屏或竖屏视图中）可以是一个辅助性的导航，或是某种“行为召唤”的按钮，又或者其他一些有用的东西。 回头再看备忘录应用，会发现在竖屏视图下去掉的那个区块包含了有用的信息，而即便此时用户处于竖屏视图下也可能需要这些信息。因此，好的做法是即便在某个朝向下有些区块不能显示，仍应为用户提供访问此区块的方法。 苹果的设计师再一次提供了一个简易方案：使用弹出式菜单，在应用头部放置按钮来访问。如此一来，无需旋转屏幕朝向也能访问到这部分信息，如图2-25所示。在可视区域内展示了用到的块模型，看起来就好像在使用iPhone一样。 图2-25 使用双区块模型的应用示例：在竖屏视图下访问横屏视图下提供的内容 iPad块模型同样也是基于以下五个区块： 品牌区 主导航区 内容区 副导航区 站点信息区 当用户和一个链接发生交互时，看上去更像是和一个桌面网页在交互。因为iPad原生支持 768×1024和1024×768的分辨率，所以大多数设计者都认为没必要专门针对iPad设计和开发专用的结构。 在开发者社区中，我们经常讨论如何优化网页。而对于新的苹果设备，也有一些关于如何运用HTML5标签或使用HTML5视频播放器来代替Adobe Flash player的指南。 为了完全兼容iPhone，一个网站必须得单独设计一个完全不同的版本。但相对而言，只需少量代码上的改动，便能把网页改造成完全兼容iPad。难点在于，为鼠标导航设计的网站对于某些移动用户（如视力不太好，或是手指比较粗大等）来说可能体验相当糟糕，例如图2-26上所示的这种。 这时，只能寄希望于Mobile Safari浏览器提供的缩放功能来改善用户的体验，但这样的做法不能非常好地体现一个设计师的创新功力和改善用户日常生活体验的想法。 图2-26 《时代》杂志的官方网站：网站能够兼容iPad并不意味着工作都做到位了 说过了iPad的块模型，下面该分析下它的用户界面了。 2.2.6 iPad用户界面 iPad运行着和iPhone一样的操作系统（iOS），因此二者界面的外观和感受都极其雷同。iPad的用户界面仍然由如下两个逻辑组成部分，但有一处区别。 原生用户界面 可视区域 和iPhone一样，原生用户界面和可视区域一起占据了所有可用的屏幕区域。但这一次自顶向下来算，iPad的屏幕区域仅由三个不同的部分组成： 状态栏（属于原生用户界面） 地址栏（属于原生用户界面） 可视区域 说明 一些原生应用（如YouTube或iTunes）使用了底部工具栏，就像在iPhone界面中看到的那样。这一底部工具栏有48像素高，用以向用户提供高级选项。 原生用户界面包含了那些显示在一个iPhone页面顶部和尾部的元素。作为针对苹果设备的设计者和开发者，感兴趣的是Safari网页浏览器界面，因为制作的网站或是Web应用最终要在浏览器中渲染展现。 即便是在iPad上，不同的原生或Web应用中也使用了不同类型的原生用户界面，但对于Mobile Safari网页浏览器而言，只有如表2-3中总结的两种（第三种是可选的）。 表2-3 iPad的原生用户界面的元素和功能 原生用户界面元素 功 能 尺寸（以像素为单位） 状态栏 显示iPhone的整体状态：网络连通性、电池电量以及当前的时间 竖屏下：高20px 横屏下：高20px 地址栏 显示网页标题和主要的浏览功能：地址栏、搜索框和刷新按钮 竖屏下：高44px 横屏下：高44px 底部工具栏 显示应用特定的高级选项：在YouTube中浏览最多的视频、iTunes的播放列表等 竖屏下：高48px 横屏下：高48px 可视区域并不总是占据了屏幕所有可用的区域，因为原生用户界面在无论横竖屏视图下都要占用66像素的高度。结果就是如果带有地址栏，在竖屏和横屏视图下将分别有94%和92%的可视面积。去掉地址栏的话，几乎可以达到100%的屏幕利用率：竖屏和横屏视图下分别为98%和97%。 说明 在iPad上，用户可以选择始终在地址栏下显示收藏夹栏，从可视区域中进一步“偷取”28个像素。相比iPhone，我们可以看到无论在哪种屏幕朝向下，可视区域的面积都有相当大的提升，正如图2-27中看到的那样。 图2-27 横屏和竖屏视图下，iPad的可用显示面积占比（带地址栏） 在一台有着近乎100%的实际可视面积的9.7英寸显示屏上，我们有足够的空间来大力改进移动用户体验，并有机会提供前所未有的交互。表2-4列出了可用显示面积所占屏幕的百分比。 表2-4 横屏和竖屏视图下，iPad的可用显示面积占比 模 式 附带地址栏的可视面积 不带地址栏的可视面积 竖屏 94% 98% 横屏 92% 97% 2.2.7 用于苹果移动设计的工具 本章用到的工具既有商业软件，也有免费软件。下面的列表列出了一些有用的工具，可以在设计网站或Web应用时好好利用。 表2-5 一些用于设计iPhone和iPad网站及Web应用的工具 名 称 适用范围 类 型 支持的操作系统 Timeline 3D 路线图 应用程序 OSX XMind 思维图、站点导航图 应用程序 OSX - Win - Linux OmniGraffle 站点导航图、线框图 软件 OSX - iOS Cacoo 站点导航图、线框图、UML Web应用 OSX - Win - Linux App SketchBook 线框图 实物工具 --- iPhone UI Stencil 线框图 实物工具 --- iPad UI Stencil 线框图 实物工具 --- iPhone GUI PSD 线框图 素材图 OSX - Win - Linux iPad GUI PSD 线框图 素材图 OSX - Win - Linux Balsamic Mockup 线框图 应用程序 OSX - Win - Linux iPhone Mockup 线框图 Web应用 OSX - Win - Linux Prototyping for iPhone 电子版原型 Adobe Fireworks的插件 OSX - Win iPlotz 电子版原型 Web应用 OSX - Win - Linux LiveView 电子版原型 应用程序 OSX - iOS