Lies in education [was Re: The "loop and a half"]
Steve D'Aprano
steve+python at pearwood.info
Fri Oct 13 11:28:20 EDT 2017
On Sat, 14 Oct 2017 01:30 am, Chris Angelico wrote:
>> It's just a technique, like greying out certain menu options - clicking
>> them will do nothing, but you won't get an error message and you don't want
>> to allow them anyway, risking more serious consequences.
>
> Even there, you often CAN get a report about the failure; clicking on
> something that's disabled will cause a short beep, unless that's
> disabled. Maybe you personally don't like that beep, and you'd rather
> it be suppressed - but that's the end user's choice, NOT the
> programmer's. "Errors should never pass silently, unless explicitly
> silenced."
Over 30 years since Apple first put out their user interface guidelines, and
people still get the basics wrong.
"Errors should never pass silently..." is excellent advise for programming,
but not necessarily UIs. With a program, errors in the code represent bugs
that should be fixed, and in principle we can remove the bugs one by one
until there are none left, after which the program will be perfect. (Yeah,
try not to laugh too much.)
But in a UI, that will never be the case. Errors are not bugs, and can't be
removed. All you can do is hope the user doesn't do it again, which they
will. So UIs should follow a slightly different ideal:
"Be tolerant of unimportant errors, and let them pass silently."
For example, pressing delete when there is no text to delete should just
silently do nothing. Why annoy the user by beeping? They probably just held
down the backspace key for a microsecond too long. Surely you wouldn't log
the error: "delete pressed but no text to delete". Um, okay, what do you
expect me to do about it?
Likewise, pressing the left arrow key when you are already at the start of the
text should just silently remain at the start, not chastise the user. Or
clicking in the body of the window where there are no controls or text
fields. (MYOB, I'm looking at you.)
But in fact, clicking a disabled button or menu item is not an error. There's
no need to chastise the user with a beep or by flashing the screen or logging
the event ("warning: user clicked disabled menu").
The point of disabling the menu is to avoid errors by preventing the user from
selecting a command that will fail. The reason the menu is disabled rather
than hidden is to provide a consistent interface and immediate visual
feedback to the user. Clicking a disabled item should simply do nothing at
all.
If, and *only* if, you cannot rely on visual feedback that the item is
disabled (perhaps you're using a text-only interface with no way to visually
distinguish items) then you should provide some other feedback, like a beep
or flashing the screen, or better (since audible feedback is annoying)
display an informational status message that doesn't require explicit
acknowledgement from the user.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
More information about the Python-list
mailing list