人机交互与界面设计材料.docx
《人机交互与界面设计材料.docx》由会员分享，可在线阅读，更多相关《人机交互与界面设计材料.docx（128页珍藏版）》请在冰豆网上搜索。
人机交互与界面设计材料
图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
→
此例中产生式规则的条件和动作部分，都以事件的方式进行表示，形式上都比较简单，当然支持复杂的交互任务的产生式规则可能要复杂的多。
事件主要有三种类型：
●用户事件（userevent），Sel-line表示从菜单中选择line命令，C-point和D-point表示用户在绘图平面上单击和双击鼠标。
●内部事件，用于保持对话状态，如start-line表示开始画线后的状态，rest-line表示选择了第一个点之后的状态。
●系统响应事件，以尖括号表示可见或可听的系统响应，如，把菜单项'line'高亮度显示，表示在屏幕上显示直线，表示橡皮筋绘制方式打开，表示橡皮筋绘制方式关闭。
在上面的产生式规则中，第一条规则表示选择画线命令后，系统状态进入了开始画线状态，接着把'line'菜单项高亮度显示；第二条规则表示，用户在开始画线状态时，在绘图区域单击鼠标则系统表示已定义了一个点，此时橡皮筋绘图方式打开；第三条规则表示在定义了一个（或多个）点后，用户单击鼠标可以连续地定义点；第四条规则表示双击鼠标则结束画线的交互过程。
对话控制由一块系统内存专门存放一系列的事件，如果来自用户的事件与系统内存中内部事件合并后与某条产生式规则匹配，则激活该条规则。
所有与用户相关的事件都由对话控制根据输入设备的动作来产生相应的用户事件，如用户单击了一下鼠标，则用户事件（如鼠标单击）被加入内存，系统响应如被调出并根据显示控制器做出相应的动作。
若某个规则被激活，则与该条件相吻合的所有事件都被从系统内存中删除，并加入相应的动作事件，例如，若用户选择了Line，则用户事件Sel-line加入到系统内存，这就是说第一条规则被激活，Sel-line事件被从系统内存中删除，并代之以start-line和，最后，显示控制器删除并完成一个显示动作。
这时只有start-line事件留在系统内存中，只有用户做其它动作才能激活其它规则。
对话控制主要负责事件的产生和规则的匹配，可以看到在每一时刻系统内存中会保存一些内部事件，当产生一个事件时，可能是用户事件（如单击鼠标），也可能是内部事件（如时钟事件等），对话控制就要将所有的产生式规则与事件集合进行匹配，这个过程是复杂的而且是耗时的，当产生式很多并且产生式规则的条件复杂时，匹配算法的效率就显的更为重要，因此需要设计好的数据结构和匹配算法来提高匹配规则的效率，例如可以将规则和事件进行分组和分层。
2．状态引导的系统
状态引导的系统与事件引导的系统有很大的不同，在系统内存保存的不再是动态的随时进出的事件，而是一些表示系统的当前状态的属性，这些属性在不同的时刻有不同的值，在上面的例子中，为了实现画线的操作，系统有下面五个属性。
Mouse:
﹛mouse-null,select-line,click-point,double-click﹜
Line-state:
﹛menu,start-line,rest-line﹜
Rubber-band:
﹛rubber-band-off,rubber-band-off﹜
Menu:
﹛highlight-null,highlight-line,highlight-circle﹜
Draw:
﹛draw-nothing,draw-line﹜
第一个特征Mouse有4个不同的状态mouse--null（鼠标空闲），select-line（选择线命令），click-point（单击鼠标），double-click（双击鼠标），当用户对鼠标进行操作时Mouse自动设置成相应的状态；第二个特征Line-state用于保持当前会话的状态，分别是menu（可选命令状态），start-line（开始绘制线），rest-line（已经定义点）；后三个属性用于控制系统响应，其中Rubber-band表示橡皮筋绘制的开和关状态，Menu表示任何项也没有选中（highlight-null）、选中绘直线命令（highlight-line）或选中绘圆命令（highlight-circle），Draw表示什么也不画状态（draw-nothing）或画直线状态（draw-line），显示控制器根据上面的状态做出相应的显示控制。
状态引导的系统的产生式规则有点类似前面介绍的事件引导的产生式规则，但也有不同，如下所示：
Select-line
→
mouse-nullstart-linehighlight-line
Click-pointstart-line
→
mouse-nullrest-linerubber-band-on
Click-pointrest-line
→
mouse-nulldraw-line
Double-clickrest-line
→
mouse-nullmenudraw-linerubber-band-off
当产生式规则的条件和状态匹配时将激活该产生式规则，对于某一特定的属性，如果前面的状态需要改变成新的状态时才需要在产生规则的后面标注，例如，在第二条规则中，规则指定"Line-state"属性应设置成"rest-line"，因为原来的"start-line"值将丢失，而在第三条规则中，没有提及"rest-line"值，因为它已默认，"Line-state"属性的值继续保留为"rest-line"。
属性的永久特性有时会引起一些奇怪的错误，因此在上述的规则集中，每一条产生式规则都要求将鼠标的状态设置为"mouse-null"，否则，当用户单击了鼠标，激活了第二条规则，如果不立即将鼠标的属性设置为"mouse-null"，则会立即激活第三条规则，此时系统的状态和第三条规则的条件是匹配的，并且会反复的一直执行下去。
3．混合引导系统
从产生式规则处理的简单性来考虑，要么使用单一的事件引导的系统，要么使用单一的状态引导的系统，从上面的实例中可以看到，有的对话过程比较适合于事件引导方式，有的对话过程适合于状态引导方式，当然也可以将两者结合起来，例如采用下面的形式：
event:
condition→action
来描述一个产生式规则，事件用来计划产生式规则，如果条件不满足，即当前系统内存中的状态和产生式的规则不匹配，则无法激活规则，另外当状态改变时，产生式规则中的action本身也可以产生新的事件，从而可以激活另一条规则。
使用产生式系统可以较容易地表示并发的对话元素，即在某个时刻同时有几个事件发生，激活不同的产生式规则。
下面的例子使用混合的事件/状态产生式系统描述如图6-2所示的粗体/斜体/下划线对话框。
图6-2粗体/斜体/下划线对话框
文本样式
系统有三个属性：
Bold:
﹛off,on﹜
Italic:
﹛off,on﹜
Underline:
﹛off,on﹜
根据用户点击鼠标的位置不同，可能产生三个事件：
select-bold,select-italic,select-under，该对话过程有下面六个产生式规则定义。
select-bold:
select-under:
→
Bold=on
select-bold:
Bold=on
→
Bold=off
select-italic:
Italic=off
→
Italic=on
select-italic:
Italic=on
→
Italic=off
select-under:
Underline=off
→
Underline=on
select-under:
Underline=on
→
Underline=off
这些规则描述得非常仔细，与状态转换网络不同，规则的数目线性的增加。
如果有n个转换开关，则会产生２n个规则。
可以通过增加下列规则：
escape-key:
→reset-action
来简单的处理Esc键，这里reset-action的作用是设置所有的状态为初始状态，因为给规则的激活条件是空，所以在对话的任何时候，用户按Esc，对话都回到初始状态，当然这样只是一种简单的处理方式，实际的交互系统对Esc键的处理要复杂的多。
产生式规则比较适合于描述并发的操作，而对于顺序的对话就不太适合，如在上面的绘制连续折线的实例中，为了追踪顺序的操作，用一个状态变量来表示操作的步骤，这种顺序对话的描述既难于分析也显得比较笨拙。
6.2.2状态转换网络
状态转换网络（STN）的基本思想是定义一个具有一定数量的状态的转换机，称之为有限状态机（FSM），FSM从外部世界中接收到事件，并能使FSM从一个状态转换到另一个状态。
这里介绍两种最基本的状态转换网络，状态转换网络（StateDiagrams）和扩展状态转换网络（StateCharts），后者是前者的一个扩展，因此详细的介绍后者。
6.2.2.1传统状态转换网络
状态转换网络的主要组成部分是状态和代表状态改变和转换的箭头，状态转换网络实际上是一个有向图，图的节点代表状态，图中的有向边代表一个状态到另一个状态的转换，交互任务在状态转换网络中表现为从任务的起始状态，经过一系列中间状态的转换，达到任务结束的状态这样一个完整转换路径上的状态转换序列。
状态可以用不同类型的图形符号表示，包括圆、矩形、圆角矩形等，不同的符号代表不同的状态，如用圆角矩形来表现系统的状态，如图6-3所示系统状态转换网络符号。
状态
图6-3状态转换网络符号
状态可以定义为在给定时间、方法和行为的情况下，与用户环境相关的一组环境变量或属性集。
状态转换网络则用于图形化地显示状态以及任何时刻在状态之间发生的交互。
如图6-4所示的简单状态转换网络，包括一个源状态、一个目标状态，以及这两个状态间的转换。
源状态
目标状态
转换
图6-4简单状态转换网络
当发生一个外部或内部事件时，系统就会从一个状态转换到另外一个状态，这称为状态转换。
外部事件主要由用户操作外部输入设备来产生，内部事件可以是系统产生的事件，如时钟事件，也可以是为了改变系统的状态和行为而产生的事件，如当一个任务完成后可以激活另一个任务等，一个状态转换与一对状态相关联。
一般的系统具有很多个状态，两个状态之间可以存在一个状态转换，假设系统由n个状态组成，状态之间的转换最多可能有n*（n-1）个，如图6-4所示的状态转换网络中有3个状态，因此最多可能有6个状态转换，事实上一般系统状态中状态转换数要远远小于最多状态转换数，如图6-4中只标出了4个状态转换。
状态1
状态2
状态3
图6-5简单的三状态FSM
在状态转换网络中，如果两个状态A到状态B不存在状态转换，则说明由状态A在任何情况下都不能转换到B，如图6-5中状态3可以转换到状态1，但不可能转换到状态2，而状态1可以转换到状态2，但不能直接到状态3。
在实际的系统中，由于交互任务比较多，而且每个交互任务相对可能比较复杂，组成系统的状态很多，可能有几百个，甚至能达到上千、上万个状态，状态转换的数目就更多了。
基本状态转换网络中的状态转换仅描述了发生一个事件而使系统从一种状态转换成另一种状态，但是并没有说明这种转换需要的条件，即当在某一状态时，什么条件可以允许产生这样的转换，另外当系统在改变状态时将执行什么动作，如进行相应的业务处理、驱动外部设备等，也没有说明。
为了能更完整的描述这两种情况，可以在描述状态转换时增加两个额外的选项：
选项条件（conditions），表示导致状态的改变的条件；
选项动作（actions），表示系统在改变状态时将执行什么动作。
带条件和动作的状态转换网络如图6-6所示。
源状态
目标状态
条件
动作
图6-6带条件和动作的状态转换网络
现在来分析一下带条件的状态转换网络，当系统在某一种状态时S时，如果满足条件C1，系统将发生状态转换T1，而转换到状态E1，当满足条件C2，系统发生状态转换T2，而转换到状态E2，如图6-7a所示的条件转换网络，现在将条件C1、C2和状态融合则得到如图6-7b所示的基本的状态转换网络。
从这里可以看到，带条件的状态转换网络是将状态中表示触发条件的部分抽取出来，这样可以大大减少状态的数量，而条件触发实现时还是比较方便的，但在实现时还要增加对触发条件的管理。
图6-7a带条件的状态转换网络
T2[C2]
T1[C1]
S
E1
E2
图6-7b带条件的状态转换网络
S+C1
S+C2
E1
E2
下面给出一个关于传统状态转换网络的实例，图6
升级会员 