[Sugar-devel] RFC:Simple Help widget for activities

[Walter Bender]

On Tue, Mar 20, 2012 at 3:29 PM, Pablo Flores <pflores2 at gmail.com> wrote:
> Sorry to disagree:
>
> * I prefer wiki-style pages to mallard as users are used to them (as they
> use wikipedia) and are more maintainable.

I am not sure that wiki pages are "more maintainable". What wiki
markup do you suggest? Mediawiki? If does have the advantage that it
is used by Wikipedia, but it is somewhat more cumbersome than mallard,
IMHO. W/O a WYSIWYG editor, I am not sure there is much advantage one
way or another.


> * 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

Not sure what you are referencing here. Personally, I think we could
use a simple help such as Gonzalo proposed and a
manpage/wikipage/pdfpage that is viewed in the browser (maybe let the
activity developer decide and specify in activity.info) that is
invoked from the Home view or Frame menu for the activity.

-walter
>
> Saludos,
> Pablo Flores
>
>
>
> 2012/3/18 Walter Bender <walter.bender at gmail.com>
>>
>> 2012/3/17 Gary Martin <garycmartin at 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 <pflores2 at 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 at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org