views:

45

answers:

4

What is the best way to deal with input elements that are currently not available, or locked to a default value, e.g. a "state" field that is only relevant to some countries, a button for functionality that the current user is not authorized to use, or a dropdown menu entry that is only relevant when the user has selected something?

There are 3 ways I've seen to deal with this, and all of them seem unsatisfying to me:

  • Locking the elements - can confuse and annoy users because it conveys no information about why they're locked. This question was actually prompted by me wanting to install east asian font support on Windows XP, finding the relevant checkbox in the control panel locked, and wondering about it for days before realizing that I was on a non-admin account.
  • Hiding the elements - Even more confusing and annoying when users see screenshots in a tutorial that differs from what they see - or are told by a helpdesk guy to click on a button that doesn't exist for them.
  • Showing an error message - best chance of conveying useful information, but might also be quite annoying when you have no visual cue about what you can and can't do.

So are there any good alternatives (ideally with real life examples where they're used)? Rules of thumb when to use what? Strong arguments why to use locking anyway? It does seem to be the most commonly used, but I suspect that may only be so because everyone's copying it without thought.

+3  A: 

If a UI element is something that the user doesn't have permission to access, it's probably a good security practice to hide that element completely. If the element is something a user may want to know about, and can acquire access by satisfying certain requirements (e.g. filling out fields), then I would disable/gray it out.

Andy West
+1 for this. What they can't see can't confuse them.
Pierreten
Kevin Montrose
+1  A: 

This has to do with real human beings so the traditional answer here is "it depends". I always work out some user models and try making life better at least for those modeled ones.

Oleg Zhylin
+1  A: 

I think locking is the most common as its simple to implement. There is no combinatorial explosion of possible states that you have to deal with. But as Oleg mentioned, it really depends on what your'e trying to hide/lockdown. If it's very unlikely that the user will get access to that item, it's best to hide it. But if its inapplicable at this point in time and might become active anytime, it's probably better to lock it down. A hover tooltip or something that indicates why the item is locked down would give the users some clue.

You might want to abstract out the localization information out of here. For example, "zip code" vs "postal code" vs nothing. This is contextual information, but can be categorized under L10N and I18N more appropriately.

In my experience, you should let the users know why they can or can't do something. Works out much better than trying to make decisions for the user and hoping it would be obvious to them.

Anurag
+2  A: 

Disable ("gray out") the controls, and display an explanation (error message) either beside them (of a similar visual weight/color palette), within them, or as a tooltip.

Also, hiding a group of controls can make sense, if there is some obvious superordinate control which would reveal them, or if the visual simplicity is a bigger win.

Kevin Reid