Lies in education [was Re: The "loop and a half"]

[Peter J. Holzer]

On 2017-10-13 15:28, Steve D'Aprano <steve+python at pearwood.info> wrote:
> 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.

It is also not a bug if - for example - a file cannot be opened, or is
malformed. But you have to tell the user what went wrong. Pretending
that all went well won't make the user happy (or at least that happyness
will be short-lived).

> 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."
[...]
> 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.
[... other examples elided ...]
> But in fact, clicking a disabled button or menu item is not an error.

If it is not an error, clearly the rule does not apply. So it depends on
whether the action is an error or not (actually in the case of the
disabled button I would tend to think it is an error: I can't think of a
reason why anybody would intentionally click on a disabled button[1]).

Pressing the left arrow key when you are already at the start of the
line is good example. The user might expect the cursor to jump the end
of the previous line, so if your program doesn't do that you probably
should give some feedback. Or the user might just have pressed the key a
bit too long, then the cursor should just stop there ("vi has two modes:
One beeps a lot and the other doesn't"). So it depends on what the user
expects. I think Chris a very good point here that this should be
configurable unless your user base is very homogenous.

        hp

[1] Except in a demo: "As you can see, this button is now disabled.
    Nothing happens when I click on it!" Everbody dives under the table
    just in time before the espresso machine in the corner explodes.

-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp at hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel