On Sat, 14 Oct 2017 07:04 am, Peter J. Holzer wrote:
> On 2017-10-13 15:28, Steve D'Aprano <steve+pyt...@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).
I don't disagree with that -- I never said that ALL errors should pass
silently. That would be silly. I said that UIs should be tolerant of
*unimportant* errors. Being unable to open a file is clearly not unimportant.
And besides, that's not really a UI error. Its either a programming error:
say, the code tries to call open("filename", "t")
or its an unavoidable environmental error (the file actually is corrupt, the
disk is failing, the user doesn't have read permission for the file). Either
case should be reported.
>> 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.
Indeed. That was my position: since clicking a disable menu item is not an
error, there's no need to treat it as an error. The action of disabling the
menu item or the button is an explicit way of saying:
temporary turn off the function of this item, and make
clicking it harmless
and once you have done so, there's no error condition to deal with because
clicking it does nothing.
> 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]).
Why do they need a reason? Maybe they just like to click on things. Since
clicking on disabled items is harmless, why elevate it to the state of an
error?
Maybe they're beginners to computers, and haven't yet learned the difference
between active controls that respond when you click them, and inactive ones
which do not respond. We all have to learn that, just as we learn which
entities respond to voice control, and which do not:
"Mummy, I'm thirsty, get me a glass of water please!"
"Whiskers, I'm thirsty, get me a glass of water please!"
The lack of response from the cat is enough to teach the user that asking your
cat is not going to be effective, and the lack of any feedback from a
disabled item likewise will quickly teach them that greyed out (disabled)
items are inactive and don't respond to clicks.
There's no need to treat it as an error and chastise the user, that just makes
your program hostile and less usable.
> 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,
I certainly do.
But that's why I specified the beginning of the text, not the beginning of the
line. There's no previous line to go back to.
> 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").
Also known as "annoy the user" and "sensible" modes :-)
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
