<div dir="auto">Also consider that focus is decoupled from mouse position so as to enable focus shift thru keyboard.<div dir="auto">What i most hate like Tim is that operate menu (pop up) is coupled with select (it's a select and operate). Operate is already requiring some motion to pick the right menu item, so i find the coupling really tiring, focus on position accurately twice, once for where we press the button, and once where we release the button... We already focused once when selecting, so doing it twice is just too many.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 22 sept. 2020 à 13:12, Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>

<div id="m_-6443314448762641729divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>> <span style="font-size:12pt">Then explain how "mouse over to focus" can work on a multi touch interface?</span></p>
<div>> Every time you touch something the focus moves to where you touch.</div>
<div>> Multi touch is the most used interface in the world, and it is click to focus.</div>
<div><br>
</div>
<p></p>
<div id="m_-6443314448762641729Signature">
<div id="m_-6443314448762641729divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div>
<div id="m_-6443314448762641729Item.MessagePartBody">I believe the difference is that on touch screens, you have kind of random access to every point of the screen, whereas when using a mouse, every click requires you to move the cursor until you reach the desired
 point, which introduces an additional level of indirection. Probably you cannot find an ultimative design concept for different input methods - just remember how successful Microsoft was with its Universal Windows Platform ...
<div id="m_-6443314448762641729Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="m_-6443314448762641729divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="m_-6443314448762641729Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
<div id="m_-6443314448762641729Item.MessagePartBody"><br>
</div>
<div id="m_-6443314448762641729Item.MessagePartBody">Best,</div>
<div id="m_-6443314448762641729Item.MessagePartBody">Christoph</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-6443314448762641729divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank" rel="noreferrer">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von karl ramberg <<a href="mailto:karlramberg@gmail.com" target="_blank" rel="noreferrer">karlramberg@gmail.com</a>><br>
<b>Gesendet:</b> Dienstag, 22. September 2020 07:11:37<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] find class is broken...</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 22, 2020 at 1:20 AM Chris Muller <<a href="mailto:ma.chris.m@gmail.com" target="_blank" rel="noreferrer">ma.chris.m@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I believe you're describing defacto habits ingrained into everyone from years of using Microsoft's original UI design than a qualitative critique of this particular design aspect.  Yes, familiarity can matter (see below), but the concept of <i>"Point
 to what you want to interact with,"</i> is such a natural way of thinking and working for a human user.</div>
</blockquote>
<div> </div>
<div>Then explain how "mouse over to focus" can work on a multi touch interface? <br>
</div>
<div>Every time you touch something the focus moves to where you touch. <br>
</div>
<div>Multi touch is the most used interface in the world, and it is click to focus.</div>
<div><br>
</div>
<div>Best,</div>
<div>Karl<br>
</div>
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Having keyboard focus decoupled and <b>way off</b> somewhere else than where the users' attention has since moved, often leads users to a similar confusion that you described, but just from the other direction -- the user wondering why
<b>nothing is happening</b> when typing into a field -- but this time because the list in which they last clicked just to check something real-quick still has the keyboard focus.  This is basically what happened to Eliot..
<div>
<div>
<div>
<div><br>
</div>
<div>Coupling it to the mouse pointer helps remove all confusion about where keyboard focus is, and is a natural concept that can be assimilated in about a day.  Dump Windows for Linux, and the behavior can be extended into the host system, too.
<div><br>
</div>
<div>
<div>Now, maybe for a single-use Form with a few fields used by external users for something simple, designing it click-for-focus may be worth aligning to Microsoft's defacto.  But for all-day developer work involving multiple, multi-paned windows, allocating
 power to pointing makes the system feel "light and responsive" instead of heavy and cumbersome.  For me, anyway...  :)<br>
</div>
<div>
<div><br>
</div>
<div>Best,</div>
<div>  Chris</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
On Mon, Sep 21, 2020 at 8:12 AM Ron Teitelbaum <<a href="mailto:ron@usmedrec.com" target="_blank" rel="noreferrer">ron@usmedrec.com</a>> wrote:<br>
><br>
><br>
> On Sun, Sep 20, 2020 at 5:14 PM Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank" rel="noreferrer">asqueaker@gmail.com</a>> wrote:<br>
>>><br>
>>> >  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.<br>
>>> ><br>
>>><br>
>>> Here you see, we differ. It's likely partly due to growing up using RISC OS and the original ST-80 UI ...<br>
>><br>
>><br>
>> 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...<br>
>><br>
>><br>
> 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.  
<br>
><br>
> 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.  <br>
><br>
> 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.
  <br>
><br>
> 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.  <br>
><br>
> 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.  <br>
><br>
> Just my 2c.<br>
><br>
> Ron Teitelbaum</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</div>

<br>
</blockquote></div>