替代大型数据集的单个<select multiple ="multiple">元素

Question

我经常在如何在我的应用程序中解决这个问题时发生冲突.我使用了许多选项,包括:

• 通用的多选 - 这是我最不喜欢和最少使用的选项.我发现可用性是残酷的,简单的误点击会搞砸你所有的努力工作.
• 一个"自动完成"解决方案 - 缺点:用户必须具有拼写能力才能找到他们需要的该死的值,不会暴露于他们可能没有想到的值,以及子串搜索的潜在后端性能.
• 两个相邻的多重选择,带有一个添加/删除按钮 - 下行:仍然是"丑陋"的imo
• 任何数量的花式JavaScript的解决方案(http://livepipe.net/control/selectmultiple,http://loopj.com/2009/04/25/jquery-plugin-tokenizing-autocomplete-text-entry/等)

我没有找到任何关于解决这个问题的最佳方法的可用性研究.当你从<10个元素到100个元素时,这些替代解决方案中的许多都是很好的,但是当你从一百个到一千个时,可能会彻底崩溃.

你们用的是什么？你为什么用它？你能指点我的可用性案例研究吗？是否有一个尚未被发现的"神奇"解决方案？

Answer 1

我的建议是不要使用通用的多选控件.我在整个职业生涯中一直在运行用户体验研究,每次我用多个选择控件测试网站时,它总是会给最终用户带来问题.

我在前一段时间做了一个帖子:多个选择控件必须进化或死亡

听起来你无论如何都知道这一点.你真正的问题是"我该用什么呢？" 那么,要回答这个问题,你必须弄清楚用户的任务是否倾向于 召回或识别.

(i)通过召回,我的意思是用户在看到列表之前就知道他们想要选择什么.在这种情况下,如果您提供自动完成工具(例如在Facebook上非常有效地使用),对他们来说可能是最简单的.当选项列表在页面上显示的时间也不可能很长时(例如位置名称等),此解决方案甚至更好.

(ii)继续承认 - 这意味着一项任务涉及用户在看到选项列表之前不知道他们想要选择什么.在这种情况下,自动完成不会给他们任何提示.一系列复选框会更有帮助.如果您可以一次显示所有内容,这对用户很有帮助.滚动DIV更紧凑,但它们为用户创建了内存负载 - 即,一旦他们向下滚动,他们必须记住他们选择了哪些项目.当用户保存表单并稍后再返回时,这一点尤其明显.

那么 - 考虑一下你的问题,你需要一个召回或认可的解决方案吗？