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

[Michael Stone]

Eben wrote:

>>> 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! :)
>
> I don't feel inclined to myself, as I've never had a problem with the
> delay, and actually used to find the speed with which these palettes
> obstructed my view of the screen frustrating before the delay was
> increased. 

Do I correctly understand that 

   a) when you wrote "we should definitely get feedback" up above, you
      actually meant "YOU should get feedback and bring it to me." and
      that

   b) when you wrote "I definitely want to make sure that we make such a
      change for the right reasons" you were not, in fact, considering
      "does it feel good to use?" to be a critical part of "the right
      reasons"?

> I have no itch.

You don't need to have an itch to try to help someone else accomplish a
reasonable goal that you do not actively oppose. That's called

                       Encouraging Contribution.

>>> 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
>
> I disagree that this is an obviously better implementation. 

Which of the following do you disagree with?

   a) "visible but unobtrusive" is a lower floor than "hover"

   b) "visible but unobtrusive" is a higher ceiling than "hover"

   c) "visible but unobtrusive" is provides increasing levels of detail
      better than "hover"

   d) other objection

> It's "better" if you're one who frequently has needs for the additional
> complexity. 

I'm actually claiming that it's uniformly better: hover without a "lock
open" as is available in the new toolbars is Just A Bad Idea,
particularly as we see more devices with touchscreens.

> It's arguably not if you use only (or mostly) primary actions.

Having the sub actions be always available in the same field of view but
unobtrusive, e.g. by means of effective use of color, contrast, and size
just seems like a better solution to me. I'm sorry that I don't have the
code or animations necessary to demonstrate this today. However, that
lack should in no way alter our consideration of the current patch.

>> 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.
> 
> Adding a preference for the delays for these palettes, as we have for
> the frame, is a another reasonable possibility, and a literal
> incarnation of the "complexity slider" you suggest.

It's one choice, but it's a bad one. We can do better.

Also, it is not a complexity slider, most notably because it is not
visible in the same field of view as the interface it controls.

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

You didn't respond to this principle. Do you accept it or feel that it
misses some important cases?

>>> 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.)
>
>We had lots of trouble with palettes obscuring other elements of the
>UI even with short delays, including, potentially, the desired target.
>I can't imagine that this issue has gone away in the intervening
>months, and removing the delay entirely seems it would exacerbate the
>issue. Do you have any experiences to report in this regard?

As I wrote to Daniel, my experience was that the overall increased
responsiveness of the UI more than made up for any annoyance that I
experienced as a result of its occasionally poor layout choices. (For
me, this was true even with jumpy cursors, again, because the interface
was just so much more easily controllable as a result of being actually
responsive.)

>>> 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.
> 
> You keep saying it's better, but fail to provide adequate reasoning or
> heuristics for why you feel this to be so.  Could you elaborate on the
> problems you identified and the way in which this resolves them?

Certainly. (I didn't do so before because no one has asked for reasons
or heuristics until now and because I consider reasons to be inferior to
actual experiences with regard to UI decisions.)

However, since you asked, here's a short treatise on the subject:

   Multi-stage context menus with delayed reveals and hides have several
   important downsides in Sugar:

   First, they make an already insufficiently responsive interface feel
   drastically slower by making the user wait *every time* they want to
   access something on the context menu.

   Second, they drastically increase the time cost of reviewing the
   current state of the system since most of the interesting system state
   is hidden on *second-level* context menu palettes. It takes multiple
   full seconds to get to this information, instead of taking fractions
   of seconds.

   Third, they needlessly delay the rewards of exploration: it can easily
   take multiple *minutes* to find out the names of people and activities
   on relatively full mesh view or home screen. Moreover, their use
   forces an excessive reliance on the visual memory and sense of timing
   of the user when the user is trying to manipulate several objects
   (e.g. trying to invite several people to join an activity.)

   Fourth, they increase the amount of time that it takes to fix
   mistakes. Everything Just Takes Longer.

   Fifth, they are not consistent with the heuristic that decisions
   should be made on the basis of comparisons within a single visual
   field.

   Sixth, they suck on many kinds of touchscreen devices and aren't too
   hot on machines with jumpy cursors. (Click-to-lock/unlock seems much
   more promising to me here.)

   ... I can probably come up with a few more, if you want ...

I feel that removing the reveal/hide delay addresses all of these
shortcomings but the last two, which I do not believe can be addressed
by any form of hover-based context menu and for which I have mentioned
several alternate approaches.

> Also, again, it's only arguably better (though I don't fully
> comprehend the argument) for those that want or need all of the
> secondary functionality, yourself included, and the ability to
> right-click to invoke palettes immediately exists to enable those who
> feel more comfortable with the system and desire the added level of
> depth it can provide to access these options without the delay.

Where else is right-clicking used in the interface? 

How will it be used on Macs? 

On touchscreens? 

By people using mousekeys?

How will it actually be discovered?

>>> 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. :)
>
> Yeah, I don't like it either. This was the genuine "thought
> experiment" I put on the table. I'm not a proponent of this design,
> but I thought it might spur others to suggest interesting
> alternatives.

Fair enough. :)

>>> 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?
>
> No, though in fairness we went through many rounds of design in which
> we entertained that possibility, and didn't succeed in finding a
> solution that did so in a way we felt was successful and that was
> doable with the available time and resources. It may be time to
> revisit those decisions

Let's.

> but I'm not as sure as you seem to be that immediately revealing
> palettes is the correct approach to doing so.

I am sure that immediately revealing palettes is good enough to be worth
recommending to you to try and that having more people try it is the
best available way to find out whether it it is a good approach for
others.

Also, I regard it as nothing more than a good incremental improvement on
the current behavior. I can certainly think of things that would be even
more pleasing to me -- just not ones that I know, concretely, how to
implement by, well, yesterday. :)

Regards,

Michael