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 _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar