人机交互与界面设计材料.doc

人机交互与界面设计材料.doc

《人机交互与界面设计材料.doc》由会员分享，可在线阅读，更多相关《人机交互与界面设计材料.doc（84页珍藏版）》请在冰豆网上搜索。

第6章人机交互界面表示模型

图6-1中国象棋分解图

[]

[]

[]

>>

>>

|||

[>

运行

中国象棋

退出

走棋

*打谱

当前方走

对弈方走

拾取棋子

放置棋子

加

速

减

速

暂停

恢复

Task中国象棋对弈

GOAL:

中国象棋

[>:

GOAL:

运行

|||:

*GOAL:

走棋

ACTION:

自动记录棋谱

>>:

GOAL:

当前方走

>>:

OPRATOR:

拾取棋子

OPRATOR:

放置棋子

GOAL:

对弈方走

>>

OPRATOR:

拾取棋子

OPRATOR:

放置棋子

*GOAL:

打谱

[]:

OPRATOR:

加速

OPRATOR:

减速

OPRATOR:

暂停

OPRATOR:

恢复

GOAL:

退出

表6-5UAN描述的任务“文件拖入垃圾箱”的多通道实例

任务：

draganddropafileintherecyclebin

用户行为

界面反馈

界面状态

2D鼠标

语音

thenhighlight（icon）

show_outline（icon）

thenhighlight（bin）

thenhide（icon）

show_bin_full（）

ifintersect（icon,x,y）

icon=selcted

ifintersect（bin,x,y）

ifintersect（bin,x2,y2）

Mouse_down（x,y）

drag_icon（x,y）

mouse_up（x,y）

Pronouce

Move_to_recycle_bin

6.1.4任务模型

ConcurTaskTrees任务模型表示法（ConcurrentTaskTreeNotation）[12,13]，它是一种基于图形符号的，采用层次的树状结构来组织并表示任务模型的方法。

下面首先介绍ConcurTaskTrees中任务种类和暂态关系的含义及其图形符号。

1.任务分析

任务分析是一个以人们的行为为出发点的分析过程，它分析人们完成任务的方法：

他们要做的事、要起作用的事和想要知道的事[1]。

任务分析的一个重要方法是任务分解，即需要考察将一项任务分成为若干子任务的途径以及这些子任务执行次序的方法。

任务分解使得任务的执行过程层次化，即一个任务的执行被委托给它下一层的子任务来完成，这些子任务之间的关系及其执行的顺序成为了解一个任务执行过程的重点。

考虑一个用户交互过程，对其进行任务分析的目的和重点在于得到交互任务及其子任务的一个层次体系，以及一些描述子任务执行的顺序和条件的解决方案[1]。

这个方案必须能够恰当地捕获用户的交互意图，能够如实地反映交互过程，并把它准确地表达出来，同时它不能曲解交互过程下蕴涵的业务要求。

这样一个层次体系以及方案就是一个任务模型。

表达越准确，则由任务模型生成的用户界面越能够越贴近实际的交互需求，符合一般的交互习惯，同时不会改变业务规则。

2.任务的种类

在ConcurTaskTrees任务表示法中，依据任务的抽象层次和任务执行过程中参与角色的不同，对任务的类型进行了归类，总共提供了5种记号,分别代表不同种类的任务：

（1）抽象任务（AbstractTask），代表一个复杂抽象的任务，通常用来表示由其它种类的任务任意组合而成的任务。

（2）用户任务（UserTask），代表一个只能有用户参与的任务，通常用来表示和用户感知或者认知行为相关的任务。

例如，用户阅读系统的反馈的信息提示，然后决定下一步的操作。

（3）交互任务（InteractionTask），代表执行过程中需要用户与系统进行交互的任务。

例如用户在线注册填写面板。

（4）系统任务（ApplicationTask），代表由系统来执行而不需要用户参与交互的任务。

例如，系统处理用户提交的注册信息，然后将处理结果显示给用户。

3.暂态关系符号

ConcurTaskTrees任务模型表示法定义了丰富的暂态关系用以表示任务之间在执行过程的相互联系和制约作用。

这些关系都有相应的图形符号：

（1）Choice：

t1[]t2[]…[]tn

从任务t1，t2，…，tn之中选择一个且只能选择一个执行，且在一次执行过程中，一旦选定了一个任务则其它任务将不能被执行。

（2）Concurrent（IndependentConcurrency）：

t1|||t2|||…|||tn

任务t1，t2，…，tn可以并发的执行，任务之间的执行开始和结束没有任何的限制。

（3）带信息交换的Concurrent：

t1|[]|t2|[]|…|[]|tn

任务t1，t2，…，tn可以并发的执行，而且允许任务之间进行信息交换。

（4）Disabling：

t1[>t2

一旦任务t2开始执行，则中断并终止任务t1的执行。

（5）Enabling：

t1>>t2>>…>>tn

任务t1，t2，…，tn必须按顺序执行，且任务ti+1不能开始执行直到ti已经执行完成，对于∀i∈{1，2，…,n-1}。

（6）带信息交换的Enabling：

t1[]>>t2[]>>…[]>>tn

任务t1，t2，…，tn必须像Enabling关系那样按顺序执行，而且允许任务之间进行信息交换

（7）Independence：

t1|=|t2

任务t1和t2可以按任意的顺序执行，但当一个开始执行后，另一个任务则不能开始执行，除非已经开始的任务执行完成。

4单用户任务模型

单用户任务模型在ConcurTaskTrees中表示为一棵树。

如图1.1所示的任务模型，表示了用户使用自动取款机（ATM）的过程。

该模型出自CTTE的一个示例。

在模型中，树中的每个节点代表一个任务，任务可以被分解为更为具体的子任务，并用该节点的子节点来表示。

根节点代表的任务抽象层次最高，叶子节点代表的任务最为具体。

拥有相同父节点的兄弟节点之间的关系由暂态关系符号来表示。

暂态关系符号决定了兄弟任务在某个时刻的相互之间的制约关系，并且决定了这组任务所能有的执行顺序，如前面所述。

任务还具有不同的种类，以示区别不同任务执行过程中参与的角色的不同，以及对交互要求的高低，如前面所述。

例如，在该模型中，抽象任务EnableAccess被分解为三个具体的子任务{InsertCard，RequirePassword，InsertPassword}，这三个任务在Enabling关系的限定下必须顺序执行。

交互任务InsertCard和InsertPassword需要用户和系统进行交互，而系统任务RequirePassword则不需要用户的参与。

基于任务表示目前已有相应的基于模型驱动的用户界面生成工具用于自动界面的生成，如：

CTTE/TERESA和Dygimes。

他们采用任务模型作为输入，支持由任务模型生成用户界面。

1）CTTE/TERESA环境

CTTE（ConcurTaskTreesEnvironment）[10,14,25]是一个集成了设计、编辑、测试、分析和调试ConcurTaskTrees任务模型等功能于一体的环境，如图1.2所示。

它由CNUCE的HCI小组开发实现，最初被用于测试ConcurTaskTrees任务模型表示法，后来被广泛用于ConcurTaskTrees的设计和分析中。

TERESA（TransformationEnvironmentforinteractiveSystemsrepresentAtions）[20,26]是一个由CTTE衍生出的工具。

它支持基于ConcurTaskTrees任务模型生成适应跨平台要求的用户界面。

利用TERESA由任务模型生成用户界面，需要经历以下几个步骤：

首先利用CTTE设计构建ConcurTaskTrees任务模型。

然后基于此模型生成针对特定平台的系统任务模型（SystemTaskModel），以适应特定平台的要求。

然后基于系统任务模型生成活动任务集（EnabledTaskSets，ETS），再由ETS得到表现任务集（PresentationTaskSets，PTS），这是可以同时映射到用户界面上的一组任务。

然后再由表现任务集生成抽象用户界面（AbstractUserInterface，AUI）和具体用户界面（ConcreteUserInterface，CUI）。

2）Dygimes原型系统

Dygimes系统（DynamicallyGeneratingInterfacesforMobileandEmbeddedSystems）[21,27]，如图1.3所示，是另一个基于模型驱动的用户界面生成系统，主要面向于嵌入式系统和移动计算设备的用户界面。

6.2结构模型

上一节介绍了用任务分析或用户行为的方法描述人机对话的过程，本节主要介绍用结构化的方法来描述人机交互的一般过程，重点讨论状态转换网络及其扩展方式，它是一种图示化的结构，在本节的最后，简单地介绍了形式化语言的描述――产生式规则，这种结构的方法从理论上可以引导界面设计者及界面工具的设计者进行有效的设计。

6.2.1产生式规则

产生式规则是一种形式化语言，这些规则可用于描述人机交互界面。

产生式规则的一般形式是：

ifconditionthenaction

这些规则可以表示为不同的形式，如

condition→action

condition：

action

所有的规则都是有效的，并且系统不断用它来检测用户的输入是否与这些条件相匹配。

若匹配则激活相应的动作，这些动作可以是执行应用程序的一个过程，也可以是直接改变某些系统状态的值。

一般来说，组成界面描述的产生式规则很多，规则定义的顺序并不重要，只要与规则中的条件相匹配，就可以激活相应的动作。

产生式规则系统可以是事件引导的，也可以是状态引导的，或者两者都有。

1．事件引导的系统

考虑下面的产生式集合，实现用户在屏幕上绘直线。

Sel-line

→

start-line

C-pointstart-line

→

rest-line

C-pointrest-line

→

rest-line

D-pointrest-line

→

此例中产生式规则的条件和动作部分，都以事件的方式进行表示，形式上都比较简单，当然支持复杂的交互任务的产生式规则可能要复杂的多。

事件主要有三种类型：

l用户事件（userevent），Sel-line表示从菜单中选择line命令，C-point和D-point表示用户在绘图平面上单击和双击鼠标。

l内部事件，用于保持对话状态，如start-line表示开始画线后的状态，rest-line表示选择了第一个点之后的状