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

[Gary C Martin]

On 14 Oct 2009, at 17:39, Eben Eliason wrote:

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


Just wanted to ping the list with a mockup and comment I've attached  
to a trac ticket regarding reverting the 'resume by default' home view  
feature:

	http://bugs.sugarlabs.org/ticket/1382

The direct link to the mockup image is:

	http://bugs.sugarlabs.org/attachment/ticket/1382/home_mockup_with_start_new_as_default.png

One worry I have is that we're generating feature churn, especially if  
OLPC starts shipping real quantities of 0.84 in a few months... Sugar  
0.82 starts new activity instances when clicking activity icons in the  
home view, we came up with the 'resume by default' design solution to  
help resolve the deluge of feedback from deployments about 'Journal  
spam' and teachers/kids not being able to easily enough find and  
resume recent work via the Journal.

Regards,
--Gary