为在桌面浏览器中显示而设计的内容的在典型移动设备空间有限的屏幕上的显示效果会大有不同。同样,由于手持设备的处理能力有限,图形化内容也会显著影响页面加载时间。正因为有着这些局限性,以用于移动设备为目的的 Web 内容往往是定制的(有时也称为为移动设备而优化的)。优化的目标是通过这样的方式显示 Web 页面信息:所需滚动最少(包括水平和垂直)、缩短下载时间、降低系统资源需求,同时维持一种直观、易于使用的用户界面。
我们粗略浏览了一些技术文献和 “为设备而优化的” Web 站点,据此确定,有几种方法可 “压缩” 传统桌面 HTML 页面以更好地适应一种设备。例如,Steinberg & Pasquale(2002)描述了基于服务器的 “Web 流定制程序” 的使用,它能压缩图形图像,重新格式化框架;而 Buyukkokten、Kaljuvee、Garcia-Molina、Paepcke, & Winograd(2002)探讨了 Web 页面摘要,在其中仅显示页面的文本或超链接。然而,优化一个页面的惟一途径就是创建一个独立的版本,从一开始设计时就考虑到这种设备的局限性(Clement & Vickers,2002)。
我们汇总了以下一系列的设计准则,协助您设计为设备而优化的 Web 内容。下面列出的准则并不完整,但介绍了一些基本规则,我们希望各种开发团队都能在界面设计工作中加以利用。
一台 PDA 的屏幕的面积大概是 800x600 显示器的六分之一(Clement & Vickers,2002)。以徽标、图标、框架和图片的形式出现的页面图形都会增加页面加载时间,并不必要地占用原本就非常有限的空间,从而导致重要信息(文本、超文本和必要的数据输入字段)超出显示范围。 Yahoo!-news Web 站点同时面向桌面浏览器和移动设备,它是一个展示为设备而优化的内容与非优化设备内容间差异的好例子:
图 1. 非优化的设备内容
图 2. 为设备而优化的内容
从图 1 和图 2 中可以轻松看出,优化后的版本减少了内容数量(特别是框架图形),从而缩短了页面加载时间,也减少了查看整个页面所必需的垂直滚动。在大多数情况下,无垂直滚动也是必要的。
同样,由于显示面积有限,文本使用也应有所限制。如图 2 所示,优化的 Web 站点的共同主题就是使用纵向的超文本列表。对于提供了实际键盘的设备来说,为链接编号是一项良好的实践。这将允许用户使用键盘或数字键而不是指示笔选择链接,便于单手完成交互。
在大多数情况下,超链接列表消除了水平滚动的需要;但若链接必须包含许多文字,例如新闻头条或电子邮件主题行,可考虑采用水平滚动,以便纵向层叠地放置更多的条目。为避免中断 URL,也可考虑使用水平滚动。
避免使用大号文本和图标。文本和图表的默认大小应与各设备的标准字号一致。Windows™ Mobile 标准字号和字形如表 1 所示:
表 1. Windows Mobile 字号和字形
| 类 | 字体 | 字号 | 字形 | 颜色 |
| 标题 | Tahoma | 8 磅 | 粗体 | COLOR_HIGHLIGHT |
| 正文文本 | Tahoma | 8 磅 | 常规 | COLOR_WINDOWTEXT |
| 子标题 | Tahoma | 8 磅 | 粗体 | COLOR_WINDOWTEXT |
| 超链接 | Tahoma | 8 磅 | 常规加下划线 | COLOR_HIGHLIGHT |
| 选项按钮 | Tahoma | 8 磅 | 常规 | COLOR_CAPTIONTEXT |
| 复选框 | Tahoma | 8 磅 | 常规 | COLOR_CAPTIONTEXT |
| 按钮 | Tahoma | 8 磅 | 粗体 | COLOR_BTNTEXT |
| 菜单栏 | Tahoma | 8 磅 | 粗体 | COLOR_MENUTEXT |
| 菜单项 | Tahoma | 8 磅 | 粗体 | COLOR_MENUTEXT |
应避免不同页面元素(文本、图标、字段等)之间的额外垂直和水平空间以及页面边框。
对于用户来说,设备数据输入通常是一个极具挑战性的过程,原因有几个方面。首先,与原尺寸的键盘和鼠标相比,输入方法(“微型键盘”、“软键盘” 以及 “手写板”)有所制约。采用这些方法时,输入速度明显降低(Commarford,in press;Roeber,Bacus & Tomasi,2003),而在软键盘的情况下,用户往往必须采取两个额外的步骤,来打开和关闭键盘功能。除此之外,在显示数据输入字段时,新用户通常希望能够在所提供的字段中手写(使用指示笔)所请求的信息,这总是会带来迷惑和挫折(Clement & Vickers,2002)。另外一个与使用包含多个数据输入字段的表单相关的问题就是空白的输入字段会很快占据整个显示空间。
同时显示所有输入字段和相关文本提示的一种替代方案就是单独显示文本提示。在用户确定他们希望填写哪个字段之后,即可选择响应的文本提示,此时即显示输入字段(Kaljuvee,Buyukkokten,Garcia-Molina, & Paepcke,2001)。
过度使用数据字段的另外一种替代方案就是为用户提供一系列的超链接,从大范围开始,每一组后续链接就缩小一点范围。此类方案的一个例子就是搜索给定地理位置处的一家旅馆。这里不会要求用户输入旅馆的名称和方位,而是为用户提供一个旅馆列表,后接一个可能位置列表(例如,国家,然后是城市/区等等)。请注意,虽然对于桌面系统来说,输入并搜索的方法要快于链接导航,但对于移动设备来说并非如此。您应权衡搜索特性节省下来的步骤与输入耗费的时间(假设触摸屏输入方法需要 12 WPM,而使用微型键盘时需要 25 WPM)。
只要可能,就在下拉菜单、图标式按钮、单选按钮或表单中使用链接。如果使用了小部件,请将其最小化到与周围的屏幕元素(例如文本)大小相匹配,以避免过度占用空间、糟糕的对齐问题和行间距问题。
允许文本在页面边界处自动换行,避免出现需要水平滚动的情况。但成对的页面元素,比如说导航链接和关联的按钮(例如,取消按钮和取消链接)不应因换行而出现在独立的几行中(通常也应避免留空,链接已经足够了)。
错误消息应以用户显而易见(例如,通过 “弹出” 窗口)的方式显示。如果错误消息必须嵌入在 Web 页面中,确保它位于一个在刷新时可清楚看到的位置处;否则,它就会被忽视,特别是在用户必须滚动才能看到它的情况下更是如此。
与主题或所显示的页面的目的不相关的超文本链接应放置在页面的底部。这能节省空间,并将最重要的信息放在用户向页面输入信息时的视图中(不需滚动即可浏览最常用的路径)。例如,图 3 所示的 Palm2 屏幕快照展示了到其他相关 Web 站点的导航链接的理想位置:
图 3. 导航链接位置
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- “Efficient Web browsing on handheld devices using page and form summarization” 介绍了在小型手持设备 —— 例如个人数字助理(PDA)或移动电话 —— 上显示和操纵 HTML 页面的一种设计和实现。(ACM Transactions on Information Systems,20(1),82-115. Buyukkokten,O.,Kaljuvee,O.,Garcia-Molina,H.,Paepcke,A. & Winograd,T. 2002)。
- “From server to PDA: an HCI perspective on porting wireless roaming business applications” 给出了英国利物浦召开的 IEEE 5th International Workshop on Networked Appliances 会议记录,107-112,Clement,P. & Vickers,P.(2002)。
- “Efficient Web form entry on PDAs” 给出一种设计建议,用于在小型的 PDA 屏幕上显示和操纵 HTML 表单。本文来自 WWW10,Hong Kong,663-672.Kaljuvee,O.,Buyukkokten,O.,Garcia-Molina,H. & Paepcke,A.(2001)会议记录。
- “Typing in thin air: The Canesta Project keyboard -- A new method of interaction with electronic devices” 介绍了电子设备的一种不同界面。本文来自 Computer-Human Interaction,USA,712-713. Roeber,H.,Bacus,J. & Tomasi,C.(2003)会议记录。
- “A Web middleware architecture for dynamic customization of content for wireless clients” 给出了一种全新的 Web 中间件架构,允许您针对 Web 定制您的视图,以实现最佳交互。本文来自 WWW 2002,USA,639-650. Steinberg,J. & Pasquale,J.(2002)会议记录。
- 这份红皮书探讨了与 Mobile applications with WebSphere Everyplace Access Design and Development 相关的设计问题。
- 另外一份关于 Patterns 的红皮书,介绍了 Pervasive and Rich Device access solutions。
- 浏览关于上述和其他技术主题的 图书。
- developerWorks Web 开发专区 专门提供关于各种 Web 开发和架构方面主题的文章。
- 通过参与 developerWorks blogs 加入 developerWorks 社区。
James Cotton 目前在 IBM 的 User-Centered Design 团队担任人类工程学实习工程师。除了从事 WebSphere Everyplace 新产品套件的设计工作之外,James 还在攻读 University of Central Florida 的应用实验和人类因素心理学的博士学位。

Patrick 是 WebSphere® Everyplace Access Client 的人类因素工程师主管。他负责增强 Everyplace 的终端用户体验,通过实施 User-Centered Design(UCD)方法学和遵循人类因素原理的应用程序达成这一目标。Patrick 已供职于 IBM® 三年之久,在这段时间里,他致力于强化面向企业和消费者市场的产品的易用性。您可通过 commarfo@us.ibm.com 与他取得联系。