BREW-教你设计用户界面

  这个书高通下的pdf，英文版。当时对BREW一无所知，也没有在手机上设计过界面，所以就从这本书入手吧，看看在手机上做程序同计算机上有什么不一样。我自己译的，水平有限。
        文档结构我没整理，按照页码来的。书中摘录别人的部分我没译，太多，自认为看看就行了。
page 9

版权

高通公司所有的图片以及商标，不可以修改。引用时请注明高通公司。

常用的设计元素

本部分中，我们将讨论软件应用程序中常用的一些元素，以及高通的一些使用建议。

帮助

与桌面应用程序不同，动态下载的BREW程序没有用户手册。当设计一个非傻瓜型的复杂程序时，建议提供Help或User Guide功能。像在第7页提到的一样，高通建议在主菜单中提供Help这一项。然而，考虑到小程序的特点，还是多多提供上下操作的暗示比较好。另一选择是提供一个含帮助的网址让用户查看，这么做的优点在于help占的资源最少，但是，连接很费时。

关于

小程序中需要“关于”。通过这个，用户可以知道发行公司的名字和软件的版本信息。

版本号

TBT（True Brew Test）要求所有的BREW小程序都有自己的版本号并可以被用户查看。版本号在用户需要售后支持和升级软件的时候很重要。当然，把版本号作为功能项专门列出没有必要，一般放在欢迎界面或者About里。

page10

使用说明

如果小程序限制用户数量或者使用次数，应该显示剩余可用的用户个数或使用次数。用户会比较乐意在不退出的情况下，查看用户状态。

高通建议：用户第一次打开小程序时，在欢迎界面上显示剩余次数。如果欢迎界面已经满了，可以在主菜单出现之前闪现。在About里显示也行。在用户退出时闪现也可以，但好像用户退出时都不怎么看的。

使用次数由开发人员确定。高通强烈建议：要明确告知用户使用次数的减少的规则，尤其在减少的规则比较复杂的情况下。向用户解释减少规则时要细心考虑。解释放在Help或者User Guide里都不错。

另外，高通建议在将要到期时给用户提示。例如：当使用次数剩下1-2次时，小程序出现对话框询问用户是否购买更多的使用次数。最好在小程序开始时提示，因为很多人不会按照正常的步骤退出，而是简单地按下End键。

显示系统程序

理想说来，小程序的响应时间应该很快。然而，在很多情况下，小程序不能及时响应用户的操作。高通建议：当需要用户等待时，先给予画面响应。另外，要有明确的终止此进程的方法提示。用户能在不退出小程序的情况下结束进程最好。

以下是从Nielsen的书里摘录的。包含对Nielsen的程序的修改。虽然他的书是教网络和桌面小程序开发的，但对我们也有用。

page11

处理耗时的设计建议

以下是处理进程时延的建议：

少于0.1秒：若0.1秒内可以响应用户操作，是立即响应，不需要处理。
0.1到1秒：1秒的延迟，用户会察觉但不会介意。可以不处理。
大于1秒：1到2的话，显示一个沙漏。除了clear，其他键全部置为不可用，因为当程序没有立即响应时，用户很可能重复地按一个键。向用户提供些文字信息，告知他们需要一定时间的等待。
大于3秒的要提供进度条。尽量提供文字信息告知用户剩余的等待时间。用动画让用户知道系统没有死机。
10秒及其以上：10秒是保持用户注意力在小程序上的极限。如果更久，在等待的同时，用户会转向其他的任务。用声音或震动提示用户小程序可以使用了。

暂停和重新开始事件

BREW小程序在以下情况下可以暂停：
电量低警告；来电；收到非BREW的SMS短消息；键盘锁启动。

这些情况在手机上频频出现。

被暂停的小程序在打断它的进程结束后继续。考虑到小程序的可用性，高通强烈建议：暂停和返回一定要考虑并处理好（不容忽视）。

