Re: Guidelines for disabling controls
Re: Guidelines for disabling controls
- Subject: Re: Guidelines for disabling controls
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 24 Sep 2006 06:06:46 -0400
- Thread-topic: Guidelines for disabling controls
on 2006-09-23 10:02 PM, Erik Buck at email@hidden wrote:
> Is it just me, or are there some words missing in the quoted text ?
> What does "Disable a control when users expect it to apply and they
> can easily deduce why the control is disabled." Did they mean "can't
> easily deduce" ?
It seems clear to me. They are addressing the circumstance where a user
expects a control to apply, but (a) in fact it doesn't apply and (b) the
mere fact that it is disabled (dimmed) is all the hint the user will need to
realize that there is a reason why it doesn't apply. If both conditions are
true, then go ahead and disable the control. That part of what they're
saying is entirely consistent with the Apple HIG, and we see it in use every
time we see a disabled menu item or control.
Where they go wrong is in offering you two additional options: if you
believe merely dimming it would be confusing to the user because it does not
provide a sufficient hint, then either (1) remove the control, or (2) leave
it enabled but present an alert explaining why it doesn't apply. Options (1)
and (2) are what's novel in their advice, and inconsistent with Apple's
approach.
Without re-reading the Apple HIG, I believe (1) is flatly contrary to
Apple's approach. For example, with respect to menu items, Apple's HIG
counsels against removing a menu item that is present in other
circumstances, because users tend to become confused when they are sure they
saw a particular menu item in that menu last time they looked but now it's
gone. In other words, the Apple HIG counsels that the message inherent in
the fact of dimming a control always conveys important information in an
easily grasped fashion. That message is (a) sometimes you can do this, but
(b) you can't do it just now. Simply removing the user control omits (a) and
is therefore less informative.
On the surface, option (2) seems to make sense if you're sure the disabling
of the control will be mysterious to the user. But I believe it is bad
advice in most situations because it means you really need to rethink your
entire user interface. Presenting an alert in that circumstance is an
example of an over-busy user interface. I hate apps that keep putting alerts
in my face to tell me I did something wrong, when there are less disruptive
ways to induce me not to do it in the first place.
In short, I believe this advice is typical of what Windows does wrong. It
either makes it impossible to do something you thought you were supposed to
be able to do and fails to explain why you can't do it now, or it goes to
the other extreme and gets in your face when you do something wrong. (I say
this as a longtime user of Windows at work.)
There are ways to reconcile this advice with what the Apple HIG advises,
though:
Read (1) (remove the control) to mean revise your user interface by
presenting a different environment when the circumstances make the old
environment confusing. Don't merely "remove" the control, but remove it and
at the same time present an alternative interface that makes more sense.
Read (2) (present an alert) to be a last resort when (1) is unavailable or
too confusing. This presumably will be very rare. I have in mind an app I
use that requires you to scroll the license to the bottom before the
"Accept" button becomes enabled. It took me an embarrassingly long time to
figure out that they wouldn't let me accept their license until I gave them
a signal that I might actually have read it. Removing the Accept button
altogether, so that it only appeared if I thought to scroll the license to
the bottom, would not have worked. I wouldn't have figured out that they
were looking for an acceptance -- part (a) of the message (sometimes you
can do this) would have been missing -- and I would have given up. If they
really felt they had to have proof that I had read the license, it was right
to leave the Accept button visible but disabled, but this still didn't
explain what I had to do to accept the license. If it were a Windows
application, they should have left the Accept button enabled but presented
an alert telling me to read the whole license before continuing. However, a
good Mac application would have redesigned the interface, perhaps by adding
a simple legend above the dimmed Accept button informing me that I can
accept the license as soon as I scroll it to the end. (This is a bad
example, however, in the sense that it shows what can happen when you let
dim-witted lawyers influence your design decisions. It's almost as bad as
the dialogs that reverse the positions of the Decline and Accept buttons so
the lawyers can prove that you must have actually thought about your
decision to accept the license instead of just hitting the Return button to
get past it.)
Shouldn't we be talking about this over on the (new) Hit-Dev list?
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden