[IAEP] Narrative.

[Michael Stone]

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