[Sugar-devel] [DESIGN RFC] Onboarding

[Tony Anderson]

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 - emphasize icons. For example, a standard 
'click' icon. This reduces the stress of making translations.

Tony

On 12/28/2015 10:23 PM, James Cameron wrote:
> 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).
>
> Sugar developers do not maintain ds-backup, and it is not in the other
> operating system builds that use Sugar.  So it can be ignored unless
> Sugar developers want to help the school server developers somehow.  I
> don't think anybody here has time for that.
>
> On Mon, Dec 28, 2015 at 04:06:26PM +0200, Tony Anderson wrote:
>> 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 if a user deletes a Journal object on
>> the XO, it will be deleted from the backup. Since users often delete
>> Journal objects to free space, this means those items are lost.
>>
>> The strategy I use is to back up Journal objects individually. The
>> 'keep' star is used to control backup and restore. If the user
>> clears the keep,
>> the backup deletes the local document to free space. if the 'keep'
>> star is set, the backup downloads the document. In this way, no
>> student's documents
>> are lost because of storage limitations.
>>
>> When storage is full (the infernal modal dialog you get 'Your
>> Journal is Full'), common practice is to reflash the XO. In this
>> context restoring the Journal simply recreates the original problem.
>> Incremental backup means that the restore only restores the
>> metadata, the documents remain on the school server. The user can
>> request individual documents be downloaded to the XO as needed.
>> The fact that the backup and restore control panel doesn't support a
>> school server doesn't surprise me - it is characteristic of the
>> disconnect I am
>> referring to. Integrating Sugar with the school server causes
>> problems for users (and developers) who do not have one.
>>
>> There are those who feel the goal of OLPC (the concept not the
>> organization) is to provide one laptop per individual child working
>> at home as is
>> typical in the developed world. This allows the comfortable
>> assumption that users have access to the same resources as the
>> developers (continuous broadband internet, for example).
>>
>> However, my involvement and I believe that of many others is to
>> support deployments in the developing world which provide one laptop
>> per child
>> in a community school in the developing world (or developed world)
>> where internet access is rarely possible or is too expensive or too
>> slow. In this environment, the schoolserver provides a means to give
>> the students local access to information from the internet.
>>
>> Where funding is insufficient, more than one child may need to share
>> a laptop. As Walter Bender described it in the Malaysia Summit, 'one
>> laptop per child' means there are enough laptops that each child in
>> the group has their own to use at that time.
>>
>> In such deployments, there is rarely enough funding for extra
>> equipment such as usb keys, external hard drives and so on. It is a
>> design goal to
>> satisfy requirements with the resources available (including the
>> school server and  related network support). Since the XO has
>> limited storage, backing
>> up the school server is essential to preserving the documents
>> produced by the users (not just for hardware failure, but more
>> importantly to handle the situation when available storage falls
>> below 50MB).
>>
>> The login at install time is not needed. However, the code could be
>> re-used to provide a standard session login with multiple users
>> sharing a laptop.
>>
>> Tony
>>
>> On 12/28/2015 09:20 AM, James Cameron wrote:
>>> 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 use the backup URL.
>>>
>>> Sugar's backup and restore control panel is for local media only;
>>> there is no backend for a school server.  Your school server
>>> maintainers don't appear to have noticed the disconnect.
>>>
>>> The move to system packaged activities instead of user directory was
>>> not a significant change in our Ubuntu integration.  That work was
>>> already led by Debian.  Similar had been done by Fedora SoaS years
>>> before.
>>>
>>> I've no plans to restore a login to the XO images.  This isn't
>>> something that OLPC needs.  We'd prefer that each child have a laptop.
>>>
>>> On Mon, Dec 28, 2015 at 08:02:27AM +0200, Tony Anderson wrote:
>>>> 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
>>>> Moodle the opening screen for http://schoolserver (which is where
>>>> you are directed by the button on the Browse main screen).
>>>>
>>>> I think you made some modifications to Sugar for the Ubuntu version
>>>> such as moving the Activities folder to common space. This would
>>>> also have to
>>>> be done for the XO images. I suppose you could consider backup and
>>>> restore of the Journal out of scope of Sugar as well - but it is
>>>> essential for laptops with minimal storage. This is what the
>>>> 'register' menu option is about. While Ubuntu provides a login, this
>>>> would have to be restored to the XO images.
>>>> I am sure there are other issues that will come up.
>>>>
>>>> However, you have provided an exciting opportunity.
>>>>
>>>> Tony
>>>>
>>>> On 12/28/2015 07:47 AM, James Cameron wrote:
>>>>> 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 07:32:59AM +0200, Tony Anderson wrote:
>>>>>> 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
>>>>>> number of the laptop. This is used for login to Moodle but more
>>>>>> importantly for backup of the Journal and for ejabberd (association
>>>>>> between nick and serial-number).
>>>>>>
>>>>>> It would be relatively easy to make the registration procedure
>>>>>> create a username account on the school server and to
>>>>>> backup to and restore from that account. Moodle can be fixed
>>>>>> relatively easily. I am not familiar with the details of ejabberd
>>>>>> and
>>>>>> collaboration so that will require some research
>>>>>>
>>>>>> I'll be able to give this serious attention when I get back to the
>>>>>> Philippines in
>>>>>> late January. You have created a very exciting opportunity for Sugar.
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/27/2015 11:51 PM, James Cameron wrote:
>>>>>>> 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 show progress more clearly; a series of "achievements" which
>>>>>>> are "unlocked".
>>>>>>>
>>>>>>> Trivial text layout error in the design makes reading it difficult;
>>>>>>> most visible in the "Interface Design" text before the next image,
>>>>>>> where forced line breaks occur, after "yet" and "overlays".  Probably
>>>>>>> caused by browser width not varied in testing.
>>>>>>>
>>>>>>> Some hasty JavaScript might show animation of hotspot engagement.
>>>>>>>
>>>>>>> A definition of onboard may be useful.
>>>>>>>
>>>>>>> I'm interested in seeing more.
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Tony raises some important problems, several of which are not
>>>>>>> functions of Sugar, but of software integration choices made by Sugar
>>>>>>> downstream organisations.  The most interesting one for me personally
>>>>>>> is how to support more than one user per machine, but this isn't
>>>>>>> something that OLPC needs, so the wider community should drive it
>>>>>>> forward.
>>>>>>>
>>>>>>> A school server with accounts, a login greeter on the laptop
>>>>>>> integrated with the authentication server, and a locally cached
>>>>>>> network filesystem?  Perhaps the school server guys and gals could
>>>>>>> look into it?
>>>>>>>
>>>>>>> Meanwhile, in my experience, Sugar handles multiple login users very
>>>>>>> well already.
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Sugar-devel mailing list
>>>>>> Sugar-devel at lists.sugarlabs.org
>>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>> _______________________________________________
>>>> Sugar-devel mailing list
>>>> Sugar-devel at lists.sugarlabs.org
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel