首先考虑功能,然后才是表示
一、
很多GUI开发人员,甚至是许多用户界面设计人员,都急于首先确定应用程序的用户界面看上去会怎样。有些人用纸和笔或计算机绘图工具勾画设计草图;有些用交互式开发工具来开发外观和控件的布局;有些编写实际的实现代码。
要坚决杜绝这种做法!一开始就担心外观是本末倒置。虽然这很诱人,但几乎总是会产生错误。它会导致产品缺乏重要的功能而包含了不必要的功能。并且难于学习和使用。
二、
软件应用程序的用户界面不仅仅是软件的外观。它还体现了一些深入到架构中的设计决策,例如要向用户揭示什么概念、信息是什么结构、后端功能以及可定制能力。因此,不能单纯在实现端断言用户界面成功与否。
更具体地讲:不要一开始就跳转到GUI不居中。开发人员在绘制屏幕草图、选择和布局空间、裁剪泡沫原形或编写代码之前,应首先下功夫回答原则1给出的那些与任务有关的问题。然后还要回答以下问题:
1、这个软件将向用户展示什么概念?他们是用户要从任务领域认识到的概念吗?或者是新概念?如果是新概念,它们表示成常见概念的扩充吗》或者它们是从计算机科学引入的外来概念吗?
2、用户会用这个软件创建、查看或操作什么数据?用户从数据中提炼出什么信息?如何提炼?它们会用哪些步骤?用户输入到软件中的数据来自哪里,从软件生成的数据又在哪里使用?
3、这个应用程序会提供什么选项、选择、设置和控件?它不是一个关于如何表示控件(例如单选按钮、菜单、滚动条)的问题。而是关于它们在软件中的工嗯呢该、目标和角色(例如、周工作日,美元数量、电子邮件地址、音量)。这是关于这个软件提供什么选项的问题。
三、开发概念模型
在设计用户界面之前开发一个概念模型通常都很难,直接讨论注入控制面板,菜单和数据显示这样的用户界面概念会更吸引人。这种诱惑又因为销售和营销人员要根据窗口布局和鼠标点击来陈述功能需求的趋势而加剧。当营销需求是使用用户界面术语来表述的时候,我们应有礼貌但坚决地拒绝这样的需求,并要求根据任务领域,即用户面临的问题以及他们希望达到的目标来表述需求。(尽可能地让它保持简单,但是不要过于简单)
为计划的软件应用程序开发一个概念模型时,一个目标就是要尽可能地让模型简单。即,使用最少的概念来提供所需的功能。设计计算机软件与其他许多工作一样,要记住这一点:更少就是更多。
基于计算机的系统通常提供新的功能。对于那些以前未计算机化的任务来说通常是这样,但对于已计算机化的任务来说也可能如此。作为结果,外来概念通常渗透到概念模型中。例如纸质的“约会本”不会主动提醒用户“事件”,但基于计算机“约会本”就会提醒用户。
然而,每个新概念的出现都要付出高昂的代价,原因有两点:
a.他增加了一个任务专家将不会认可并因此必须学习的概念。
b.它潜在地与软件中的每个其他概念发生交互。随着概念的添加,系统的复杂性不是线性上升,而是以指数级上升!
四、执行对象、操作分析
在任务领域中的概念可能具有不同的重要性:一些概念比其他概念更常用。根据类型,部门、全部层次结构、包含层次结构以及他们的相对重要性来列出概念模型的对象和操作。对于设计和开发一致、清晰、易于学习的用户界面将产生极大的促进作用。
在对象、操作分析之后,概念模型的第二个最重要的组成部分是词典,它规定了要在整个软件以及其文档中使用的术语。
五、编写任务场景
一旦完成一个概念模型,开发人员就可以仅用来自概念模型的术语编写应用或场景,它们用来描述使用这个应用程序的人们。这些场景可以在产品文档、产品功能评审和易用性测试脚本中使用。
六、从设计概念模型开始进行设计具有几个好处:
1、以任务为中心:设计概念模型迫使设计人员考虑每个用户可见的概念与任务的相关性,以及对象之间的关系。在设计用户界面之前彻底考虑这些问题,可以将用户界面更自然地映射到用户任务上。
2、一致性:通过列举应用程序所支持任务的对象和操作。设计人员可以注意到许多对象共享的操作。然后可以为各种对象之间的操作使用相同的用户界面。这使得用户界面更简单一致,因此也更易于学习。
3、重要性:列出所有用户可见的概念使设计人员能够排列它们的相对重要性。这对用户界面设计和开发优先级都会产生影响。
4、词典:概念模型提供了一个产品词典,它是软件中包含的每个对象和操作的术语词典。这促进了术语的一致性,不仅是软件中的术语,也包括产品文档中的术语。
5、场景:概念模型允许开发团队编写产品的任务领域级的场景。这些场景在检查设计合理性的时候很有用,它们也可以在产品文档、功能评审和易用性测试脚本中使用。
6、开发起点:对象/操作分析提供了初始的对象模型------至少是那些用户遇到的对像。开发人员甚至可以在设计用户界面之前开始对其进行编码。
7、关注团队和过程:概念模型可以作为所有开发团队成员以及其他涉众的焦点,用以讨论和不断地评估设计。