表现层——用户体验优先

用户体验优先

对于一个应用程序来说，最有趣的事通常发生在领域模型层里，这里也是你构建引擎并赋予整个系统生命与动力的地方。从领域模型层开始设计当然是可以接受的，也是常见的。但我们打算在这里推行另一个可以节省时间和精力的方案，尤其在你对领域比较不熟悉而且用例也与用户密切相关时。在过去的某些演讲里，Dino把这种方案称为“软件开发之哥白尼革命”。哥白尼并未看到过去没人看得到的东西。相反，他只是为一些东西提供了全新的视角，为每个人都经历过的白天和黑夜等东西提供了不同的解释。

同样地，我们并未声称有一种新的可以拯救世界的特效药。简单地说，我们想分享一种设计方案，把注意力集中在表现层，关注任务，以及让你在用户界面被用户验证、经过提炼和批准之后可以着手处理最有趣的东西。一切仍会改变，但大多数表现层的问题都会被解决。用户体验优先是用户体验优先的简写，顾名思义，这种软件设计方案的核心是表现层和用户系统交互。

为什么关注交互

写软件的目的是让客户以他们喜欢的最有效的方式开展他们自己的业务。任何软件都会产出结果，不管是通过屏幕、文件还是数据库更新。毫无疑问，越是了解预期结果，就越能有效地制定开发计划。
当预期结果涉及与之用户交互的某个图形界面时，先关注那些交互就是一个很自然的决定了。关注交互会引出基于任务的设计。

基于任务的设计

有时候你所面临的复杂性太大而无法一次处理。从模型开始处理又有点“杀鸡用牛刀”的感觉。较为轻量级的做法是关注要实现的任务、每个任务需要的输入以及每个任务产生的输出。
那么，不断地从列表领取任务，绘制用户界面的草图及其背后的工作流。这正是统一建模语言（UML）用例图的用途。
在UML里，用例图提供应用程序用例的图形表现。用例描述系统和其中一个参与者之间的交互。具体地，用例图展示了哪些参与者要做什么。参与者是与当前描述的系统进行交互的用户或者任何其他外部系统（如数据库）。系统不能控制参与者；参与者定义在系统本身之外。

这个用例标识了两个操作：获取订单和获取产品细节。这个场景可能需要一个屏幕提出请求以及另一个屏幕显示响应。用户不会直接操作获取订单或产品细节的系统组件。用户感兴趣的是他如何指定要获取的订单或产品。

下一步是绘制屏幕草图，记下请求应该如何指定以及响应应该如何展示。

重要：采用面向任务UI是行业的一个新兴趋势，与读写模型分离齐头并进。由于行业认为有需
要分离领域和数据，那么从以数据为中心的用户界面（Access风格，基于表格）转向面向任务界面
就是一个很自然的发展这种新的方案使需求更易转成规范，也能改善用户界面，使之变得更好。
最后，面向任务UI可以通过命令/查询责任分离（CQRS）等架构模式简化后端的结构，这个架构模
式会在第10章"CQRS导论”展开讨论。

目标是找到最佳的做事方式

几十年来，开发者没有太多关注他们的应用程序的用户界面。他们的注意力放在模型和数据库，而表现层背后的模型在很大程度上被忽略了，而且还被看作一件苦差事。似乎表现层和存储拥有不同的模型是一种不好的设计。

关注交互而不是数据，持续改善草图才是正路。本质上，我们认为这就是用户界面(UI)和用户体验(UX)之间的区别。

为每个界面创建一个视图模型类

就软件开发而言，屏幕经过定义并且通过批准是一件好事，也是构建系统余下部分的绝佳起始点。一个屏幕最终就是一组输入元素，可以轻易抽象成一个类。

这个类不需要有丰富的行为，一个简单的数据传输对象（DTO)就己经足够了。DTO是一个类，用来携带跨越系统的逻辑层和物理层的相关数据。有一个DTO表示来自屏幕并传给应用程序层执行命令的数据。另一个DTO表示通过服务器操作的响应传递回来填到表单上的数据。出去的DTO构成了输入模型（InputModel），而进来的DTO构成了视图模型(ViewModel)。

用户界面仅仅是是用户体验的一部分

随着智能手机和平板电脑出现之前，设计良好的可视化界面对于软件应用程序的用户来说己经算得上一个好的体验了。但往后的发展似乎表明一个好的用户界面对于交付设计良好的表现层己经不再足够。

为了保持前瞻性，我们不得不把UI替换成UX。

用户体验专家的职责

用户体验专家(用户体验架构师、用户体验设计师) 一一是一个同时需要分析能力和创造能力的职位。用户体验专家分析用户的行为，并为他们找出使用系统的最佳体验。用户体验的四大要点总结如下。

• 信息架构——了解信息的层次结构，然后确定通过应用程序显示它的理想方式。
• 交互设计——确定用户与这些信息交互的方式，以及为此而提供的图形工具。
• 可视化设计
• 可用性审查

