为移动电话设计应用软件

当开发者要决定移动终端的各种应用软件应包含什么信息时，他们应考虑用户在什么情况下使用移动电话。服务内容应满足目标用户群的需要，并且应该对最常见的任务进行最优化。由于较小显示设备便于移动，所以，在没有PC机的情况下，用户可能会首先使用移动电话访问英特网以及获取急需信息。相应的范例包括快速访问航班信息、查看简讯和天气情况等。但用户使用移动电话上网冲浪的可能性要小一些。

保持用户任务流的流畅及图像的合理使用

彩色页面看起来很诱人，但当图像传输使得服务减慢时，彩色页面也许并不让人觉得很舒服。根据可用性研究2，用户不太热衷于那些由于图像传输而中断他们任务流的服务。特别地，当用户在搜寻目标页面时，大的图像就不太合适。含有信息价值的图像是令人青睐的，但在多数情况下，用户或是关掉图像以节省时间和金钱，或是不等图像下载就切换到下个页面。在下载所有图像之前允许用户继续浏览页面，是很重要的。

大表格也许会产生相似的问题——也就是说，在某一页面下载完之前，用户的操作被冻结；或者在页面下载完之前不能继续进行其他操作。因为移动电话显示屏的大小不同，所以开发者应确保即使是在最小的显示屏上，也能够阅读数据表格；通常这些数据表格要进行压缩以符合显示屏的要求。

结构对新用户要简单但也不能忽视熟手用户

在移动通信服务中，浅层结构似乎常常比深奥结构更容易理解。链接和页面应该冠以描述性的名称，这样可以帮助用户找到他/她需要的信息。

很难说在一个链接列表页面上应该提供多少个链接。如果链接明显属于同类且容易浏览（每个链接占一行，以字母顺序，或另外以逻辑顺序排列，这样用户就不必把每个链接都读一遍），那么，比较好的方法是在一个页面上提供30个链接，而不是每个页面上提供5个链接，总共需要6个页面。如果有好几十个链接，在显示这些链接前提供排序选项是个不错的主意。如果链接能放置在一行上，则选择起来一目了然，页面也更美观。

WAP 2.0 没有<do>元素，相反，它们由access keys取代。然而，大多数用户似乎并不了解access keys元素，并且无法找到他们。为了帮助用户理解accesskeys 的概念，开发者应确保access keys在屏幕上可见，而且以类似电话键的形式出现。

如果有可能，应提供搜索功能。熟手用户很欣赏这个功能，正如新手用户浏览著名站点一样。

在页面上提供足够信息

交互式页面应该简短，信息页面应该较长3。不建议使用doormat 页面来启动站点，doormat 页面除了问候访问者和显示logo 外，没有其他作用。较好的方式是用户能够直接访问服务。

在XHTML 下，信息以页面形式下载，而不是以WML 下的deck 形式。这意味着向用户提供单个页面上的信息以支持他们的任务流就显得更为重要。由于XHTML 页面是各自独立下载的，所以在XHTML页面间来回切换可能会消耗更多的时间。后向导航尤其存在这种情况，在这些情况下页面不能缓存，例如，与付帐或提供私人信息有关的系统就是这种情况。

任何页面的第一屏（最顶端）都是最重要的。所有经常使用的导航链接、搜索域、登录屏幕和大量信息都驻留在那儿。用户可在页面的剩余部分加载之前向前浏览，并且无需滚动页面。应避免在页面顶端放置横幅广告或没有任何信息的图形。最好是把广告放在页面的左侧或右侧边框。

上下滚动页面是困难的，因此带有表格的交互式页面不应该太长，因为用户不能确信他们是否已经填完长表格上的每个域。如果表格所占空间超过两屏，用户可能容易失去控制感。用户访问的目标页面应该具有足够多的信息。例如，如果目标页面包含故事或用法说明，则应该在一个页面上显示所有内容。当用户浏览一个长而信息量较大的页面时，能够在页面内引导用户的子标题将帮助用户浏览页面。

