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

[Manuel Quiñones]

Hi Gary, hi everybody,

El día 9 de marzo de 2012 21:09, Gary Martin
<garycmartin at googlemail.com> escribió:
> Hi Manuel,
>
> On 9 Mar 2012, at 03:36, Manuel Quiñones wrote:
>
>> Hi Gonzalo,
>>
>> El día 7 de marzo de 2012 09:37, Gonzalo Odiard <gonzalo at laptop.org> escribió:
>>> We receive many times request about adding help in the activities,
>>> and if is true Sugar propose a exploratory approach,
>>> not all the people learn in the same way,
>>> and there are people who prefer a little guidance.
>>>
>>> For the development we need a simple api, and easy i18n,
>>> and a non obtrusive experience for the user.
>>>
>>> Inspired by the DescriptionItem, I was experimenting with a widget to add
>>> simple help to activities.
>>> This is not:
>>> * A manual
>>> * Lessons
>>> * Tips
>>> Is a short startup help for the activity.
>>
>> I think tips can be better than direct guidance.  "Do this, then do
>> that" manner is counterproductive for exploration.  Of course tips can
>> be ordered in a convenient way, is a matter of manners.  Would be
>> better to see each section at once instead of a large scrollable list.
>> I imagine a slideshow with back/forward buttons.
>>
>> Also I think visual help can be used instead of text when possible, so
>> would be great if the widget allows it.  Images can be understand by
>> early children, and are universal, so no need to translate.  Of course
>> a little paragraph below the image can be convenient too.
>>
>> Here is a mockup I did for the same activity with this ideas:
>>
>> http://dev.laptop.org/~manuq/simple_help_mock.png
>>
>> What do people think?
>
> I think Gonzalo's mockup is a more attainable goal for most activities, it's using standard UI feature designs as used already else where in Sugar, and introduces no new metaphors (e.g. the iOS/iTunes like page dots). The trick (in either case) will be to keep them short and to the point, too much text, or too much fine detail and few will read much of them – writing the one for Calculate or Write is going to be a challenge to get right ;-)

I think we should not be afraid to add new metaphors if this allows a
better user experience to the children.  I find an image with
highlights, circled items and lines, a better explanation for an
interaction than just text.  Of course text-only can be left as a
fallback, and we can concentrate in designing nice startup graphics
for the core activities.  I would like to see the text-only also
having this slideshow view, so there is not too much text shown at the
same time inside a scrolled window.  Separated by sections / tips.

> At a side note, many iOS apps take the startup help route where they provide a graphical overlay that indicates what each button does (sometimes several overlays are needed for each different app view). These provide plenty of flexibility to the developer for the types of information they include (mixed text, graphics, even animation), and they place the help in context next to the real widgets; however they are harder to localise for more than a few languages and require reliable alpha compositing support for fullscreen overlays (ideally through hardware). Folding this information into a single palette, as per Gonzalo's mockup, looses the spacial information context (though the existing palette hints are still there for context if needed), but it seems a good design for us to provide some additional information and help point a user in the right direction.

Yes, that help in context is so much more nice because it shows next
to the real widgets.  I think something similar is doable now with the
GtkOverlay widget, but only for GTK+3.

OK!  I will try to resume the topics raised in this thread.

I think we should distinguish A. a startup help, and B. a complete
documentation for an activity.

A is for helping the children to get started quickly, should be inside
the activity, and should not be exhaustive.  That is, should not
describe the most advanced topics (just gets you started).  I will
focus on this one (A).

Ideally this would not be needed, as the child with her/his curiosity
is able to discover the usage just by touching buttons and seeing the
results in the screen, that is, interacting.  But for complex
interactions that require a few steps, will be helpful, if the
activity design can't get simpler.  To put a bad design example of my
own, the stamps in Paint: first make a selection, then select the
stamp tool, then change size, then stamp.. ouch, hard to discover and
such a simple tool.

Also, for getting started, filling the blank canvas with samples would
be better than a startup help.  For example in Jukebox, we can start
with a playlist of all the medias in the Journal.

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.

Back to A, the current possibilities are:

- gonzalo's code with text and icons in a scroll
- my mockup, a slideshow of startup tooltips with graphics
- the iOS apps overlay in Gary's comment (we should check if doable)

Cheers,

-- 
.. manuq ..