最优雅的项目分类 UI？
我有一个项目集合，用户需要以多种方式对这些项目进行分组/分类。 举个例子，假设它是汽车的集合，用户希望按以下方式对它们进行分类：
- 颜色（红色、银色、蓝色、黑色等）
- 车身形状（掀背车、轿车、轿跑车、旅行车、等）
- 座位（2、4、5、6 等）
- 等。
您是否遇到过一种特别优雅的方法，允许用户完全自由地定义自己的类别和值？
显然，任何设计都需要做出许多权衡。 例如，可学习的设计可能效率不高，反之亦然。 或者某些设计可能比其他设计对空间的要求更高。 其中一些的开发时间比其他的要长得多。
无论如何，如果您已经看到或设计了一个好的模式，我很想听听。 如果有截图就更好了。
尝试澄清：标签确实是一种很好的分类方式，但在我见过的所有实现中，只有一个级别的标签。 用户通常不会定义类别/属性以及该类别中的项目值。。 要使用上面的示例和 StackOverflow 的标记，您可以将汽车标记为“蓝色”、“轿车”、“4”等。 StackOverflow 不会固有地知道某个项目不能同时标记为“轿车”和“轿跑车”。
我正在考虑的界面需要知道这类事情，因此用户定义的属性建议更符合我的想法。 我只是渴望找到一个具体的例子来说明如何优雅地实现这种系统（在桌面应用程序中，如果这有影响的话）。
这样是不是更清楚了？ 如果没有，请发表评论，我会再次尝试澄清。 :)
I have a collection of items that the user needs to group/categorize in several ways. For the sake of an example, let's say it's a collection of cars and the user wants to categorize them in the following ways:
- Color (red, silver, blue, black, etc.)
- Body shape (hatch, sedan, coupe, stationwagon, etc.)
- Seats (2, 4, 5, 6, etc.)
- etc.
Have you ever come across a particularly elegant way of doing this that allows the user full freedom to define their own categories and values?
Obviously, there will many be trade-offs to make in any design. For example, a learnable design might not be efficient, and vice versa. Or some designs may be more demanding of real estate than others. And some will take significantly longer to develop than others.
Regardless, if you've seen -- or designed -- a good pattern for this, I'd be interested to hear about it. If you have screenshots, all the better.
Attempt at clarification: tags are indeed a great way of categorizing things, but in all implmentations I've seen, there's only ever one level of tagging. The user doesn't generally get to define a category/property and the item's value in that category. To use the example above and StackOverflow's tagging, you'd tag a car as "blue", "sedan", "4", and so on. StackOverflow would have no inherent knowledge that an item couldn't be tagged as both "sedan" and "coupe".
The interface I'm thinking of would need to know that kind of thing, so the user-defined attributes suggestion is more along the lines of what I'm thinking. I'm just keen to find a concrete example of how that kind of system could be elegantly implemented (in a desktop app, if that makes a difference).
Is that any clearer? If not, leave a comment and I'll try to clarify again. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
听起来您有两个任务： 任务 1 对对象进行分类，对于一系列对象，用户在多个维度（属性）的每个维度上为每个对象分配一个类别（值）。 任务 2：创建和修改维度和类别。
在数据建模者、面向对象程序员和数据库设计者之外，维度和类别的概念是一个很难掌握的概念。 您应该为用户不理解类别和维度之间的差异做好准备。 但是，用户通常会理解表格，其中每一列都是一个维度（包含多个类别），每一行都是一个对象。 尽可能使用表格。
第一个关键问题是通过用户研究弄清楚任务1和任务2是整合还是分离的程度。
如果任务是集成的，用户经常不假思索地从一个任务切换到另一个任务，那么一种 UI 设计就是有一个按维度的对象表，但提供一个空白列（或“插入”按钮）以允许用户添加维度。 列标题具有用户可以编辑的维度名称。 标题下方的空间列出了该维度的类别。 每个类别名称都是可编辑的，并且有一个空行（或“插入”按钮）用于添加新类别。 下面是要分类的对象，每个对象的每列中都有一个维度下拉列表。
在可用性测试中，请注意用户尝试通过单击类别列表中的类别而不是从下拉列表中选择来设置对象的类别。 使类别列表在视觉上分开显示以防止这种情况发生。
您可能需要一个按钮来隐藏/显示类别列表，因为这可能会占用大量空间（即使使用滚动条）。 即使任务 1 和 2 紧密集成，我认为您会发现用户有时可能希望将类别列表移开。
如果您发现任务 1 和 2 是分开的，很少一起完成（例如，用户通常设置其维度，然后对一堆对象进行分类），那么您最好为每个任务使用单独的窗口（或页面），尽管在它们之间来回导航应该很容易。 例如，虽然用户通常可能会事先设置其维度，然后很少修改它们，但有时用户会意识到在对不寻常的对象进行分类时需要一个新的维度类别，因此您提供了一个“添加类别”菜单项，该菜单项可以让用户到“管理类别”窗口，其中为当前维度插入了一个新类别，等待用户提供名称。
任务 1 的窗口与以前相同：对象表，每个维度都有一列下拉列表，但不包括类别列表、维度名称的编辑以及添加新维度的能力。 如果用户需要扫描需要分类或重新分类的对象，或者如果用户通常需要将一个对象与其他一些对象进行比较（例如，决定如何对对象进行分类），则这是最有效的。 然而，如果用户的任务确实仅限于根据外部信息一次对一个对象进行分类（例如，抄写纸上的信息），那么请考虑使用表格而不是表格来显示数组列表框，每个属性一个。 只需单击每个列表框即可设置每个类别，这比使用下拉列表更快。
任务 2 的窗口可能类似于任务 1 的标题部分。 它与任务 1 所用的表格一致，允许用户同时查看多个维度的类别，帮助他们找出最佳的分类方案（例如，帮助他们找到本质上相同的类别出现在两个不同维度中的位置）。 然而，如果空间是一个问题，那么请考虑一个维度列表，每个维度都显示主从关系中的类别列表。
任务 2 的最终用户功能和灵活性是树状控件。 树的根级别包括维度，层次结构中的下一步包括每个维度内的类别。 主要优点是它支持依赖类别的维度。 例如，可能有一个车辆类型维度，其中包括汽车、船、飞机等类别。对于汽车类别，可能有一个车身类型维度，其中的类别仅适用于该类别（轿跑车、掀背车等）。 ）。 从属维度在树中由类别的分支表示。 结果是树在每个级别的维度和类别之间交替。
在视觉上区分类别和维度非常重要，可能通过不同的图标，也可能通过不同的字体 - 告诉用户层次结构中的交替步骤是定性的不同（例如，如果您创建一个维度，那么您应该至少创建两个类别）。 即便如此，如果用户混淆维度和类别，请提供一种轻松恢复的方法（例如，允许他们将一堆“维度”移动到另一个维度下，将前者转换为类别）。
我想再次强调人们在维度和类别等抽象概念上遇到的困难。 即使人们确实理解了这一点，通常也很难自己创建合适的维度和类别。 您需要仔细考虑可能会导致复杂的交互（例如，当类别移动到新维度时，对象分类会发生什么情况？）。 如果您期望每个用户真正创建自己的新颖维度，那么您可能需要认真重新思考您的整个方法。 这是一项本质上复杂的任务。
如果文化、组织或领域中已经存在相关的多维方案（例如我们针对汽车的方案），用户会做得更好。 当然，如果已经有一个方案，那么您可以研究它并将其安装为产品中的默认尺寸集。 任务2只需要支持以允许专家用户对其进行微调。
It sounds like you have two tasks: Task 1 Categorize Objects, where for a series of objects, the user assigns each a category (value) on each of multiple dimensions (attributes). Task 2: Create and Modify Dimension and Categories.
Outside of data modelers, object-oriented programmers, and database designers, the idea of dimensions and categories is a very hard concept to grasp. You should be prepared for users not understanding the difference between categories and dimensions. However, users generally will understand tables, where each column is a dimension (that comprises several categories) and each row is an object. As much as possible, work with tables.
The first key question is to figure out through user research is the degree Task 1 and 2 are integrated or separate.
If the tasks are integrated, with users often switching fluidly from one to the other without much thought, then one UI design is to have a objects-by-dimension table, but provide a blank column (or an “Insert” button) to allow the user to add a dimension. The column header has the dimension name, which the user can edit. Under the header is a space listing the categories of that dimension. Each category name is editable and there is a blank line (or the Insert button) to add a new category. Below that are the objects to categorize, each with a dropdown list in each column for dimension.
In usability testing, watch out for users trying to set an object’s category by clicking on a category in the category list, rather than selecting from the dropdown list. Make the category list appear visually separate to prevent this.
You may want a button to hide/show the category lists, as this can take a lot of space (even when using scrollbars). Even if Task 1 and 2 are tightly integrated, I think you’ll find users may want to get the category lists out of the way sometimes.
If you find that Task 1 and 2 are separate, rarely being done together (e.g., users typically set up their dimensions then categorize a bunch of objects), then you’re better off with a separate window (or page) for each task, although it should be easy to navigate back and forth between them. For example, while users may typically set up their dimensions beforehand then rarely modify them, sometimes a user will realized one needs a new category for a dimension while categorizing an unusual object, so you provide a “Add category” menu item that takes the user to the Manage Categories window, with a new category inserted for the current dimension awaiting the user to provide a name.
The window for Task 1 is the same as before: table of objects with a column of dropdown lists for each dimension, but exclude the category lists, the editing of the dimension names, and the capacity to add a new dimension. This is most efficient if the user needs to scan for objects needing categorizing or re-categorizing, or if typically the user needs to compare one object against some others (e.g., to decide how to categorize the object). However, if the user’s task is truly limited to just categorizing an object one at a time based on outside information (e.g., transcribing information from paper), then consider a form rather than a table, showing an array of list boxes, one for each attribute. With a single click of each list box to set each category, this is faster than using dropdown lists.
The window for Task 2 could be like the header portion for task one. It is consistent with the table used for Task 1 and allows users to see categories for multiple dimensions at once, helping them figure out the best categorization scheme (e.g., help them find where essentially the same category appears in two different dimensions). If space is a problem, however, then consider a list of dimensions each showing a list of categories in a master-detail relation.
The ultimate in user power and flexibility for Task 2 is a tree-like control. The root level of the tree comprises dimensions and the next step in the hierarchy comprises the categories within each dimension. The main advantage is that it supports dimensions being dependent on categories. For example, one may have a Vehicle Type dimension that includes categories like Car, Boat, Plane, etc. For the Car category, one may then have a Body Type dimension with categories that only apply to that category (Coupe, Hatchback, etc.). Dependent dimensions are represented in the tree by branches off a category. The result is the tree alternates between dimensions and categories with each level in.
It’s important to visually distinguish the categories from the dimensions, perhaps by different icons, and maybe different font as well –something to tell users that alternating steps in the hierarchy are qualitatively different (e.g., if you create a Dimension, then you should create at least two categories). Even then, provide a means of easy recovery if users confuse dimensions with categories (e.g., allow them to move a bunch of “dimensions” to under another dimension, converting the former into categories).
I want to emphasize again the difficulty people have with abstractions like dimensions and categories. Even when they do understand it, people generally have great difficulty creating decent dimensions and categories on their own. There are complicated interactions that can result that you need to think through (e.g., what happens to object categorization when a category is moved to a new dimension?). If you are expecting each user to truly create their own novel dimensions, then you may want to seriously re-think your whole approach. It is an inherently complicated task.
User do much better if there’s already a relevant multi-dimensional scheme in the culture, organization, or domain (such as we have for cars). Of course, if there already is a scheme, then you can research it and install it as a default set of dimensions in your product. Task 2 only needs to be supported to allow expert users to fine-tune it.
您可以使用标签：让用户标记每个图像，然后显示一组按标签排序的图像缩略图。
也许比标签更高级的是一组用户定义的属性。 例如，不要用“红色”标记图片，而是用属性“color=red”标记它。
You could use tags: Have the user tag each image, then show a set of image thumbnails sorted by tags.
Maybe more advanced than tags would be a set of user-defined attributes. For example, instead of tagging a picture with "red", tag it with an attribute "color=red".
我建议使用类似于 stackoverflow 上的标记系统。 允许他们标记图像，然后按标记或选项卡组合进行查看。 查看页面时，显示图像的缩略图及其下方该图像的标签。
编辑：根据您的说明，您可以拥有标签类型。 当用户定义自己的标签时，他们需要指定它派生的类型。 考虑到这一点，您需要将标签限制为仅该类型之一。
当用户想要添加图像标签时，请为他们提供带有 TagType 的下拉菜单。 下面给出了另一个带有 TabSubTypes 的下拉菜单。 给他们一个“定义新类型”的选项，这将导致出现一个文本框，他们可以在其中输入新类型。
我还将这些选项添加到上下文菜单中，以便用户可以在树形菜单中查看标签。
即使图像聚焦时，您也可以抓住按键，查找 TagType 和 TagSubType 名称并显示可供选择的选项菜单。 如果未找到匹配项，请提供“单击添加新标签”选项。
I'd suggest a tagging system similar to the one here on stackoverflow. Allow them to tag the images, then view by tag, or combination of tabs. When viewing the page, show thumbnails of the images and the tags for that image below it.
Edit: Based on your clarifications you could have types of tags. When the user defines their own tag, they would need to specify which type it derivies from. With that in mind, you would need limit tags to only one of that type.
When a user wants to add tag an image give them a drop down with the TagType. Below that give then another drop down with the TabSubTypes. Give them an option to "Define New" which will cause a textbox to appear where they can type in a new type.
I'd also add these options to the context menu so users can view the tags in a tree style menu.
You could also grab the keypress even when an image is focused, look up the TagType and TagSubType name and present a menu of options to choose from. If no matches are found, offer a "Click to add new tag" option.
分面分类是一种对未得到应有关注的事物进行分类的方法。 它允许您定义互斥的类别，并为每个类别的每个内容项提供一个值。 例如，您可以按地区、品种、年份和价格对葡萄酒进行分类，用户可以通过在一个或多个类别中选择一个或多个值来进行搜索。 例如，“40 美元以下的法国或意大利红葡萄酒”。 假设您手头有类别数据，这通常是可用的最强大的分类和搜索技术，比尝试将所有内容放入单个层次结构或依赖标签更好。
要在后端实现此功能，请为每个类别创建表格并用不同的值填充它们。 然后创建一个表，其中每个类别表都有一个外键，以及一个包含内容的字段。 这类似于维度数据库设计中的“事实”表。
要了解它如何在 UI 中工作，请查看 Facetmap。 我不能保证他们的产品，因为我没有使用过它，但我已经为我自己的应用程序实现了类似的东西，并取得了良好的结果。
http://www.facetmap.com/
再次强调，分面分类背后的思想值得更多关注，我我知道我在这里没有公正地对待他们。 要了解 Clay Shirky 对这个主题的有趣处理，请收听“本体论被高估了”：
http:// /itc.conversationsnetwork.org/shows/detail470.html
Faceted Classification is a way to categorize things that doesn't get the attention it deserves. It allows you to define mutually exclusive categories and provide a value for each content item for each category. For example, you could classify wines by region, varietal, vintage and price, and a user would conduct their search by picking one or more values in one or more categories. For example, “French or Italian reds under $40”. Assuming you have the category data at hand, this is often the most powerful classification and search technique available, better than trying to fit everything into a single hierarchy or relying on tags.
To implement this on the backend, make tables for each category and fill them with the distinct values. Then make a table what has a foreign key to each category table, together with a field that contains the content. This is similar to a “fact” table in dimensional database design.
To get an idea how this can works in the UI, take a look at Facetmap. I can’t vouch for their product because I haven’t used it, but I’ve implemented something similar for my own applications with good results.
http://www.facetmap.com/
Again, the ideas behind faceted classification deserve more attention, and I know I'm not doing them justice here. For an entertaining treatment of the subject by Clay Shirky, listen to "Ontology is Overrated":
http://itc.conversationsnetwork.org/shows/detail470.html
我可能会误解你的问题，但如果不完全是标签的用途（如堆栈溢出和 gmail 中），那不是非常相似吗？ 或者您正在寻找比这更具体的东西？
I may be misunderstanding you question, but isn't that very similar if not exactly what tags are for (as in stack overflow and gmail). Or are you looking for something more specific than that?
好吧，我倾向于继续谈论这个太多，但标记只是您可以使用三重图执行的操作的一个示例，例如使用 RDF。 [插入维基百科链接]。 现在我知道你说过，根据嵌套的要求，标签是不够的，但没有理由你不能进一步将“标签标签”作为彼此的子代。
通过这种方式，您的数据仍然非常灵活，并且数据和元数据之间的界限实际上变得模糊。
Ok, well, I tend to go on about this too much, but Tagging is just an example of what you can do with a triple graph, eg using RDF. [Insert Link To Wikipedia]. Now I know you said that tags are not enough, based on requirements for nesting, but there is no reason you cannot further "tag tags" as children of eachother.
This way your data remains ultra-flexible, and really the divide between what is data, and what is metadata becomes blurred.
这似乎是一个需要解决的问题，特别是让用户将维度数据分类为更进一步、更简化的维度（组或类别，无论你如何称呼它们），以便他们可以通过简化的类别/维度更好地可视化数据。
用户需要能够导入列表，并为列表创建维度，然后根据这些维度直观地对列表进行分类。 创建维度将包括命名/重命名维度（列名称），然后添加/重命名/删除该维度的类别（列项目）。 在创建新维度和使用用户创建的新维度单独或批量对列表项进行实际分类之间应该是无缝切换的。 然后，用户可以导出包含新创建类别的附加列（维度）的列表。
这个想法是，与仅拥有一个表并向其中添加列相比，它会更加用户友好。 理想情况下，您可以选择列表中的项目，然后从用户创建的维度列表中为它们分配一个经过验证的类别项目，该列表将自动填充可导出的只读表。 输入=列表，输出=综合分类列表。 不需要电子表格。
It seems like an issue that needs to be addressed especially for having users classify dimensional data into further, more simplified, dimensions (groups or categories whatever you want to call them) so that they can visualize the data better via the simplified categories/dimensions.
The user needs to be able to import a list, and both create dimensions for the list and then categorize the list intuitively based on those dimensions. Creating the dimensions would consist of naming/renaming the dimension (name of column) and then adding/renaming/removing the categories (column items) of that dimension. It should be seamless to switch between creating new dimensions and actually categorizing the list items individually or in bulk using the new dimensions created by the user. The user could then export the list with the additional column or columns (dimensions) containing the newly created categories.
The idea is that it would be much more user friendly that just having a table and adding columns to it. Ideally you would be able to select items in the list, and then assign them a validated category item from the user created dimension list which would auto-populate a read-only table that could be exported. Input = list, Output = comprehensively categorized list. No spreadsheet required.