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 <garycmar...@googlemail.com> > Hi Mikus, > > On 4 Jul 2010, at 20:23, Mikus Grinbergs <mi...@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 > > o...@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/olpc > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
