树形视图 (Windows)
出自UXGuide.net
树形视图
Tree Views
目录 |
树形视图(Tree View)用于通过单选或多选方式查看和操作以层级方式组织的一组对象。
在树形结构中,包含数据的对象称为“叶子结点”,而包含其他对象的对象则称为“容器结点”。位于最顶端的单个容器结点称为“根结点”。用户可以通过单击“加号减号扩展器按钮”来展开或折叠容器结点。
典型的树形视图
它用在这里合适吗?
数据具有层次结构并不意味着就一定要使用树形视图。很多时候,列表视图(List View)是更加简单而有效的选择。列表视图能够:
- 支持多种不同的视图。
- 在详细信息视图下支持按任意列对数据进行排序。
- 支持数据分组,实现两级层次结构。
要使用列表视图,你可以使用下列方法来去除信息的层次结构:
- 如果存在根节点,就将其去除。根节点通常是不必要的。
- 使用列表视图分组、选项卡、下拉列表或可扩展标题(Expandable Heading)来取代顶层容器。
-
- 在这个示例中,列表视图的分组被用作顶层容器。
-
- 在这个示例中,选项卡被用作顶层容器。
-
- 在这个示例中,下拉列表被用作顶层容器。
- 如果所选容器的内容会在另一个相关控件中显示,那么那个控件即显示了较低的层次信息。
-
- 在这个示例中,低层次的容器显示在文档窗口内。
如果需要显示层次级别多于两级的数据(不包括根结点),则必须使用树形视图。
考虑下列问题,以判断是否应当使用树形视图控件:
- 数据是否具有层次结构?如果不是,则应改用其他控件。
- 层次结构是否达到三层或者三层以上(不包括根)?如果不是,考虑使用其他的方案,如列表视图分组、选项卡、下拉列表或可扩展标题(Expandable Heading)。
- 数据项带有附加信息吗?如果有,考虑使用列表视图,并采用其详细信息视图模式来展现附加信息。
- 低层次的数据是否与独立的子任务相关?如果是,考虑用另外的控件或在单独的窗口中显示相关信息(使用命令按钮或链接显示)。
- 目标用户是高级用户吗?高级用户对于树的使用非常精通,如果你的应用程序是面向初学者的话,应当避免使用树形视图。
- 这些条目存不存在大多数用户都比较熟悉的、单独的、自然的层次结构分类?如果存在,树形视图是理想的选择。不过如果需要多种视图或排序方式,则应改用列表视图。
- 用户是否不必在所有的情况下或者不必同时看到所有低层次的数据?如果是,树形视图是理想的选择。
注:有时,看起来像是树形视图的控件其实是通过列表视图来实现的。这种情况下,应当基于其使用来遵守设计规范,而不是实现。
设计理念
树原本是用于组织对象并使其易于查找,但要让树中的对象易于发现是非常困难的。当考虑选择树形视图或是其他组织方式时,应当牢记下列原则。
可预见性与可发现性
树形视图是基于对象间的关系的。当对象之间的关系是清晰、熟知、互斥的,且每个对象都可以对应到单个易于确定的容器中时,树是最为合适的。
一个严重的问题在于,一个对象可能出现在不同的结点上。例如,用户会期望在哪里找到能够播放音乐、拥有大容量硬盘并使用 USB 接口的硬件设备?也许是好几个不同的容器结点,比如多媒体、存储、USB,也可能是硬件资源。一个解决方案是把对象置于最合适的容器中,不考虑之前的情况;另一种方法是把每个对象置于所有合适的容器中。前者有助于形成一个简单、清晰的层次结构,而后者则提高了可发现性——各有好处也都存在潜在的问题。
用户可能无法完全理解树的布局,但他们在对树操作一段时间之后会形成一个关于其关系的心理模型。如果这个心理模型是错误的,则会导致困惑。例如,假设音乐播放器可以在多媒体、存储及 USB 容器中找到。这种安排提高了可发现性。如果用户先在多媒体中发现了这个设备,用户可能会认为所有像音乐播放器这样的设备都会出现在多媒体容器中。然后用户会期望类似像数码相机这样的设备也出现在多媒体容器中,如果他发现那里没有的话,就会感到困惑。
设计树的挑战即在于平衡可发现性与可预见性的用户模式,以最大化减少混乱。
广度 vs 深度
可用性研究显示,用户在较宽广的树中寻找对象比在较深的树中更容易成功,因此在设计树时,应当优先考虑广度。理想情况下,树的层级应当不超过四级(不包括根),最常访问的对象应当出现在前两层中。
其他原则
- 当用户找到他们要找的东西后,就会停止查看。他们不会去看对象还有可能在哪里出现,因为没有必要。这些用户可能会假设他们找到的第一条路径是唯一的路径。
- 用户在大且复杂的树中查找对象会遇到困难。用户不会为了在这种树里寻找对象而进行彻底的手工搜索,相反,一旦他们认为已经花费了足够精力之后就会停下。因此,大且复杂的树需要通过其他访问方式来辅助,如字词搜索、索引或筛选。
- 有些程序允许用户自己创建树。虽然这类自行设计的树应该会符合用户的心理模式,但它们往往是偶然创建的且没有得到很好的维护。例如,虽然文件系统、电子邮件程序和收藏列表通常保存的是相似类型的信息,但用户很少去花精力以相同的方式整理它们。
最重要的一件事:
仔细权衡使用树形视图的优缺点。具有层次结构的数据并不意味着需要使用树形视图来展示。
使用模式
树形视图具有下列使用模式:
|
仅包含容器结点的树形视图 用户一次可以查看并操作一个容器。 |
通常,这类树形视图具有一个关联控件用于显示选定容器的内容,因此用户一次只能操作一个容器。
在这个示例中,树形视图仅包含容器节点。选中节点的内容显示在关联的列表视图控件中。 |
|
带有容器及叶子结点的树形视图 用户能够查看和操作容器及叶子。 |
通常来说,这类树形视图具有一个关联控件,用于显示选中容器或叶子的内容。让用户能够操作叶子结点往往是支持多选的基础。
在这个示例中,树形视图既有容器也有叶子结点。因为支持多选,已打开项的内容通过选项卡显示在关联控件中。 或者,树形视图也可以具有组织结构化列表,容器为标题,叶子是内容选项。
在这个示例中,树的叶子结点是选项而容器是选项分类。 |
|
带复选框的树形视图 用户能够选择任意数量的项,包括不选。 |
复选框明确指明可以进行多选。当多选是基本操作或者经常被使用时,应当使用这种树模式。
在这个示例中,带复选框的树形视图将选择用于打开或关闭功能。 |
|
树形视图构造器 用户能够通过每次添加一个容器或叶子结点及可能的顺序排列来构造树。 |
很多树可以由用户来创建或修改。有些树是通过快捷菜单和拖放操作(如 Windows® Explorer 中的文件夹)来就地创建的,而其他树则是通过专门的对话框(如 Windows Internet Explorer® 中的收藏夹列表)来构建的。
在这个来自 Windows Internet Explorer 的示例中,用户能够通过对话框构造他们自己的收藏夹列表。 |
|
具有其他访问方式的树形视图 用户可以通过使用树形层次结构之外的方式查找对象。 |
之前曾提到过,用户在大而复杂的树中查找对象可能会感到困难,因此这类树应当具有其他辅助的访问方式,如字词搜索、索引或筛选。
在这个示例中,用户可以通过目录、索引及收藏夹来访问信息。对于有些用户来说,Index 及 Search 选项卡比 Contents 选项卡更有用。
在这个示例中,Windows 开始菜单也允许用户通过在搜索框中输入部分名称来访问程序、文件及网页。 |
设计规范
呈现
- 在一个容器中,以逻辑顺序排列各项。名称以字母顺序排列,数值则以数字大小排序,日期则以时间顺序排列。
- 使用“始终显示选择”属性,这样即使控件没有获得焦点,用户也可以确定选中项。
- 如果树是用作目录的话,应当使用单个展开属性以简化树的管理。这样一来,只有树的相关部分才会展开。
- 避免呈现空的树形视图。如果用户创建了一个树,应当将用说明文本或用户可能会需要的示例项来初始化该树。
-
- 在这个示例中,该列表最初显示的是示例项。
- 如果用户完全不需要折叠某容器结点的话,切勿折叠容器结点。这么做会增加不必要的复杂性。
- 如果加载性能是一个问题的话,则默认只显示树的第一及第二级容器。你可以根据需要在用户展开树的分支时加载额外的数据。
- 如果用户展开或折叠了某个容器,应当维持该状态使下次显示该树形视图时这些设置仍然有效。这些设置应当是基于特定的列表视图及用户的。
- 如果高级别的容器内容较为相似的话,考虑通过视觉线索加以区别。
- 错误:
-
- 在这个示例中,Mailbox 和 Archive 文件夹的内容相似,一旦树被展开了多层之后,用户就很难知道自己在树的什么位置,从而引起困惑。在不同的部分使用稍稍不同的图标可以解决这个问题。
- 重新考虑连接线。虽然这些连接线能够清晰显示容器与叶子结点之间的关系,但它们增加了视图混乱却未能明显有助于理解。尤其是它们对于关闭的结点来说没有任何帮助,对于需要滚动的相隔很远的结点更是如此。
- 正确:
-
- 更好:
-
- 连结线对理解没有什么帮助。
交互
- 考虑提供双击操作。双击操作应当与选择一项并执行其默认命令的效果相同。
- 双击操作应当是冗余的。应当始终有一个命令按钮或快捷菜单命令具有相同的效果。
- 如果列表项需要进一步解释,应当通过信息提示来提供解释说明。应当使用完整的带有句末标点的句子。
-
- 在这个示例中,信息提示用于提供进一步的信息。
- 为相关命令提供快捷菜单。这类命令包括:剪切、复制、粘贴、移除/删除、重命名、属性。
- 当禁用列表视图时,应当同时禁用所有相关联的标签和命令按钮。
树的组织
- 使用大多数用户所熟悉的自然层次结构。
- 如果你无法使用这种结构的话,尽可能平衡可发现性与可预见性的用户模式,以最大化减少混乱。
- 要安全可靠地提高可发现性,应当在下列情况下将条目置于多个容器内:
- 该条目与任何其他类似的条目都没有联系(因此用户不会因错误的关联关系而困惑)。
- 只有少数这类重复放置的条目(因此该树不会变得臃肿)。
- 使用最简单可行的层次结构。做法:
- 将最常访问的对象放在树的前两级内(不包括根结点),将不太常用的对象放在深一些的层级中。
- 去除不必要中间层容器,或将重复的合并。
- 应当优先考虑广度。理想情况下,树的层级应当不超过四级,最常访问的对象应当出现在前两层中。
- 决定你是否确实需要根结点。如果用户需要执行能够用于整个树的命令(可能是通过根结点上的快捷菜单)的话,则应提供根结点。否则,没有根结点的树将更为简洁易用。
- 如果该树具有像字词搜索或索引等其他访问途径的话,应当将树为着重浏览最重要的内容而优化。有了其他的访问方式,树的内容则不必包罗万象。对树进行简化可以使用户能够更容易地找到最有用的内容。
带复选框的树形视图
- 在列表下方显示选中项的数量,尤其是当用户很可能选择多项时。这种反馈有助于用户对其做出的选择加以确认。
-
- 在这个示例中,选中项的数量显示在树的下方,很明确有两项未选中。
- 如果有可能存在大量列表项,且经常需要选中或清除所有项的话,应当添加“全部选择”和“全部清除”命令按钮。
- 将混合状态的复选框用于指出容器中条目的部分选中。
- 正确:
-
- 在这个示例中,复选框的混合状态用于指示部分选中。
推荐尺寸与间距
用于树形视图的推荐尺寸与间距
- 当树完全展开时,应当为大多数条目调整树形视图的宽度以避免水平滚动的需要。
- 应当预留额外 30% 的长度以便于本地化。
- 调整树形视图的高度以消除不必要的垂直滚动。如果把树形视图稍稍加长(如果空间足够还可以再加大一些)可以消除垂直滚动条的话,可以考虑调整列表框的高度。
- 错误:
-
- 在这个示例中,稍稍增加树形视图的宽度和高度可以在大多数情况下消除滚动条。在这个树中,一次只能打开一个容器。
- 如果增大树形视图对用户来说有好处的话,应当使树形视图及其父窗口可以缩放。这么做使用户能够根据需要调整树形视图的尺寸。
标签
控件标签
- 应当为所有树形视图添加标签。标签文本应当为以冒号结尾的单词或短语,而不是句子。应当使用静态文本。
- 分配唯一的访问键。相关设计规范,参见键盘。
- 使用句子大写样式。
- 将标签放置于控件的左侧或上方,并将其与控件的左边对齐。
- 对于多选树形视图,应当使用明确指示可以多选的标签。带复选框的树形视图的标签则可以无须那么明显。
- 错误:
-
- 在这个示例中,标签没有提供关于多选的信息。
- 较好:
-
- 在这个示例中,标签明确指出可以进行多选。
- 更好:
-
- 在这个示例中,复选框明确指出可以进行多选,因此标签无须那么明显。
数据文本
- 使用句子大写样式。
说明文本
- 如果你需要为树形视图添加说明文本,应当将其放置在标签的上方。应使用完整的包含句末标点的句子。
- 使用句子大写样式。
- 那些有用但并非必须的附加信息应当保持简短。这类信息要么放在标签与冒号之间的括号内,要么不带括号放在控件的下方。
-
- 在这个示例中,附加说明信息位于控件的下方。
文档编写
当提及树形视图时:
- 原样引用标签文本,包括其大小写,但无须包含访问键下划线和冒号。当需要在上下文中与普通列表加以区别时,可包含“list(列表)”或“hierarchical list(层级列表)”字样。
- 对于树形视图项,应严格引用项目文本,包括其大小写。
- 仅仅在编程或其他技术文档中才可将树形视图称为“tree view(树形视图)”。在其他地方,应使用“list(列表)”或“hierarchical list(层级列表)”名称,因为术语“tree(树)”对于大部分用户来说难以理解。
- 描述用户交互行为时,对于数据应使用“select(选择)”一词,对于加号及减号按钮应使用“expand(展开)”和“collapse(折叠)”。
- 应尽可能为标签和树条目文本应用粗体样式。对于英文来说,仅当需要避免歧义时才在文本两侧添加引号;对于中文来说,则应总是使用引号。
示例:In the Contents list, select User Interface Design.(在“目录”列表中,选择“用户界面设计”。)
当提及复选框时:
- 原样引用标签文本,包括其大小写,并包括“check box(复选框)”字样。不要包含访问键下划线。
- 用“select(选择)”和“clear(清除)”描述用户的交互行为。
- 应尽可能为标签文本应用粗体样式。对于英文来说,仅当需要避免歧义时才在其两侧添加引号;对于中文来说,则应总是使用引号。
示例:In the Items to back up list, select the My Documents check box.(在“要备份的项目”列表中,选择“我的文档”复选框。)