信息是以单个页面下载而不是以deck下载的这个事实是影响导航以及WML和XHTML之间结构性差异的最大单个变化。

为用户操作提供信息反馈

开发者应该对用户操作、以及错误和问题情况提供正确的反馈。例如，在用户点击链接之后，页面标题应该与链接名相同。减小导航步骤应该不增加用户的不安全感，例如，用户操作的确认页面是必要的，尽管这些页面需要再次点击。如果确认页面丢失，用户也许觉得她/他需要检查，以确认这一行为是否发生——这会导致更多次的点击。应该认用户觉得他们始终在控制着系统如果出现问题，应提示用户下一步该怎么办。向用户解释期望输入的格式以及对必填项进行标记可阻止错误发生。

尽可能减少图像数量和减小图像容量大小

应该认真考虑一个XHTML 页面上图像数量和容量大小。页面上的每一幅图像就产生一次独立的来回，这反过来使整个页面的显示速度减慢。因此，应该尽量减少来回的数量。还要注意的是，当每次一幅图像到达移动设备时，整个页面的内容可能需要重新排列，这会占用时间和处理器资源。因此，一个仅有几幅图像的页面也许比一个有许多更小图像的页面下载得更快。如果有可能，建议在全部服务中各个页面上使用相同的图像；那么一个特定的图像只需下载一次且能够保存到高速缓存器中。例如，如果自定义的图像被用作bullet，则在整个服务中应该使用相同的图像。

TCP/IP 连接也许会造成页面下载速度的不同，即使其数据量相同。例如，下载一个包含四个图像（每个图像大小为2 KB 的XHTML 页面）要比下载一个包含八个图像（每个图像大小为1KB 的页面）的速度要更快。

如果使用WAP 网关，则WAP 网关应与通用分组无线服务(GPRS)支持节点网关（GGSN）放得近一点。在这个例子中，“近”是指数据延迟及数据包丢失的概率。由于HTTP重传，丢失信息会产生附加延迟。WAP网关和内容服务器间的时延应尽可能的小。

定义图像高度和宽度属性

建议内容开发人员在标记语言中明确地指定图像的高度和宽度，以使浏览器为图像预留适当的空间。如果在图像标签中使用高度和宽度参数，那么XHTML 浏览器就能在下载图像之前为图像预留空间。因此，在图像下载之前页面就能够显示出来，当然，图像在下载后也能够出现在页面上。这并不影响XHTML页面的完整下载和处理时间，但却大大改善用户的感受，因为在下载图像之前用户可浏览页面。例如：

<img src="pics/header_main_page_001.gif" width="175" height="41" />

谨慎使用表格

XHTML 页面浏览器支持表格和嵌套表格的使用。在定义表格单元宽度，尤其是处理嵌套表格时，开发人员应谨慎行事。

考虑添加样式定义选项

开发者可以用各种方式来定义自己的样式，例如：使用外部样式表、使用文档头部的样式元素，或通过使用指定元素的行间样式属性等。一般而言，虽然使用外部样式表无论何时都有可能把样式从标记语言中分离出来，这是一种好的方法，但应注意权衡考虑。如果样式定义包含在XHTML代码中，则XHTML页面的显示就更快，但是外部样式表的使用提供一种在整个服务中更改样式的便利方法。在整个服务中应该使用相同的外部样式表以避免把多个样式表下载到电话上。外部样式表仅需下载一次并能够保存在高速缓存器中。

删除代码内不必要的空白区和代码内的注释

确保代码内没有多余的空白区非常重要。虽然空白区在屏幕上是不可见的，但仍要被处理，因为浏览器要对空白区进行分析、排版、CSS 分配和显示等。

XHTML 代码内注释数量应尽量地少，以使代码尽可能地紧凑。

使用HTTP 标题指示来支持页面缓存

