基于任务的UI(Task-Based UI)
基于任务的用户界面也被称为感应用户界面(响应式界面),做好基于任务的界面关键是要搞清楚用户想如何使用软件,并引导他们。当前,Web,移动,特别是苹果用户界面的设计趋势是基于任务驱动(Task-Based)。
基于任务的UI设计能够提供给你一个感知上下文的全新过程,可以始终保持你设计的正确方向,能够提供更好的用户体验,而用户的体验已经成为整个软件设计中一个不可或缺的组成部分。
当我们关注用户是如何使用该软件;,这实际上启动了我们对这个领域中动词的认识。
Task-Based UI主要介绍了一种基于任务的用户界面的概念,并比较它与传统CRUD风格的用户界面不同。 显示了在应用服务器后端切换到任务导向的风格时前端发生的变化。
传统“刻板架构”最大的问题之一是用户意图的丢失。 由于客户端与Application Server来回互动是以数据DTO为中心,在这个领域中没有任何动词。 领域实际变成了一个抽象数据模型。 在客户端,在纸上,或在该软件的用户脑子里都没有任何行为概念。
比如用户在屏幕xyz编辑foo为bar,然后再到其他屏幕编辑xyz到abc,我们的设计目标是:
在任何时候业务逻辑时只要改变工作流,而无需改变软件。
处理这个问题的方法之一是来自于DTO的向上/向下“定型架构”。
如下图,用户界面向服务器后端请求一个Customer的DTO对象,DTO返回到客户端时会在屏幕上显示。 用户以某种方式与DTO交互(例如DTO的一个视图模型)。 用户确认点击“保存”按钮,客户端将其确认的DTO发送到服务器后端。 后端服务器将这个DTO映射成领域模型,并保存更改,然后返回成功或失败。
在这里用户的意图被丢失了,因为客户端的“操作”完成后,发送的DTO只是代表对象的当前状态,而不是反映用户的那个“操作”意图行为本身,后端服务器应该接受用户提交的“操作”意图行为本身,而不是单纯执行这个意图(保存数据)。
banq补充:简单说,用户点按的按钮是“保存”, 服务器做的事情是"执行保存" ,两者不是一回事,"保存"是一个命令,而服务器做的事情是执行命令,而不是先接受这个命令,再执行这个命令。
打个比喻,司令部发出”攻占A山头“的命令,你的小组马上执行,跑到山头一看,没有敌人,你只能再打开命令文件查看,原来是A山头,你跑到了B山头;如果你当初刚接到命令时立即销毁了命令文件,你其实丢失了司令部的命令原始意图。
在DTO架构中,服务器端总是在实现执行,丢失"为什么要这么做"的信息,为什么要这么做?因为用户发出了”保存“指令,但是你在服务器端架构设计时,其实是丢失了这个"保存"指令,而是在执行保存指令,两者不是一回事。
[该贴被admin于2013-05-11 08:22修改过]