<div dir="ltr">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.<div><br></div><div>-walter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 20, 2016 at 2:00 AM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi, Walter<br>
    <br>
    I have some concerns about the proposed GSOC tasks as well as some
    ideas for new tasks.<br>
    <br>
    I agree that the Journal needs rethinking. Below are my thoughts
    (re-thoughts?).<br>
    <br>
    Specifically,<br>
    <br>
    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 <br>
    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). <br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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, <br>
    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).<br>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    I would propose these tasks more as follows:<br>
    <br>
    <dl>
      <dt>1. Brief explanation</dt>
    </dl>
    <dd> 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. <br>
    </dd>
    <dd>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 <br>
    </dd>
    <dt>save/save as gives the user the ability to manage versions by
      using unique names.<br>
    </dt>
    <p>2. Brief explanation<br>
              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.<br>
    </p>
    <p>3. Brief explanation<br>
              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). <br>
          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. <br>
    </p>
    <p>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.<br>
    </p>
    <p>4. Brief explanation<br>
          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.<br>
      Unfortunately, a consequence is that the Journal view fills with
      essentially meaningless links to this metadata (mine fills with
      Terminal Activity and Log entries).<br>
      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.</p>
    <p>5. Brief explanation<br>
          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.<br>
    </p>
    <p>6. Brief explanation<br>
          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. </p>
    <p>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. <br>
    </p>
    <p>7. Brief explanation.<br>
           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). <br>
    </p>
    <p>8. Brief explanation<br>
          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.<br>
    </p>
    <p>9. Brief explanation<br>
          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 (<a href="https://www.sam.today/blog/sugar-onboard-design.html" target="_blank">https://www.sam.today/blog/sugar-onboard-design.html</a>).
      This task is to implement an interpretive system that allows <br>
      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. <br>
      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?<br>
    </p>
    <p>10. Brief explanation<br>
          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 (<a href="http://wiki.sugarlabs.org/go/Ubuntu" target="_blank">http://wiki.sugarlabs.org/go/Ubuntu</a>).

      Unfortunately, this procedure does not work with 32-bit systems.
      There exists an opportunity to deploy Sugar <br>
      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 <br>
      be installed on 32-bit systems as an alternate Ubuntu desktop.<br>
    </p>
    <p>11. Brief explanation<br>
          Many deployments want to protect their XOs against theft. OLPC
      provides an 'activation lease' mechanism in firmware which makes
      it impossible to <br>
      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].  <br>
          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.<br>
    </p>
    <p>12. Brief explanation<br>
          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. <br>
    </p>
    <p>13. Brief explanation<br>
          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. <br>
          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 <br>
      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. <br>
    </p>
    <p>14. Brief explanation<br>
          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.<br>
          <br>
    </p>
    <p>    <br>
      I have some comments on the other tasks:<br>
    </p>
    <p>"The newer Sugar builds have performance issues on <i>some old
        hardware</i> 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."<br>
    </p>
    <p>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). <br>
    </p>
    <p>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?).<br>
    </p>
    <p>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 <br>
      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?). <br>
    </p>
    <p>It is likely that one result of this task may be to limit the
      capabilities of Sugar on the XO-1.<br>
    </p>
    <p>"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."</p>
    <p>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?<br>
    </p>
    <p>Nutritional Microworld<br>
    </p>
    <p>relevant tool—one that invites learners to explore fundamental
      concepts of nutrition that are both intrinsic to music yet
      transcendent of a specific discipline.
    </p>
    I assume the reference to music is a typo. <br>
    <br>
    At Eurovision 2014, a speaker demonstrated nsound - an alternative
    to csound. The claim is a simpler and more understandable api.<br>
    <br>
    Turtle Confusion and Turtle Flags. <br>
        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.<br>
    <p> </p>
    <p>I'll try to send you some additional task proposals as soon as I
      can.<br>
    </p>
    <p>Tony<br>
    </p><div><div class="h5">
    <br>
    <br>
    <div>On 02/19/2016 05:30 PM, Walter Bender
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">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. 
        <div><br>
        </div>
        <div>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: </div>
        <div><br>
        </div>
        <div><a href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016" target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016</a></div>
        <div><br>
        </div>
        <div>Thanks.</div>
        <div><br>
        </div>
        <div>-walter</div>
        <div>
          <div><br>
          </div>
          -- <br>
          <div>
            <div dir="ltr">
              <div><font><font>Walter Bender</font></font><br>
                <font><font>Sugar Labs</font></font></div>
              <div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br>
                <br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Sugar-devel mailing list
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div>
</div>