当小程序暂停时，不考虑用户干预，因为在暂停时，小程序需要保存数据，停止动画，或者冻结控制和暂停计时。总之，对暂停的处理要十分小心。当一个暂停的小程序又开始后，最好弹出一个对话框让用户选择：继续使用还是退出。与此同时，在小程序暂停又开始后，小程序能“记住”刚才的数据以方便用户，是最好的。

page12

对熟练用户的支持

小程序要设计得好用，这样用户即使是第一次，也可以没有任何问题地使用它。但是，对小程序十分熟悉的用户我们也要考虑。熟练用户更喜欢捷径或者个性化来加速响应。

为熟练用户简化界面的一种方法是利用数字为菜单选项定义快捷键，用户就不需要拉菜单来选择所需的项。利用快捷键，一个相对而言比较大的5层菜单，按5次键就可以选择完毕；如果没有快捷键，需要按很多次。

如果熟练用户被允许个性化用户界面或导航部分，他们也很高兴。小程序能否被个性化取决于它的特性，下面列举了一些个性化方式：
允许用户更改菜单项的排列顺序；
为主菜单的选项增加快捷键；
更改颜色主题。

使用BREW用户界面特征

菜单

在BREW小程序中，菜单是最普遍使用的用户界面元素。设计菜单时，要注意其层次的宽度和深度。宽度是指每一层中选项的个数，深度指层数。

一般说来，层数（2-3）的菜单，不多的选项（4-8）表现出色。如果菜单用来列出整齐的固有项。例如年月日，按字母排序的姓名列表，宽度就很大了。

操作列表

菜单列出用户可进行的操作。典型地做法是用不同图标区别不同操作。

page13

内容选择

菜单可以列出不同内容选项供用户选择。比如：在一个交通信息小程序中，菜单可以列出所有可知的高速路；一个铃声下载小程序中，菜单列出所有用户可选择的铃声列表。大体说来，图标在这类菜单中不是必须的。

小程序选项

菜单可以用来为用户提供使用小程序时的选择项。经常用到复选框和单选按钮。

同时使用双菜单

有需要时，水平和垂直菜单可以同时用。使用时，上下键控制垂直菜单，左右键控制水平菜单。这样，两个菜单相互独立，用户也乐于接受。

page14

如果需要来来回回切换菜单，用户会感到迷惑，这种做法不可取。最好是设计一对菜单，分别为垂直和水平，犹如一个二维矩阵。双菜单可以提供给用户同时选择的乐趣。

举个例子，一个铃声小程序可以使用户为不同组群设置专门的铃声。垂直菜单列出可用的铃声，水平菜单列出组群。用户选择一个铃声和一个组群，然后确定以激活设置。

双菜单的另一用途是简化复杂列表。如果菜单中有很多项，水平菜单可以将其分类，那么，在垂直菜单中只显示一部分项就可以了。例如：在一个地址薄的小程序中，垂直菜单可以显示姓名，水平菜单用于按字母对姓名分类。

注意：为了在小程序中有效地同时使用双菜单，BREW的目标机必须提供上、下、左、右键。

图标

为用户界面增加图标可以明确一些操作的意义，使小程序更易使用。下面介绍何时使用图标，怎样使用图标才可以增加小程序的可用性。

状态图标

如果一个菜单项包含多于一种状态时，最好利用图标来告知用户它的当前状态。例如，在一个铃声小程序中，列表中有的铃声已经被使用。利用图标来区别已有的和新的铃声很有用。再例如，一个股票信息小程序，列出股票价格时，用上下箭头表示价格的涨跌。

page15

图标栏

用于在不占用太多屏幕的情况下，显示一系列的操作。比如歌曲编辑小程序，一个图标栏可以使用户在编剧歌曲时保存、打开、更改目录。

它的一个缺点是，图标没有文字易懂。采用图标栏前，细心衡量图标是否能准确地代表意思。

图标的提示信息

和PC程序类似，可以用提示信息来明确图标的意思。一个图标被选中几秒后，提示信息就出现了。

图片大小

对一般的图标而言，建议图标的高度不能高于文字。一般图标略小于文字高度时看着比较舒服。

