On Jul 1, 2008, at 5:02 PM, Dan Saffer wrote:

I'd rather set the users' expectations correctly than to have them click on a menu item and have a pop up appear telling them why they can't do that. A really long tooltip: "If you want to Paste an object, first you need to unlock this layer." is definitely better, but could have tons of conditionals.

I agree with you. Sure, there could be a lot of conditions, but they are known, so custom messages can be displayed for as many as need be. And, the length of the tooltip can be mitigated by wordsmithing.

Now, if you are creating a web app in which you have free reign over the UI (i.e. not tied to OS-specific widgets) , you could add a small help icon beside disabled menu items that could open a pop-up, rather than a tooltip.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

Design is a process -
an intimate collaboration between
engineers, designers, and clients.

- Henry Dreyfuss

Dan Saffer said:
I'd rather set the users' expectations correctly than to have them click on a menu item and have a pop up appear telling them why they can't do that. A really long tooltip: "If you want to Paste an object, first you need to unlock this layer." is definitely better, but could have tons of conditionals.

Right on, Dan. Making a menu item active to show a message why it is not actually available should be reserved for VERY unusual circumstances. In addition to the point you make, disabling menu choices in context provides a quick way to see what can and cannot be done at any moment: i.e., an effective tool for learning. And disabled choices also provide feedback to the more advanced user about what the current context is (e.g., it's sometimes hard to discern if 0, 1, or multiple items are selected, and the available choices can give good feedback about this).

In addition to your suggestion about the wordy tooltip, one often overlooked area of online help in traditional software is information not only about what a field or UI element DOES, but also how to find it and how to enable it.

Paul Eisen
Principal User Experience Architect
tandemseven

I was surprised at this comment by Joel also. The best solution, as far as I'm concerned, is to have items be disabled — don't expect users to select things just to be told why they don't work — but offer a tool tip showing why the item is disabled if you hover over it or select it. The code already knows why the thing's disabled.

I was also surprised at a comment by John Gruber ("Daring Fireball"  on this:

Spolsky’s suggestion is also predicated on the assumption that the user is stupid. Better is to assume that the user is clever and curious and will be able to figure out for themself why a certain command is currently disabled.

Yeah, that's it. If people don't know why some command is disabled, they must be stupid. Clever and curious users will be EAGER to explore for several minutes trying to figure out why the command is disabled. It's like a game - who wouldn't want to play?

On Jul 1, 2008, at 5:02 PM, Dan Saffer wrote:

Joel ("On Software"  says, "A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used. Don't do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work. Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why." http://www.joelonsoftware.com/items/2008/07/01.html I agree about the hiding, but I don't [trim]

One other thing I look at when determining how the user will be informed about the functionality of a disabled control is what the conditions or configurations are that would cause the control to be enabled/disabled.

Sometimes I find that the where the control exists in a task/workflow creates a context for the user and they either conciously or subconciously the user understands why the control is at some points disabled and other points enabled.

When observing this, its important to look at how long it takes the user to pick up on this context, obviously if it seems to take a while, a number of iterations on the task perhaps, you wouldn't want to depend on the context being the only communication vehicle and do something a little more explicit - something like a tool-tip as Dan pointed out, or even just a text hint displayed beside the control.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=30957

I'd have to agree with what I believe all this threads comments are pointing to (and add that this is what we're doing in our app, with great user feedback) , - it's better to disable a button when this functionality is not available then:

1. Hide it, or
2. Leave it visually enabled but thru user intervention the user discovers it is actually "disabled".

Guru's can be wrong, (often) , and assumptions should be challenged. Not to mention there's often a good reason, (in context) , to do something which otherwise would seem counter intuitive.

On 7/1/08, Jeff Garbers jgarbers at xltsoftware.com wrote: I was surprised at this comment by Joel also. The best solution, as far as I'm concerned, is to have items be disabled — don't expect users to select things just to be told why they don't work — but offer a tool tip showing why the item is disabled if you hover over it or select it. The code already knows why the thing's disabled. I was also surprised at a comment by John Gruber ("Daring Fireball"  on this: Spolsky's suggestion is also predicated on the assumption that the user is stupid. Better is to assume [trim]

-- Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

On Jul 2, 2008, at 8:42 AM, Rich Rogan wrote:

I'd have to agree with what I believe all this threads comments are pointing to (and add that this is what we're doing in our app, with great user feedback), - it's better to disable a button when this functionality is not available then: 1. Hide it, or 2. Leave it visually enabled but thru user intervention the user discovers it is actually "disabled".

Actually, no. We've been saying we agree with Joel, that # 1 is usually bad. The best practice we seem to be hovering around is:

Leave the item visible, but visually distinguished as disabled. When possible, allow for some means to explain why it is disabled (tooltip, help icon).

Dan

Actually, no. We've been saying we agree with Joel, that # 1 is usually bad. The best practice we seem to be hovering around is: Leave the item visible, but visually distinguished as disabled. When possible, allow for some means to explain why it is disabled (tooltip, help icon) .

I swear I recently saw a very relevant blog post on this idea from some company called ... Adaptive Path?

http://www.adaptivepath.com/blog /2008 /06 /05 /what -to -do -with -unused -letters /

: 

-r-

I would seriously suggest reconsidering this "Hide buttons" in this case and "show buttons" in that case, VS Enable button in this case and disable button in that case.

We did both of these designs and users were consistently confused when choosing a specific entity and an option would suddenly "not be there" (feedback - system has bugs, what changed/somethings broken) , VS when we disabled the button this reinforced that entity "x" didn't have this functioanlity.

Rich

On 7/2/08, Dan Saffer dan at odannyboy.com wrote: On Jul 2, 2008, at 8:42 AM, Rich Rogan wrote: I'd have to agree with what I believe all this threads comments are pointing to (and add that this is what we're doing in our app, with great user feedback) , - it's better to disable a button when this functionality is not available then: 1. Hide it, or 2. Leave it visually enabled but thru user intervention the user discovers it is actually "disabled". Actually, no. We've been saying we agree with Joel, that # 1 is usually bad. The best practice [trim]

-- Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

I think we're all saying the same thing, (making my ordered list more organized) :

Optimal solution:

1. Disable button when functionality is not available, (with messaging) .

Sub-Optimal solutions:

1. Hide buttons

2. Leave buttons visually enabled but thru user intervention the user discovers buttons are actually "disabled".

(There is consensus on the above Optimal solution, right?)

On 7/2/08, Dan Saffer dan at odannyboy.com wrote: On Jul 2, 2008, at 8:42 AM, Rich Rogan wrote: I'd have to agree with what I believe all this threads comments are pointing to (and add that this is what we're doing in our app, with great user feedback) , - it's better to disable a button when this functionality is not available then: 1. Hide it, or 2. Leave it visually enabled but thru user intervention the user discovers it is actually "disabled". Actually, no. We've been saying we agree with Joel, that # 1 is usually bad. The best practice [trim]

-- Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

That list sounds right, Rich, and consistent with the GUI-design guidelines of yesteryear (ahhh...the days when applications were just applications and didn't need a "Web 2.0" moniker to make them sound rich and interactive).

A more generalized rule can be stated:
Disable (gray out) options that are sometimes available to a particular user, but not in the current context. Hide options that are never available to a particular user.

The latter point is important when considering features to which not all user roles have access. Leaving those showing but disabled can be frustrating.

Paul Eisen
Principal User Experience Architect
tandemseven

Original Message
From: Rich Rogan

I think we're all saying the same thing, (making my ordered list more organized):

Optimal solution:

1. Disable button when functionality is not available, (with messaging).

Sub-Optimal solutions:

1. Hide buttons

2. Leave buttons visually enabled but thru user intervention the user discovers buttons are actually "disabled".

(There is consensus on the above Optimal solution, right?)

There is some research on whether buttons should be disabled or hidden in Deborah Mayhew's great book
Principles and Guidelines in Software User Interface Design. Whether items should be disabled or hidden depending on the frequency of use and expertise and goals of the user. There was research into efficiency versus predictability. One of the issues with messaging for disabled buttons is that with some functions, there might be multiple reasons for disabling the button so any message might have to convey 1 or more reasons for the disabling. There was a controversy in the early days of pop-up menu design about whether a pop-up menu should have any disabled items since the intent of a pop-up menu was to provide only functions that are currently available for a specific context. When disabled items are included in pop-up menus, the menus get longer which is an issue.

The Mayhew books is old (1992) , but some of the classic research about many of the common UI questions is still quite applicable.

Chauncey

On Wed, Jul 2, 2008 at 2:38 PM, Rich Rogan jrrogan at gmail.com wrote: I think we're all saying the same thing, (making my ordered list more organized) : Optimal solution: 1. Disable button when functionality is not available, (with messaging) . Sub-Optimal solutions: 1. Hide buttons 2. Leave buttons visually enabled but thru user intervention the user discovers buttons are actually "disabled". (There is consensus on the above Optimal solution, right?) On 7/2/08, Dan Saffer dan at odannyboy.com wrote: On Jul 2, 2008, at 8:42 AM, Rich Rogan wrote: I'd have to agree with what I believe all this threads comments are pointing to (and [trim]

So given this discussion, what (if anything) is the impact of what we're saying on the use of Progressive Disclosure in UI design?

I'm not saying that there is an impact, it just seems to me that I've heard the rationale before for hiding/showing some controls conditionally as being based on the Progressive Disclosure pattern.

Forgive me if this is a stupid question.

Posted from the new ixda.org
http://www.ixda.org/discuss?post=30957

Paul you're touching on context, and I beleive talking about "Apples VS Oranges":

For instance, (this is exactly what we're presently dealing with) :

Case 1 - different entities within a screen, (for a single logged in user) :

In "Table X" different employees are displayed in rows. There is a superset of options for all employees.
When one employee is selected only a subset of options are available In this case I would "disable" the "non-actionable" buttons

Case 2 - different users with different access rights to the system:

When "User - lower access rights" logs in, they only have access to a subset of the total options, (they can never access "option A" lets say) They also see "Table X"
Options which are "always" unaccessible for this user should not display In this case "Option A" button never displays for this "User - lower access rights"

Case 1 has multiple "entities" for a single logged in user Case 2 has multiple "access rights" for different logged in user types

On 7/2/08, Paul Eisen peisen at tandemseven.com wrote: That list sounds right, Rich, and consistent with the GUI-design guidelines of yesteryear (ahhh...the days when applications were just applications and didn't need a "Web 2.0" moniker to make them sound rich and interactive) . A more generalized rule can be stated: Disable (gray out) options that are sometimes available to a particular user, but not in the current context. Hide options that are never available to a particular user. The latter point is important when considering features to which not all user roles have access. Leaving those showing but disabled can be frustrating. Paul Eisen [trim]

Here's another context. The Nokia Series 60 UI Style Guide (from 2005) touches on this issue and prohibits the dimming of unavailable menu items. They outline the rationale for hiding or erroring instead and allow for either, depending on the situation.

// jeff

6.6.2 Unavailable Items

Situations often occur where a certain function cannot be used. In these cases, the corresponding items in the Options menu must either be hidden, or there must be an error message given when the user tries to access a function that cannot be accomplished. The Series 60 user interface does not use dimming of menu items.

This is a trade-off issue: removing unnecessary options makes the Options menus shorter, but at the same time it changes the menu from situation to situation, preventing users from learning the function locations. It may even cause frustration if the users expect some function to be found in the menu, but it is sometimes not there.

An example of this is Digital Rights Management (DRM) protected files: for example, sending commands shall be visible in the user interface although sending such a file would not be allowed. Appropriate DRM specific notifications are displayed if the user attempts to select one of the options that the user is not allowed to perform on DRM protected media objects. This is to facilitate end- user’s learning of the DRM concept.

Adam, I've seen the term "progressive disclosure" used in more than one way. For example, in a dialog, revealing subsequent fields based on earlier user choices. Or are you referring to showing short menus containing common or high-use actions, and then revealing more choices in response to an explicit user action? Can you clarify?

Paul Eisen
Principal User Experience Architect
tandemseven

416.840.4447 office/mobile

peisen at tandemseven.com
http://www.tandemseven.com

From: Adam Connor

So given this discussion, what (if anything) is the impact of what we're saying on the use of Progressive Disclosure in UI design?

I'm not saying that there is an impact, it just seems to me that I've heard the rationale before for hiding/showing some controls conditionally as being based on the Progressive Disclosure pattern.

Forgive me if this is a stupid question.

On Jul 2, 2008, at 4:12 PM, Jeff Howard wrote:

The Series 60 user interface does not use dimming of menu items.

But they don't say why. Without a good reason, I think this is a poor decision.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

In our society,
the scarce factor is not information,
it is time to attend to information.

- Herb Simon

On Jul 2, 2008, at 1:12 PM, Jeff Howard wrote:

Here's another context. The Nokia Series 60 UI Style Guide (from 2005) touches on this issue and prohibits the dimming of unavailable menu items. They outline the rationale for hiding or erroring instead and allow for either, depending on the situation. - If the user searches for a function, even though it cannot be used in the current situation, it is often better to display the option and give an appropriate message if the user tries to access that function. An example of this is Digital [trim]

I guess I'm questioning whether error messages are the correct way to "teach" users anything. Seems like the "slap on the wrist" method of learning. I've always been a bigger fan of the Poke Yoke Principle myself, which says to not allow users to make "mistakes" at all if possible. Disabling (and I guess hiding as well) do that.

Dan

Hi,

Here's another context. The Nokia Series 60 UI Style Guide (from 2005) touches on this issue and prohibits the dimming of unavailable menu items. They outline the rationale for hiding or erroring instead and allow for either, depending on the situation.

If/when drawing conclusions from S60 style guides, please do remember the context, software environment in which those guidelines are utilized and limitations before making generalizations to other domains. Jeff's mail makes a note about the context (first sentence above), but I just wanted to highlight its importance.

Best regards,

- Janne Kaasalainen

Dan Saffer wrote:

I guess I'm questioning whether error messages are the correct way to "teach" users anything.

Are you really questioning, Dan, or are you being polite and giving them the benefit of the doubt? :-)

Me, I would state it outright: Error messages are not the correct way to teach them.

Does anyone remember the long-established principle that "Error prevention is better than error recovery"? (Chauncey, you can put your hand down; I know you do. :-)

Elizabeth

-- Elizabeth Buie
Luminanze Consulting, LLC
www.luminanze.com

Yes, error prevention is a primary goal, but I will play devil's advocate here and modify that to state, prevent errors whenever possible, but if you can't prevent the error (because of system or code limitations or something else that can't be changed immediately) , present a well-crafted message that explains how to prevent the error the next time. Error messages may not be the best teaching method, but one of the goals of a good error or informational message is to instruct and prevent the next error. One of the interesting aspects of our field is that the guidelines for effective error messages have been around since the late 1980s but many systems still ignore the basic pattern for good error messages. One thought about error messages is that if they are sufficient, a person may not have to call internal or external support or search a knowledge base for a problem so a good message can be cost-effective (though prevention is still better) .

Chauncey

On Thu, Jul 3, 2008 at 7:26 AM, Elizabeth Buie ebuie at luminanze.com wrote: Dan Saffer wrote: I guess I'm questioning whether error messages are the correct way to "teach" users anything. Are you really questioning, Dan, or are you being polite and giving them the benefit of the doubt? :-) Me, I would state it outright: Error messages are not the correct way to teach them. Does anyone remember the long-established principle that "Error prevention is better than error recovery"? (Chauncey, you can put your hand down; I know you do. :-) Elizabeth — Elizabeth Buie Luminanze Consulting, LLC www.luminanze.com Welcome to the [trim]

Absolutely, Chaunceh. My point is not that error messages are not necessary, but that they are not sufficient.

Elizabeth

Chauncey Wilson wrote:

Yes, error prevention is a primary goal, but I will play devil's advocate here and modify that to state, prevent errors whenever possible, but if you can't prevent the error (because of system or code limitations or something else that can't be changed immediately) , present a well-crafted message that explains how to prevent the error the next time. Error messages may not be the best teaching method, but one of the goals of a good error or informational message is to instruct and prevent the next error. One of the interesting aspects of our field is that the guidelines [trim]

-- Elizabeth Buie
Luminanze Consulting, LLC
tel +1.301.943.4168 (US)
tel +39.347.394.7022 (Italia)
fax +1.301.949.9694 (US only)
www.luminanze.com

I wrote:

My point is not that error messages are not necessary, but that they are not sufficient.

And that they are not the best starting point.

Elizabeth

-- Elizabeth Buie
Luminanze Consulting, LLC
www.luminanze.com

On Jul 3, 2008, at 7:26 AM, Elizabeth Buie wrote:

Me, I would state it outright: Error messages are not the correct way to teach them.

Yes, but nothing says "Don't press that button" better than a couple of electrodes emitting 10,000 volts. They won't make the mistake again, I tell you.

Let see, the usability ethics code restricts electric shock features to less than 270 volts and remember that amperage is the more critical voltage.

Chauncey

On Thu, Jul 3, 2008 at 9:30 AM, Jared Spool jspool at uie.com wrote: On Jul 3, 2008, at 7:26 AM, Elizabeth Buie wrote: Me, I would state it outright: Error messages are not the correct way to teach them. Yes, but nothing says "Don't press that button" better than a couple of electrodes emitting 10,000 volts. They won't make the mistake again, I tell you. Welcome to the Interaction Design Association (IxDA) ! To post to this list . discuss at ixda.org Unsubscribe .... http://www.ixda.org/unsubscribe List Guidelines http://www.ixda.org/guidelines List Help http://www.ixda.org/help

On Jul 3, 2008, at 9:51 AM, Chauncey Wilson wrote:

Let see, the usability ethics code restricts electric shock features to less than 270 volts and remember that amperage is the more critical voltage.

Fortunately, the current administration has made the need for ethics obsolete. It's no longer a concern.

My 2 cents - the people who chose to not only users to do something that is not allowed by the system, but further codified this little turdblossum (I wonder how much user testing was involved validating this design decision) need electroshock. There are many ways to solve whatever problem space they think they might have had.

On Thu, Jul 3, 2008 at 9:58 AM, Jared Spool jspool at uie.com wrote:

On Jul 3, 2008, at 9:51 AM, Chauncey Wilson wrote: Let see, the usability ethics code restricts electric shock features to less than 270 volts and remember that amperage is the more critical voltage. Fortunately, the current administration has made the need for ethics obsolete. It's no longer a concern.