Hi Mikus,

On 4 Jul 2010, at 06:45, Mikus Grinbergs <mi...@bga.com> wrote:

>> The down side is that every activity start would be then be two clicks, one 
>> to bring
>> up the large dialogue (I like to think of it as a one page gallery), and one 
>> for new
>> or resume choice... But that was partly the point, no one here could agree 
>> on a new
>> or resume default behaviour, so there needs to be an extra user end 
>> decision, just to
>> settle the UI feud and allow us move on, to more gainful tasks.
> 
> If the user needs to choose case-by-case whether to launch new or
> resume, if he wants to "resume" he can go to Journal (one click) and
> launch from there (second click) -- whereas if he wants to launch new he
> can go to Home, hover, and (one click) 'Start' in the existing palette.

That's how the Sugar UI used to be. Users ended up launching new activities 
most of the time bringing the machine to it's knees, filling the Journal with 
junk entries, and then not being able to find what they want when they do look 
in the Journal to resume something. 

> For those users who consistently "resume" all the time, provide a
> setting within the control panel to override the directly_on_Home_icon
> first-click behavior (perform "launch new" vs. "show menu of resumes").
> If "frame" behavior can be specified by user, so should "home" behaviour 

I think that choice needs to be much closer and explicit in the new/resume user 
action, it's a choice you make each time based on your current goal. Pushing 
that choice into the CP would  be pushing the default choice to deployers 
making builds who would then be stuck in the same loop (default resume == kids 
often manually wipe past work; default new == kids often OOM machines and fill 
Journal with junk entries).

Regards,
--Gary 

> My $.02   mikus
> 
> _______________________________________________
> olpc mailing list
> o...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/olpc
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Reply via email to