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
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
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
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
Welcome to
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
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
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
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 [EMAIL PROTECTED] wrote:
On Jul 3, 2008, at 7:26 AM, Elizabeth Buie wrote:
Me, I would
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
25 matches
Mail list logo
