[Sugar-devel] RFC: Kill the delayed menus for good

[Michael Stone]

Eben,

First, thanks for the interesting and detailed history of your vision. I
very much appreciate your ability to generate thought experiments
describing other ways that the world could be.

Next...

Eben wrote:
> Simon Schampijer <simon at schampijer.de> wrote:
> 
> > You can use right click to get the menu immediately. The delay is on
> > purpose.
> 
> We should definitely get feedback. I wouldn't be entirely opposed to a
> change, but I do want to make sure that we make such a change for the
> right reasons, and that it's actually the right change to make.

So try it, and encourage your friends to do the same! :)

(NB: merging it is a good way to accomplish this!)

> The initial design intent was to develop a system which worked in a
> sufficiently complete manner without needing palettes at all. Kids
> should be able to start activities, resume activities, join
> activities, write, paint, stop, etc. without ever seeing a palette at
> all. [1] This is the "low floor". For kids with more experience or
> curiosity, we decided to provide contextual palettes which grouped
> related actions and provided more complex interactions with the
> system. This is "no ceiling". Furthermore, we wanted to help introduce
> kids to the availability of additional options in a discoverable way,
> which is why the hover effect was chosen to provide increasing levels
> of detail and interaction for a given object.

This is a good story, but a bad implementation. A better implementation
would be to provide the extra options in a *visible but unobtrusive
form* or, if you absolutely must hide them, to make them visible with a
device like a "complexity slider" or like the new toolbar's "transient
hover; lock on click" behavior.

Remember -- comparisons should be made in a fixed visual field, not
across multi-second long gulfs of time, cursor positioning, and fine
motor control.

> Finding that many kids were actually waiting for the palette to appear
> always, instead of, for instance, simply clicking on an activity icon
> to join it, encouraged us to INcrease the delay on the palettes to
> help emphasize this as a secondary mechanism for interaction. A agree
> that hovering in one place to click in another isn't great; but that's
> also not the intended primary means of interaction, and should only
> really be done when one of the secondary actions is desired.

Understandable, but as you say, the result "isn't great". This makes it
better. Try it! Merge it! (Then come up with something better.)

> Removing the delay pushes us, I fear, even farther away from an
> interface in which nice friendly large clickable icons can be directly
> manipulated and encourages every action to be done through a
> contextual menu with a bunch of text in it. Is that really what we
> want kids to face?

It's better than the present. Again, merge it, then find something
better.

> Just for fun, I might suggest an alternate possibility which actually
> decreases the discoverability of the secondary palette. We could
> reveal the primary palette (label) on a delay as we do now, with some
> indication of "more options" that can be clicked to expand the menu to
> reveal the secondary items. This would provide the (essential) primary
> palette as a label and introduce kids to the existence of more
> controls without encouraging them to use this as a primary method of
> interaction. Advanced users, of course, could still right-click to
> invoke the full menu in one shot.

I mean this in the nicest of ways but, er... yuck. :)

> In practice, it seems it has worked too "well". It used to be that
> kids never resumed activities. Now, it seems, they never start new
> ones. The solution seems to be in encouraging use of the Journal and
> the Home view for these different default actions, and in clarifying
> the UI such that kids understand and desire to do so.

Is it really so hard to imagine showing pictures of both possibilities
at once on the same screen?

Regards,

Michael