Re: [sugar] [IAEP] Narrative.
On Fri, Oct 10, 2008 at 12:27 AM, Michael Stone <[EMAIL PROTECTED]> wrote: > Bill, > > Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, > and Bobby Powers on my interpretation of "narrative" as it might apply > to a user interface designed for "engaging children in the world of > learning": >http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 > > === Highlights > > * By "narrative", I mean "a rational sequence (or graph) of events". > * It's rather hard to use XOs to prepare direct lessons. By "direct > lesson", I mean a guided learning experience, usable in variable > network conditions, which minimizes the amount of decision-making and > navigation that the end-user needs to perform in order to experience > 'the whole thing' regardless of what software implements each > individual experience contained in the lesson. > > === Toy Problem > > Concretely, suppose I invent a new Python trick like the ones at > > http://wiki.laptop.org/go/User:Mstone/Tricks > > How might a prepare a slick explanation for an inexperienced user? > > * I might write up a web page for my trick, then write a Pippy bundle > showing off the trick in a toy program, then give a pointer to a git > repo containing an instance of the trick in 'production'. > > Question: How do I write web pages on an XO? Question: Do I have to be > able to read in order to find and run the >Pippy bundle? > > * I might write up a larger Pippy example for my trick in the literate > style. I might also create a puzzle revolving around integrating the > trick into some sample code. I might include links to 'advanced > reading' or more examples in comments in the source code. > > Question: Pippy doesn't know anything about hyperlinks. Will my >readers? > Question: I must either comment out my puzzle so that the example can >run or I must provide it in a separate bundle. How many >users would figure out how to try both the example and the >puzzle? > > * While not obviously applicable to this specific example, two other > common solutions to this sort of problem include the "scripted > transitions between freeform experiences" idea common to wizards and > role-playing games and the 'build a custom but user-editable program' > idea underlying most EToys lessons. > > === Larger Concerns > > Since Sugar is strongly concerned with UI unification, it's worth > spending more time thinking about how well each of the solutions to your > favorite toy problem integrates with encompassing narratives of > reflection, criticism, and human collaboration. (None of the solutions > I've proposed above satisfy me in any of these regards.) > > > > In any case, I hope this followup helps explain the motivation and > 'line-of-thought' behind my initial email. Please discuss. hi michael, I don't know the answer but think it's a good question, which has now been somewhat clarified "narrative" is a big suitcase word (roger schank comes to mind, his book "tell me a story") - I would think of your idea as something like "sequenced instruction" because you are linking "a rational sequence (or graph) of events" to the preparation of direct lessons or "a guided learning experience" What Bryan says in his article is a pragmatic approach to what many teachers request (more sequence and structure, a structured curriculum). The comments to his article by John Maxwell and Yoshiki point out that the comparison with alan kay's dynabook idea is not very accurate. It's a big topic - an important topic but I'd say the language being used here is not accurate and might have created some initial confusion. I'm not qualified to talk about the software changes you are suggesting - don't know enough python ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Sun, Oct 12, 2008 at 2:48 AM, Wade Brainerd <[EMAIL PROTECTED]> wrote: > These issues could best be solved by a sugar-webcontent-activity package > which is shipped by default. It would contain the Browse GUI classes plus a > template Activity class. It would also provide a base WebServer class that > takes care of finding an unused port and binding to localhost. Content > bundles could use the template Activity class as is without any Python code, > or else could subclass it (and optionally the WebServer class as well). > We are planning to provide a sugar.web python package in sugar-toolkit for 0.84, which I guess is quite similar to what you are thinking about... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Sat, Oct 11, 2008 at 6:43 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 12 Oct 2008, at 01:48, Wade Brainerd wrote: > > On the bad side, you can't run two Wikipedias because they will try to >> bind webservers to the same port. Also, if the user removes Browse, >> Wikipedia will no longer run. >> >> These issues could best be solved by a sugar-webcontent-activity package >> which is shipped by default. It would contain the Browse GUI classes plus a >> template Activity class. It would also provide a base WebServer class that >> takes care of finding an unused port and binding to localhost. Content >> bundles could use the template Activity class as is without any Python code, >> or else could subclass it (and optionally the WebServer class as well). >> > > I'm sure I'm missing some obvious rainbow security issue here, but as an > exercise in putting my foot in my mouth, could the Activity with the > imbedded browse view not just access its files directly via file:// perhaps > using some magic to give it the activities installed path location? Oh yeah, that works fine! If it's just static content, no need to subclass anything or even start a webserver. The sugar-webcontent-activity Activity class could just be used directly with file:// URLs, the same way Content bundles work now. The WebServer class is needed in cases where there is something more complex going on. For example with our Wikipedia activity, each page request involves decompressing Wikitext and dynamically rendering it to HTML. There is also a dynamically generated Search page for search queries, etc. Ideally I'd like to see *that* code become part of sugar-webcontent-activity as well so many Wikislice's could be created without duplicating the server code. It should be as simple as selecting your article list somehow, creating an index page and an icon, and running some script to create a brand new Wikislice activity (say Wikislice Sports etc). Another example of needing the server would be if someone were to write some kind of interactive testbook with builtin quizzes, that remembered your answers in the journal. Basically any kind of complex Web app that wants to run locally on the XO as an Activity. -Wade ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On 12 Oct 2008, at 01:48, Wade Brainerd wrote: > On the bad side, you can't run two Wikipedias because they will try > to bind webservers to the same port. Also, if the user removes > Browse, Wikipedia will no longer run. > > These issues could best be solved by a sugar-webcontent-activity > package which is shipped by default. It would contain the Browse > GUI classes plus a template Activity class. It would also provide a > base WebServer class that takes care of finding an unused port and > binding to localhost. Content bundles could use the template > Activity class as is without any Python code, or else could subclass > it (and optionally the WebServer class as well). I'm sure I'm missing some obvious rainbow security issue here, but as an exercise in putting my foot in my mouth, could the Activity with the imbedded browse view not just access its files directly via file:// perhaps using some magic to give it the activities installed path location? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Sat, Oct 11, 2008 at 8:34 AM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > Activities are "verbs". Collections are "nouns". Sugar should make > the getting_to/using of "nouns" as easy as that of "verbs". Activities are really nouns too, a lot of them are just named with verbs that describe what they do! They are tools which allow the user to do something. They are not the act of doing something. -Wade ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Sat, Oct 11, 2008 at 8:34 AM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: >> What if Activity and Content bundles were one and the same. You could >> have bundles that just hold an Activity to install, or just have >> Content for the library, or more interestingly have it hold both an >> Activity and library Content. > > There exist CLI scripts (e.g., sugar-install-bundle) that handle > Activity bundles (which install Activities), but currently support > for Content bundles (which install Collections) is thin. > > What I wish for is that Content bundles were not second-class > citizens. The entire Home View is devoted to presenting Activities > for launching (or deletion). But Collections currently are > presented only within the left-hand panel in Browse. To be viewed, > they have to be "downloaded" by Browse to Journal, and then manually > "launched" (from Journal). [Deleting of Collections from the panel > shown by Browse is done only with manually issued CLI commands.] > > Activities are "verbs". Collections are "nouns". Sugar should make > the getting_to/using of "nouns" as easy as that of "verbs". So Browse has the unnamed function of turning nouns into verbs then? Well, I suppose we could talk about the infinitive, as in _to_ Google. The reverse of the gerund -ing that turns verbs into nouns. We get this in some languages constructed for greater grammatical generality, including Lojban and the later transformations of APL, such as APL2, SAX APL, and J. Variable-->Noun; Function-->Verb; Operator-->Adverb, and so on. > mikus > > ___ > IAEP -- It's An Education Project (not a laptop project!) > [EMAIL PROTECTED] > http://lists.sugarlabs.org/listinfo/iaep > -- Don't panic.--HHGTTG, Douglas Adams fivethirtyeight.com, 3bluedudes.com Obama still moving ahead in EC! http://www.obamapedia.org/ Join us! http://wiki.sugarlabs.org/go/User:Mokurai For the children ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Sat, Oct 11, 2008 at 2:11 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > 1) Content bundles are distributed and installed into the default home > page library. No way to manage these in Sugar once installed (have to > drop to a command line and know what you're doing). > > 2) Content is being shipped in an Activity build from a minimal Browse > template (hopefully sharing as much code as possible). The Wikipedia > slice and Help are examples in this direction. They can be managed > within the current Sugar GUI, just like any activity. They are also > visible (or can be) from the home view. They allow custom icons for > the content to be accessed. They allow customisations via the Activity > interface to improve access to information in a Sugar HIG way. I'm the one who did the activity part of the Wikipedia slice, which extends Browse. It was based on one of mstone's older projects. On the good side, the Wikipedia example imports 99% of its code directly from Browse, adds a Search toolbar, starts up a webserver, and goes to a URL. Quite simple, really. On the bad side, you can't run two Wikipedias because they will try to bind webservers to the same port. Also, if the user removes Browse, Wikipedia will no longer run. These issues could best be solved by a sugar-webcontent-activity package which is shipped by default. It would contain the Browse GUI classes plus a template Activity class. It would also provide a base WebServer class that takes care of finding an unused port and binding to localhost. Content bundles could use the template Activity class as is without any Python code, or else could subclass it (and optionally the WebServer class as well). I agree with you that right now, Activity Bundles are a better way to distribute content than the Library bundles. There is a lot of infrastructure and UI built around activity management now. Activities are also more visisble - good content is currently too well hidden inside Browse. I think it would be a nice simplification to the Sugar environment. -Wade ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On 11 Oct 2008, at 16:34, Mikus Grinbergs wrote: > What I wish for is that Content bundles were not second-class > citizens. The entire Home View is devoted to presenting Activities > for launching (or deletion). But Collections currently are > presented only within the left-hand panel in Browse. To be viewed, > they have to be "downloaded" by Browse to Journal, and then manually > "launched" (from Journal). [Deleting of Collections from the panel > shown by Browse is done only with manually issued CLI commands.] > Activities are "verbs". Collections are "nouns". Sugar should make > the getting_to/using of "nouns" as easy as that of "verbs". There seems to be two competing paths running, I'm not sure if one will win out over the other. 1) Content bundles are distributed and installed into the default home page library. No way to manage these in Sugar once installed (have to drop to a command line and know what you're doing). 2) Content is being shipped in an Activity build from a minimal Browse template (hopefully sharing as much code as possible). The Wikipedia slice and Help are examples in this direction. They can be managed within the current Sugar GUI, just like any activity. They are also visible (or can be) from the home view. They allow custom icons for the content to be accessed. They allow customisations via the Activity interface to improve access to information in a Sugar HIG way. You can probably tell, I'm slanting towards option 2 ;-) and doing away with all the extra engineering/resources needed to keep supporting option 1. The main benefit of option 1 seems to be down to getting any extra features that get added to Browse for free, though that also means you get features you may not want***. As long as there is a Browse like Activity helloworld template, content creation wouldn't be any worse than trying to get content builders jumping through the library bundle requirement hoops. ***If I wrote some JavaScript games and/or tools (i.e. spreadsheet seems a good case), I'd not want to distribute as library content; I'd want them to be peers of the other Activities, with equal control over their tool bars icons, palettes, and potentially sharing/collaboration features. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
> Do we have any proposals of changes to Sugar so it better supports > learning in light of the reflections on "narrative"? It seems to me that implementation of a Sugar "batch" language would address 'providing a "sequence" (or graph) of events'. I see two principal functions that need to be provided: ((1)) Automatically launching an Activity (or Collection). Currently in Sugar, it takes a "click" by the user to launch something. Sometimes everything is automatic (clicking on an .ogg file link in Browse) and sometimes it is not (clicking on a .pdf file link in Browse). There needs to be a facility in Sugar whereby one entity (e.g., Browse) can automatically invoke a different entity (e.g., Read) without manual intervention. This automatic invocation needs to carry along with it the necessary data references -- for Read to display a .pdf file, it should not be necessary to first copy that file to the datastore -- passing the URI of the file where it now exists (even if it is on an external device) should be enough to allow any invoked entity to access it. ((2)) Allowing launch events to be "batched" in a control sequence. I'm not familiar with Visual Basic and its like. But the developer (or user) ought to be able to "string together" a sequence (or graph) of launch events to create a self-contained "Narrative". The connectors between events should allow for "logic testing", such as "skip this next event if the preceding event indicated an error". Given the ability to construct an automatic sequence of launch events (including "packaged" input references), what one gets is a 'Sugar script' to provide a guided learning experience. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
> What if Activity and Content bundles were one and the same. You could > have bundles that just hold an Activity to install, or just have > Content for the library, or more interestingly have it hold both an > Activity and library Content. There exist CLI scripts (e.g., sugar-install-bundle) that handle Activity bundles (which install Activities), but currently support for Content bundles (which install Collections) is thin. What I wish for is that Content bundles were not second-class citizens. The entire Home View is devoted to presenting Activities for launching (or deletion). But Collections currently are presented only within the left-hand panel in Browse. To be viewed, they have to be "downloaded" by Browse to Journal, and then manually "launched" (from Journal). [Deleting of Collections from the panel shown by Browse is done only with manually issued CLI commands.] Activities are "verbs". Collections are "nouns". Sugar should make the getting_to/using of "nouns" as easy as that of "verbs". mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Fri, Oct 10, 2008 at 1:42 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 10 Oct 2008, at 14:26, Tomeu Vizoso wrote: > >> On Fri, Oct 10, 2008 at 3:02 AM, Bill Kerr <[EMAIL PROTECTED]> wrote: >>> On Fri, Oct 10, 2008 at 12:27 AM, Michael Stone >>> <[EMAIL PROTECTED]> wrote: Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of "narrative" as it might apply to a user interface designed for "engaging children in the world of learning": http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 >> >> Do we have any proposals of changes to Sugar so it better supports >> learning in light of the reflections on "narrative"? > > One random thought that overlaps with some ideas on Activity help... > > What if Activity and Content bundles were one and the same. You could > have bundles that just hold an Activity to install, or just have > Content for the library, or more interestingly have it hold both an > Activity and library Content. > > For a concrete example, I could see myself writing a handful of web > pages as part help, and part guide, to viewing and understanding the > Moon, it's phases, some traditions, stories etc. I do not want to > bloat out the Moon Activity UI with help tabs, buttons, and pages of > text and images formatted in some weird GTK encoding. The Activity > should be clean and light and focused on it's function. > > All the 'narrative' material should go into the library as html web > content (pdf's can be nice but are resource intensive and have > interaction issues of their own). It would be great if by installing > Moon.xo, the bundle could also contain some library content. > > Actually this is what the Mac OSX does. Applications contain what is > pretty much some indexed html help files that the system auto adds to > it's help engine when you install an Application. My MoonDock app uses > this to provide a page or two of instruction about the Moon. > > I guess I could provide something similar today by making two bundles, > one of html library content, and one of the Activity bundle. Maybe > there are benefits to this dual bundle arrangement (separate the > Activity from documentation translation tasks; only install what you > need to preserve nand space)? You bring up very good pros and cons. I think it would be convenient indeed if the bundle format allowed activity, help, and content bundles to be packaged up together and handled appropriately by the relevant parts of the system. Making a "pluggable" help system like this was one hope we had. Maybe the right thing to do instead (or in addition) is to extend the idea that bundles can come in a variety of canonical forms, perhaps each with their own mime-type, so that they can be downloaded from anywhere and then opened by the correct activity when launched (and, better, automatically detected by the relevant activities when needed). We should definitely give another look at bundles and how we expect them to operate in Sugar. All types of bundles currently hobble along; a precise definition for what they are and how they function would be a big step forward. - Eben > --Gary > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On 10 Oct 2008, at 14:26, Tomeu Vizoso wrote: > On Fri, Oct 10, 2008 at 3:02 AM, Bill Kerr <[EMAIL PROTECTED]> wrote: >> On Fri, Oct 10, 2008 at 12:27 AM, Michael Stone >> <[EMAIL PROTECTED]> wrote: >>> >>> Bill, >>> >>> Here's a short dialogue between myself, Ben Schwartz, Martin >>> Dengler, >>> and Bobby Powers on my interpretation of "narrative" as it might >>> apply >>> to a user interface designed for "engaging children in the world of >>> learning": >>> http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 > > Do we have any proposals of changes to Sugar so it better supports > learning in light of the reflections on "narrative"? One random thought that overlaps with some ideas on Activity help... What if Activity and Content bundles were one and the same. You could have bundles that just hold an Activity to install, or just have Content for the library, or more interestingly have it hold both an Activity and library Content. For a concrete example, I could see myself writing a handful of web pages as part help, and part guide, to viewing and understanding the Moon, it's phases, some traditions, stories etc. I do not want to bloat out the Moon Activity UI with help tabs, buttons, and pages of text and images formatted in some weird GTK encoding. The Activity should be clean and light and focused on it's function. All the 'narrative' material should go into the library as html web content (pdf's can be nice but are resource intensive and have interaction issues of their own). It would be great if by installing Moon.xo, the bundle could also contain some library content. Actually this is what the Mac OSX does. Applications contain what is pretty much some indexed html help files that the system auto adds to it's help engine when you install an Application. My MoonDock app uses this to provide a page or two of instruction about the Moon. I guess I could provide something similar today by making two bundles, one of html library content, and one of the Activity bundle. Maybe there are benefits to this dual bundle arrangement (separate the Activity from documentation translation tasks; only install what you need to preserve nand space)? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Fri, Oct 10, 2008 at 3:02 AM, Bill Kerr <[EMAIL PROTECTED]> wrote: > On Fri, Oct 10, 2008 at 12:27 AM, Michael Stone <[EMAIL PROTECTED]> wrote: >> >> Bill, >> >> Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, >> and Bobby Powers on my interpretation of "narrative" as it might apply >> to a user interface designed for "engaging children in the world of >> learning": >>http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 Do we have any proposals of changes to Sugar so it better supports learning in light of the reflections on "narrative"? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
I posted a comment on Bryan's call for textbook/narrative creation. http://www.olpcnews.com/content/education/scaling_constructionism_with_dynabooks.html Let's do this, Bryan. Where should we set up the workshop? What tools do we need? Wiki, mailing lists, forums, repository...? I and others have plenty of ideas for textbook replacements using Etoys, Measure, and other Sugar Activities in pretty much every subject. What we need is a place and a process, not only to write, program, and otherwise create learning materials, but to get them tested in classrooms, refined, and put into new curricula. On Wed, Oct 8, 2008 at 6:34 AM, Bill Kerr <[EMAIL PROTECTED]> wrote: > On Sun, Oct 5, 2008 at 2:09 PM, Michael Stone <[EMAIL PROTECTED]> wrote: >> >> Bryan Berry wholly captured my attention tonight when he said (in >> summary): >> >> "Sugar offers an excellent mode for discovery but no excellent way to >> manipulate narratives. Both discovery and narrative are essential for >> learning." [1] >> >> This statement seems to me both indisputable and damning; if true, it >> strikes to the core of the claim that Sugar is appropriate for learning. >> >> Even though Bryan has already found some partial solutions to this >> problem [2], we should take time to debate the more primitive thesis >> that: >> >> "Narrative is a basic component of much educational material which >> Sugar ought to 'natively' recognize, respond to, and manipulate." >> >> so that we may decide whether this issue should receive a greater share >> of our limited design and implementation resources. >> >> Regards, >> >> Michael >> >> [1]: Sugar presently records actions which may occasionally be >> decomposed into narrative or situated within an external narrative; >> however, Sugar is presently blind to these relationships. >> >> [2]: Bryan is currently encoding narratives in HTML and is attempting to >> use Offline Moodle to make this cheaper to support. I decided to write >> this email because I believe that it might well be worth our time to >> either give him a hand with his effort or to bake support for similar >> use cases directly in to Sugar. > > bryan's ideas are explained more fully in this article on olpcnews: > http://www.olpcnews.com/content/education/scaling_constructionism_with_dynabooks.html > > the comments there are worth reading too > > it's hard to discuss without having the ideas spelt out > "narrative is good" is not really a sufficient basis for a discussion but > bryan's article has more detail > > ___ > IAEP -- It's An Education Project (not a laptop project!) > [EMAIL PROTECTED] > http://lists.sugarlabs.org/listinfo/iaep > -- Don't panic.--HHGTTG, Douglas Adams fivethirtyeight.com, 3bluedudes.com Obama still moving ahead in EC! http://www.obamapedia.org/ Join us! http://wiki.sugarlabs.org/go/User:Mokurai For the children ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Thu, Oct 9, 2008 at 11:28 AM, Brian Jordan <[EMAIL PROTECTED]> wrote: > On Thu, Oct 9, 2008 at 4:57 PM, Michael Stone <[EMAIL PROTECTED]> wrote: >> Bill, >> >> Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, >> and Bobby Powers on my interpretation of "narrative" as it might apply >> to a user interface designed for "engaging children in the world of >> learning": >> >> http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 >> > > My favorite part was the end: > > bemasc> making content bundles work better sounds very valuable. We certainly > don't provide nice content creation tools. I heartily agree that this > is an area in which improvements are worth pursuing. > m_stone> lovely. now if only you weren't in engaged in pursuit of further > education... :) > bemasc> right. > > >> === Highlights >> >> * By "narrative", I mean "a rational sequence (or graph) of events". >> >> * It's rather hard to use XOs to prepare direct lessons. By "direct >> lesson", I mean a guided learning experience, usable in variable >> network conditions, which minimizes the amount of decision-making and >> navigation that the end-user needs to perform in order to experience >> 'the whole thing' regardless of what software implements each >> individual experience contained in the lesson. >> >> === Toy Problem >> >> Concretely, suppose I invent a new Python trick like the ones at >> >> http://wiki.laptop.org/go/User:Mstone/Tricks >> >> How might a prepare a slick explanation for an inexperienced user? >> >> * I might write up a web page for my trick, then write a Pippy bundle >> showing off the trick in a toy program, then give a pointer to a git >> repo containing an instance of the trick in 'production'. >> >> Question: How do I write web pages on an XO? >> Question: Do I have to be able to read in order to find and run the >> Pippy bundle? >> >> * I might write up a larger Pippy example for my trick in the literate >> style. I might also create a puzzle revolving around integrating the >> trick into some sample code. I might include links to 'advanced >> reading' or more examples in comments in the source code. >> >> Question: Pippy doesn't know anything about hyperlinks. Will my >> readers? >> Question: I must either comment out my puzzle so that the example can >> run or I must provide it in a separate bundle. How many >> users would figure out how to try both the example and the >> puzzle? >> >> * While not obviously applicable to this specific example, two other >> common solutions to this sort of problem include the "scripted >> transitions between freeform experiences" idea common to wizards and >> role-playing games and the 'build a custom but user-editable program' >> idea underlying most EToys lessons. >> >> === Larger Concerns >> >> Since Sugar is strongly concerned with UI unification, it's worth >> spending more time thinking about how well each of the solutions to your >> favorite toy problem integrates with encompassing narratives of >> reflection, criticism, and human collaboration. (None of the solutions >> I've proposed above satisfy me in any of these regards.) >> >> >> >> In any case, I hope this followup helps explain the motivation and >> 'line-of-thought' behind my initial email. Please discuss. >> >> Regards, >> >> Michael >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar >> > > So, how about (1) a way of creating content bundles with journal > content created on the XO, and (2) a way of transferring these bundles > and journal items from XO --> XO without having to use a USB key? We've always envisioned (1) as an activity (The "Bundle" activity, in fact), which would serve both as a way of creating and managing activity and content bundles, as well as provide a generic tool for inspecting , modifying, or creating various type of archived format (zip, tar, gz, etc). Also, please note that Lewis Barnett (CC'd), a professor from the University of Richmond, has adopted this project and is working on it as a class initiative. I had a teleconference with some of his students several weeks ago to discuss initial details, and I'm excited about what we can accomplish with them. I haven't heard from them since, and I'm not sure if a project has been setup for them yet. Perhaps you could give us a breif status update, Lewis? Thanks! (2) Should be handled like any other object transfer between XOs, which hasn't been built yet, but is certainly on the list of needed features. There is, of course, special consideration to be given to the passing of activity bundles, a la the former discussions on implicit sharing, trusted code, etc. - Eben > Does (2) currently exist (outside of terminal), by the way? Could (1) > and (2) be done as activities? > > Regards, > Brian
Re: [sugar] [IAEP] Narrative.
Brian Jordan wrote: > My favorite part was the end: > > bemasc> making content bundles work better sounds very valuable. We > certainly > don't provide nice content creation tools. I heartily agree that > this > is an area in which improvements are worth pursuing. Quite some time ago we presented Sophie (http://opensophie.org) at OLPC. but despite initial interest we never got anywhere. Part of the problem back then was the lack of resources/funding to support the work needed to sugarize and streamline Sophie to run reasonably well on the OLPC. We did, however, adapt the UI look to Sugar :-) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Thu, Oct 9, 2008 at 4:57 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > Bill, > > Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, > and Bobby Powers on my interpretation of "narrative" as it might apply > to a user interface designed for "engaging children in the world of > learning": > > http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 > My favorite part was the end: bemasc> making content bundles work better sounds very valuable. We certainly don't provide nice content creation tools. I heartily agree that this is an area in which improvements are worth pursuing. m_stone> lovely. now if only you weren't in engaged in pursuit of further education... :) bemasc> right. > === Highlights > > * By "narrative", I mean "a rational sequence (or graph) of events". > > * It's rather hard to use XOs to prepare direct lessons. By "direct > lesson", I mean a guided learning experience, usable in variable > network conditions, which minimizes the amount of decision-making and > navigation that the end-user needs to perform in order to experience > 'the whole thing' regardless of what software implements each > individual experience contained in the lesson. > > === Toy Problem > > Concretely, suppose I invent a new Python trick like the ones at > > http://wiki.laptop.org/go/User:Mstone/Tricks > > How might a prepare a slick explanation for an inexperienced user? > > * I might write up a web page for my trick, then write a Pippy bundle > showing off the trick in a toy program, then give a pointer to a git > repo containing an instance of the trick in 'production'. > > Question: How do I write web pages on an XO? > Question: Do I have to be able to read in order to find and run the > Pippy bundle? > > * I might write up a larger Pippy example for my trick in the literate > style. I might also create a puzzle revolving around integrating the > trick into some sample code. I might include links to 'advanced > reading' or more examples in comments in the source code. > > Question: Pippy doesn't know anything about hyperlinks. Will my > readers? > Question: I must either comment out my puzzle so that the example can > run or I must provide it in a separate bundle. How many > users would figure out how to try both the example and the > puzzle? > > * While not obviously applicable to this specific example, two other > common solutions to this sort of problem include the "scripted > transitions between freeform experiences" idea common to wizards and > role-playing games and the 'build a custom but user-editable program' > idea underlying most EToys lessons. > > === Larger Concerns > > Since Sugar is strongly concerned with UI unification, it's worth > spending more time thinking about how well each of the solutions to your > favorite toy problem integrates with encompassing narratives of > reflection, criticism, and human collaboration. (None of the solutions > I've proposed above satisfy me in any of these regards.) > > > > In any case, I hope this followup helps explain the motivation and > 'line-of-thought' behind my initial email. Please discuss. > > Regards, > > Michael > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > So, how about (1) a way of creating content bundles with journal content created on the XO, and (2) a way of transferring these bundles and journal items from XO --> XO without having to use a USB key? Does (2) currently exist (outside of terminal), by the way? Could (1) and (2) be done as activities? Regards, Brian ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of "narrative" as it might apply to a user interface designed for "engaging children in the world of learning": http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 === Highlights * By "narrative", I mean "a rational sequence (or graph) of events". * It's rather hard to use XOs to prepare direct lessons. By "direct lesson", I mean a guided learning experience, usable in variable network conditions, which minimizes the amount of decision-making and navigation that the end-user needs to perform in order to experience 'the whole thing' regardless of what software implements each individual experience contained in the lesson. === Toy Problem Concretely, suppose I invent a new Python trick like the ones at http://wiki.laptop.org/go/User:Mstone/Tricks How might a prepare a slick explanation for an inexperienced user? * I might write up a web page for my trick, then write a Pippy bundle showing off the trick in a toy program, then give a pointer to a git repo containing an instance of the trick in 'production'. Question: How do I write web pages on an XO? Question: Do I have to be able to read in order to find and run the Pippy bundle? * I might write up a larger Pippy example for my trick in the literate style. I might also create a puzzle revolving around integrating the trick into some sample code. I might include links to 'advanced reading' or more examples in comments in the source code. Question: Pippy doesn't know anything about hyperlinks. Will my readers? Question: I must either comment out my puzzle so that the example can run or I must provide it in a separate bundle. How many users would figure out how to try both the example and the puzzle? * While not obviously applicable to this specific example, two other common solutions to this sort of problem include the "scripted transitions between freeform experiences" idea common to wizards and role-playing games and the 'build a custom but user-editable program' idea underlying most EToys lessons. === Larger Concerns Since Sugar is strongly concerned with UI unification, it's worth spending more time thinking about how well each of the solutions to your favorite toy problem integrates with encompassing narratives of reflection, criticism, and human collaboration. (None of the solutions I've proposed above satisfy me in any of these regards.) In any case, I hope this followup helps explain the motivation and 'line-of-thought' behind my initial email. Please discuss. Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Sun, Oct 5, 2008 at 2:09 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > Bryan Berry wholly captured my attention tonight when he said (in > summary): > > "Sugar offers an excellent mode for discovery but no excellent way to > manipulate narratives. Both discovery and narrative are essential for > learning." [1] > > This statement seems to me both indisputable and damning; if true, it > strikes to the core of the claim that Sugar is appropriate for learning. > > Even though Bryan has already found some partial solutions to this > problem [2], we should take time to debate the more primitive thesis > that: > > "Narrative is a basic component of much educational material which > Sugar ought to 'natively' recognize, respond to, and manipulate." > > so that we may decide whether this issue should receive a greater share > of our limited design and implementation resources. > > Regards, > > Michael > > [1]: Sugar presently records actions which may occasionally be > decomposed into narrative or situated within an external narrative; > however, Sugar is presently blind to these relationships. > > [2]: Bryan is currently encoding narratives in HTML and is attempting to > use Offline Moodle to make this cheaper to support. I decided to write > this email because I believe that it might well be worth our time to > either give him a hand with his effort or to bake support for similar > use cases directly in to Sugar. bryan's ideas are explained more fully in this article on olpcnews: http://www.olpcnews.com/content/education/scaling_constructionism_with_dynabooks.html the comments there are worth reading too it's hard to discuss without having the ideas spelt out "narrative is good" is not really a sufficient basis for a discussion but bryan's article has more detail ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
