[Sugar-devel] GSoC proposal status

[Walter Bender]

I added a section "Sugar on the Ground". I left out the "not Sugar"
projects: flashing XOs, anti-theft. I added a few of the more controversial
UI proposals, but they merit discussion. IMHO, we made a mistake when we
removed the obligatory "commit message" when exiting activities.

-walter

On Sat, Feb 20, 2016 at 2:14 AM, Walter Bender <walter.bender at gmail.com>
wrote:

> Thanks Tony. I'll give this a careful read in the AM. I'm at the end of my
> productive energy level at the moment.
>
> -walter
>
> On Sat, Feb 20, 2016 at 2:00 AM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi, Walter
>>
>> I have some concerns about the proposed GSOC tasks as well as some ideas
>> for new tasks.
>>
>> I agree that the Journal needs rethinking. Below are my thoughts
>> (re-thoughts?).
>>
>> Specifically,
>>
>> The Journal is the file system for Sugar. It does not use directories but
>> instead was intended to collect objects by tag (a la Picasa). Currently,
>> the user sees
>> a scrolled list of objects in chronological order. However, selection is
>> by activity or media type, not by a user defined criteria (as represented
>> in other systems by the directory).
>>
>> The Journal acts as an activity with awkward consequences for the user.
>> On the keyboard, the icon for the Journal (a magnifying glass or search
>> icon - not the icon shown in the frame) is to the left of the zoom group on
>> the keyboard and to the right on the frame. If the Journal is selected, it
>> replaces the current activity when the activity key is pressed. It also
>> appears as an activity when using alt-tab. The first makes using
>> screenshots awkward. Screenshots are given a title by the system of
>> 'Screenshot of ....'. The user needs to switch to the Journal to provide a
>> meaningful name. However, the user must open the frame and click on the
>> activity icon to return to it. If the Journal were viewed as a Sugar
>> service, the activity key would return the user to make another screen shot
>> or continue whatever the task is. Similarly, it is convenient to present
>> the user with instructions to perform a task using a Sugar activity (e.g.
>> Write). The instructions can be given by a web page or by a document in a
>> different activity. For example, a user could show a flag as an image in
>> Image Viewer and try to duplicate the flag with TurtleBlocks. However,
>> using alt-tab to switch between the activities requires cycling through the
>> irrelevant Journal activity or open the frame to click on the activity icon.
>>
>> More importantly, when a Journal object is launched from the Journal
>> activity, it is immediately loaded into activity.py. Therefore, any
>> subsequent action by the user will be saved and the previous object will be
>> overwritten. Suppose I resume the Paint Activity to continue making a
>> picture. However, I decide that after some strokes, the original picture
>> was better. There is nothing as a user I can do to revert to the original.
>> I suspect the reference to git may be intended to address this problem.
>> When an object is launched, activity.py should make a clone. The user
>> should then have the option to revert to the original or to overwrite it or
>> to change it's name so that a new object is created alongside the original.
>> I believe an implementation of the 'save/save as' logic of virtually all
>> other systems should be provided.
>>
>> Probably, in the interests of 'reflection' or possibly statistical data,
>> the Journal saves every activity instance - by default with the name of the
>> activity. Further,
>> most activities now implement write_file to create a data file associated
>> with the object. This creates clutter in the Journal and takes storage for
>> meaningless data files. For example, the Browse activity saves a data file
>> containing URLs of open tabs. Aside from the fact that this creates
>> spurious error messages if Browse is opened in a different network
>> environment, it creates the unnecessary need to save a data file. I believe
>> that activities should only save a data file if the user supplies a name
>> for it and that activities should save state in the metadata, not in a data
>> file. Naturally, it may be desirable for Memorize to save its state so the
>> user can resume the game - this can be done by a field in the metadata.
>> However, when the Paint Activity saves a file, it is reasonable to assume
>> it contains an image (usable, for example, by the Image Viewer).
>>
>> The XO has limited storage capacity. A freshly installed XO-1 image
>> leaves about 300MB free space. A freshly installed image on other models
>> with 4GB capacity leaves 1.9GB free space. Today, it is almost impossible
>> to buy a USB stick with 2GB storage or less. When the available storage is
>> less than 50MB, the user sees a modal dialog saying the Journal is full
>> with the only option to look at the Journal. The Journal activity shows the
>> amount of available storage which could help a user avoid going below the
>> 50MB limit but is no help to correct the problem. Currently Sugar provides
>> no help to the user in dealing with this problem. Most deployments I am
>> familiar with reflash the laptop when this happens. So much for reflection.
>> Essentially this step erases the user's prior work.
>>
>> Journal backup, according to James Cameron, is beyond the scope of Sugar.
>> The present Sugar-independent (?!?) scheme was developed by Martin Langhoff
>> using rsync to create snapshots on the school server. This was a bad
>> decision. If a user deletes an object from the Joural on the XO to create
>> space, that object is deleted from the backup. The backup should be
>> considered the actual repository of Journal entries with effectively
>> unlimited space and the backup on the XO should upload new and modified
>> objects to that repository. Further the user should have a way to recall
>> data files from the repository as needed. In general, the limited storage
>> on the XO should be viewed as a cache of the users' data kept on the school
>> server.  Consider that OLPC recommends a minimum of 2GB storage on the
>> school server (/library/users) per registered laptop. However, at most, the
>> user has 1.9GB on the XO (which includes optional Sugar activities and
>> optional media and e-book downloads).
>>
>> The proposed GSOC tasks include statements such as: "This idea needs more
>> thought and coding." I believe SugarLabs is responsible for doing the
>> thought and proposing the guidelines for implementation. This is not an
>> appropriate task for a GSOC participant. One of the obvious problems as a
>> Mentor in last years GSOC is that the participants had no experience with
>> or understanding of Sugar or how it works on an XO. The development
>> environment gives the developer many capabilities not available on an XO
>> (fast gpu, large memory, effectively unlimited storage, 24/7 high speed (>
>> 1MB/s) access to the internet, 1080p screen resolution and aspect ratio).
>> Further, Sugar on the development environment is not available on the XO
>> (and vice versa). Asking participants from this environment to design ui
>> for users on the other side of the digital divide requires an unreasonable
>> expectation of their ability to empathize.
>>
>> I would propose these tasks more as follows:
>>
>> 1. Brief explanation The Sugar Journal should provide a 'save/save as'
>> interface which should enable a user to choose whether to save the current
>> document when an activity is closed. The interface should require a name
>> change from 'current.activity' to a user supplied name. If the document is
>> derived from one currently saved in the Journal, the user should be allowed
>> to save (overwrite) or save as (create new document) by giving a new name
>> to the document. This could be accomplished by showing a modal dialog at
>> close time requesting the user to supply a name or not save the document.
>> If the document has a user supplied name, the dialog could request the user
>> to save or to provide a new name to create a new document.
>> Note: this approach satisfies the needs referenced in the git task. Git
>> is a little like a hammer looking for a nail. Using git for this function
>> will likely double the size of the data stored in the Journal (based on
>> normal experience using git). Unfortunately, we don't have this space on
>> the XOs. The standard
>> save/save as gives the user the ability to manage versions by using
>> unique names.
>>
>> 2. Brief explanation
>>         The Journal activity is currently implemented as an activity. It
>> should be changed to a 'service'. This means the Journal icon on the frame
>> should be to the left of the zoom group icons to match the sequence on the
>> keyboard. The Journal is always running as a service when the Sugar is
>> running. It is accessible by the Journal key on the keyboard and also by
>> the Journal button in the frame. When the view is switched to the Journal,
>> clicking on the activity view (right most key of the zoom group) should
>> switch the screen back to the current activity.
>>
>> 3. Brief explanation
>>         Sugar provides a method to backup and restore the Journal (one
>> method to a USB key and one method to the school server). The Journal also
>> provides a select box to enable an action to be taken for all selected
>> objects. This mechanism should be sufficient for the USB key case. However,
>> the school server backup currently is based on taking a snapshot of the
>> current Journal state. This means the size of the objects in a user's
>> Journal cannot exceed the available local store on an XO (300MB for an
>> XO-1, 1.9GB for other models). A mechanism is needed to save on the school
>> server all documents created by the user and to restore a selected object
>> to the Journal from the school server. Since many documents may represent
>> library objects (e-books, audio, image or video media), the mechanism
>> should recognize these and not save them as user documents. However, the
>> metadata saved should enable the system to download the library items again
>> as needed (and, as available).
>>     For example, the mechanism may be to upload Journal documents to an
>> OwnCloud repository. The user could then select an item in the OwnCloud
>> repository to be downloaded to the Journal. The user could also share any
>> item in OwnCloud with other user groups or individuals.
>>
>> Note: This would essentially accomplish the intent of the group/buddy
>> task. Further, OwnCloud could be provided on a school server or on the
>> internet. as appropriate.
>>
>> 4. Brief explanation
>>     One goal of Sugar is to record information about user sessions. This
>> is currently accomplished by creating statistics from the metadata stored
>> in the Journal.
>> Unfortunately, a consequence is that the Journal view fills with
>> essentially meaningless links to this metadata (mine fills with Terminal
>> Activity and Log entries).
>> This makes it much harder for the user to identify meaningful Journal
>> objects (documents, images, items from the library, ...). A mechanism is
>> needed to that session data can be logged independently of the Journal view
>> (i.e not shown on the screen). This logged information should be
>> transferred to a backup repository (e.g. school server or usb drive) as
>> soon as possible and deleted from the local store to free up space. The
>> available reporting activities should be modified to use this new mechanism.
>>
>> 5. Brief explanation
>>     The Journal icon provides information the amount of free space in the
>> user's store. if this amount is less than 50MB, a dialog is shown requiring
>> the user to switch to the Journal view and claiming that the 'Journal is
>> Full'. This message is, at best, misleading. The available storage can
>> arise from several causes - the fact that an activities 'instance' store
>> was not deleted, the space required by installed activities, or space
>> required by data files in /home/olpc/Library, or data stored by activities
>> in 'data', 'instance' or 'temp'. Currently, Sugar provides no guidance or
>> help to enable a user to deal with this problem short of reflashing the
>> image. The goal of this task is to provide a quota management system on
>> storage with a way for the user (e.g. by a special Sugar activity) to
>> analyze the usage of storage and to save by usb key or school server or
>> cloud storage large or currently unneeded items and then delete them. The
>> system should show the user the size of items and provide updates on how
>> much storage has been made free by his/her actions.
>>
>> 6. Brief explanation
>>     In Sugar's Home View, a click on an activity icon by default resumes
>> the most recent instance of the activity. This capability is designed into
>> the Journal and is redundant in the Home View. A Sugar activity is a tool
>> to enable the user to accomplish some task. If that task is not completed,
>> the user can resume it via the Journal. If the tool is to be used on a new
>> task, the user can launch it from the Home View. The current Home View
>> assumes that the intent of the user is to continue the most recent task
>> with that tool.
>>
>> This task should set the Home View default to launch a new instance of
>> the activity. The Alt key should be set to enable resuming a selected
>> instance of the activity.  By serendipity, this also shows the Home View
>> with black and white icons. Icons with color signifying a resumable
>> instance use the colors associated with the laptop. Unfortunately many of
>> these color combinations make the icon much more difficult to distinguish
>> than the black and white version.
>>
>> 7. Brief explanation.
>>      Sugar provides a 'web services' capability. However, these services
>> are only available to an XO which has connection to the internet. This is
>> not useful to a large number of users who do not have internet access. The
>> school server (e.g. XSCE) provides an alternative to the internet for many
>> deployments. This task is to provide a capability on the school server to
>> support some or all of the Sugar web services (e.g. by OwnCloud or ELGG).
>>
>> 8. Brief explanation
>>     There are a number of Sugar activities which currently require access
>> to the internet (InfoSlicer, GetBooks). These activities should have an
>> option to function with the school server. For example, GetBooks could
>> access books on the school server and InfoSlicer could create slices from
>> Wikipedia on the school server as Journal objects.
>>
>> 9. Brief explanation
>>     Sugar users are often new to computers and not familiar with other
>> operating systems. We need a mechanism to allow users to more quickly
>> develop skills in using the capabilities of the XO ('onboarding'). One
>> proposal is to develop scripts which lead the user through a series of
>> interactive steps illustrating common usage of the XO with Sugar (
>> https://www.sam.today/blog/sugar-onboard-design.html). This task is to
>> implement an interpretive system that allows
>> deployments or experienced users to create an 'onboard' script that
>> guides the user to carry out a task. The referenced proposal suggests some
>> user tasks where this mechanism could be employed. Since there is no finite
>> list of these tasks, an interpretive approach enables the scripts to be
>> created as necessary.
>> For example, how does a user switch to the Gnome desktop? A script could
>> be created guiding the user through the necessary steps. How does the user
>> make a screen shot, use Gimp in the gnome desktop to crop and resize, and
>> then insert it as an image in a Write document? How does the user initiate
>> or join a chat?
>>
>> 10. Brief explanation
>>     Sugar is available on the XO and some other platforms. In particular,
>> Sugar is available for 64-bit systems with Ubuntu 14.04 LTS installed (
>> http://wiki.sugarlabs.org/go/Ubuntu). Unfortunately, this procedure does
>> not work with 32-bit systems. There exists an opportunity to deploy Sugar
>> with relatively inexpensive or refurbished laptops which do not provide
>> 64-bit support. This task is to create a comparable version of Sugar which
>> can
>> be installed on 32-bit systems as an alternate Ubuntu desktop.
>>
>> 11. Brief explanation
>>     Many deployments want to protect their XOs against theft. OLPC
>> provides an 'activation lease' mechanism in firmware which makes it
>> impossible to
>> boot an XO once the activation lease has expired, unless the XO has
>> access to the key via a removable device. This task is to provide a similar
>> mechanism which is not dependent on OLPC. A USB key or network device
>> (school server) should have an inventory of XOs identified by serial_number
>> (and, perhaps, uuid). if this key is readable by the firmware, the XO
>> should boot. If the key is not readable (e.g. reflash), then the XO should
>> boot if the key is readable on a removable device or on the connected
>> school server. [this suggests the XO can connect to the schoolserver by
>> firmware alone - might be difficult].
>>     Whenever an XO connects with the network device, the network device
>> should confirm the activation lease and extend it by a time specified by
>> the deployment (administrative owner of the network device). A report
>> should be available to the deployment on the XO inventory and when each was
>> last connected to enable detection of 'missing' XOs. Perhaps, the mechanism
>> should have a 'blacklist' of serial_numbers of 'missing' laptops. If such a
>> laptop is connected, it could be allowed to proceed with a warning to the
>> administrator that the 'missing' laptop is in the house. This mechanism
>> should be available for optional implementation by a deployment without
>> reference to a central organization such as OLPC.
>>
>> 12. Brief explanation
>>     OLPC firmware in the XO-1 supported a feature called 'nandblaster'.
>> This mechanism allowed a 'master' XO to broadcast its image in a loop to
>> the XO Lan. Other XOs could then be flashed by the firmware by making a
>> copy of each sector as it was broadcast to their local store. Once a cycle
>> in the loop was finished, the XO could detach and was ready for reboot with
>> the newly installed image. This task is to re-create this capability where
>> the 'master' XO image could be on a network device such as a school server
>> or another XO. This mechanism should store a new version of firmware (as
>> done currently) so that the firmware upgrade can be automatically installed
>> on the next boot when connected to an AC adapter.
>>
>> 13. Brief explanation
>>     The OLPC model is that each user has full possession and is the only
>> user of an XO laptop. Therefore, Sugar assumes a 1-1 correspondence between
>> users and XO serial numbers. However, Sugar is being used on other
>> platforms (e.g. SOAS), where there is no obvious equivalent to a serial
>> number. SOAS and James Cameron have created versions of Sugar which do not
>> assume the user is 'olpc', but implement a standard username/password login
>> system. The users storage is allocated to his/her home directory.
>>     This task is to create a Sugar image for the XO which allows for
>> user's to login by username and password. The basic task is to move the
>> Activities folder
>> to a common space so that only one copy is needed per system. This will
>> support deployments where one set of laptops are shared across multiple
>> classes (and users) or where there one laptop is shared between two
>> students - one in a morning shift and the other in an afternoon shift.
>>
>> 14. Brief explanation
>>     The TuxMath activity is popular with deployments. However, the
>> upstream version appears to be abandoned. This task would be to implement a
>> sugar-web-activity math game comparable to TuxMath.
>>
>>
>>
>> I have some comments on the other tasks:
>>
>> "The newer Sugar builds have performance issues on *some old hardware*
>> with limited memory. This is keeping some Sugar deployments from upgrading.
>> This project is to look into the performance issues and tune Sugar for
>> low-memory devices."
>>
>> I think this task should be unambiguously focused on the XO-1 (1GB
>> store). The majority of deployed XOs are XO-1s with a 1GB store. These
>> deployments generally do not have the funds to purchase and deploy an SDHC
>> card for these devices (ask Adam about this possibility in Haiti, I was not
>> able to get a firm number from Rwanda but I believe they may have deployed
>> more than several thousand XO-1s. The cost is not so much the card itself,
>> but the logistics cost to prepare the cards with an XO-1 image and to
>> deliver the cards to the deployment locations).
>>
>> The performance problem is not limited to low-memory (250GB). It is also
>> related to no gpu, low persistent store, slower and more limited processor
>> and so on.). It is also likely that their are specific limitations on
>> executing newer software releases on this hardware. As a minimum, someone
>> who takes on this task needs an XO-1 (and possibly access to an XO-1.5 for
>> performance comparisons - a task for the mentor?).
>>
>> One task could be to identify some significant performance measures (a
>> form of benchmark which could be applied to all models and releases to
>> obtain
>> relative performance measures). The task also requires some analysis to
>> determine the bottlenecks limiting performance (processor speed, graphics
>> speed, memory usage, storage access times, etc.). This, in turn, requires
>> defining important workloads (boot, launch activity, switch activities,
>> shut down activity, shut down system, connect to network, effective network
>> speed, and so on). I think the community should be able to help with this
>> (what are the most significant tasks in Haiti which have unacceptable
>> response times on the XO-1?).
>>
>> It is likely that one result of this task may be to limit the
>> capabilities of Sugar on the XO-1.
>>
>> "Now that JavaScript has become a first class citizen in the Sugar
>> ecosystem, we must re-design our collaboration model to allow collaboration
>> between web activities regardless of the platform."
>>
>> I am not sure what is meant here by platform. Except for development
>> environments, I am only aware of Sugarizer, SOAS, and Sugar on XO in the
>> wild (i.e in use by deployments without any developers or computer
>> professionals on site). As I understood it, Sugar has adopted the
>> collab-wrapper model for Sugar activities. Is this collab-wrapper usable in
>> a Javascript environment? Is is possible for XO users to collaborate in
>> this model with users of SOAS or Sugarizer?
>>
>> Nutritional Microworld
>>
>> relevant tool—one that invites learners to explore fundamental concepts
>> of nutrition that are both intrinsic to music yet transcendent of a
>> specific discipline.
>> I assume the reference to music is a typo.
>>
>> At Eurovision 2014, a speaker demonstrated nsound - an alternative to
>> csound. The claim is a simpler and more understandable api.
>>
>> Turtle Confusion and Turtle Flags.
>>     These activities reproduce the Turtle Blocks engine. I think a
>> simpler solution is to provide the confusion images and the flag images via
>> html and have the user create them using the existing javascript Turtle
>> implementation. The user can easily switch screens via alt-tab or the
>> frame. For example, the confusion challenges and the flags could be
>> presented by an .xol content.
>>
>> I'll try to send you some additional task proposals as soon as I can.
>>
>> Tony
>>
>>
>> On 02/19/2016 05:30 PM, Walter Bender wrote:
>>
>> FYI, as per the discussion at this month's SLOB meeting, I submitted an
>> application to Google Summer of Code on behalf of Sugar Lbs. Lionel has
>> agreed to be the co-admin this summer. We should hear by the end of the
>> month as to whether or not we are accepted and how many slots we get.
>>
>> It is important that we add some more potential projects to the list in
>> the wiki over the next few days as a show of interest from the community.
>> Please add your ideas to:
>>
>> https://wiki.sugarlabs.org/go/Summer_of_Code/2016
>>
>> Thanks.
>>
>> -walter
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>>
>>
>>
>> _______________________________________________
>> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>> _______________________________________________
>> 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
> <http://www.sugarlabs.org>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
<http://www.sugarlabs.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160220/768ade03/attachment-0001.html>