2012/3/17 Gary Martin <[email protected]>:
> 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 <[email protected]> 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
> [email protected]
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
_______________________________________________
IAEP -- It's An Education Project (not a laptop project!)
[email protected]
http://lists.sugarlabs.org/listinfo/iaep

Reply via email to