Sorry to disagree: * I prefer wiki-style pages to mallard as users are used to them (as they use wikipedia) and are more maintainable. * Making a weird question to the user that's asking for help before moving him out to another activity doesn't seem much helpful to me :-S
Saludos, Pablo Flores 2012/3/18 Walter Bender <walter.ben...@gmail.com> > 2012/3/17 Gary Martin <garycmar...@googlemail.com>: > > Hi Manuel, > > > > On 17 Mar 2012, at 18:38, Manuel Quiñones wrote: > > > >> El día 15 de marzo de 2012 10:48, Pablo Flores <pflor...@gmail.com> > escribió: > >>>> For B. either mallard (like GNOME does) or a wiki page can be used. > >>>> We can add a shortcut in the activities to open them. > >>> > >>> IIUC it would be a button that would open Browse with the activity's > help > >>> pages, right? I like this idea. In this case, there should be for every > >>> activity a core documentation that keeps maintained and can be > installed > >>> (for having help even being offline... and for being sure the > documentation > >>> corresponds with the version of the activity and sugar that's being > used). > >>> > >>> If we're going this way, having the wiki pages of activities updated > would > >>> be a high priority when it comes to Sugar documentation (to be > considered > >>> for the April's documentation sprint participants). It would also > require > >>> this documentation to be updated every time a new version of the > activity is > >>> developed with changes to the user experience (to be considered in the > >>> development cycles). > >> > >> Yeah, also see mallard, GNOME apps use that: > >> > >> http://projectmallard.org/ > >> > >>> BTW I'm afraid jumping into the browser when looking for help may be > >>> confusing for unexperienced users, but I don't have a proposed > solution for > >>> this :( > >> > >> We should come with a real solution for opening one activity from > >> inside another, in a way that is not disturbing for the little user. > >> That is, we should ensure that she/he _wants_ to do it. > > > > I think I've mentioned this once before, but how about if we use the > Sugar alert strip UI, much like we use it in Browse 'Show in Journal' when > an object is downloaded? It would be something like a 'Start <object_title> > with <default_activity>?' message. This would allow the user to Cancel if > triggered by mistake (or maliciously/automatically), and mean the user is > directly interacting with the dialogue to trigger the activity Start. It > would need to be a new type of Sugar shell alert, I guess, for security > (e.g. Sugar shell enforces the user interaction handover before the object > is started by the new activity). > > +1 if used with some discretion. We should come up with some clear > guidelines as to when to do this. > > > > Note that this generates a NEW activity object in the Journal each and > every time an activity is used to launch another with an object. You would > need to use the Journal (or home view) to resume an already created object > if you didn't want another new instance generated (ideally the FS or > datastore is/would be smart enough when identical unmodified objects are > created to save storage space). > > > > Regards, > > --Gary > > > >> -- > >> .. manuq .. > > > > _______________________________________________ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel