Question

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.

Answer 1

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.