在同一菜单中，图片的宽应该是一样的。如果使用不同的宽度，由于图标不居左，将会降低文字标签的可读性。同时还要注意，如果使用过宽的图标，文字的空间就少了。虽然菜单会逐项滑动，但应该在屏幕内尽量配合文字标签，尤其是操作选项。

page 16

确定在一个菜单中使用的图标在设计时具有一致性，不要显得突兀。

注意：只在需要的时候用图标。图标使用得当，可以形象化菜单项。但是，图标需要占用较大的空间（7-10%），如果不能增加界面的可用性，小程序不要用图标。

动态菜单项及其图标

罗列操作、项目的菜单会根据用户的操作而动态地改变。动态菜单适合以下情况：
触发小程序功能的项；多状态的项。

触发功能

举例航班信息，最左边的菜单项是“显示细节”按钮。如果用户选择它，小程序显示细节航班信息，同时，菜单项被“显示概要”按钮取代。

音频小程序也是如此。播放功能和暂停相互取代，因为两者没有同时可用的必要。

状态改变

一个动态菜单项中的功能项可以有不同的状态。例如，一个小程序，允许卡车司机汇报运输状态给调度员。用动态菜单，司机可以告知调度员他到达的时间，开始装运或卸货的时间，离开的时间。这些菜单项被设计为只用一次。当一个菜单项被选中，图标变成省略号，表示信息正要被发送。一旦信息送出，图标变为确认符，此操作也被关闭。

另一种多状态的菜单项。仍然是运输和接收的小程序，显示所有司机的任务。任务动态地刷新，并作为菜单项列出。通过点击任务查看细节（例如运送和接货的地点、地图等）。每个任务有三个状态：新任务，正在执行，已完成。每一个状态由一个图标表示。

使用动态菜单项的要点

在使用时，图片和文字一起换，因为只改变一个的话会导致状态不明确。除非确实很有用，不要使用触发操作的菜单项。当菜单项自动改变时，用户容易迷惑。确定触发的操作对用户有用。

动态菜单操作复杂，这很容易让用户感到困扰。高通强烈建议：拥有动态菜单的小程序，要通过目标用户组测试。

page18

静态文字和滚动

IStatic提供了自动的水平滚动。然而，在大多数情况下，自动滚动没啥用。一般用户要求手动地滚动。本建议只适用于IStatic API对文本的应用。

文本列表

“菜单控制”API可以用于显示一系列没有相关操作的信息项。标准菜单可以被选择并执行操作，“菜单控制”不可以。换句话说，菜单控制只是用来显示内容列表的一个简单途径。例如，股票信息小程序可以用一个菜单列出股票的价格，选择操作在这种菜单中是被忽略的。

图标可用于为项目分类。例如，向上、向下的箭头图标代表股票价格的改变趋势。

用复杂的菜单项显示很多组信息是可行的。对于一个股票信息小程序来说，每一组包括股票价格，成交量，涨幅等。

page19

为了不让用户迷惑，最好不要在信息内容列表菜单中夹杂操作。改变菜单选项的高亮方式也很重要。不要使用和操作项一样的高亮方式。

导航和文本输入

本部分讲如何在小程序内实现导航和文本输入。

前进/后退功能

一般说来，在文本控制中，Clear键用来删除光标之前的那个字符。这就意味着，用户不可以用Clear键回到前一个界面。有两种方法可以使用户导航至前一界面。

推荐方法是用一个软键菜单。文本控制经常和软键菜单一起使用。所以，你可以在菜单项中增加“后退”或“删除”功能按钮。如果界面录入时出现错误，用户可以选择回到前一个界面。

第二种方法是：在文本控制中没有文字的时候，使Clear键有前进或后退的功能。这种方法的使用很受限，因为用户不大能理解。两种方法结合使用是值得考虑的。

输入方式

BREW小程序允许用户设置文本域的输入法，包括multitap，符号，数字和T9。手机的按键远少于计算机的键盘，使得用户难以输入混合了字母和数字的文本。这个问题至今无法解决，但你可以花些心思好好设计文本输入时的界面。

page20

