How to visually reject user input in a table?_问答_开发者

In the programming of a table-based application module (i.e. the user mostly enters tabular data in an already laid-out table), how would yo开发者_如何学Cu reject user input for a given cell?

The scenario is: the user edits the cell, enters something (text, picture, ...) and you want them to notice when they finish editing (hitting enter, for example) that their entry is not valid for your given "format" (in the wider meaning: it can be that they entered a string instead of a number, that their entry is too long, too short, they include a picture while it's not acceptable, ...).

I can see two different things happening:

You can rather easily fit their entry into your format, and you do so, but you want them to notice it so they can change if your guess is not good enough (example: they entered "15.47" in a field that needs to be an integer, so your program makes it "15")
You cannot guess what to do with their entry, and want to inform them that it's not valid.

My question specifically is: what visual display can you offer to inform the user that his input is invalid? Is it preferable to refuse to leave the editing mode, or not?

The two things I can imagine are:

using colors (red background if invalid, yellow background for my case 1 above)
when you reject an input, do something like Apple does for password entry of user accounts: you make the cell "shaking" (i.e. oscillating left and right) for one second, and keep the focus/editing in their so they don't loose what they've typed.

Let's hear your suggestions.

PS: This question is, at least in my thought process, somehow a continuation and a specialization of my previous question on getting users to read error messages.

PPS: Made this community wiki, was that the right thing to do on this kind of question or not?

Be careful using autocorrection such as forcing user input to fit your format. See:

Is it acceptable to normalize text box content when it loses focus?.

It’s generally better to prevent invalid entries in the first place than to autocorrect them later. For example, if only integers are allowed, then you ignore any keying of the decimal point (along with all letters and most special characters). In some environments, you may want to provide a quiet audible signal that input is ignored (e.g., a dull thud).

As for when you need to alert the user to an error, how about a callout? Draw a bright line from the control or point in question (field, status annunciator, button, menu, location of a drag and drop) to the margin of the window and put a brief message (two or three words, like "Unrecognized date") in a balloon. Placing the message on the margin should keep it from occluding anything of interest in a crowded table.

The sudden appearance of the call-out should be sufficient to catch user attention, so it's okay to let the user move on to other cells in case they want to fix the error later. For efficiency, you may want to hold the user in the error-related field when the error originally occurs (since often the user wants to correct it right away), but then allow the next tab or mouse click to navigate the user away.

On mouseover or when focus is on the control associated with the error, the line is highlighted (to distinguish it from other callout lines that may be present) and the balloon expands to a full error message, providing more details on how to fix the problem (up to two sentences). Allow the user to drag and drop the balloon to a new location in case this occludes something of interest.

Include a Help button in the expanded balloon for further details. You can also include a button to fix the error (e.g., Retry, Reconnect, or set to default value).

The balloon disappears automatically when the error is fixed. Undo reverts whatever caused the error (e.g., reverts the field to its original value), which should clear the error.

If the user scrolls away from the place associated with the error, the balloon shrinks to an icon that remains in view so that the user is less likely to forget about it. Maybe an exclamation point in a triangle is a good icon. Place the icon beside or in the scrollbar track to indicate its relative location in the table, so the user can quickly scroll to find it later. Mouseover expands the icon to its full message. Perhaps clicking the icon can scroll to the right place in the table and put focus in the relevant control.

Balloons could also shrink to icons if they start visually interfering with each other. You may even want to include a control in a balloon to allow the user to force it to assume an icon.

For consistency, use for all errors, not just those associated with fields in tables.

The last time I did such a form (on a web page) I put a red box around the offending input.

I thought it was really neat... until a user asked me "Why's there a red box around this cell?"

What'd be nice is also displaying why the input's incorrect: "This field accepts only numbers", say.

You could display an icon in the cell, or a tooltip. The tooltip could open automatically or when mouse pointer hovers over the icon. It could disappear automatically when user edits another cell or when some timeout expires.

You can go with arrow tooltips like Adobe Flex's error tooltips. It focuses the attention to the error and supplies a brief description.