#4908 HIGH FutureF: Basic Sugar UI primitive is bizarre: hover, then move, then click

[Zarro Boogs per Child]

#4908: Basic Sugar UI primitive is bizarre:  hover, then move, then click
-------------------------------+--------------------------------------------
  Reporter:  gnu               |       Owner:  Eben          
      Type:  defect            |      Status:  new           
  Priority:  high              |   Milestone:  FutureFeatures
 Component:  interface-design  |     Version:  Build 623     
Resolution:                    |    Keywords:                
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by Eben):

 Replying to [ticket:4908 gnu]:
 > Sugar only has two ways of letting the user do something:  clicking
 directly on a visible object; or something much more bizarre and unusual.
 You move the mouse to the object, but don't click on it.  Hover there.
 Eventually, Sugar will pop up a menu of some sort (even though you didn't
 click anything).  Sometimes it comes up in several pieces (e.g. first a
 name, then a fraction of a second later, some menu items).  Now you can
 move the mouse onto that menu and click one of the popped-up things.

 > I wondered why I was having trouble with this UI.  It's because nobody
 else ever does anything like this.  "Tooltips" pop up from hovering, but
 you can never click on them; they're informational only, and disappear
 when your mouse moves.  Everything else on every other UI I've used
 requires that you click on something before a menu will come up.  (Linux
 uses right-clicks; Mac uses ctrl-click; etc.)  You're free to move the
 mouse to anywhere on the screen, and bad things won't happen.  Nothing
 will pop up and obscure the thing under it that you were about to click,
 for example.  (If a tooltip obscures something, it doesn't matter much,
 since the click will go right through it.)
 >
 > E.g. you have the Journal and another activity running in the donut.
 Your cursor is on the left side of the screen and you're slow at moving on
 the touchpad.  (Or maybe the touchpad is jumpy and so you're moving very
 deliberately.)  You want to resume the Journal, but as your mouse heads
 toward the Journal, it crosses the other activity.  Your mouse ends up
 stopping over the Journal, but meanwhile, the other activity's pop-up has
 obscured it, and will no longer let you click on what you just aimed for.
 If you were a faster expert at using a touchpad, you wouldn't have this
 trouble -- but not every kid is.  You end up having to move the mouse OFF
 the Journal, so the menu will pop down; but depending where you move it
 to, you could end up with a different menu popping up before you can get
 back to the Journal icon that you want to click.

 This is a new concept.  It combines the idea of tooltips with contextual
 menus, with the core idea being that both of these are contextual
 information of varying granularity.  While navigating the UI, I can pause
 briefly to find out what something is, and pause for a longer period of
 time to find out mode about what I can do with it.  This was, actually,
 carefully considered because we wanted everything in the UI to be
 discoverable.  Granted, one could take that too far, and as you mention,
 this can occasionally get in the way, especially in the current
 incarnation.

 The first reason this is so is very high on the list of fixes to the
 contextual palette interactions, and that is that these palettes currently
 appear based solely on a time delay, and not at all based upon mouse
 speed.  That is, they really shouldn't appear unless the mouse is
 sufficiently still over a particular item, such that the palettes never
 pop up as you're attempting to travel across the screen to another item,
 regardless of how quickly one can control the cursor.

 A second set of rules that isn't currently implemented is the clicking
 behavior.  As you mention, usually contextual menus appear on click (often
 of the right variety).  Our system aims to function in precisely the same
 manner, with the hover interaction being a secondary means of performing
 this action that doesn't depend on the user knowing what "right-click" is.
 Anywhere you can hover to invoke on of these menus, you should also be
 able to right click to immediately invoke the full contextual palette.
 When it is invoked with a click, it will be dismissed in precisely the
 same way: with a selection from the menu, with a click outside, or with
 the escape key.  All the common behaviors you expect with normal
 contextual menus will hold true for this UI element.

 > This pop-up interference tends to happen a lot on crowded Mesh View
 screens too.

 The third problem here is "scrubbing", which is a technique that
 immediately reveals palettes for new items you mouse over when the item
 you left already had a palette revealed.  This is enormously useful when
 looking through palettes in toolbars or the frame, for instance, since you
 can quickly take in the various options.  Of course, this breaks down in
 view like the mesh, where the mouse has nowhere to "land", and the
 palettes can get in the way.  For this reason, we've decided to reduce
 this effect in such views, either by eliminating scrubbing, or by always
 scrubbing the "tooltip" portion but not the entire contextual palette.

 > This form of pop-up seems like one of those random Sugar UI decisions
 that was made without much thought.  But gradually, everything in the UI
 is starting to get these pop-up menus, which make it a pervasive
 bizarreness in the interface.

 As you can see, much thought was indeed put into this.  Clearly this is a
 new type of UI that requires adequate testing and tweaking to get right,
 and at present the full specification isn't even implemented so we can
 really do proper testing.  The current state has informed us about a
 number of interactions, but we're trying to explore other possibilities
 and adapt the ideas instead of throwing them out simply because they
 haven't been done before.

 > PS:  Touchscreens, like what Gen 2 is currently presumed to have, are
 really terrible at "hovering" without "clicking".

 Touchscreens weren't even on the table when this interface was being
 designed.  Obviously the UI might require some re-thinking should they
 appear, but I don't see this as a problem.  A tap could always act as a
 "right click" on such items, so that the actions one can take are
 presented.  Tap one: what do I want to act upon?; tap two: how do I want
 to act upon it?

-- 
Ticket URL: <http://dev.laptop.org/ticket/4908#comment:3>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system