Nell/Architecture

Nell consists of several modules. They're not independent; there are defined API interactions between them. (Listing them here doesn't mean that we're going to design and implement each top-down before putting any activities together -- I think being very demo-focused and starting right at the user-visible layer is still a fine idea.)

Nothing here is final yet; still at the brainstorming stage.

Modules

Narrative

The Narrative contains state and ties together dependencies to provide a unified "story" for all of the child's interactions with Nell.

Avatar Services

• We imagine "Avatar Services" to be a storefront of some kind, thematically.
• Stores user's name, chosen avatar appearance, avatar's friends, preferences.
• How literate is this user?
• What kind of learning style (visual, puzzle solving, blackboard) do they learn from best/prefer?
• Like Sugar's Journal, this should provide an opportunity for reflection on (and replay of) past experiences.
• Tied into the narrative model, so that narrative chunks ("lesson plans") can be tailored to individual students.
• Provides a sense of ownership of the device -- the child gets to name their avatars, their friends, establish favorite colors, etc.

Tech tree

• For background on what a tech tree is, see http://www.trevorowens.org/2009/02/science-grows-on-trees-the-history-of-science-and-technology-acording-to-video-games/ (For a playful example, see http://www.mit.edu/~puzzle/11/puzzles/civilization/ )
• Operates on the dependencies between activities. Could also function much like a package manager, handling downloading new activities on demand, and only opening access to new activities once you've met the prerequisites.
• Could show the user what kind of stories are available in the future, and what they should head towards to unlock them.
• Partially implemented as a narrative "spine". Branch points for the "first year", "second year", etc of the adventure have well-known interfaces, so that narrative chunks/lesson plans can be slotted in at the appropriate developmental level.
• Partially implemented as separate characters in the narrative. "Max" is the math whiz, so math-centric narrative chunks are adventures for "Max", and cross-cutting narratives are written to require Max's participation.
• Other dependencies/ordering might simply be given well-known names in the narrative, so that independently-written narrative chunks can refer to them consistently.

Story

• Contains metadata visible to the tech tree about what kind of narrative this is.
• The prerequisites for a narrative chunk aren't limited just to which story chunks have been completed -- they might also depend on outcomes from narratives, stored in Avatar Services. This provides for a coherent narrative arc, with the side effect that the user gets to hear stories that are more like the stories they've enjoyed and chosen to go deeper into previously.
• Stories must be extremely pluggable. The same story or "lesson plan" may have many different implementations available -- some with different languages, teaching styles, some may have been written by teachers and some by kids. Some pieces of the story may be written with the flexibility to incorporate various bits of information stored in Avatar Services (character names, preferences, etc), but other parts may exist as multiple independently-written narrative chunks, each of which matches a certain set of preconditions ("visual learners", "auditory learners", "year one kids", "year two kids", etc). At some points we can randomly select between different chunks which effect a certain desired educational outcome to add variety to the child's experience (or because a previously-selected chunk was ineffective).
• The narrative model defines possible outcomes from this activity, and passes them down to Avatar Services as they're made.
• Achievements are types of outcomes, too.

Narrative view

• Takes a narrative model and renders the story on-screen, incorporating partially scripted interactions with an underlying Activity. At interesting decision points or events, evokes outcomes to the model. Much of the story logic is probably embedded in the view. The view hooks into avatar services to decide how best to present itself. The view hooks into the underlying activity to make special functions available -- for example, to present a piano or a drawing canvas or turtle programming environment or a cut scene.

Activities

• So far we've discussed narratives, which are pieces of software that provide plot to an activity. An activity is a piece of software that a narrative chooses to launch to conduct a task like piano playing, showing a movie, painting, using a calculator, and so on. Narratives (may) launch activities when the goal of a narrative can't be accomplished just using the visual view provided by the narrative API.

Story creator

• We'll need a tool that can author an narrative chunk. It should allow the author to choose prerequisites, define outcomes, and have access to any prior outcomes it's interested in when deciding on a narrative.
• Some shared space to collaboratively define common preconditions, avatar state, etc.
• Activities can be authored using Pippy-like or TurtleArt-like tools. These might be integrated with the narrative authoring tool, but don't need to be. One should be able to author lots of narratives ("lesson plans") around a single Activity ("turtle art", say).

Open questions

• Is the narrative model/view split actually interesting, or should everything other than prerequisites just happen inside the view? (Maybe this should be decided after a few demo activities exist.)