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
