活动：设计用户界面原型

设计用户界面原型
下面列出了设计用户界面原型的工作的不同方面：确定主窗口设计可视化主窗口设计主窗口操作设计特征窗口设计涉及多个对象的操作设计其他功能
这些方面将在下文中进行说明。然而，在项目中不必考虑原型设计中所有这些方面的问题。相反，通常可以把某些方面的问题留给实施员，而不用在原型设计中对它们进行处理。在这种情况下，我们建议您忽略清单中列出的次要方面问题，集中处理重要方面的问题。
设计原型时，您应当： 连续不断地实施您的设计（请参见下面的步骤实施用户界面原型）并把它展示给其他人（请参见下面的步骤获得有关用户界面原型的反馈）； 对项目专用的工件：用户界面指南加以考虑。
确定主窗口
每一个边界类聚合关系都可以产生备选的用户界面主窗口。然而，请回忆一下，构建对象模型的目标之一是确定层次尽可能少的聚合关系分层结构；其根本目的是最大限度减少主窗口的数目，因而也最大限度减少它们之间的导航路径。导航路径太长不仅增加不必要的交互开销，而且使得用户更容易在系统中“迷路”。理想状况是，所有窗口都应当从一个主要主窗口打开，这样窗口导航长度最大为 2。设法避免窗口导航长度大于 3。
主要主窗口应当是用户启动应用程序时打开的窗口。正常情况下，只要应用程序在运行时，它就始终处于打开状态，而且它还是让用户花费大量“使用时间”的地方。由于它始终处于打开状态，并且构成用户与系统的第一接触，因而它是加强用户系统思维模型的最重要载体。
最明显的备选主要主窗口是由聚合关系分层结构的顶层边界类所确定的，例如文档编辑器中的文档类。有关详细信息，请参考指南：边界类。如果有几个聚合关系分层结构，则选择对用户而言最重要的一个分层结构，即让用户花费大部分使用时间的结构。
主要主窗口确定之后，您应当考虑组成聚合关系分层结构的其他聚合关系类，并决定是否应将它们设计为主窗口。默认的推荐方案是它们应当设计成复合窗口而不是主窗口本身（如果可能的话）。同样，这也是为了最大限度减少主窗口的数目，从而最大限度减少它们之间所需的窗口导航路径。此外，复合窗口通常通过需要共同显示的组成成分、它们之间的空间关系以及其他复合窗口的组成成分来说明其合理性；注意，如果使用（主）窗口，则很难达到同样的目的。
示例：
文档编辑器中的段落聚合关系设计成复合窗口，而不是主窗口本身。这其中一部分是由需要一起显示的段落的组成成分即字符、组成成分的空间关系和其他段落的字符共同决定的。
作为一种备选的设计方案，想象一下此时文档编辑器的可用性：每次查看特定段落时，用户都不得不导航到一个独立的（主）窗口。
然而，由于屏幕显示的限制，所有的聚合关系通常不能将设计成复合窗口。如果没有足够的空间将所有的聚合关系设计成复合窗口，至少试试将下面的聚合关系设计成复合窗口： 作为用户的系统思维模型核心的聚合关系。 用户将花费大部分使用时间的聚合关系。 提供用例初始化的聚合关系。
注意，在本步骤中，对象的平均容量是一项重要的输入，因为它们规定可能需要同时显示多少个对象。对象太多味着它们不能设计成复合窗口；反之，它们在所属的主窗口中不仅可以有一个简洁表示，而且可以定义它们自己的主窗口。
设计可视化主窗口
主窗口可视化，尤其是主要主窗口的可视化，对系统的可用性有非常重要的影响。显示窗口的设计在一定程度上意味着您必须考虑所包含对象的哪些部分（属性）应当显示；使用事件流（示意板说明）无疑将有助于确定显示属性的优先顺序，尤其是在使用所需指导说明对其进行扩展时更有帮助。如果用户需要查看对象许多不同的属性，您可以实现在一个主窗口中包含几个视图，每一个视图显示一组不同的属性。设计此可视化窗口也意味着您必须考虑应当如何使用所有的可视化元素实现所包含对象的组成部分（属性）可视化。有关详细信息，请参考指南：用户界面（一般）中的“可视化维度”部分。
如果一个主窗口包含几个不同类的对象，则找到这些类的“公有基”很重要，比如在所有或大部分类中都包含的属性类型。通过某种维度显示公有基，这样用户就能把不同类的对象互相联系起来，并可以查看主窗口的样式。这大大地增加了用户界面的“带宽”。
示例：
假设您希望在一个客户服务系统中显示如下几个方面： 一定时间内客户的抱怨和问题。
客户一定时间内购买的产品。
一定时间内客户的发票累计金额。
这里公有基是“时间”。因此，在同一水平时间轴上将抱怨/问题、所购物品以及发票金额相继显示出来，这样用户就能看到显示它们之间的联系（如果有）模式。
设计主窗口操作
边界类的职责指定了它们对应的窗口所需的操作。主窗口和所包含对象的操作也常作为快捷菜单和工具栏中的替代选项和补充选项显示出来。如果某个主窗口包含几个类的对象，并且它们具有不同的操作，您可以给每一个类，或者给每一组紧凑的操作分配一个菜单。
示例：
例如，在文档编辑器中设有编辑菜单，将紧密相连的操作如剪切、复制等进行分组。
还要注意，某些操作可能需要与用户进行复杂的交互，因而使用它们自己的辅助窗口就顺理成章了。
示例：
在文档编辑器中，针对文档的打印操作需要进行复杂的交互，因此有必要使用一个单独的对话窗口。
设计特征窗口
需要为所有边界类的设计特征窗口，这样用户就可以得到这些类的所有属性。注意，某些对象在主窗口中可能只是部分显示出来（请参见上面的“设计可视化主窗口”一节）；另一方面，它们的特征窗口将显示它们所有的属性。注意，所有属性平均值都是此步骤的重要输入，因为它们可以帮助确定某个特定属性的最佳可视化方式。
边界类的某些简单职责，例如设置某个具体属性的值，通常作为某项操作在特征窗口显示出来。这样的操作或者在对象所在的主窗口中无法执行，或者是作为主窗口中的相似操作的备选项或者补充项。
另外，如果边界类是某个关联关系的一部分，则在特征窗口中通常显示该关联关系（包括被关联关系的对象）。
设计涉及多个对象的操作
如果某个边界类定义了许多将在用户界面中显示的对象，则设计包含这些对象的操作通常会比较棘手。以下是这类操作的不同变形： 提供在多个对象中进行搜索的机制的操作。请参考指南：用户界面（一般）中的“提高查找和选择性能”部分。 提供对多个对象进行排序的机制的操作。请参考指南：用户界面（一般）中的“排序”部分。 提供多个对象间用户控制继承的机制的操作。请参考指南：用户界面（一般）中的“用户控制继承”一节。 提供对浏览多个对象的分层结构进行管理的机制的操作。请参考指南：用户界面（一般）中的“浏览分层结构”部分。 提供选择多个对象的机制的操作。
设计其他功能
给用户界面添加需要的动态行为。大多数动态行为由目标平台产生，如选择操作范式、双击打开、右击鼠标弹出菜单等。这里您仍然需要作出一些决策，包括： 如何支持窗口管理。请参考指南：用户界面（一般）中的“窗口管理”部分。 在会话之间存储什么样的会话信息，如输入光标位置、滚动条位置、打开的窗口、窗口大小、窗口相对位置等等。请参考指南：用户界面（一般）中的“会话信息”部分。 主窗口是否支持单文档接口或者多文档接口（SDI 或 MDI）。
同时评估其他增强可用性的常见功能，包括： 是否应提供“联机帮助”，包括“向导”。请参考指南：用户界面（一般）中的“联机帮助”部分。 是否应当提供“撤消”操作，保证系统在探索使用阶段的安全。请参考指南：用户界面（一般）中的“撤消”部分。 是否应当提供“代理”，以监控用户事件并主动建议应执行的操作。请参考指南：用户界面（一般）中的“宏代理”部分。 是否应当提供“动态突出显示”，以显示关联关系。请参考指南：用户界面（一般）中的“动态突出显示”部分。 是否应当支持用户定义的“宏”。 是否应当有用户可配置的特定区域。
实施用户界面原型
实施用户界面原型有三种基本方法： 制图：使用铅笔和纸绘制。 位图：在位图编辑器中绘制。 可执行文件：可以“运行”并能和最终用户交互的模拟应用程序。
在大多数项目中，您应当按照上面列出的顺序采用所有这三种实施方法。由于三者的标准实现时间存在极大的差异（绘制和修改图纸的速度比创建和修改可执行文件的速度要快很多），所以采用这一顺序可以在初期直接纳入变更内容。然而，制图并没有正确地反映受限制的屏幕范围；在制图中很容易放置过多的组件而在屏幕中却容纳不下。
最终确定用户界面的最好方法是结合使用位图和可执行文件。一旦您需要将原型展示给除了用户界面设计员之外的其他人员，则应该采取种方法。位图可以指定主窗口的准确外观，而可执行文件可以近似地显示主窗口的外观，支持主窗口的操作以及辅助窗口的外观和行为。当然，如果您可以通过适当努力在可执行文件中表示主窗口的准确外观，这要胜过结合使用可执行文件和位图。如果没有足够的资源生成可执行文件，也可以使用位图作为原型的最终实施手段。在这种情况下，用说明它们动态行为的用例示意板对它们进行补充很有益处；否则，用户界面实施员造成动态行为错误的可能性很大。
注意，不应当把注意力集中在获得好的结构和模块化可执行原型的源代码上；而应当集中在创建丢弃式原型上，这种原型显示用户界面非常重要的方面，并提供某些重要的操作。此外，当完成原型设计并将它展示给其他人后，原型很可能会需要进行几次修改，这些修改通常通过低廉的修补程序完成。结果，原型源代码的价值通常有限，并且在实施实际的用户界面时不会“演进”。
通常情况下，实施可执行原型比实施实际用户界面耗费更低，这一点是很有价值的。下面列出了原型和用户界面实际实施之间的一些差别： 原型无需支持所有的用例和场景。相反，只有很小数目的用例和（或）场景可以确定优先顺序，原型只支持这些用例和场景。 实施主窗口通常是最复杂；如果您正在制作一个高级用户界面，它能够真正充分利用可视化的潜在价值，这时可能很难找到现成的构件。与实施新构件的做法相反，您通常可以使用原始构件（例如按钮开关、切换按纽或者选项按纽等）来近似说明用户界面将如何查找某一组数据。在可能情况下，请制作几个原型显示几组不同的数据，数据中包括平均值和平均对象容量。 模拟或者忽略在实施并不烦琐的窗口中的所有操作。 模拟或者忽略系统的内部操作，如业务逻辑、辅助存储器、多进程以及与其他系统的交互。
获得有关用户界面原型的反馈
将用户界面原型展示给其他人是极其重要。但是，为获得有价值的反馈，您不必非得进行完全的使用测试，即实际用户使用原型执行实际任务。在使用测试中发现的大多是一些“视而不见”的缺陷。这些缺陷是任何未参与用户界面设计的人本来可以提醒您注意的问题。
随着原型设计和实施的不断深入，需要将设计展示给越来越多的复审员，其中包括： 其他项目成员 外部可用性专家 用户
将设计展示给其他项目成员
这是一种被低估的展示设计的方法。这种做法需要的时间很短：项目成员比较熟悉应用程序，通常都会自愿参加这项演示活动。在活动过程中连续不断地使用该方法，以克服“视而不见”的问题。
将设计展示给外部可用性专家
一个好的可用性专家可以利用他的技能以及通过对用户界面不同角度的观察，指出原型中存在的明显的可用性缺陷，从而减少开发工作。因此，在设计原型活动进行到一半之前，让外部可用性专家加入是有意义的；这样，您可以有时间按照可用性专家的建议重新调整您的工作方向。
将设计展示给用户
给用户演示原型通常是您利用时间的好方法。尽可能地做到这一点（接近用户的机会通常有限），以纠正在需求分析时对用户需求的错误理解。但在得到至少还过得去的主要主窗口的位图原型之前，不要将原型展示给用户。也不要把原型不止一次展示给同一位用户；因为第二次展示时，用户就会受到您早先的设计思想的影响（和“视而不见”类似）。
同时，还要注意合理地设定期望。许多用户希望在系统建立后能对用户界面（即窗口）进行正确操作。
如何展示原型
展示原型的最佳途径通常是与您要向其展示原型的人员对象一起坐在屏幕前观察显示的原型。按用例示意板中的说明走查常见的场景，例如，具有标准取值的用例标准流。鼓励他提出问题和发表评论。把这些问题和评论记录下来。
另一种有些被高估的展示原型的方法是执行使用测试。在使用测试中，实际用户使用原型执行实际任务。该方法的问题在于如何得到可靠的结论： 您必须有一个非常“现成”的原型，它几乎具有和最终用户界面一样的功能。当您在开发进行很久后才得到这一原型，通常这时进行重大变更就有些得不偿失。 您需要为用户提供充分培训。大部分用户处于“一般水平”。如果要了解这些用户对原型的看法，就必须对他们进行培训。培训最多需要几周时间。
由于这些原因，并且如果创建用户界面没有非常充足的预算，应该至多在创建用户界面（的组成部分）的迭代结束时进行使用测试。