Entering data into a grid

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

For Numeric values, I usually just use JavaScript to restrict entering any values other than those you want them to enter. In this case, numbers. No need to give them alerts or anything else, just don't allow it.

For enum values, I would really go with some sort of a select or drop down box. That's what people are use to with web sites. You can get fancy with it and hide it until the mouse over, or click on the box.

For tabbing, I would allow them to tab into another select box. This will be faster for some people to enter a lot of data.

Answer 2

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.

Answer 3

ExtJS

Editable Grid: http://extjs.com/deploy/ext-3.0-rc2/examples/grid/edit-grid.html

Row Editor Grid: http://extjs.com/deploy/ext-3.0-rc2/examples/grid/row-editor.html

I haven't personally used the 3.0x versions yet, but 2.0 is pretty awesome. There's a little bit of a learning curve for the Ext framework, but it pretty much does everything: validation, input restriction, databinding, etc.

Answer 4

jQuery has some cool plugins that assist in common data entry idioms.

High usage of jQuery, and some of these plugins, along with the aesthetics factor, indicate to me that these plugins represent some of the best ways of handling user input...

Isaac over at evolt also has a good article on Usable Forms

Answer 5

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.

Answer 6

Hi,

Have a look at http://www.peterblum.com

We use this product in many of our application for the past 4+ year. It definitly enhances UI of web forms and solves many validation problems. In particular, it works well with grid control.

Best of luck