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

[Art Hunkins]

My vote is to eliminate the delayed palettes altogether.

They just get in my way, obscuring other items.

The right-click option is fully satisfactory. As a senior citizen (in motor 
activity, similar to a child), my errant attempts to click inside a palette 
that disappears on me, are highly frustrating.

Art Hunkins

----- Original Message ----- 
From: "Eben Eliason" <eben at laptop.org>
To: "Michael Stone" <michael at laptop.org>
Cc: <sugar-devel at lists.sugarlabs.org>
Sent: Wednesday, October 14, 2009 11:39 PM
Subject: Re: [Sugar-devel] RFC: Kill the delayed menus for good


On Wed, Oct 14, 2009 at 11:12 PM, Michael Stone <michael at laptop.org> wrote:
> 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! :)

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. I assume there is a group of individuals — developers and
kids alike — who feel the same as I do, and others who feel the same
as you. Those that feel as you do, of course, should definitely try it
and provide feedback, which I'd be happy to hear.

I have no itch.

> (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

I disagree that this is an obviously better implementation. It's
"better" if you're one who frequently has needs for the additional
complexity. It's arguably not if you use only (or mostly) primary
actions.

> 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.

> 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.)

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?

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

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.

>> 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.

>> 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, but I'm not as sure as you seem to be that
immediately revealing palettes is the correct approach to doing so.

Eben
_______________________________________________
Sugar-devel mailing list
Sugar-devel at lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel