关于在 Web 应用程序中处理数据列表选择的建议？
我正在努力寻找更好的实践或推荐的 ui 设计模式来从数据列表（更具体地说，键/值数据）中进行选择。
我的问题是：
- 什么时候应该使用下拉菜单？
- 什么时候应该使用单选按钮列表而不是下拉菜单？
- 什么时候 我应该使用列表框吗？
- 如果允许多项选择，使用复选框列表是否更好？
- 什么是 处理选择的最佳方式 大量数据？
- 允许过滤/选择数据的弹出窗口
- 自动完成文本框（尽管支持键/值的不多）
- 有没有好的网站可以解释数据列表选择的 ui 模式？
当从大量数据中进行选择时，您如何处理？我看到很多仅使用值而不使用键的自动完成指南。
我意识到这可能是主观的，但我确实需要一些关于处理此类数据输入的更好方法的指导。
不管怎样，我正在使用 C# 和 ASP.NET Web 窗体开发我的应用程序。
更新
下面是一个用于选择客户的大型列表的数据示例：
Id Name Address Active
-------------------------------------------------------------------
1 XYZ Company 1234 Main St., Some City, Some State Y
2 ABC Company 1234 Main St., Some City, Some State N
3 RST Company 1234 Main St., Some City, Some State Y
有时我的客户希望看到更多信息，而不仅仅是值字段，在本例中为“名称”（这是相关文本框中将显示什么）。
I am struggling with what the better practices or recommended ui design patterns are for making selections from a list of data, more specifically, key/value data.
My questions are:
- When should I use a drop down?
- When should you employ a list of radio buttons verses a drop down?
- When
should I use a list box?- If you do allow for multiple selection, is it better to use a list of check boxes?
- What is the
best way to handle selection from a
large list of data?- Pop-up windows that allow filtering/selecting the data
- Autocomplete text boxes (though not many support key/value)
- Are there any good websites that explain ui pattern for data list selection?
When selecting from a large list of data, how are you handling this? I see lots of guidance for autocompletion using just values, but no keys.
I realized this may be subjective, but I really need some guidance on the better ways to handle this type of data entry.
For what it's worth, I am developing my application in C# and ASP.NET Web Forms.
Update
Here is an example of what the data might look like for a large list, for selecting customers:
Id Name Address Active
-------------------------------------------------------------------
1 XYZ Company 1234 Main St., Some City, Some State Y
2 ABC Company 1234 Main St., Some City, Some State N
3 RST Company 1234 Main St., Some City, Some State Y
Sometimes my customer wants to see more information, than just the value field, in this case Name (this is what would be displayed in the related text box).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
单选按钮：当只有几个选项 (<10) 并且您只选择一个时，请使用它们。
复选框列表：几个选项（<10），您需要选择多个。
列表：另一种允许多重选择的可能性。
列表/下拉列表：从长列表中选择一个元素。
双列表：从一个长列表中选择单个元素，然后单击“选择”按钮将所选项目转移到第二个列表中。第二个列表将为您提供选择的概述。
自动建议：从极长的列表（数千个）中选择一个元素。
Radio buttons: Use them when there are a few options only (<10) and you only select one.
Checkbox list: A few options (<10) and you need to select many.
Lists: Another possibility to allow multiple selection.
List/Dropdownlist: Select one element from a long list.
Double lists: Select a single element from one long list and then click a button "select" to transfer selected item into the second list. The second list will give you an overview of selection.
Auto-suggestion: Select one element from an extremely long list (thousands).
我会仔细研究 Gmail 如何处理列表。
本质上，电子邮件就是处理项目列表。 Gmail 可以轻松移动、复制、删除和操作这些项目。
I would look closely at how Gmail deals with lists.
In essence, email is all about dealing with lists of items. Gmail makes it easy to move, copy delete and action these items.
花一点时间看看 Remember the Milk（这是一个在线待办事项列表）如何管理列表选择。
Take a minute of your time and see how Remember the Milk (it's an online to do list) manages lists selections.
为了回答您的具体想法，公认的智慧是，对于少数数据元素，使用带有单选按钮的完整列表；当元素很少时使用复选框进行多重选择，当元素较多时使用多选列表（在多选列表中选择更容易）
对于过滤/自动完成，这是一个非常好的工具，用于大型数据集，但精确的形式取决于以下问题的答案：
每个键有 1 个值吗？ >=每个键 1 个值？ 1/许多键值对，其中整个键值对被视为原子数据？
有很多钥匙吗？每个值有多个键？
To answer your specific ideas, the established wisdom is that for few data elements, use a full list with radio buttons for single selects; check-boxes for multiple selects when there are few elements and multi-select lists when there are more than a few elements (it's easier to select in multi-select list)
For filtering/auto completion, it's a VERY good diea to use for large data sets but the precise form would depend on the answers to the following questions:
Is it 1 value per each key? >=1 value per each key? 1/many key-value pairs where entire key-value pair is taken as an atomic datum?
Are there many keys? Many keys per value?