User interface 我应该如何处理过度膨胀的选择框/下拉列表

当项目中的数据量增长时，所有web开发人员都会遇到这个问题，我还没有看到一个明确的、直观的最佳实践来解决这个问题。启动项目时，通常会创建带有标记的表单，以帮助为一对多关系拾取相关对象

例如，我可能有一个邻居系统，每个邻居都属于一个邻居。在应用程序的第1版中，我创建了一个编辑用户表单，该表单有一个用于选择用户的下拉列表，它只列出了我的地理位置有限的应用程序中的5个可能的社区

一开始，这很有效。只要我有100条或更少的记录，我的选择框就会快速加载，而且使用起来相当简单。然而，假设我的申请启动并进入全国范围。我拥有的不是5个街区，而是10000个。突然间，我的小下拉列表需要永远加载，一旦加载，就很难在大量按字母顺序排序的列表中找到你的邻居

现在，在这种特殊情况下，拥有分层数据，并允许用户使用几个动态生成的下拉列表进行深入研究可能会很好。但是，当所选对象/记录本质上不是分层的时，最佳解决方案是什么？在过去，of是通过一个带有搜索框和列表的弹出窗口来完成的，但这看起来很笨重而且过时。在今天的Web2.0世界中，在多个for one表单中找到一个对象的好方法是什么

我曾考虑过使用Ajaxifed搜索框，但它似乎最适合自由文本，当要保存的数据只是对另一个对象或记录的引用时，它会出现一些问题

---

请随意引用具有此问题通用解决方案的特定库，或者简单地以更一般的方式分享您在项目中所做的工作

我认为在这种情况下，自动完成文本框是一种很好的方法。在这里，他们还使用一个自动完成框来标记条目已经存在的位置，即不是自由文本而是选择。（请记住，创建新标签需要声誉！）

---

我个人更喜欢这种方式，因为我打字比用鼠标选择东西快，但我想这是程序员的病：）

自动完成通常是我经验中搜索的最佳解决方案，但只有在用户能够轻松提供文本标记的情况下，作为包含对象的对象名称或分类法的一部分（例如产品类别或邮政编码）

然而，这并不总是有效的，特别是在“浏览”行为更合适的地方——举个真实的例子，我曾经为一个社区网站写过一个页面，允许用户向朋友发送消息。我们在那里使用自动完成，允许多个条目用逗号分隔

当你知道你想要发送信息的人的名字时，它非常有效，但是我们发现在用户接受过程中，大多数人并不知道谁在他们的好友列表中，并且不能很好地使用该页面-因此我们添加了一个带有好友图标的列表弹出窗口，这更成功

---

（这是很久以前的事了-现在每个人都在复制Facebook…

组织大量数据的不同方法：

• 等级制度
• 空间（地理/几何）
• 标记或面

---

搜索大量数据的不同方法：

• 过滤（包括自动完成）
• 排序/分页（按字母排序的数据也可以按第一个字母分页）
• 向下钻取（假设数据按上述方式组织）
• 自由文本搜索

层次结构易于理解且（通常）易于实现。然而，它们可能很难导航并导致歧义。如果您的数据实际上是空间的，或者可以用这种方式表示，那么空间可视化是迄今为止最好的选择；不幸的是，在我们日常处理的数据中，这只适用于不到1%的数据。标签很好，但是——正如我们在这里看到的那样——经常会被误用、误解，或者比预期的效果差

如果您可以以某种相对自然的方式重新组织数据，那么这应该始终是第一步。无论什么东西最能传达自然的秩序，通常都是最好的答案

无论您如何组织数据，最终都需要开始提供搜索功能，并且与数据组织不同，搜索方法往往是正交的——您可以实现多个。过滤和排序/分页是最简单的，如果一个自动完成的文本框或分页列表（网格）可以达到预期的结果，那么就去做吧。如果您需要提供在没有连贯组织的情况下搜索真正海量数据的能力，那么您需要提供完整的文本搜索

---

如果我能给你们指出一些“最佳实践”，我会的，但HID很少如此明确。使用上述选项作为起点，看看它会把你带到哪里。

你能解释一下，当你建立对另一个对象的引用时，ajaxified搜索框会崩溃的原因吗？@MaxGuernseyll-我想“崩溃”有点强。这似乎让事情变得有点笨重。如果是像SO标记这样的情况，数据（可能）保存为文本，但如果我真正想要的数据是id字段，我必须对表单进行额外的查询，以将他们输入的文本与记录id关联起来，并验证他们输入的有效字符串。