[IAEP] [Sugar-devel] [DESIGN RFC] Onboarding

[Sam P.]

Hi Tony,

Thank you for the comments on the proposal.

(For context, by onboarding I refer to the users first run experience.
Similar to [1].  Specifically something that helps them understand the
basics of sugar)

>From an implementation perspective it is important as you note to bind to
widgets rather than hard coded positions and recognise when the user
completes the task.  I think from that perspective, it would be very
complex to use a JSON file.  I would much prefer to have a singleton class
"Onboarder" (or whatever) which would have 2 main methods.
 "add_hotspot_over(hotspot, widget)" and simmilar for other places that
hotspots are placed over and "signal_hotspot_completed(hotspot)" which
signals that a hotspot has been completed.  There would then be a separate
list of hotspots and their content.  Having more of the implementation in
python in will give this flexability.

I feel that adding lots of different tutorial in different places almost
conflicts with our contextual help system (the help window that pops up).
I think that adding a small initial explanation/tutorial is a different
issue and targets a different need.  Does this need to be added to the
onboarding though (how to open the help)?

Supporting the F6 frame activation could be added, I will mock something up
tomorrow.

Earlier you mentioned that design should use more icons than text.  I think
that I could show screen shots of the expected result.  However, sometimes
I personally find icons can be more vauge than text for explaining ideas,
and I believe that some users may feel a similar way.  Therefore I believe
that the supplementary copy could be helpful for many users.  However, I
you point out the issue of translation loads.  Should the copy be hidden if
text is not available in the same language?

Thanks,
Sam

[1]  https://useronboard.com

On Wed, Dec 30, 2015 at 6:24 PM, Tony Anderson <tony_anderson at usa.net>
wrote:

> Some thoughts:
>
>     Trigger this with the help button (see TurtleBlocks). If there is
> already a help, make the help button show options:
>         help
>         tutorial: how to launch an activity
>
> where tutorial is the Onboarding implementation. It should be possible to
> have more than one tutorial with some description of the purpose.
>
> Add a help button to the left of the home view button on the home view and
> the list view (list view help gives tutorial on list view.
> Add a help button to the right upper corner of the frame.
> Add a help button on the bottom bar of the Journal view (away from the
> mount icons but not in the far corner to avoid conflict with the frame)
> Add a help button on the top bar of the neighborhood and group views (to
> the right, away from the corner)
>
> Implement the system so that activity author/maintainers can create their
> own help button tutorials.
>
> Use a list of jsons to define the steps in the tutorial:
>     [{'hotspot':'x,y,w,h','click':test for completion,....}
>
> On the home view, at the deployments I support, pressing the alt key makes
> 'always start new' the default. This makes it easier to separate a
> deliberate attempt to resume a task (from the Journal) from a new task
> (from the Home view). With the above approach, the home view tutorial can be
> easily modified.
>
> For the frame, the corners are disabled so that the frame is only
> available from the frame key. This is essential for the original XO-1
> keyboard since moving the cursor to stop an activity almost invariably
> covers the button with the frame. It would be nice if the tutorial
> implementation had a way to show a keyboard hotspot (e.g. a on-screen
> keyboard) to show how to access various views from the keyboard.
>
> In the context of the proposal:
>
>     Onboarding goals should be supported by the implementation but not
> limited.
>
>     User flow: user clicks on help button and clicks on tutorial (if more
> than one option).
>                     home view tutorial shows how to launch an activity -
> but an activity has it's own help button and tutorial
>
> When a user completes an onboarding task, the window should flash through
> a huge tick, then fade away.
>                     a new hotspot appears to set up the next task.
>
> The image in the popup could be a screen shot showing the expected result
> of the previous task.
>
> So, in general, the tutorial definition should be separated from the
> tutorial mechanism.
>
> I suspect the 'hotspot' implementation to be relatively easy but the
> tricky code will be to determine whether the task was executed correctly.
>
> The hotspot mechanism must be able to handle changes. Suppose that a home
> view tutorial sets a task to launch 'Record' by placing a hotspot around
> the Record icon. The mechanism needs to find where the Record icon is on
> the home view, not just position it where Record shows in a
> freshly-installed Home View. The user (or deployment) could have added or
> removed activities from favorites.
>
> Tony
>
> On 12/29/2015 03:55 AM, Tony Anderson wrote:
>
>>  The important thing is Sam's proposal and its implementation.
>>
>> Two considerations:
>>
>>      1) Make the implementation scriptable as much as possible so that
>> new help scenarios can be easily implemented in the wild.
>>      2) Minimize text - emphasize icons. For example, a standard 'click'
>> icon. This reduces the stress of making translations.
>>
>> Tony
>>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20151230/0b77fe2f/attachment.html>