Hiding and Disabling Menu Items

[Adam Connor]

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


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Dan Saffer]

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 think I necessarily agree about  
the disabling. What is missing from his critique is how "the menu item  
can display a message telling the user why." Does he mean pop-ups?  
Tool tips?

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.

Thoughts?


Dan




________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Jack Moffett]

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

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Paul Eisen]

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


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Jeff Garbers]

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 think I necessarily agree  
> about the disabling. What is missing from his critique is how "the  
> menu item can display a message telling the user why." Does he mean  
> pop-ups? Tool tips?
>
> 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.
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[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.


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


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Rich Rogan]

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@...> 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 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?
>
>

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Dan Saffer]

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


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Robert Hoekman Jr]

>
> 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-
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Rich Rogan]

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@...> 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 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
>

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[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?)


On 7/2/08, Dan Saffer <dan@...> 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 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
>
>

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Paul Eisen]

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?)

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Chauncey Wilson]

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@...> 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@...> 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 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
>>
>>
>
> --
> Joseph Rich Rogan
> President UX/UI Inc.
> http://www.jrrogan.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss@...
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Rich Rogan]

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@...> 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
> Principal User Experience Architect
> tandemseven
>
>
>
> --
> Joseph Rich Rogan
> President UX/UI Inc.
> http://www.jrrogan.com

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Jeff Howard]

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.

* In case the user has no reason to search for a certain function in  
the given situation, it should be hidden. As an extreme example, the  
Delete option is not needed when there are no items to be deleted.

* 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 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.

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Paul Eisen]

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@...
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.


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Jack Moffett]

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


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Dan Saffer]

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 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.

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


________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Janne Kaasalainen-4]

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
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

[Elizabeth Buie-4]

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 Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help