当前位置：文江博客话题详情

将数据输入网格

发布于 2024-07-23 11:04:03 字数 1934 浏览 9 评论 0原文

一个用户界面问题：对于将数据输入网格的最佳方式（定义为“最终用户最喜欢的方式”）或最不糟糕的方式是否存在一些共识？

我有一个网格，有很多行。网格的列包含用户可以输入/编辑的各种类型的属性。属性的“类型”包括：

自由文本
数字（数字）
枚举值（例如“高”、“中”和“低”之一）
其他（例如日期、持续时间）

“自由文本”类型不是很难设计（所以我不会问这个），但是接下来的两种类型呢？

数字

当使用键盘输入数字时，您是否允许自由文本输入，然后在模糊时运行验证方法？或者，监视每个按键以将数据输入限制为仅数字？
如何告诉用户（在网格上，而不是在表单上）某些列中数据的语法仅限于数字？如果用户按了错误的（非数字）键，您该怎么办？
“旋转”或“旋转器”控件是标准 Windows 控件；尝试在基于 HTML 的网格上使用它是否合适？

枚举值

对于使用鼠标输入或编辑枚举值，我猜想在单击鼠标时弹出一个小上下文菜单就是要做的事情。

另一种方法是使用
当焦点因键盘（即 [Tab] 键）而不是鼠标（即单击）而改变时，您还会在焦点上弹出相同的菜单吗？换句话说，按 Tab 键切换到字段是否会导致弹出菜单？顺便说一句，我见过的基于 CSS 的弹出菜单响应鼠标，但不响应键盘（例如，[向上] 和 [向下] 箭头键）。您是否知道任何可以在浏览器中运行的类似 Intellisense 的数据输入实现？

例如？

我也有兴趣看到您认为是示例的任何内容。我对桌面用户界面和/或浏览器内的答案感兴趣。

编辑：按照[data-entry]标签的另一个问题（“有人使用过Sigma Grid（基于Javascript的可编辑数据网格）吗？")，我正在查看 Sigma Grid 示例。在我看来，它在很多方面都做得很好（对键盘和即时选择框的良好支持）；但它对数字字段的支持可能不完善，例如，如果我在数字单元格中按“a”，那么有时它会弹出一个警告框，告诉我我错了（也许工具提示的干扰性较小），和/或有时它会将单元格留空（空白），擦除“a”并且不留下任何内容。

编辑回复以下答案之一。

但是，再次确定表单的主要用途是什么，并对此进行优化。数据可视化或分析与批量录入有着不同的需求，满足键盘用户与键盘+鼠标用户完全不同。

我希望相同的显示（即表格/网格）能够很好地显示现有属性、创建新属性和编辑现有属性。我期望有几十个项目（即几十行数据），每个项目只有几列（例如一列文本/项目描述，加上 1 列或多列用于 1 个或多个关联项目属性）。

一些数据/属性可能是主观的和相对的（例如，每个项目的两个属性是每个项目的“优先级”或“难度”，只有与其他项目相比才特别有意义），这就是我想要的原因将所有数据一起显示在一个屏幕上：以便最终用户可以比较它们。

我的应用程序适用于相对专业（而不是新手）的计算机用户，但不是数据输入专家：例如，用户是软件开发人员、项目经理、产品经理、质量检查人员等，但在某种程度上也是他们的客户；它在内部网（而不是公共互联网）上运行，尽管如此，易于使用和易于学习和/或直观都很重要。

另外，我不明白为什么满足键盘用户与键盘+鼠标用户完全不同：我认为单个解决方案可以/应该支持其中一个和/或两者。

原文

A UI question: is there some consensus on the best (defined as "the one which end-users like best") or least-bad way to implement data entry into a grid?

I have a grid, with many rows. The grid's columns contain various types of properties, which the user can enter/edit. The "types" of properties include:

Free text
Numbers (numeric digits)
Enum value (e.g. one of 'High', 'Medium', and 'Low')
Others (e.g. date, duration)

