最优雅的UI用于分类项目?

Mal*_*oss 8 usability user-interface

我有一组项目,用户需要以多种方式进行分组/分类.举个例子,假设它是汽车的集合,用户希望通过以下方式对它们进行分类:

  • 颜色(红色,银色,蓝色,黑色等)
  • 车身形状(舱口,轿车,轿跑车,旅行车等)
  • 座椅(2,4,5,6等)
  • 等等

您是否曾经遇到过这样一种特别优雅的方式,它允许用户完全自由地定义自己的类别和价值观?

显然,在任何设计中都会有许多权衡取舍.例如,可学习的设计可能效率不高,反之亦然.或者某些设计可能比其他设计对房地产要求更高.有些人的开发时间比其他人长得多.

无论如何,如果你已经看到 - 或设计 - 一个很好的模式,我会有兴趣听到它.如果你有截图,那就更好了.

尝试澄清:标签确实是对事物进行分类的一种很好的方式,但在我看到的所有实践中,只有一个级别的标记.用户一般不会去定义一个类/属性和商品的价值在该类别中.要使用上面的示例和StackOverflow的标记,您可以将汽车标记为"蓝色","轿车","4"等.StackOverflow没有固有的知识,一个项目不能被标记为"轿车"和"轿跑车".

我正在考虑的界面需要知道这种事情,因此用户定义的属性建议更符合我的想法.我只是想找到一个具体的例子,说明如何优雅地实现这种系统(在桌面应用程序中,如果这有所不同).

那更清楚吗?如果没有,请发表评论,我会再次澄清.:)

Mic*_*lag 9

听起来你有两个任务:任务1对对象进行分类,对于一系列对象,用户在每个多维度(属性)上为每个对象分配一个类别(值).任务2:创建和修改维度和类别.

在数据建模者,面向对象程序员和数据库设计者之外,维度和类别的概念是一个非常难以理解的概念.您应该为不了解类别和维度之间差异的用户做好准备.但是,用户通常会理解表,其中每列是一个维度(包含几个类别),每行都是一个对象.尽可能使用表格.

第一个关键问题是通过用户研究弄清楚任务1和2的程度是集成还是分开.

如果任务是集成的,用户经常在不经过深思熟虑的情况下从一个流程切换到另一个,那么一个UI设计就是拥有逐个维度的表,但是提供一个空白列(或"插入"按钮)以允许用户添加维度.列标题具有维度名称,用户可以编辑该名称.标题下方是列出该维度类别的空间.每个类别名称都是可编辑的,并且有一个空行(或"插入"按钮)来添加新类别.下面是要分类的对象,每个对象都有维度的每列中的下拉列表.

在可用性测试中,请注意尝试通过单击类别列表中的类别来设置对象类别的用户,而不是从下拉列表中进行选择.使类别列表在视觉上分开显示以防止这种情况.

您可能需要一个按钮来隐藏/显示类别列表,因为这可能会占用大量空间(即使使用滚动条).即使任务1和2紧密集成,我认为您会发现用户可能希望有时会将类别列表排除在外.

如果您发现任务1和2是分开的,很少一起完成(例如,用户通常设置他们的维度然后对一堆对象进行分类),那么最好为每个任务使用单独的窗口(或页面),虽然在它们之间来回导航应该很容易.例如,虽然用户通常可以事先设置其尺寸,但很少修改它们,有时用户会在分类异常对象时意识到需要维度的新类别,因此您需要提供一个"添加类别"菜单项在"管理类别"窗口中,为当前维度插入了一个新类别,等待用户提供名称.

任务1的窗口与之前相同:对象表,其中包含每个维度的下拉列表列,但不包括类别列表,维度名称的编辑以及添加新维度的容量.如果用户需要扫描需要分类或重新分类的对象,或者通常用户需要将一个对象与其他对象进行比较(例如,决定如何对对象进行分类),则这是最有效的.但是,如果用户的任务真的仅限于根据外部信息一次一个地分类一个对象(例如,从纸上转录信息),那么考虑一个表单而不是表格,显示一个列表框数组,每个一个属性.只需单击每个列表框即可设置每个类别,这比使用下拉列表更快.

任务2的窗口可以类似于任务1的标题部分.它与用于任务1的表一致,并允许用户一次查看多个维度的类别,帮助他们找出最佳分类方案(例如,帮助他们找到基本上相同类别出现在两个不同维度的位置).但是,如果空间有问题,则考虑一个维度列表,每个维度都显示主 - 详细信息关系中的类别列表.

任务2的最终用户功能和灵活性是树状控件.树的根级别包括维度,层次结构中的下一步骤包括每个维度内的类别.主要优点是它支持依赖于类别的维度 .例如,可以具有包括诸如Car,Boat,Plane等类别的Vehicle Type维度.对于Car类别,可以具有Body Type维度,其具有仅适用于该类别的类别(Coupe,Hatchback等. ).依赖维度在树中通过分类表示.结果是树在维度和类别之间交替,每个级别在.

重要的是在视觉上区分类别和尺寸,可能是通过不同的图标,也可能是不同的字体 - 告诉用户层次结构中的交替步骤在质量上是不同的(例如,如果你创建了一个Dimension,那么你应该在至少两类).即便如此,如果用户将维度与类别混淆(例如,允许他们将一堆"维度"移动到另一个维度下,将前者转换为类别),则提供一种易于恢复的方法.

我想再次强调人们对维度和类别等抽象的困难.即使他们确实理解它,人们通常很难自己创建体面的维度和类别.有些复杂的交互可能导致您需要思考(例如,当类别移动到新维度时,对象分类会发生什么?).如果您希望每个用户真正创建自己的新颖维度,那么您可能需要认真重新思考整个方法.这是一项固有的复杂任务.

如果在文化,组织或领域(例如我们的汽车)中已经存在相关的多维方案,则用户会做得更好.当然,如果已有方案,那么您可以研究它并将其作为产品中的一组默认维度进行安装.仅需要支持任务2以允许专家用户对其进行微调.