[Sugar-devel] UI experiments: pop-up menus and hot corners
garycmartin at googlemail.com
Sun Jul 4 12:37:47 EDT 2010
On 4 Jul 2010, at 06:45, Mikus Grinbergs <mikus at 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).
> My $.02 mikus
> olpc mailing list
> olpc at lists.fedoraproject.org
More information about the Devel