可用性审查详情
用户体验专家可以与客户面谈很多次，实际上也应该这样做，但这只能理解客户的基本要求。这会产生一些可以讨论和调整的草图。仅当界面和交互构成流畅的运行机制，既没有可用性瓶颈，也没有带来流程障碍，才能得到非常令人满意的用户体验。
对于用户体验专家来说，与用户交谈是非常基本的，但实地验证用户界面、观察用户操作、聆听用户反馈以及在可能的时候录制他们的操作可能更加重要。
可用性审查是一个迭代流程，它产生的模型可以转成允许使用的技术所支持的用户界面形式。从编程的角度来说就是创建CSS、HTML或者XAML模板等东西。

用户体验开发的顺序，使用的工具

用户体验开发的阶段

• 草图(sketch)
• 线框(wireframe)
• 模型(mockup)
• 原型

前3个阶段需要专门的工具，第4个阶段只需一些常规的编码工具。

4个用户体验工具：Axure、Balsamiq、UXPin、Wirify；微软SketchFlow介于线框和原型之间，但只适用于XAML应用程序。

为什么你需要在交互上花时间

就用户体验而言，即使简单到只有两页的CRUDweb应用程序，也可能暗藏出人预料的陷阱。只有通过观察用户使用这个应用程序，你才可以肯定地判断你提供的用户体验是好还是坏。

如何实现杀手级用户体验

• 第一，你以迭代的方式描述你的想法，从草图到线框最后到完备的模型。
• 第二，你使用预存数据、不用后端或者使用伪造的仅用于测试的后端把视图转成可工作的原型。
• 第三，完成这个原型之后，就要应对最棘手的部分了：告诉客户他刚批准的只是一个原型而不是最终应用！

注意：需要澄清一下草图、线框和模型等常见用户体验行话的确切含义。草图是徒手绘图，主要用来记录想法。线框是更高级的草图，它关注功能、布鬲、导航和信息。线框并不关注用户界面细节。最后，模型关注实际的外观和感受，可以看作加上样板用户界面的线框。

把交互变成视图

毫无疑问，HTML和CSS，甚至XAML，可以让你在几分钟内创建一个可工作的原型视图。但是，这里的重点是为客户描述交互模型。如果首先你展示草图而不是彩色截屏，客户可能会感到更加放松，思想也会更加开放。不要太早牵涉太多无关重要的细节。

所以你最好使用低保真草图，不要牵涉到技术。当草图足够清楚，你就可以创建线框，添加更多关于功能、布局和导航的细节。Balsamiq等工具在快速创建线框方面提供很大帮助。线框设定屏幕的结构；模型只是在线框之上开发的一些图形想法。

但是，到目前为止你所得到的都是纯静态内容，不会动，也不能操作。根据你为创建线框选择的工具，你可能想创建真实的故事板演示UI屏幕的流动。

把视图变成原型

即使是最好和最广为接受的用户界面也可能在大量使用之后暴露问题。步骤：

• 自我确信——不要在得到首次批准就停下脚步；尝试使自己确信你所创建的交互设计的质量。
• 创建原型（可选）——如果仍然心存疑虑，可以创建一个原型，甚至录制用户使用这个原型的情景，以便获得他们感觉的真实反馈。

原型只包含表现层，仅仅使用预存数据或者一个伪造的后端来模拟一些行为，可以是HTML页面或者XAML程序。
根据你想提供的保真度，为一组认可的草图创建线框和原型只是短短几天的事情。

现在告诉客户它只是一个原型

客户喜欢这个原型，让你继续构建这个应用程序。理想状态下，每个界面应该绑到一个视图模型类（ViewModel），它描述了用来填充视图的数据。此外，每个界面应该绑到一个输入模型类（InputModel），它描述了触发操作时将会离开界面的数据。

重要，在第5章“发现领域架构”里，我们强调了标识松散耦合的业务上下文的重要性。大多数情况下，这会产生一张由一些块和少数关系构成的图表。每个块都可能使用最合适的架构、设计和技术单独实现。

MVC、MVP、MVVM以及其他模式

MVC
MVC是Model-View-Controller的简称，MVC的主要目标是把应用程序分成不同的部分——模型、视图和控制器。模型表示应用程序的状态。它包含了应用程序的功能，在状态改变是发出通知。视图表示显示给用户的任何图形元素。它获取并处理任何用户操作。控制器把用户操作转换成模型上的操作，然后切换到下一个视图。
MVP
MVC模式演化成Model-View-Presenter（MVP），其中，表示器元素取代了控制器，也承担了更多的责任。这包括从编排任务到渲染视图的一切东西。在MVP里，视图和模型是严格分离的，表示器则在它们之间进行协调。
MVVM
Model-View-VlewModeI（MVVM）是原来的Presentation Model模式的更受欢迎的名字。在MVVM里，你有一个类整合了用户界面的命令和视图模型。一个单独的类一一一视图模型对象一一暴露了绑到用户界面可视化组件的属性以及绑到用户界面事件的方法。MVVM尤其适合具有强大双向数据绑定机制的应用程序场景。这对于基于XAML的应用程序以及Universal Windows应用程序来说尤其适合。
不要混淆：就分层应用程序而言，MVC、MVP和MVVM都是表现层的模式。