The 'free text' type isn't difficult to design (so I won't ask about that), but what about the next two types?

Numeric digits

When using a keyboard to enter a number, would you allow free-text entry, and then run a validate method on blur? Or, monitor each key-press to restrict the data entry to digits only?
How do you tell the user (on a grid, not on a form) that the syntax of the data in some column is restricted to numeric-only? What do you do if the user presses a wrong (non-numeric) key?
A 'spin' or 'spinner' control is a standard Windows control; is it appropriate to try to use one on a HTML-based grid as well?

Enum values

For entering or editing an enum value using the mouse, I guess that popping a little context menu on a mouse click is the thing to do.

An alternative is to use the <select> input control (i.e. a combo box). I guess though that having a whole column-ful of combo boxes isn't as easy to read as having a column of text value (because the combo boxes add extra non-text ink)? What do you think of usually displaying plain text, but replacing that text with a combo box when the field gets the input focus (and then removing the combo box on blur)?
Would you also pop that same menu on focus, when the focus changes as a result of the keyboard (i.e. the [Tab] key) instead of a result of the mouse (i.e. a click)? In other words, should tabbing to a field result in a popup menu? Incidentally, the CSS-based popup menus that I've seen respond to the mouse but not to the keyboard (e.g. to the [Up] and [Down] arrow keys). Do you know of any Intellisense-like data entry implementation that can run in a browser?

For example?

I'd also be interested in seeing anything you think is an exemplary example. I'm interested in desktop UI and/or in-browser answers.

Edit: following another question with the [data-entry] tag ("Has anyone used Sigma Grid (Javascript-based editable data grid)?"), I'm looking at the Sigma Grid example. It does a lot of things well IMO (good support for the keyboard and just-in-time selection boxes); but its support for numeric fields may be imperfect, for example if I press 'a' in a numeric cell, then sometimes it pops an alert box to tell me I'm wrong (where maybe a tool-tip would be less intrusive), and/or sometimes it leaves the cell empty (blank), erasing the 'a' and leaving nothing in place.

Edit in reply to one of of the answers below.

Again, however, determine WHAT the primary use of your form is going to be, and optimize for that. Data visualization or analysis has different needs than bulk entry, and satisfying keyboard users is completely different than keyboard+mouse users.

I want the same display (i.e. a table/grid) to work well for displaying existing properties, creating new properties, and editing existing properties. I expect dozens of items (i.e. dozens of rows of data), each with only a few columns (e.g. one column of text/item description, plus 1 or more columns for 1 or more associated item properties).

Some of the data/properties may be subjective and relative (e.g. two properties for each item are the 'priority' or 'difficulty' of each item, which is especially meaningful only when compared with other items), which is a reason why I want to display all data together on one screen: so that the end-user can compare them.

My application is for relatively expert (not novice) computer users, but not data-entry specialists: e.g. the users are software developers, project managers, product managers, QA people, etc., but also to some extent their customers; it's running on an intranet (not public internet), nevertheless easy-and-a-pleasure-to-use and easy-and/or-intuitive-to-learn are both important.

Also I don't see why satisfying keyboard users is completely different than keyboard+mouse users: I thought that a single solution could/should support either and/or both.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不语却知心 2024-07-30 11:04:03

恕我直言，您需要问的一个大问题是页面的主要目的以及用户的相对复杂程度。您是否正在与 Tab+10 键专业人士、鼠标点击+狩猎打字员打交道，或者两者兼而有之？

您做出的选择需要考虑到这一点。我假设通过选择网格，您的用户是从底部向上迈出的一步，并使用选项卡导航作为导航表单的主要方式，并且主要用途是批量数据输入。

关于数字输入：

