[Sugar-devel] UI experiments: pop-up menus and hot corners

[James Zaki]

Hi all,

For what its worth on this topic, I agree with automatically taking the
resume option (from what I've read in this thread, the more probable and
less problematic).

But could you add a message hint that then dissappear after some seconds ?
For example, when you launch, and auto-resume last saved work, a discrete
message appears and after some time dissappear (fade, or slide away), say 5
or so seconds.
For example a title with a button (eg: "This is <journal title> ..." ["start
new instead?"]
)  that descends from the top just beneath the menu (like web browser
notifications)

James.


2010/7/5 Gary Martin <garycmartin at googlemail.com>

> Hi Mikus,
>
> On 4 Jul 2010, at 20:23, Mikus Grinbergs <mikus at bga.com> wrote:
>
> >>>> some current (ongoing) future design changes will remove this issue
> completely with a
> >>>> full screen screen dialogue for deciding new/resume. One click on a
> home view activity
> >>>> displays a gallery/journal like display of past work or a new blank
> template
> >>
> >> 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.
> >
> > What this design change will do is deliberately introduce a 'pause' into
> > the process of launching an Activity -- to force the user to evaluate
> > "why am I launching?"  What I am wondering is whether "force decision
> > before launching" is more user-friendly than simply "launch".
> >
> > If the problem is "users filling up the machine",
>
> No, sorry if I wasn't clear in my explanation, it's not users filling up
> their disk space that this design effort is trying to resolve (most Sugar
> activities have very small Journal entries). Having 'start new' as the
> default home behaviour leads to many concurrently open activities, often
> bringing the machine to a grinding halt due to OOM. The Journal also fills
> up with more junk entries (making it harder to search though and find work
> to resume from).
>
> > will making it more
> > difficult to launch a new instance be an adequate solution ?
>
> The new design strives to make resuming and 'start new' behaviours of equal
> priority in the UI. The current version of Sugar has resume as the default
> behaviour (since 0.84) in an attempt to resolve the flood of deployment
> feedback about the above mentioned lockups due to OOM and Journal spam. We
> now have feedback that 'start new' is too hidden and that kids are often
> resuming recent work and manually erasing the canvas to start something new
> (I've seen this happen first hand, child asks in Paint how to make a big
> brush, and then paints out their previous work with white; also I've started
> to see requests for activities to have a clear all tool button for much the
> same reason).
>
> So the new design work will make 'start new' more visible than with the
> currently released Sugar.
>
> > Will the
> > kid who wants to make a new drawing on Tuesday be content with resuming
> > the activity he used Monday -- thereby wiping his drawing from Monday ?
>
> She might want to paint some more on Mondays painting, or start something
> new. We're trying to put that choice equally up front for her before the
> activity launches, though I accept this adds an extra click/decision to
> every activity invocation. FWIW: We could leave in the alt-click 'start new'
> home short cut for those expert users who know they want a fresh activity
> session and no dialogue.
>
> > Forcing a decision on every launch may work -- but there still needs to
> > be a user-helpful way to address "I've filled up the machine" when that
> > happens -- for those who nevertheless persist in overusing "new launch".
>
> Yes, this is a separate design issue we are not trying to fix with this
> specific work. There are already a couple of features. One is that a warning
> dialogue pops up when you've filled N% of your flash, and switches you to
> the Journal and asks for you to remove things — it's better than nothing but
> I've not found it useful so far, it keeps dragging you back to the Journal
> view, usually I'm trying to get back to Terminal to stop a yum, a git clone,
> a file curl/wget :) The other is I think something new Bernie has been
> experimenting with, basically a last chance saloon script that auto deletes
> some activities, so that the machine can at least be booted.
>
> Regards,
> --Gary
>
> P.S. We keep slipping on a date/time for the next irc #sugar-meeting design
> meeting, folks are most welcome, Christian has some nice mockups he's been
> polishing up for publication. We're trying again for tomorrow/Monday, but no
> time confirmed just yet.
>
> > [Would an "ultimate" design propose to make the machine be the master
> > over the user -- and employ this full screen launch dialogue to refuse
> > launch whenever the machine approaches "being brought to its knees" ??]
> >
> > mikus
> >
> >
> > p.s.
> > The Journal user-interface was invented, with a "filter" capability.
> > Now a full screen dialogue user-interface would be duplicating what the
> > Journal can show.  I myself am not comfortable with duplication.
> >
> > _______________________________________________
> > olpc mailing list
> > olpc at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/olpc
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100705/b5b10aa4/attachment.html>