如果程序要求用户输入字母、数字、符号的混合文本，请确保：在界面上，用户可以自由地切换输入法。如果程序只需要输入一种字符，不许用户切换输入法，以免他们输入非法字符。所以可否切换输入法，要随机应变。如果小程序要求用户输入一个电话号码，把文本控制设置为只接受数字。避免非法字符的输入比给用户错误提示要好。若输入字符的个数有上限，在到达上限时，禁止用户继续输入。

变换焦点

若对话框包含一个或多个文本框，或者软键，那么它还得提供给用户把焦点从一个文本框变换到另一个文本框或者软键的方法。有两种方法：用上/下键，用选择键。当用户输入完毕时，他们会很自然地按选择键，然而，选择键通常只用于焦点变换十分明显的时候。高通建议：在选择键用于变换焦点的同时，上/下键也可实现相同功能。

设计表单

表单通常是搜集用户信息的渠道。手持设备屏幕狭小的局限，导致在BREW小程序中设计好用的表单往往很困难。本部分就设计界面友好的表单给出一些建议。

桌面程序（如浏览器）中的表单在用户进行输入或选择之前，需要用鼠标/触摸屏来选择焦点，还支持用Tab键来转移焦点。在BREW小程序中，往往没有鼠标/触摸屏/Tab键。所以，你的设计要充分利用上/下/左/右、清除、选择键。

page21

高通建议：用上/下键控制输入焦点。要在视觉上提示用户输入焦点现在的位置。若文本框的内容是可以选择的，让用户使用左/右键浏览选项。这时注意：一定要是视觉上提示用户可以用左/右键，比如使用左右箭头图标。

page22

这个方式只用于在一行里面，只有一个文本框支持内容选择的情况，比如日期、时间。也就是说，一行里面，最好只有一个可选择的文本框，左/右键用于选择内容，上/下键用于转移焦点。

举个反例：有一行，是选择“持续时间”的，包括小时和分钟两项。先选小时，用上/下键；再用左/右键切换焦点至分钟，仍用上/下键选分钟。选择完毕，再用左/右键移动焦点至最右侧，用上下键进入别的行。这样虽然也可行，但上/下键，左/右键的功能不一致，这样很容易把用户搞迷糊。所以类似的设计不推荐。

page23

虽然选择框有多种设计方式，但它应该在一出现时就明显区别于直接输入的文本框，这样用户才知道该怎么操作。

page24

表单中的多行文本框

表单可能包含一个允许用户输入长文本的多行文本域。多行文本域难以和其他文本框一起使用，因为多行文本域需要同时使用上/下/左/右键。我们建议多行文本域单独放在一个界面中，而且有详细的操作指南。

软键菜单

表单往往在最下端有一个软键菜单。

如果表单不使用左/右键（即没有可选择的域），软键菜单可以一直处于可用状态。上/下键用于选择域，左/右键用于软键菜单。

如果表单四个键都要用（即至少有一个可选择的域），那么软键菜单只有在用户需要时可用。这可以借助选择键来完成，因为表单用不到选择键。还有，当用户在最后一个域继续按向下键的话，应该将焦点移至软键菜单。当焦点在软键菜单上时，用户可以按上键回到表单。

输入实数

如果需要用户输入实数，你的小程序必须提供输入小数点的方法。然而，当输入法切换为数字时，没有空闲的键可以用于输入小数点。以下有几种解决办法。

如果说小数点的位置是固定的（比如钱），建议小程序自动加上小数点。例如，在默认情况下，显示000.00，表示精确到小数点后两位。用户输入的数字串由右向左填充。

page25

第二种方法：当小数点的位置不固定时，让用户输入小数点。包含计算器和度量换算的小程序需要采取这个方法。你可以在软键菜单中包含小数点，也可以利用*键或者#键输入小数点。这样的设计用户不能一眼就看出来，所以要在屏幕上提示或者在小程序的user guide里说明。

可以输入数字的域也有多种表现方式。

page26

布局

域的布局和标题很大程度上影响了表单的可用性。

设计表单的要诀