如果您计划提供转换例程，则无需限制为数字。
如果用户输入无效输入（请注意，某些数字，而不仅仅是文本可能无效......例如，负年龄），您最好立即内联显示错误。
避免使用旋转器，尤其是在处理带小数的数字时。旋转器将焦点从数据输入上移开，并提供最小的价值，除非您处理的是一组有限的离散数字。如果是这种情况，组合/选择可能会更好（我将在下一篇文章中详细说明原因）。

关于枚举值：

像瘟疫一样避免弹出窗口/上下文菜单。它们要求用户使用鼠标并将焦点从当前任务上移开，毫不夸张地说，当您生成一个新窗口时。组合/选择允许用户进行一定程度的提前输入，并允许通过箭头进行键盘选择。
您提出的组合框问题（下拉箭头使文本难以阅读）可以通过您提供的焦点解决方案来缓解，但是，通常可以通过在行和列之间添加更多填充来使网格更具可读性。

额外评论：

如果可能的话，用文字说明带有转化的日期。除非你计划培训你的用户，或者选择采用一些严厉的屏蔽系统（以及同样令人恼火的验证失败的惩罚），否则他们应该被允许输入他们想要的日期。 请注意如果您与国际人士打交道，他们输入的月份和日期会有所不同。美国的 SOP 以 mm/dd/yyyy 为单位，而许多国家/地区更喜欢 dd/mm/yyyy。
如果您有大量字段，您可能需要考虑将数据输入分成多行。平面网格> 10 列在单一视图中很难理解。这样做的缺点是增加了垂直滚动，因此您必须在一方面解释当前编辑数据行时使用数据上下文（例如上面的行和下面的行）的重要性与获取所有一行的信息（多行或水平滚动）在另一行上。

不过，请再次确定表单的主要用途是什么，并对此进行优化。数据可视化或分析与批量输入有不同的需求，满足键盘用户与键盘+鼠标用户完全不同。

编辑：回复评论

我也不明白为什么令人满意
键盘用户完全不同
比键盘+鼠标用户：我认为
单一解决方案可以/应该
支持其中之一和/或两者。

这并不完全不同。将其视为“优化”和“支持”大部分用户之间的区别。举几个例子：代码编辑器针对键盘用户进行了优化。在热键、快捷方式和键盘导航之间，用户很少需要使用鼠标。大多数 RTS 游戏都是使用单手操作鼠标、另一只手操作键盘的方式进行操作。它们通常支持专门使用鼠标，但并未为此优化。 ITunes 则处于另一个极端——它几乎完全依赖鼠标（就像大多数以拖放为主的 UI 一样），仅使用键盘几乎是不可能的。

您是否允许该条目并显示
错误; 或阻止进入并
显示错误？你是什么意思
当它是网格时将其显示为“内联”
（表格内某处的单元格）？

我不确定你正在哪个平台上构建，但是是的，我的意思是表内的某个地方，最好是在你正在谈论的数据行上。在 ASP.NET 的 GridView 中，允许使用 TemplateFields，它允许您将多个控件嵌入到同一个“单元格”中。在富客户端世界中，大多数第 3 方组件都提供对类似 OOTB 的支持（例如 IDataErrorInfo），这会在上下文中提供错误。

如果替代方案是将所有错误放在网格上方或下方，则用户将很难找出数十行数据中的哪一行存在错误。有关对此进行次优处理的示例，请尝试将 10 件商品添加到亚马逊购物车，然后将所有金额更改为 2，但 1 件商品除外，您将其更改为 -1。点击更新并查看是否可以轻松导航到有错误的行。

此外，验证风格的“流行”风格是允许用户输入数据并在数据不正确时向他们发送消息，不会阻止输入和/或删除他们的输入。 StackOverflow 在很多地方都这样做，最容易通过添加评论来证明。验证会通知您至少需要 15 个字符，但在通知您时不会删除您的评论。紧随其后的第二个方法是让用户立即明确知道他们的输入不正确。一个例子是尝试在 Windows 中重命名带有反斜杠的文件。您会立即看到一个带有精确说明的气球。

嗯，智能感知或自动完成
是一种弹出窗口，但它可以是
使用操作（不占用焦点
远离）键盘。

如果您可以像 Visual Studio 中的 Intellisense 一样干净地支持弹出窗口，我会说那就去吧。我对弹出窗口的非 VS 经验是，大多数尝试都失败了（有些非常可怕，要求我拿起鼠标并重新聚焦到正确的位置）。使用 Intellisense 需要记住的另一件事是，它具有出色的语句结束处理（我的意思是与您键入的单词的交互 + 前瞻 + 拼写/大小写宽恕 + tab/enter 处理）。由于我假设您正在使用选项卡在字段之间导航（请注意，VS 没有字段），您将不得不找出另一种方法来让您的应用程序知道“我现在完成了，转到自动” -完整/智能感知我刚刚输入的内容”

我以为组合框的
文本周围的框架使文本
较难快速阅读；也许一些
最小组合框，带有向下箭头
但组合框周围没有框架
（只是表格单元格的边框）
对于不这样做的细胞来说会更好
有焦点：虽然我想知道为什么
甚至向下箭头也可能有用
没有焦点的单元格。

如果您担心 ComboBox 的框架，我完全同意 - 将框架颜色更改为对比度较低的颜色。任何在未聚焦时最小化控件“chrome”的解决方案显然都会使其更像文本，并且（可能？）更具可读性。

无论如何，祝您的设计好运。

IMHO, the big question you need to ask is the primary purpose of your page and the relative sophistication of your users. Are you dealing with Tab+10 key pros, mouse-click + hunt-peck typists, a little bit of both?

The choices you make need to take this into account. I'm assuming by virtue of choosing a grid, your users are a step up from the bottom, and use tab-navigation as a primary means of navigating your form, and the primary use is bulk data entry.

Regarding numeric input:

