[IAEP] [sugar] Sugar Digest 2008-10-27

[Michael Stone]

On Mon, Oct 27, 2008 at 08:12:37PM -0400, Walter Bender wrote:
>2. What would creating a Sugar Activity require from me and what
>benefits would it bring?

I've been pondering this question in some depth for the last week using
my list summarization problem as a model. In hopes of offering something
useful to other people facing this question, I have also started an
outline covering some of the challenges and goals I have discovered

   http://dev.laptop.org/git?p=users/mstone/summarize-activity;a=blob;f=NOTES;hb=HEAD

in preparation for a talk that I intend to give on this subject in
November. Would you care to speak alongside me?

>7. ¿Qué? ¿Cómo? ¿Por qué? ¿Para qui?: We also discussed the role that
>a portfolio might play in Sugar. What? How? Why? For who? are
>questions that are part of the teacher/student discourse in Peru. They
>are also questions that are important to the "select-reflect-perform"
>cycle of portfolio assessment. Scott, Rafael, Sebastian and I spend
>quite a bit of time discussion possible approaches to building a
>Portfolio Activity (we agreed that it makes sense to make it a
>separate Activity from the Journal for the time being). My
>hair-brained idea is to make a Turtle-Art-like snap-together
>programing Activity to create narrative presentations from items
>selected from the Journal. I'll make some sketches in the coming days
>and post them to the wiki. The team at the ministry was very upbeat
>about portfolio tools, regardless of the implementation details.

This work sounds like it complements another talk I hope to give in
November describing several conversations I've had recently with a mixed
tech/learning-team audience on the subject of "how can small activities
be combined to make bigger activities?". We have proceeded by
identifying three model use cases:

   1) Going on a hike:

       a) Making a manifest of what to take which can be refined for
       future trips.
       b) Recording beautiful scenes that I pass.
       c) Taking measurements at my destination.
       d) Returning and combining my measurements and observations with
       those of friends who went on similar hikes to other destinations.

   2) Developing a recipe:

       a) Writing a recipe draft and recording the stages of preparation.
       b) Sending the draft to a friend who will try to follow the recipe
          and who will suggest improvements.

   3) Running a physics jam:

       a) Preparing for the jam by snagging some sample physics-based
       activities.
       b) Making a new physics-based activity, perhaps by modifying one
       of the samples.
       c) Capturing developer commentaries and screenshots explaining the
       new activity as it is created.
       d) Publishing the results to, e.g., a wiki.

which we are in the process of exploring with paper mockups.

Questions: 

  * Do you have favorite model interactions that you'd like to share?

  * Anyone else want to talk about this subject in November besides
    Walter and me?

>9. On collaboration
>: Juliano Bittencourt has stirred the pot regard the Sugar
>collaboration model. In a discussion on the developers mailing list
>(http://lists.laptop.org/pipermail/devel/2008-October/020588.html) he
>raises the issue of synchronous vs asynchronous collaboration, arguing
>that too much emphasis has been given over to the former, when the
>latter is generally more useful in a school setting.  I agree with him
>to a great extent. 

I agree. (Tangentially, one fundamental goal for my summarization
project (described above) is to experiment with "async-collab" in the
sense in which summarization "collaborates" with the data being
summarized as more data accumulates over time. (If I have success in
this area, then I might try something fancier too. We'll see.))

>To some extent, Juliano's point was less in regard to synchrony and
>more in regard to the lack of any means within Sugar to maintain
>persistence of a collaboration over a longer time frame than a single
>interactive session. This omission is will in part be filled by
>services external to Sugar, such as Moodle or AMADIS. However, some
>aspects of the yet-to-be-implemented Bulletin Board would also meet
>these needs. (Better versioning in the Journal/Datastore—in the
>roadmap for 0.84—will play a role as well.) The Bulletin Board is
>designed to be a place for the persistent sharing of objects and
>actions between a group of collaborators. In some sense, one could
>think of it as a share, persistent clipboard. Bulletin Boards would be
>created in support of group projects that involve multiple activities
>and multiple sessions. We should develop a requirements document and
>architectural description of what is needed in order to both best
>leverage existing tools and set realistic goals for any Sugar
>developments.

I think that the technologies you mention are all incidental to the
essence of asynchronous collaboration, which I take to be diff-and-merge
(or perhaps 'guided-cut-and-paste'). To see why, consider the list
summarization example I mentioned in passing above. How would any of the
technologies you mention actually help ease the human task of
collaboratively writing up a nice list summary on a weekly basis?

Note that there are _three_ kinds of collaboration desired here: 

  1) Async collab between 'the summarizers' and 'the data source' in the
  sense of the desire to import _new_ messages from the lists as they
  become available.

  2) Async collab between individual summarizers who may agree to
  divide-and-conquer the overall (and ridiculously parellizable) summary
  problem.

  3) Synced-collab between individual summarizers when feasible.

Your technologies might be helpful if I lacked for ways to share blobs
or to be notified of the availability of new and interesting blobs, but
I don't have that lack as a generic application author inspired by the
principles articulated in the vision of 'activities'. (Note that Sugar
is not my primary platform for this work, and nor is it for most other
people writing interesting software; therefore, I am greatly interested
in finding solutions which at least work on both stock Linux and on
Sugar if not even more broadly.) 

Regards,

Michael