Hi Sam,
This is a fine proposal and I cannot fault your 15 points.
One comment, some are essential, "first ten minutes of use issues" and
some might be seen as essential to getting productive.
Of course onboarding runs at many levels, and may be significantly
different for different user groups.
Hi Sam,
Nice proposal.
A few releases ago, OLPC images included a activity named Welcome [1]
that included just images to explain the basic operations in Sugar.
At the time, olpc images included a patch to run that activity in the first
run,
(the activity can run from the command line too [2]).
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
Hi, Sam
What is our contextual help system? Do you mean right-click popups?
Your proposal mentions the need for a simple trigger. The help button
(or a sub-option) should invoke the class specifying a particular
onboard 'tutorial'.
For Python that seems very straightforward.
Yes, there is
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
I think this is becoming unproductive so let's move on. 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 -
Hi, James
This thread is growing but each time there is new information.
At least as of 0.106, Sugar has the backup URL (see
/usr/bin/ds_backup.py and ds_backup.sh). I can't say whether they are being
used.
The primary flaw in ds_backup.py is that it performs an rsync (with -d).
This means
No, ds-backup is not part of Sugar.
As I said before, Sugar itself does not use the backup URL. I've
checked the Sugar code already.
ds-backup (not Sugar) does read the backup URL from GConf schema
/desktop/sugar/backup_url (Given Sugar has migrated to GSettings,
so too should ds-backup).
Hi, James
One of the big problems in our community is the disconnect between the
school server and the XO. The two work together form a system.
Ejabberd supports gabble which is how collaboration works for XOs
connected to a school server. The design of the school server has always
made
Sure, but as I said, not really a function of Sugar, but instead of
the operating system that Sugar is installed on. Sugar does all the
right things already. The other things you are using with Sugar, such
as Moodle and ejabberd, are also somewhat out of scope for Sugar.
On Mon, Dec 28, 2015 at
Hi, James
This issue of supporting more than one user per machine is very
important in the wild (not many deployments can afford literally one
laptop per
child and so provide classroom sets with each laptop having multiple users.
On registration, a new user is created server-side: the serial
Thanks Sam!
I like the design. It reminds me of one we discussed in Netrek
development at about the same phase of the project lifecycle; long
after the peak of interest.
It doesn't look like it would be much programming.
It could involve sound as well; as reinforcement of each goal.
It could
Yes, but we're talking about Sugar here, not the XO. Sugar supports
more than the XO.
Sugar supports a school server using the register feature, which sets
a Jabber server and a backup URL.
Sugar uses the new Jabber server as a replacement for the default
provided by Sugar Labs.
Sugar does not
Hi All,
Sugar has a novel user interface, with lots of beautiful and logical
things. However, there are some important elements (such as the frame or
journal) that are not familiar or intuitive to new users. This is an
issue, as sugar currently relys upon exploration as our only user
onboarding
Hi, Sam
Excellent proposal. We should solicit community input on additional
items which experience users need to learn to get comfortable with using
the XO.
I think your implementation involves too much programming. Perhaps a
youtube style screencast walkthroughs and posters would be an
15 matches
Mail list logo