If you're planning on providing a conversion routine, there's no need to restrict to digits.
In the case where a user enters invalid input (note that some numbers, not just text may be invalid... for instance, negative age) you're better off showing the error inline and immediately.
Avoid spinners, particularly if you're dealing with numbers with decimals. Spinners take focus away from data-entry and provide minimal value unless you're dealing w/a finite set of discrete numbers. If this is the case, a Combo/Select may be better (I'll detail why in the next post).

Regarding enum values:

Avoid popups/context menus like the plague. They require the user to use the mouse and take focus away from the current task, quite literally when you spawn a new window. A Combo/Select allows the users some degree of type-ahead, and allows for keyboard selection via arrows.
The combo box issue you bring up (the drop arrow making the text harder to read) is something you can alleviate with the focus solution you provide, however, you can generally make your grid more readable in general with more padding between the rows and columns.

Extra comments:

Free text the dates w/conversions if possible. Unless you plan on training your users, or opt to adopt some draconian masking system (and equally irritating wrist-slapping on validation failure) they should be allowed to enter dates however they want. Caveat if you're dealing w/international folks, they enter months and days differently. SOP in the US in mm/dd/yyyy whereas a lot of countries prefer dd/mm/yyyy.
If you have a considerable amount of fields, you may want to consider splitting up the data-entry into multiple lines. A flat grid of > 10 columns is pretty hard to comprehend in a single view. The drawback to this is increased vertical scrolling, so you'll have to balance between the importance of using data context (e.g. the rows above and the rows below) in interpreting the current row of editing data on one hand, and getting all of the information of one row (multi-line or H-scrolling) on the other.

Again, however, determine WHAT the primary use of your form is going to be, and optimize for that. Data visualization or analysis has different needs than bulk entry, and satisfying keyboard users is completely different than keyboard+mouse users.

EDIT: Replies to comments

Also I don't see why satisfying
keyboard users is completely different
than keyboard+mouse users: I thought
that a single solution could/should
support either and/or both.

It's not completely different. Think of it as the difference between "optimizing for" and "supporting" the bulk of your users. A few examples: code editors are optimized for keyboard users. Between hot-keys, shortcuts, and keyboard navigation, a user rarely needs to use the mouse. Most RTS games work using the one-hand-on-mouse-the-other-on-keyboard. They generally support using the mouse exclusively, but it's not optimized for this. ITunes is on the other extreme -- it relies on the mouse almost exclusively (as do most drag-drop dominated UIs) and using the keyboard only is next to impossible.

Do you allow the entry and display an
error; or prevent the entry and
display an error? What do you mean by
showing it "inline" when it's a grid
(a cell, somewhere inside a table)?

I'm not sure which platform you're building on, but yes I mean somewhere inside the table, preferrably on the row of data you're talking about. In ASP.NET's GridView allows for TemplateFields which allow you to embed multiple controls into the same "cell". In the rich client world, most 3rd-party components provide support for similar things OOTB (e.g. IDataErrorInfo) which give you errors in context.

If the alternative is putting all the errors above or below your grid, it will be hard for your users to figure out which of the dozens of rows of data that has the error. For an example of sub-optimal handling of this, try adding 10 items to an Amazon cart, then change all of the amounts to 2, except 1 item, which you change to -1. Hit update and see if you can easily navigate to the row with errors.

Also, the "in" flavor of validation style is to allow users to enter data and give them messages if it's incorrect without preventing entry and/or deleting their input. StackOverflow does this in numerous places, most easily evidenced by adding a comment. The validation notifies you that you need at least 15 chars, but doesn't delete your comment when notifying you. A close second would be to let the user know explicitly, and right away that their input is incorrect. An example of this would be to try to rename a file with a backslash in Windows. You'll see a balloon with precise instructions immediately.

Well, Intellisense or auto-completion
is a kind of popup, but it can be
operated using (doesn't take the focus
away from) the keyboard.

If you can support popups as cleanly as Intellisense in Visual Studio, I would say go for it. My non-VS experience with popups is that most try and fail (some, quite horribly by requiring me to pick up my mouse and refocus to the correct place). Another thing to keep in mind w/Intellisense is that it has brilliant end-of-statement handling (by that I mean the interaction with your typed words + lookahead + spelling/casing forgiveness + tab/enter handling). Since I'm assuming you're using tab to navigate between fields (note that VS doesn't have fields) you're going to have to figure out another way to let your application know that "I'm done now, go auto-complete/Intellisense what I just typed"

I was thinking that the combo box's
frame around the text makes the text
harder to speed-read; maybe some
minimal combo box, with a down-arrow
but no frame around the combo box
(just the borders of the table cells)
would be better for cells which don't
have the focus: though I wonder why
even the down-arrow might be useful on
cells which don't have the focus.

If you're worried about the ComboBox's frame, I totally agree -- change the frame color to something with lower contrast. Any solution that you take to minimize the control "chrome" when it's not focused will obviously make it more text-like, and (possibly?) more readable.

In any event, good luck with your design.

回复收藏 0 原文

少女七分熟 2024-07-30 11:04:03

ExtJS

可编辑网格： http://extjs.com/ deploy/ext-3.0-rc2/examples/grid/edit-grid.html

行编辑器网格：http://extjs.com/deploy/ext-3.0-rc2/examples/grid/row-editor.html

我个人没有使用过3.0 x 版本还没有，但是 2.0 非常棒。 Ext 框架有一点学习曲线，但它几乎可以完成所有操作：验证、输入限制、数据绑定等。

回复收藏 0 原文

明媚如初 2024-07-30 11:04:03

对于数字值，我通常只使用 JavaScript 来限制输入除您希望输入的值之外的任何值。在这种情况下，数字。无需向他们发出警报或其他任何信息，只是不允许这样做。

对于枚举值，我真的会选择某种选择或下拉框。这就是人们对网站的习惯。您可以喜欢它并将其隐藏，直到鼠标悬停或单击该框。

对于选项卡，我将允许他们选项卡进入另一个选择框。这对于某些人输入大量数据来说会更快。

回复收藏 0 原文

凡间太子 2024-07-30 11:04:03

以下是多年来使用报名表观察所得的杂乱清单。

数字：

不要限制字段长度 - 如果您添加了一个分隔字符（或太多）却发现您现在无法填写该字段，那真的很烦人。然后你必须返回，删除“冒犯”的字符，走到最后，然后继续填充。一个好的系统应该在退出字段时修剪和删除任何非数据字符。如果该值仍然不适合，请立即告知用户。
为了避免非数字，只需忽略将填充非数字字符串的键。请注意千位/小数分隔符、空格和控制字符 (CTRL-x)。您应该能够粘贴几乎任何可用格式的值，包括货币符号（将被删除）。
旋转控件尚未普及，因此它们只能用于专家界面。他们还分享了滚动条的许多陷阱：是否有足够的空间来放置终点箭头，滚动条是否应该带有比例尺，比例尺是否应该是线性的，最简单的最小/最大滚动条长度是多少点击并给出足够的精度，即使使用键盘也能准确快速地递增吗？
用户退出该字段后，该值应四舍五入到允许的最大位数，并且最好根据操作系统设置进行格式化以确保易读性。

枚举值：

在输入时更改字段小部件会让新用户感到困惑，因此它应该仅用于专家界面。
当列表很大但用户熟悉时，类似 Google Suggest 的界面非常有用，因为只需单击几下即可将长列表的导航缩减为更易于管理的部分。如果用户确实想查看所有现有选项，也许应该提供下拉选择器。如果该字段不允许新条目，并且字段内容与任何选项都不匹配，则当用户离开该字段时，它应该尝试查找最接近的匹配项。例如，如果您知道选项为“高”、“中”和“低”，则仅输入第一个字符并让系统完成其余操作会很有用。
当该字段通过鼠标或键盘获得焦点时，如果可用选项不是很多，它应该立即显示可用选项。这对用户来说是一个很好的提示。一个陷阱是，如果它太明显，当用户试图离开时，会遮挡屏幕的其他部分。

Here's a jumbled list of observations from working with entry forms for years.

Numeric digits:

Don't limit the field length - It's really annoying if you've added a separation character (or one too many) only to figure out you now can't fill in the field. Then you have to go back, remove the "offending" character, go to the end, and continue filling. A good system should trim and remove any non-data characters when exiting the field. If the value still doesn't fit, let the user know immediately.
To avoid non-numbers, just ignore keys which would fill in a non-number string. Beware thousand / decimal separators, whitespace and control characters (CTRL-x). You should be able to paste values from just about any format available, including currency symbols (to be removed).
Spin controls are not yet ubiquitous, so they should only be used for expert interfaces. They also share many of the pitfalls of scroll bars: Is there enough space to have end-point arrows, should the bar scale with the, um, scale, should the scale be linear, what is the minimum / maximum bar length that is easy to click and gives adequate accuracy, can it be incremented accurately and fast even with a keyboard?
After the user exits the field, the value should be rounded to the maximum allowed digits, and preferably formatted according to the OS settings for legibility.

Enum values:

Changing the field widget on entry would be confusing to new users, so it should be used only for expert interfaces.
Google Suggest-like interfaces are useful when the list is big but familiar to the user, since navigation of a long list can be reduced to a more manageable portion in a few clicks. Maybe a drop-down selector should be available in case the user really wants to see all existing options. If the field doesn't allow new entries, and the field contents doesn't match any of the options, it should attempt to find the closest match when the user navigates away from it. For example, it's useful to enter only the first character if you know the options are "High", "Medium", and "Low", and have the system do the rest.
When the field acquires focus, via mouse or keyboard, it should immediately show available options if they are not very numerous. It's a good hint for the users. One pitfall is if it's too insistent, obscuring other parts of the screen when the user is trying to navigate away.

回复收藏 0 原文