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

Eben Eliason eben at laptop.org
Wed Oct 14 12:39:10 EDT 2009


On Wed, Oct 14, 2009 at 12:04 PM, Simon Schampijer <simon at schampijer.de> wrote:
> On 10/13/2009 04:36 AM, Bernie Innocenti wrote:
>> Hello,
>>
>> Michael just passed by the Acetarium and, since the dinner was late, we
>> found the time to test and review his latest prototype^W patch.
>>
>> I'm loving how the menus suddenly are now snappy and responsive. Please,
>> test it yourself and report back. If we like this change, I think we
>> should go on and also kill the code that this patch makes redundant.
>> (please, let's not add another configurable knob!)
>>
>>> From 83ef08969ed7bee08f90c12bfa1eedcb7fb0500c Mon Sep 17 00:00:00 2001
>> From: Michael Stone<michael at laptop.org>
>> Date: Mon, 14 Sep 2009 22:33:12 -0400
>> Subject: Make various palette animations happen more quickly.
>
> Can you describe what the patch will change from the user point of view?
> Is this to get rid of the delayed build up of palettes when hovering
> over icons?
>
> 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.

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.

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.

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?

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.

Eben

[1] Incidentally, one of my major complaints with the "resume by
default" behavior is that it makes starting new activities hard to do,
and virtually impossible to do without using a secondary action, which
is the wrong approach in my mind. I think starting from home, with the
option to resume, while encouraging one-click resume from the Journal
is still the correct approach.  I think offering the option to enter
"resume by default" mode is great, but I'm not sure it should be,
itself, the default for Home view.

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.

Eben



> Regards,
>    Simon
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


More information about the Sugar-devel mailing list