Hiding and Disabling Menu Items

1 Jul 2008 - 4:02pm
6 years ago
27 replies
5782 reads
Dan Saffer
2003

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

Comments

1 Jul 2008 - 4:20pm
Paul Eisen
2007

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

1 Jul 2008 - 4:27pm
Jeff Garbers
2008

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

1 Jul 2008 - 9:53pm
Adam Connor
2007

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

1 Jul 2008 - 4:17pm
Jack L. Moffett
2005

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

2 Jul 2008 - 10:42am
jrrogan
2005

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

2 Jul 2008 - 12:24pm
Dan Saffer
2003

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

2 Jul 2008 - 12:54pm
Robert Hoekman, Jr.
2005

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

2 Jul 2008 - 1:00pm
jrrogan
2005

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

2 Jul 2008 - 1:38pm
jrrogan
2005

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

2 Jul 2008 - 1:50pm
Paul Eisen
2007

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

2 Jul 2008 - 1:59pm
Chauncey Wilson
2007

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 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 at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

2 Jul 2008 - 2:22pm
Adam Connor
2007

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

2 Jul 2008 - 2:31pm
jrrogan
2005

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

2 Jul 2008 - 3:12pm
Jeff Howard
2004

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.

2 Jul 2008 - 3:14pm
Paul Eisen
2007

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.

2 Jul 2008 - 3:29pm
Dan Saffer
2003

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

3 Jul 2008 - 6:26am
Elizabeth Buie
2004

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

3 Jul 2008 - 7:33am
Chauncey Wilson
2007

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

3 Jul 2008 - 7:40am
Elizabeth Buie
2004

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

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

3 Jul 2008 - 7:43am
Elizabeth Buie
2004

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

2 Jul 2008 - 3:47pm
Janne Kaasalainen
2008

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

2 Jul 2008 - 3:20pm
Jack L. Moffett
2005

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

3 Jul 2008 - 8:30am
Jared M. Spool
2003

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.

3 Jul 2008 - 8:51am
Chauncey Wilson
2007

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
>

3 Jul 2008 - 8:58am
Jared M. Spool
2003

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.

3 Jul 2008 - 9:03am
SemanticWill
2007

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

3 Jul 2008 - 10:45am
Elizabeth Buie
2004

Jared "Stanley Milgram" Spool writes:

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

Quite right!

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

Syndicate content Get the feed