数字右对齐；
如果是钱，钱币符号左对齐，钱数右对齐；
标题和输入域要明显地区别开；
对输入域进行合理地排序和分类，减去用户前进和后退的麻烦；
标题和输入域要联系在一起。

page27

缓存

BREW小程序不同于基于浏览器的程序，它可以利用手持设备的本地存储器来提升用户体验。

例如一个交通信息小程序中，用户的路线可以被保存下来，以后就不需要到菜单中查找街道的名称了。一个股票报价小程序中，用户可以保存自己关注的股票查询信息，下次使用时就不需要再输入了。有的小程序直接利用手持设备的存储器来暂存上一次的菜单选择。

使用本地存储或缓存的小程序必须能够清除不再使用的数据，而且尽量少占用存储空间。

视觉创意

排版

对于文本的模样考虑在BREW小程序设计中很重要。这一部分如何运用字体以及排版。

字体

在BREW设备上，字体的选择余地很小，只有：正常、加粗、加大三种。作为典型的用户界面元素，比如菜单和题头，加大字体是没法用的，这样一来，就剩两种。

菜单和静态文本，在用户正在查看时，往往加粗显示。在同一个菜单中，加粗字体也用于突出显示一个比较重要的项。

在一个运输监视小程序中，有个让司机选择任务，并查看运输细节的菜单。

page28

不推荐用7种以上的颜色来表示分类，因为很难找到7种明显相互区别的颜色。当多于三个分类时，不要只用颜色来区别分类，还可以加上图标。

颜色还可以用来代表数量。在温度的显示中，红色代表高温，蓝色代表寒冷。颜色只能表示一个大致的量，不确切。

page29

在显示地图时，颜色用于模拟现实：绿色表示公园，蓝色表示湖泊。

只要和别的颜色不冲突，还可以使用一些新颜色作为修饰。

设计要针对于不同色深的设备

若小程序有默认的颜色，比如菜单的背景色，那么在任何一台目标设备上运行时，都应该是这个颜色。

可以为每种色深各准备一个图片，也可以只用一个图片，让它自己适应色深的改变。在BREW小程序中，高色深的图片会被自动转化为低色深，但鉴于设备的不同，会有所差异。

服务色盲

大概8%的男人和0.5%的女人有不同程度的色盲。最好的解决——不要让任何界面完全依赖颜色来表现其内容。

屏幕设计

屏幕小，所以要好好设计。记住：组织信息有很多方式。如果可以和潜在用户沟通，问问他们信息组织是否合理。

显示给用户的信息，要么是动态生成的，要么是下载来的。如果你使用动态内容，要保证完整地显示（没有截断，没有遮挡）。

page30

注意用户群的阅读方式。不同地域有差异。西方人是从上到下，从左到右；但阿拉伯和西伯来人是从右往左读的。

高通强烈建议：BREW小程序要可以用在不同的屏幕上。分别在最大和最小的屏幕上测试小程序。如果你为了适应屏幕而修改了界面的布局，不要影响程序的可用性。

使用声音

声音提供了一个完全不同于屏幕的和用户交流的方式。

可用在程序中的声音：人声/讲话；音乐；提示音；模拟音。

声音的作用：吸引用户的注意；分类；表示进度；设置模式；创建品牌特征；代表数据。

用铃声或嘟声吸引用户注意。手机程序的用户往往不会一直盯着屏幕看，特别是处理的等待时间。10秒左右，用户的注意就会转移，所以在处理完成后，需要声音来通知他们。

page31

如果目标设备支持，震动可以代替声音。在社交场合，震动比声音好。其实，震动除了吸引用户注意力就没别的用了。

声音可以用来给信息分类。例如为用户组或者某一用户设置独特的铃声。不要用尖锐或嘈杂的声音代表分类，那样在吵闹的环境下不易辨别。一句话：独特的旋律或乐器演奏经常用来表示分类。

可以用水倒入杯子的声音表示小程序正在下载数据。用户可以通过高低音变化知道下载的进度。这种方式远没有图像来得精确，所以最好和图像结合使用。

