界面模式一致性分析与自动化方法
1. 模式与一致性
从基于状态的视角能更清晰地看到一致性与模式之间的关系。模式可定义为用户界面以特定方式运行的一组状态。显然,根据所考虑的行为,我们可能同时处于多种模式。
假设在模式 M 中,操作 A 通常呈现行为 B。按照定义,存在另一个模式 M′,即“A 呈现 B 的状态”。一致性原则表明,如果处于模式 M,就应始终处于模式 M′,也就是说 M 应是 M′的子集。若模式 M 中有少数例外状态不在 M′中,那么界面就是不一致的。
部分行为为相关的一致性现象提供了形式化描述:使用包含用户操作的事件代数来指定界面行为。部分行为是一种代数属性,在给定模式中通常成立,但并非总是如此,这表明可能导致模式混淆的不一致性。该方法建议重新设计,使该属性在整个模式中保持一致。
我们可以将“有趣的”(从用户或设计师的角度来看)模式不一致性描述为几乎成立且用户可能感知到的模式之间的任何关系。即对于大多数状态成立,但有少数例外状态不成立的简单关系。如果仅对少数状态成立,用户不太可能感知到;如果对所有状态都成立,则不存在不一致性。只要关系几乎成立,用户可能会通过经验学习到该关系,但不会注意到例外情况,他们不同的用户模型可能会导致模式混淆。此外,重新设计用户界面可以使关系一致并消除错误源。
2. 模式不一致性模型
由于只需考虑用户可能(错误)学习到的模式关系,我们将范围限制在基本集合论。我们已经讨论了一个模式是另一个模式的子集或相等的情况。其他关系也可能被错误学习,但根据经验,只要使用模式的简单并集和补集,就可以用子集(⊆)来解释。例如:
- A = B 等价于 A ⊆B 且 B ⊆A。
- A 与 B 不相交等价于 A ⊆BC。
- A1, …, An 划分 B 等价于对于每个 i ≠ j,Ai ⊆ACj 且 A1 ∪ … ∪ An = B。
为了提供模式不一致性的模型,需要形式化状态集合之间的近似子集关系。
2.1 近似子集和近子集
我们定义近似子集关系 ⊂≈:
[A⊂≈B \Leftrightarrow \frac{|A \cap B|}{|A|} \geq \rho]
这表示如果 A 中同时属于 B 的状态比例至少为 ρ(0 ≪ρ < 1,即 ρ 接近 1),则 A 是 B 的近似子集。如果比例为 1,则 A 恰好是 B 的子集。
近子集关系 ⊂∼定义为排除相等和实际子集的近似子集。两个模式 A 和 B 不一致当且仅当 A⊂∼B 或 B⊂∼A,其中:
[A⊂∼B \Leftrightarrow (A⊂≈B \land A \nsubseteq B)]
⊂≈(以及 ⊂∼)的定义由值 ρ 参数化。降低 ρ 会增加被分类为近子集的子集数量。在本文中,我们将 ρ 视为设计师设定的标准。设计工具也可以自行确定合适的 ρ,或者允许设计师动态调整 ρ,并根据 ρ 对近子集进行排序,以供设计师关注。
2.2 操作模式与指示模式
到目前为止,我们假设用户通过经验学习各种界面模式,并(可能错误地)学习它们之间的关系。模式定义为界面以特定方式运行的一组状态,该定义较为宽泛。然而,所涉及模式的具体性质可能会影响用户学习哪些模式和关系。我们通过区分操作模式和指示模式来细化模型。
操作模式是特定用户操作组合或其他事件具有一致效果的状态集合。对于手机,可能是取消按钮将用户返回到初始状态的状态集合,或者两个按钮组合用作键盘锁切换的状态集合,或者使用特定协议输入文本的状态集合。该模式由给定事件的状态转换决定。特定的操作模式是用户相信但不能直接观察到的。也就是说,根据到目前为止的用户操作历史,用户(从经验或培训中)相信系统处于操作模式。这种信念可能会影响后续交互。需要注意的是,每个操作模式是根据系统而不是用户定义的:用户可能无法准确理解模式,甚至可能没有注意到其存在。目标是设计不会让注意到这些模式的用户感到沮丧的系统。
指示模式是界面向用户发送或显示一致反馈的状态集合。例如,特定 LED 亮起的状态集合,或播放音乐的状态集合(例如,MP3 播放器的“播放模式”)。用户原则上可以看到系统处于给定的指示模式。
模式不一致性 A⊂∼B 的影响取决于所涉及的模式类型组合,如下表所示:
| 模式 A | 模式 B | 用户信念 | 界面状态 |
| ---- | ---- | ---- | ---- |
| 操作 | 操作 | 在 B 中 | 在 A 中且不在 B 中 |
| 指示 | 操作 | 在 B 中 | 观察到 A 且不在 B 中 |
| 操作 | 指示 | 不在 A 中 | 在 A 中且未观察到 B |
| 指示 | 指示 | — | — |
在通过并集和补集定义复合模式时,我们做了简化假设,即模式仅与相同类型的其他模式组合,组合后的模式也是该类型。例如,两个指示模式的并集是一个指示模式。我们推测用户不太可能对由事件行为和指示组合定义的模式进行推理。
2.3 使用模型
上述模式不一致性模型是启发式的,因为它没有建议具体的一致重新设计,仅提供了性能特征,即 ρ 的值和不一致模式的数量。此外,更一致的重新设计(即更少的不一致模式或相同模式下更大的 ρ)并不一定能改善界面:可能会违反其他设计约束。例如,重新设计可能会用两个极不一致的模式取代三个轻微不一致的模式。然而,减少不一致模式的重新设计有其内在的合理性,并且在其他条件相同的情况下,有望改善界面设计。使用设计工具,设计师在发现问题后可以轻松尝试重新设计及其代表的权衡。
3. 模式分析方法
分析要求设计师已经知道要检查哪些模式。指示模式是界面设计的一部分,因此至少需要设计师隐式提供。操作模式是界面设计中固有的且隐含的,因此更难找到。下面提供一种查找操作模式的方法,该过程可以自动化。
3.1 代数模型
从用户界面设计的有限状态机(FSM)模型开始,生成一个规范代数。FSM 定义如下:
- 状态集合 S
- 事件集合 E,包括用户可用的操作
- 转换关系 trans : S × E × S
也可以使用转换函数 S → powerset(S) 进行等效表述。此外,我们可以选择有一组指示模式 MI。
熟悉的 FSM 概念是布尔转换矩阵,它定义了从每个状态到每个其他状态的所有转换。我们为每个事件 e 定义按钮矩阵,即有限状态机限于事件 e 的转换矩阵。这是解决各种用户界面问题的一种非常有效的方法的基础。
状态用行向量表示,每个元素对应界面可能处于的单个状态。因此,每个特定状态对应一个只有一个非零元素的向量,而状态组(如模式)可以用任意向量表示。
形式上,我们使用 ||.|| 表示从 FSM 元素到矩阵代数的映射。因此,我们区分状态 s ∈ S 及其向量 ||s||,以及事件 e ∈ E 及其矩阵 ||E||。对于任何指示模式 m ∈ MI,也有一个向量 ||m||。需要注意的是,模拟 FSM 对应于矩阵乘法:trans(s, e, s′) 当且仅当 ||s||.||e|| = ||s′||。
3.2 指定操作模式
使用标准 BNF 符号描述用于定义事件/状态属性(从而定义操作模式)的规范语言:
P ::=
E ≡ E
| S ≡ S
| not(P)
| undo(E)
E ::=
Nothing
| e
| E.E
| ¬E
| E ∨ E
| E ∧ E
| go(S)
S ::=
All
| None
| s
| S.E
| ¬S
| S ∨ S
| S ∧ S
该语言的简单语义使用矩阵代数定义:状态(S)求值为向量,事件(E)求值为矩阵,并且有关于它们的简单可计算命题(P)。语言运算符对应于简单的向量/矩阵操作。等价(≡)是在状态或事件之间定义的,定义为向量/矩阵的逐元素相等。命题 undo(E) 在矩阵 ||E|| 可逆时成立。Nothing 是一个不执行任何操作的事件,求值为单位矩阵。All 和 None 分别是所有状态和没有状态的集合,分别求值为所有非零元素的向量和所有零元素的向量。E1.E2 是事件 E1 后跟事件 E2。S.E 是通过 E 从 S 到达的状态集合。两者都通过矩阵乘法求值。事件 go(S) 将任何状态转换到状态集合 S。
其余运算符是布尔运算符:¬S、S1∨S2 和 S1∧S2 分别是不在 S 中的状态、在 S1 或 S2 中的状态以及在 S1 和 S2 中的状态。事件 ¬E 仅导致 E 未执行的转换。事件 E1 ∨ E2 表示由 E1 或 E2 引起的转换(它们的组合功能),而 E1 ∧ E2 表示由两者引起的转换(它们的共同功能)。
这个规范语言的表达能力有限。代数属性本身不足以支持我们可能想要进行的所有类型的可用性分析。然而,它们可以用于陈述和计算事件和状态的简单行为。此外,语言的简单性使我们能够轻松构造定义操作模式的属性。
3.3 模式分析
使用这些代数属性进行模式分析是一个三阶段过程:
1. 界面设计师必须制定与设计特定部分的预期功能相对应的属性。例如,他们可以指定取消按钮将用户返回到初始菜单状态 MainMenu,并且与 ∗ 按钮一起用于切换键盘锁:
Cancel ≡ go(MainMenu)
Cancel.Star.Cancel.Star ≡ Nothing
对于另一个设备,他们可能指定播放按钮开始播放音乐,即进入音乐状态集合中的一个状态,并且播放和音量功能独立工作:
Play ≡ go(Music)
Play.(+Vol ∨ -Vol) ≡ (+Vol ∨ -Vol).Play
每个属性都定义了一个操作模式,即属性为真的状态集合。尽管制定这些属性是一项需要技巧的任务,但在适当的工具支持下,许多界面设计师都能够完成。实际上,也可以使用下一节描述的算法自动生成这些属性供设计师审核。
2. 给定由代数属性定义的操作模式集合 MA,通过对 MA 中的模式进行补集、并集和交集操作,形成修订后的模式集合 M′A。对指示模式 MI 重复相同的过程,得到集合 M′I。
3. 使用 ⊂∼ 关系比较 M′A ∪ M′I 中的模式对,避免比较指示模式对。任何不一致的对都被标记为重新设计的候选对象。
下面是模式分析的流程 mermaid 图:
graph LR
A[制定属性] --> B[生成修订模式集]
B --> C[比较模式对]
C --> D[标记不一致对]
4. 方法自动化
为了支持设计师应用模式一致性方法,我们现在介绍一种新颖的算法,该算法可以自动找到代数属性/操作模式,以“输入”到分析中。该算法还可以用于作为更通用设计方法的一部分生成操作规范。
我们开发了 MAUI,一个 Java/XML 原型设计工具,支持此类属性的规范和自动生成。在 MAUI 中实现了该模式分析技术的原型,我们打算用它来评估这种方法。早期结果表明,它可以处理实际的界面设计。
该算法只能生成规范属性的一个受限子集,具体来说,是以下形式的属性:
- A1. … .An = B1. … .Bm
- C1. … .Cp = go(s)
其中 Ai, Bi, Ci ∈ E 且 s ∈ S。它生成这些属性,直到设计师设定的最大乘积长度界限 N(即 n, m 和 p)。该算法的复杂度与 N 呈指数关系,但我们发现实际示例可以轻松计算。如果计算资源成为问题,可以使用更复杂的实现。
4.1 自动化 - 查找等价关系
给定事件集合 E,我们希望将单个事件组合成复合操作,用矩阵乘法形成的项集合 TE 表示。这是一个无限集合,我们限制自己研究一个有限子集 TNE(对于某个 N > 0),归纳定义如下:
- e ∈ E,则 e ∈ T1E
- t ∈ TkE 且 e ∈ E,则 t.e ∈ Tk + 1E
第一步是将 TNE 划分为一组等价类 CNE,由事件之间的等价性定义。形式上,CNE = {C1, …, Cm},使得 ∪Ci = TNE,并且对于 a ∈ Ci 和 b ∈ Cj,||a|| = ||b|| 当且仅当 i = j。还有一个代表函数 φ : CNE → TNE,它从等价类中选择一个特定元素,即 φ(C) ∈ C。
计算等价类涉及逐步构建 CNE 和 φ,我们用伪代码描述这个过程,以便清晰地描述算法。实际实现可以在“代码”的基础上进行大量效率优化(但会更难理解)。为了简洁起见,我们的代码使用各种全局数据结构:事件集合 E、从项到矩阵的函数 matrix(均作为输入)、新项集合 Novel、唯一事件集合 Unique、等价类集合 EQC 以及将每个类 C 映射到其代表元素 φ(C) 的函数 rep。算法的目的是计算 EQC 和 rep。
主要算法依赖于三个函数:
- classify 用于将新项放入适当的等价类中:
classify(term t) {
if (exists c in EQC and matrix(rep(c)) = matrix(t))
put t in c;
else
new class c’;
put c’ in EQC;
if (matrix(t) = matrix(go(s)) for state set s)
put go(s) in c’;
r = go(s);
else
r = t;
fi
put t in c’;
extend rep so that rep(c’) = r;
put r in Novel;
fi
}
- redundant 用于测试一个项是否有已经计算过的子项。
- newTerms 用于计算当 n 增加 1 时引入到 CNE 中的新项。
计算 N > 1 时的 CNE 的算法调用 newterms 等函数,这里不再详细列出其伪代码。通过这些步骤,可以实现操作模式分析的自动化,帮助设计师更高效地发现和解决界面模式不一致的问题。
4.2 自动化操作步骤总结
以下是使用该自动化方法进行操作模式分析的具体步骤:
1.
确定事件集合 E 和最大乘积长度界限 N
:设计师根据实际需求设定事件集合 E 和最大乘积长度界限 N。
2.
生成有限子集 TNE
:按照以下规则归纳生成 TNE:
- 若 e ∈ E,则 e ∈ T1E。
- 若 t ∈ TkE 且 e ∈ E,则 t.e ∈ Tk + 1E。
3.
划分等价类 CNE
:
- 初始化等价类集合 EQC、新项集合 Novel、唯一事件集合 Unique、代表函数 rep。
- 对 TNE 中的每个项 t,使用 classify 函数将其放入适当的等价类中:
classify(term t) {
if (exists c in EQC and matrix(rep(c)) = matrix(t))
put t in c;
else
new class c’;
put c’ in EQC;
if (matrix(t) = matrix(go(s)) for state set s)
put go(s) in c’;
r = go(s);
else
r = t;
fi
put t in c’;
extend rep so that rep(c’) = r;
put r in Novel;
fi
}
-
生成操作模式属性
:算法会生成以下形式的属性:
- A1. … .An = B1. … .Bm
-
C1. … .Cp = go(s)
其中 Ai, Bi, Ci ∈ E 且 s ∈ S。
-
进行模式分析
:
- 按照前面提到的三阶段模式分析过程,使用生成的操作模式属性进行分析。
- 制定与设计预期功能对应的属性。
- 生成修订后的操作模式集合 M′A 和指示模式集合 M′I。
- 使用 ⊂∼ 关系比较模式对,标记不一致的对。
下面是自动化方法的流程 mermaid 图:
graph LR
A[确定 E 和 N] --> B[生成 TNE]
B --> C[划分 CNE]
C --> D[生成操作模式属性]
D --> E[进行模式分析]
5. 总结
界面模式的一致性对于提升用户体验至关重要。通过对模式与一致性关系的研究,我们明确了模式不一致性的定义和影响。操作模式和指示模式的区分有助于更细致地分析模式不一致性对用户的影响。
模式分析方法为设计师提供了一种有效的手段来发现和解决界面模式不一致的问题。通过代数属性来定义操作模式,并进行三阶段的分析过程,可以找出需要重新设计的模式对。
自动化方法的引入进一步提高了模式分析的效率。通过自动生成代数属性和操作模式,设计师可以更快速地进行分析,并且可以处理实际的界面设计。
在实际应用中,设计师可以按照以下步骤进行操作:
1. 利用 MAUI 等工具,设定事件集合 E 和最大乘积长度界限 N。
2. 运行自动化算法,生成操作模式属性。
3. 按照模式分析的三阶段过程,对生成的模式进行分析。
4. 根据分析结果,对标记的不一致模式对进行重新设计。
通过这些方法和步骤,设计师可以提高界面设计的一致性,减少用户的模式混淆,从而提升用户体验。
以下是一个总结表格,展示了不同类型模式的特点和处理方式:
| 模式类型 | 定义 | 用户感知 | 不一致性影响 | 处理方式 |
| ---- | ---- | ---- | ---- | ---- |
| 操作模式 | 特定用户操作组合或其他事件具有一致效果的状态集合 | 不能直接观察到,用户从经验或培训中相信系统处于该模式 | 可能导致用户对操作效果的错误预期 | 通过代数属性定义,进行模式分析和重新设计 |
| 指示模式 | 界面向用户发送或显示一致反馈的状态集合 | 原则上可以看到 | 一般不会因不一致性导致错误,但可能影响用户对系统状态的判断 | 进行模式分析,必要时重新设计 |
通过合理运用这些技术和方法,设计师可以打造出更加一致、易用的用户界面。
超级会员免费看
10万+

被折叠的 条评论
为什么被折叠?



