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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Sep 21 13:24:03 UTC 2020


Plus, moving away from host feel is disruptive... Unless we deliver a
SqueakNOS.

Le lun. 21 sept. 2020 à 15:12, Ron Teitelbaum <ron at usmedrec.com> a écrit :

>
> 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/4c1da5ff/attachment.html>


More information about the Squeak-dev mailing list