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

[Wade Brainerd]

+1 from me!

Resume by Default inhibits learning the difference between "Activity"
and "Activity Instance" which is a key computer concept.

Back-porting to 0.84 and 0.86 sounds great to me; is the patch simple?

-Wade

On Wed, Oct 28, 2009 at 2:14 PM, Gary C Martin <gary at garycmartin.com> wrote:
> 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
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>