浏览器能够把已经阅读的XHTML 页面放在缓存器中。然而，内容开发者不应假定页面缓存是默认的4。如果可能，应与文档一起发送明确的缓存标题以确保页面在客户端能够缓存。另外，应将过期时间设置为至少数天，这是为了确保在跨越多个时区的情况下，内容能够缓存一段适当的时间。

浏览器不支持在Meta 标签内 (例如，使用 HTTP-EQUIV)放置缓存指示，但可用HTTP标题控制缓存。HTTP 服务器可设置”Cache-control: no-cache” HTTP标题指示，而此服务器放置了能够定义“页面不进行缓存”的页面。

缓存使用“最近最少使用”算法，这意味着最少使用的项首先被清除。建议重复使用所有XHTML页面内的图像和外部CSS，以确保它们留在缓存中，以便每次使用它们时不需要重新下载。

使用Unicode 2.0 字符集编写XHTML 的内容

诺基亚XHTML 浏览器支持ASCII 和 Unicode 2.0 字符集。因此，为了确保XHTML 最大程度的互操作性，应该使用非拉丁语的Unicode 来创建所有的XHTML内容。对于拉丁语，也可使用ASCII来创建。有些网关和代理能把本地字符集转换成Unicode ，但并非所有的字符集都能转换。所以，保证终端接收Unicode 的唯一方法就是用Unicode 创建内容。

使用正确的MIME 类型和经过验证的XHTML 代码

由OMA 定义的XHTML MP 内容的首选MIME 类型为：”application/vnd.wap.xhtml+xml”。这一类型可以用于向XHTML 用户代理提供XHTML MP 文档支持。另外，也可使用 “application/
xhtml+xml”。在一些 Series 60 浏览器上，必须使用MIME类型“application/vnd.wap.xhtml+xml”以确保正确的XHTML MP内容视图。MIME类型“text/html”也是可用的，但是，对于XHTML来说，这种类型应被保留，以便用于在现有的HTML用户代理上的显示功能。应注意“text/html”格式的XHTML文档将不作为XML格式来处理。例如，这意味着用户代理也许不能检测到形式上不像错误的错误。对于既想支持XHTML用户代理又想支持HTML用户代理的软件开发者来说，可以通过让HTML文档作为“text/html”类型，XHTML文档为“application/vnd.wap.xhtml+xml”类型来使用内容协商机制。

建议所有XHTML MP 内容使用*.xhtml 的文件扩展名。为了避免出现任何互操作性问题和提高性能，应该对XHTML代码进行验证。例如，可用http://validator.w3.org上的 W3C验证器来验证XHTML内容。如果动态地创建XHTML内容，则生成的代码是合法的DTD XHTML MP 1.0 代码。

使用描述性页面标题和元素标签

页面标题描述所显示的页面内容。在WML中推荐使用标题，而在XHTML中强制使用标题。标题帮助用户浏览应用软件，因为它们会提醒用户她/他处于应用软件的什么位置。一个较好的方法就是标题用应该用服务的名称开头并且应该很短。用户以前选择的栏目将决定标题文本。例如，标题“书签”告诉用户显示屏包含了应用软件的一个书签列表，以及前一次选择的选项项目是“书签”。

标题文本应该使用比例字体，如果标题文本太长，文本会被自动删减。通常，删减标题的效果要比缩写更好，因为用户可能会对不熟悉的缩写困惑不解。虽然建议元素标签使用缩略词，但不应该使用目标用户群不大熟悉的首字母缩写词。相同的标签应该总是用于相同的操作，尤其是诸如Delete、Remove、 Erase、Clear 和 Destroy 的功能标记。

进行可用性测试

对新的应用软件进行可用性测试总是正确的选择。没有参与设计和开发应用软件的人往往会注意到潜在的可用性问题，这些问题对于那些非常了解设计的人常常不是显而易见的。可用性测试应该在开发过程中尽可能早地进行。这样，在开发时间表内能够完成根据测试结果需要进行任何必要的更改。应该邀请能够代表未来最终用户的测试人员进行测试。如果日程安排不允许进行大量测试，至少应进行小规模测试。