部分企业或产品把“音乐标志”作为他们品牌特征的一部分。音乐标志是一段容易记住的优美旋律，使人们能联想到其代表品牌。如果你的程序和其他公司或产品有冲突，可以考虑设计一个音乐标志。

如果你们公司的产品很多，可以在各个程序的开始界面播放同一个音乐标志。

page32

声音很少用于表示数据。如果你在界面上显示数据，那么声音可以作为补充。比如显示道琼斯指数，可以用一段升调或降调的钢琴声来表示它增长或下跌。如果声音和画面结合地好，还可以为程序节省出更多的屏幕空间。

使用声音的其他考虑

如果你决定使用声音，保证在没有声音的时候，程序也可以使用。吵闹和安静的环境都要考虑。短消息成为很好的交流方式后，越来越多聋的或听力受损的人也在使用手机。

可达性

设计前，先调查用户群是否有残疾人。聋哑人可以使用大多数界面不依赖于声音的程序。视力受损的人可以使用包含声音提示的程序。

page33

国际化考虑

为了满足不同语种的用户需求，你需要国际化或本地化小程序。虽然棘手，但比起用户群的扩大还是值得的。

减少对用户习惯的猜测。所有人都从左向右输入字符？都用mm/dd/yy的格式纪录日期？汇率改了没？不一定的。

本地化是为某地区、用户群、文化创建一个新的版本。需要市场调查和用户测试。如果你的程序显示交通或股票信息，你需要与各地的数据提供商建立关系。

设计程序时注意：
要考虑不同地方用户的需求。免得本地化成为拦路虎。
把资源（文字，图标，声音）放在程序代码之外。这可以简化本地化工作。
为屏幕留些空余。翻译后的文字也许会占更多的地方。

page34

本地化后，在目标设备上测试。
用Unicode设计。因为BREW支持Unicode标准。
如果你提供用户多种语言选择，势必占用很多存储空间。
如果程序很大程度上依赖于文字输入（比如电话号码薄或短消息），亚洲化将会是个挑战。输入中文、日文、汉文时可能需要有第三方软件进行转化。
如果使用图片和声音，高通强烈建议让潜在目标用户过目，来确认他的理解和你想表达的意思有无偏差。当然也要检查措词有无失误。
注意各地区的输入方法差异。

page35

可用性检查

检查软件的可用性有多种方式，部分在人机交互领域也被推荐使用。高通建议：用户试用和启发式评价。

用户试用的缺点在于：必须在程序原形出来后才可以测试，修改成本高。用户投入增加，费时。高通建议组织小规模（4-8人）用户试用。一定要让真的潜在用户或者和潜在用户有很多共同点的人试用。设计原形和非正式试用也是必须的。

启发式评价可以在开发的任一阶段展开。要试用多个标准来评价。高通建议：让3-5各人来评价用户界面。以下是几个标准：

系统状态可见：无论何时，系统要通过合适的方式把自己的状态反馈给用户，告诉用户它在干什么。
考虑以下问题：
系统包括网络连接吗？如果有，系统有没有实时地显示上传/下载状态？否则，用户会误认为程序没有工作。
程序是不是有时候需要用户等待几秒？如果是，有没有画面提示？比如说计时器？
用户可以查看程序的使用说明、许可证吗？

和现实一致

应该使用用户熟悉的语言，不要用术语。要考虑到用户群的思维方式。

限制用户，也给他们自由

用户常常由于误操作而得到“紧急退出”的警告。最好能在合适的地方实现“退出”和“重试”功能。

要有手动的水平滚动功能；充分利用Clear键；在有输入框的页面中，要有明确的退出方法；允许终止进程。

一致性标准

不要用有歧义的词，让用户推敲它的意思。

图标风格一致；单色屏幕不要用3D图标；使用颜色时考虑色盲。 

最后感叹一下，外国人考虑得还是很细致的。但这些东西我们做不到，小公司么，老板觉得浪费人力物力浪费时间。不过对我们自己设计界面还是很有帮助的。

原著名为《BREW User Interface Guidelines.book》