跳转到主要内容

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

当您初次登录到 developerWorks 时,将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人,但您可以随时修改这些信息的显示状态。您的姓名(除非选择隐藏)和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

  • 关闭 [x]

当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

所有提交的信息确保安全。

  • 关闭 [x]

针对移动浏览器设计 Web 内容

优化移动设备上的信息展示的 UCD Recommendation

James Cotton, 人类因素工程师
James Cotton 目前在 IBM 的 User-Centered Design 团队担任人类工程学实习工程师。除了从事 WebSphere Everyplace 新产品套件的设计工作之外,James 还在攻读 University of Central Florida 的应用实验和人类因素心理学的博士学位。
Patrick Commarford (commarfo@us.ibm.com), 顾问人类因素工程师, IBM
Patrick 是 WebSphere® Everyplace Access Client 的人类因素工程师主管。他负责增强 Everyplace 的终端用户体验,通过实施 User-Centered Design(UCD)方法学和遵循人类因素原理的应用程序达成这一目标。Patrick 已供职于 IBM® 三年之久,在这段时间里,他致力于强化面向企业和消费者市场的产品的易用性。您可通过 commarfo@us.ibm.com 与他取得联系。

简介: 由于显示区域和处理能力有限,移动计算设备无法有效地呈现那些专为标准桌面浏览器设计的 Web 内容。因而,要在移动设备上查看或与之交互的 Web 内容在设计时应考虑到这些局限性。这篇文章以优化信息显示和改进人机交互为主旨,给出了创建此类内容的基本准则。

发布日期: 2007 年 6 月 11 日
级别: 初级
访问情况 : 695 次浏览
评论: 


简介

为在桌面浏览器中显示而设计的内容的在典型移动设备空间有限的屏幕上的显示效果会大有不同。同样,由于手持设备的处理能力有限,图形化内容也会显著影响页面加载时间。正因为有着这些局限性,以用于移动设备为目的的 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 字号和字形

字体 字号 字形 颜色
标题Tahoma8 磅粗体COLOR_HIGHLIGHT
正文文本Tahoma8 磅常规COLOR_WINDOWTEXT
子标题Tahoma8 磅粗体COLOR_WINDOWTEXT
超链接Tahoma8 磅常规加下划线COLOR_HIGHLIGHT
选项按钮Tahoma8 磅常规COLOR_CAPTIONTEXT
复选框Tahoma8 磅常规COLOR_CAPTIONTEXT
按钮Tahoma8 磅粗体COLOR_BTNTEXT
菜单栏Tahoma8 磅粗体COLOR_MENUTEXT
菜单项Tahoma8 磅粗体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. 导航链接位置
导航链接位置

参考资料

作者简介

James Cotton 目前在 IBM 的 User-Centered Design 团队担任人类工程学实习工程师。除了从事 WebSphere Everyplace 新产品套件的设计工作之外,James 还在攻读 University of Central Florida 的应用实验和人类因素心理学的博士学位。

Patrick Commarford

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

关于报告滥用的帮助

报告滥用

谢谢! 此内容已经标识给管理员注意。


关于报告滥用的帮助

报告滥用

报告滥用提交失败。 请稍后重试。


developerWorks:登录


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 使用条款

 


当您初次登录到 developerWorks 时,将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人,但您可以随时修改这些信息的显示状态。您的姓名(除非选择隐藏)和昵称将和您在 developerWorks 发布的内容一同显示。

请选择您的昵称:

当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

(长度在 3 至 31 个字符之间)


单击提交则表示您同意developerWorks 的条款和条件。 使用条款.

 


为本文评分

评论

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Web development
ArticleID=229552
ArticleTitle=针对移动浏览器设计 Web 内容
publish-date=06112007
author1-email=jcotton@us.ibm.com
author1-email-cc=
author2-email=commarfo@us.ibm.com
author2-email-cc=

标签

Help
使用 搜索 文本框在 My developerWorks 中查找包含该标签的所有内容。

使用 滑动条 调节标签的数量。

热门标签 显示了特定专区最受欢迎的标签(例如 Java technology,Linux,WebSphere)。

我的标签 显示了特定专区您标记的标签(例如 Java technology,Linux,WebSphere)。

使用搜索文本框在 My developerWorks 中查找包含该标签的所有内容。热门标签 显示了特定专区最受欢迎的标签(例如 Java technology,Linux,WebSphere)。我的标签 显示了特定专区您标记的标签(例如 Java technology,Linux,WebSphere)。