[squeak-dev] find class is broken...

Ron Teitelbaum ron at usmedrec.com
Mon Sep 21 13:12:24 UTC 2020


On Sun, Sep 20, 2020 at 5:14 PM Chris Muller <asqueaker at gmail.com> wrote:

> >  For example, imagine the power of having EVERY PIXEL on your desktop
>> being ready for ANY INPUT, regardless of window z-ordering, simply by
>> moving pointer there and pressing a mouse or keyboard button.
>> >
>>
>> Here you see, we differ. It's likely partly due to growing up using RISC
>> OS and the original ST-80 UI ...
>
>
> I grew up using MS Windows, the beast that made "click for focus" the
> defacto disaster it is today.  Not everyone is willing to change how they
> work, but a few years ago I got a tendonitis that *really* made me notice
> that I was doing, literally, hundreds upon hundreds, of extra clicks every
> day for no other purpose than reassigning keyboard focus, which, as you
> know, have to even be "strategic clicks" (window title bars, borders, etc.)
> to avoid suffering unwanted selection change, otherwise having to click yet
> again just to "get back" to what I as looking at.  Not only the pain, but I
> realized what a total time sink it was.  The only way to escape was I had
> to be willing to change, which actually turned out a lot easier than I
> thought...
>
>
> Hover to select is one of the greatest causes of user confusion that I
encounter.  Most windows users are used to clicking and moving the cursor
out of the way so they can see.

Now imagine a text box.  As a user you click on it so that you can type
into it.  You move your mouse away to type into the box BUT NOTHING
HAPPENS.  Why because your moving the mouse away from the text field took
focus away from the text field.

Or you click and start typing but your mouse pointer is in the way so you
move it and now nothing you type goes into the field.  We worked around
this issue by locking some of the important fields when a user selects it
but not all of them so it's not consistent.

We also have the issue that if your mouse happens to be hovering above a
button things work for a minute but then stop working because the button is
capturing keystrokes.  The user only moved their mouse. They didn't mean to
hover over a button or they clicked a button and got the result they
expected but had no reason to move their mouse cursor off the button
afterwards.

While I understand the unnecessary click argument and the harm that
clicking does to your wrist, there is still a lot to be said for
consistency, user understanding, and user experience.

Just my 2c.

Ron Teitelbaum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200921/8c72c5ca/attachment.html>


More information about the Squeak-dev mailing list