
GUI规范似乎是行业必须遵循的规则了,多数的从业人员也了解在BS、CS界面设计中的必要性,但要很好的实施确存在系列的问题:设计师是否具备这方面的意识;在具体开发过程中的跟进力度;开发人员的配合问题;规范制作开始的阶段问题等等。在团队的交互和视觉的设计处于磨合阶段时,这个问题尤为难以处理,总是有顾此失彼的感觉。计划性不够或团队的组合基础不够,往往会因为观念和态度问题造成规范流于形式。
到底在开发中需要多少文档才够呢?
实际的开发过程,文档的编写是必要的过程,但也是很难以做到位的阶段,从最近的项目中看出文档的编写有三层概念,一是作为设计阶段的结果沉淀;二是作为与其他部门的沟通工具;三是文档描述中发现设计过程未尽事宜或逻辑缺漏(此问题我认为是设计过程的不合理造成)。
柚意上笔者从自身的经验中总结了开发新产品所需要的十类文档,较为全面,——即“1、产品概念文档(项目策划书)、2、用户调研报告、3、产品需求列表、4、产品说明书、5、交互设计说明书、6、交互设计规范、7、视觉设计规范、8、开发文档、9、测试用例、10、产品评估报告”。但要真正做到似乎还是存在困难,文档作为每个阶段输出结果,要像完成十类文档势必需要公司具有配套的流程,并前后的流程点要有质量控制。同时设计过程是以文档为交流主线,还是在设计过程中的个职位配合参与为主线呢?需要更深入的实践来证明。从个人的观点来看,本公司存在的后期文档阶段再发现设计问题,确实设计过程的不严密所造成,需求、分析、设计、测试的大过程深入到项目的设计细节,需要承担任务的设计师能有较强的责任心和发现问题、逻辑分析思维能力,当然也需要管理者的合理组织和知道。线性的分析(需求分析过程)、网状的逻辑分析(焦点小组、任务分析、专家评估等)需要反复的进行。
什么时候开始GUI规范的编写
这点郭大侠已经有比较深入的介绍了,可以参见什么时候开始整理界面规范。大概是先做好再规范不行,先规范在来做也不行,那就边做边规范叫为合理。不管怎么规范目的都是为了界面的统一性,一致性。从细节建构软件产品的品质感觉,当前视觉的刺激信息占的比例越来越大,往往是细节的关系决定产品的成败。如前新浪总裁王志东表明当前抢占桌面时代的到来,尤为注重感官的吸引,比较大部分的情况人是以直觉来判断事物。我们需要满足越来越挑剔的用户眼光。我们要达到MS和Apple的视觉规范水准,需要继续努力。
这里引注“出色图形用户界面(GUI)设计规范” 翻译:spark.bbs@bbs.nankai.edu.cn
形用户界面(GUI)已经成为用户界面的首选,但不论GUI如何流行,令人诧异的是没几个程序有好的界面设计。另外,想找一些介绍如何编制出色用户界面的材料也相当困难。本文给出了出色界面应该如何和不该如何的一些最重要的基本规则。
忽略了用户
开发者常常只设计他们自己知道的,而非用户知道的东西。这个古老的问题在软件开发的多个领域发生,例如测试、文档编写等等。设计界面时这样会更有害,因为用户在使用产品的时候会立刻感到一点不熟、无所适从。这个错误是最应努力避免的。
由用户控制
GUI设计者倾向于控制程序是显而易见的,在程序中通过使菜单项和控件变灰或变黑,不断的试图控制用户的走向。控制用户同事件驱动的程序设计风格是极端矛盾的,事件驱动要求是用户而非软件来决定什么事件应该发生。作为开发者,如果你花费了大量的时间在动态的控制控件的变灰和变黑中,就需要反省一下自己的设计方法和实现。可能你正在试图控制用户,而他不希望被控制。在业务变化越来越快的今天,用户界面的弹性将成为适应改变的关键方法。允许用户用各种方式甚至是你自己都想不到的方式使用程序,有点令人心里不安,但这会让你作为开发者很有成就感,同时赋予用户更大的权利。
顶层有太多的功能特性
看一下1985年产的录像机,然后再看一下1995年产的。你一定会为这两款录像机界面上的差异感到震惊。1985年的那款在前面板上会有各种各样易用的按钮,很多按钮会因为你几年前丢了说明书而永远不知道它们是干什么用的。1995年的那款可能只有大家常用的几个按钮:播放、快进、倒带、停止和弹出。这款可能比十年前那款有更多的功能,但这些功能将被隐藏在弹出式面板或滑门之后,你需要的时候才去用它们,而不是放在表面上。
同样,你应该只选择常用和易用的功能,避免把所有的东西都放到第一屏或者在工具条上放不常用的按钮。多做一点分析,看看那些功能可以放到隐藏的面板而非前面板。
成功的用户界面(GUI)
现在,让我们谈谈一些成功的GUI设计。成功的GUI设计具有很多共同的特征。最重要的,出色的图形用户界面(GUI)应该是非常带有直觉特征的。实现这些的一个方式是尽可能的采用现实世界中的抽象(暗示、隐喻)。例如,我最近看到一个用Visa卡和Master(万事达)卡图标做为按钮图标的程序,这个按钮用来指示用户如何付款,这个图形立刻使用户产生一种直觉并帮助他们更快的学会使用程序。
出色的用户图形界面的另一个重要特征是速度,更专业一点说,是响应速度。很多速度问题的处理是通过GUI而非硬件。根据应用程序的类型,速度可能是决定程序是否被用户群接受的成败关键。例如,如果你的程序是面向在线事务处理(OLTP)的,操作太慢很快就会导致用户产生放弃系统的念头。
你可以用几种方法使用户界面上显得很快的样子。除非绝对必要,不要重绘屏幕。另一个方法是使这个屏幕的所有区域同时可用,而非一个区域一个区域的来。另外,根据用户的熟练程度,应该在用户界面中加入一些功能,这些功能可以让熟练用户在不同的区域快速的输入数据。这些功能包括重复功能、快捷键、带有有意义的图标的按钮等等,所有这些可以使速度快的用户可以控制界面并加快数据的输入。
应该怎样和不该怎样
每个好的开发者都应该把目标定在尽可能的设计最好的图形用户界面。 但如何把这个目标变成现实呢?下文中,在各个章节给出了图形用户界面设计的规范(标准)。
同任何出色的专业人士一样,你需要一些可重复的成功设计法则。我们就是用这里提供的法则为我们的客户服务并教授了超过20000名的国内国际GUI设计专业的学生。这些规范也会对你有帮助的。
程序必须反映用户的视角和行为。要充分理解用户开发者首先要理解人,因为我们都具有共同的特征。人类通过辨别比通过记忆学习起来更容易。要经常试着提供一个数据列表给用户,而非让用户凭记忆自己输入数据。普通人能记住2000到3000单词,但却可以认出50000单词。
留意不同的视角
很多设计者在设计图标或程序整个行为的时候会不自觉的陷入视角陷阱。最近我看到一个图标,它用于在一个会计系统中指明汇总。为了标示这个功能,设计者花了很多心思在画一个把桂圆组合到一起的图标。不幸的是,这个系统的用户对这个图标的喻意更本就没有一点概念,虽然它从设计者的视角来看是非常直观的。保留图标列表中给出了标准图标,如图一所示,可以帮助你消除这些问题。(原Html文件中就没图,估计老外也时兴转载)
|
Reserved Icons |
||||
|
Picture |
Meaning and Behaviour |
Use to Identify an Application |
Used to Identify a Function |
Reserved Word Text Label |
|
Information Message |
No |
Yes |
None |
|
|
Warning Message |
No |
Yes |
None |
|
|
Question Message |
No |
Yes |
None |
|
|
Error Message |
No |
Yes |
None |
|
清楚一致的设计
很多GUI程序对最终用户常常不够清楚。一个增强程序清楚表述能力的有效方法是使用列表中的保留字进行开发。用户中最常见的抱怨是某个术语表述的不清楚或不一致。我常常看见开发者们激烈的争论按钮或菜单项上用那个术语更合适,而同时就在一墙之隔的另一群开发者也在争论同样的问题,在程序发布之后,一个屏幕上可能写着 “项目”,而下一屏却写着“产品”,而第三屏又变成了“货物”,可是其实这三个术语是指的同一个东西。这种一致性的缺乏导致用户非常迷惑并产生操作失误。
图二给出了保留字列表的一个例子。一个开发小组应该用更多的保留字来完善和扩充这个表。
|
保留字列表 |
|||||
|
文本 |
含义和行为 |
是否出现在按钮上 |
是否出现在菜单上 | Mnemonic Keystrokes 热键? |
Shortcut |
|
OK |
接受输入的数据或显示的响应信息,关掉窗口 |
Yes |
No |
None |
<Return> or <Enter> |
|
Cancel |
不接受输入的信息,关掉窗口 |
Yes |
No |
None |
Esc
|
|
Close
|
结束当前的任务,让程序继续进行;关掉数据窗口 |
Yes
|
Yes
|
Alt+C
|
None
|
|
Exit
|
推出程序 |
No
|
Yes
|
Alt+X
|
Alt+F4
|
|
Help
|
调出程序的帮助信息 |
Yes
|
Yes
|
Alt+H
|
Fl
|
|
Save
|
保存数据,停留在当前窗口 |
Yes
|
Yes
|
Alt+S
|
Shift+Fl2
|
|
Save As
|
用新名字保存数据 |
No
|
Yes
|
Alt+A
|
F12
|
|
Undo
|
撤销前一个动作 |
No
|
Yes
|
Alt+U
|
Ctrl+Z
|
|
Cut
|
剪切高亮字符 |
No
|
Yes
|
Alt+T
|
Ctrl+X
|
|
Copy
|
拷贝高亮的文本 |
No
|
Yes
|
Alt+C
|
Ctrl+C
|
|
Paste
|
在插入点粘贴被拷贝或剪切的文本 |
No
|
Yes
|
Alt+P
|
Ctrl+V
|
|
何时使用对话框、窗口
图三 |
|||
|
类型
|
描述
|
使用
|
例子
|
|
有模式
|
对话框
|
给出一个确定的任务 | 打开文件对话框 另存为对话框 |
|
无模式
|
对话框 |
给出一个持久的任务
|
查找框 历史记录框 任务列表框 |
| 应用程序窗口 |
含有子文档窗口的窗口框架
|
给出一个对象的多个实例 比较两个或多个窗口中的数据 |
文字处理 电子表格 |
| 文档窗口 |
无模式对话框或者被应用程序窗口管理和包含的文档窗口
|
给出一个程序的多个部分 |
数据的多个视图 (表单)
|
| 从属窗口 | 附属应用程序的主窗口 | 给出被父程序调用的另一个程序 | 调出一个程序的帮助 |
|
控件使用说明
图四 |
||
|
控件
|
范围内应用的数量
|
控件类型
|
|
Menu Bar
|
最多十个子项
|
Static action
|
|
Pull-Down Menu
|
最多十二个子项 |
Static action
|
|
Cascading Menu
|
最多五个子项, 一层级联 |
Static action
|
|
Pop-up Menu
|
最多十个子项 |
Static action
|
|
Push-button
|
每个对话框中最多六个
|
Static action
|
|
Check Box
|
每组最多10~12个 |
Static set/select value
|
|
Radio Button
|
每组最多六个
|
Static set/select value
|
|
List Box
|
表中最多50行, 显示8~10行 |
Dynamic set/select value
|
|
Drop-down List Box
|
控件中一次显示一个选项,下拉框中不超过20项 |
Dynamic set/select single value
|
|
Combination List Box
|
控件中按标准格式一次显示一个选项,下拉框中不超过20项
|
Dynamic set/select single value; add value to list
|
|
Spin Button
|
最多十个子项 |
Static set/select value
|
|
Slider
|
依赖于显示的数据
|
Static set/select value in range
|


