The Old Joel on Software Forum: Part 3 (of 5) - Disabling of Controls vs Error Messages

Disabling of Controls vs Error Messages

I've read in some recommendations, that in general UI dialogs should not popup error messages (frightening the user / disturbing the work flow etc.), but instead, disable the controls / menu items that are not possible to be clicked in a given situation.

Do you think sometimes it is worse to wonder why one can't click on some menu item / button, instead of receiving meaningful erorr message?

Hairy Monkey
Thursday, December 11, 2003

This is an easy one - when you mouse over a disabled control, there should be some feedback given as to why it is disabled.

la la
Thursday, December 11, 2003

Not everyone can be bothered to hover their cursor on a disable menu item. Why? Because users are taught that disabled items cannot be 'clicked', so why even bother with the hovering in the first place?

Thursday, December 11, 2003

Surely this is the difference between users who are expert in some feature or piece of software and those who are not? The clued up will know why an option does not appear or is disabled, whereas the newbie will require more "forceful" guidance.

Thursday, December 11, 2003

If the reason for the disabled control is intuitively obvious, then disabling is the way to go. For example, disabling copy when no text is selected is fine. On the other hand, if it is not obvious why a control is disabled then I lean towards leaving it enabled and providing detailed feedback when clicked why it is not available. As an example, in an IDE I developed the debug command was disabled if certain criteria were not set (not using a project, no JDK set, etc) and none of these were intuitive to users.

Gerald

Gerald
Thursday, December 11, 2003

"Surely this is the difference between users who are expert in some feature or piece of software and those who are not? The clued up will know why an option does not appear or is disabled, whereas the newbie will require more 'forceful' guidance."

Wrong.

The problem is, we are all "clueless" at one moment or another, even in software we are expert in.

My favorite example is in Quicken. Now, I've been using Quicken since 1991, and it's an excellent product - and I know it very, very well. One day, I was looking at the "Calendar" window, and I decided I wanted to reconcile my checking account, so I went to click the "Reconcile" toolbar icon. It was disabled.

I had no idea why it was disabled. I had never seen that icon disabled before. Why is it disabled now? Is this a bug in the program? How am I supposed to reconcile my damned checking account? I re-started Quicken, rebooted, validated the file, all to no avail. After 20 wasted minutes, I was stumped. And pissed. Finally, I gave up, and went to the checking account's "Register" window to enter some checks.

The "Reconcile" toolbar icon was immediately enabled.

Get it? It makes no "sense" to try to Reconcile from the Calendar window, so some genius decided they should disable the "Reconcile" toolbar icon for me. Why? I suppose that they were afraid that an error message like, "You must be in the Register window to reconcile" would damage my delicate self-esteem. I can't express how stupid that is.

Disabling controls should be made a felony.

Grumpy Old-Timer
Thursday, December 11, 2003

"Disabling controls should be made a felony."

Amen!

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, December 11, 2003

Word disables plenty of things until you open a document, even if it's only a new blank one.

The reason is that nearly every change you can make affects a template and until a document is opened it doesn't know which template to make changes in.

Now, if there's a sub-menu, Word will let you open it but all is grayed out. Pretty stupid in my opinion, and I am sure it would be a lot more logical to gray out the original menu bar items.

I think in general it is better to disable the control. Look at the number of controls disabled when you have no document selected in Word; do you reall want to use an error message for each.

Where it is not too clear, and there are only a couple of controls involved, then I would tend to be in favour of an error message, but this is certainly not an occasion for a religious war.

Stephen Jones
Thursday, December 11, 2003

In some cases, rather than disabiling controls, you should just hide. In the case of the reconcile button example, perhaps that would have worked better.

Almost Anonymous
Thursday, December 11, 2003

Disabling controls, hiding controls, and error messages each has their place and each can be abused.

I disable controls rather than hiding them in the situation where being able to read them helps the user in figuring out what can can be done.

It's also less surprizing to users to have a control change from disabled to disabled than having the control become visible.

If an action within a dialog, allows additional actions, consider using enable/disable rather than visible/invisible. Make it clear that the action has control over the other actions.

njkayaker
Thursday, December 11, 2003

NJK is right, they all have their place.

I am usually in favor of disabling controls that can't be used, but I've see marketing folks insist that all options be visiable (including ones that haven't been implemented!!) so that the user can see what's available.

Under previous management, we once had a product that had a bunch of menu picks for things that didn't work that brought up a dialog box that said "Not Implemented Yet". This was in shipping software, I'm embarrased to say. The marketing people agreed to grey out the menu items, but not to remove them.

pdq
Thursday, December 11, 2003

There's no magic answer, of course :) But here's one approach:

If this user can NEVER access this function (e.g., they don't have authorization to access it), make the button or menu option invisible.

If the function does not apply to the current context (such as in the "Reconcile" example), make it invisible.

If a new user could figure out why the function is not available, disable it. You could gratuitously include a mouseover message as well, but I don't think that's too useful because most users will never see it.

Otherwise, enable it and display an error message.

Zahid
Thursday, December 11, 2003

It's vile to disable things that are not implemented because it appears that the items are available if you do the "right thing".

Disabling should be reserved for indicating that an option has some other requirement to enable it. It should not be used as a place holder for missing features.

Things that are not implemented should not be visible at all! I'd almost rather see the "not implemented yet" dialog than see a disabled item that I can't figure out how to enable.

If one wants to used the disabled state to indicate missing features, then maybe add (something like) "(not implemented yet)" to the menu option (e.g. "Print (not implemented yet)"). That way, the user knows not to try to figure out how to enable it.

Dopey marketers.

njkayaker
Thursday, December 11, 2003

Disabling can be pretty intuitive. Example, if you lock a door by using the push button lock, you can't lock it afterwards because the pushing of the lock is disabled because it is already pushed down - meaning it is already locked.

Gamut
Friday, December 12, 2003

I think there are better UI items for the locked/unlocked example:

"sticky" buttons or radio buttons or check boxes.

njkayaker
Friday, December 12, 2003

"The problem is, we are all "clueless" at one moment or another, even in software we are expert in."

*sigh* yes, that was exactly what I was getting at.

Tuesday, December 16, 2003