Basic Sugar UI primitive is bizarre: hover, then move, then click

[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 pop-up interference tends to happen a lot on crowded Mesh View screens too.

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.

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

[jg]

Note gnu's comments about touchscreens...

[gnu]

BTW, I found a Sugar UI component that doesn't work this way. It's the menu for sharing, in the top bar of activities. You have to click on it before its menu comes up.

[Eben]

Replying to 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?

[Eben]

A lot of palette improvements have been going in, which cover most of the complaints in this ticket. Obviously the future integration of a touchscreen will require mode thinking and design. I've added it as a keyword to this ticket for future reference into my initial thoughts on the matter.

[gregorio]

Milestone FutureFeatures deleted