Requirements as of March 2004

Mostly output from the March 2004 Retreat.

Level 1 Foci

Some things that we decided on day 1 of the retreat.

Browser only versus Client computation

This distinction is between an LE that can be delivered fully in the/a browser (think WISE) versus an LE that requires some extra-browser computation (think Pedagogica models). The later only buys you more capabilities. The former wont require installation of anything on the client machine.

• installation (+ BO)
• user location transparency (+ BO)
• "advanced" content (+ CC - just easier, not necessary)
• Flow control, navigation (+ CC)
• Tech integration (+ CC)
• Real Time commmunication (+ CC)

And the winner is: client-side computation.

Note that "installing on client machines" is a bad thing – Marcia, for instance, is quite sensitive to this. We don't feel it is a deal breaker, though:

• by including the sorts of things that Pedagogica specializes in, we really tilt the balance towards client-side computation. Applets and java script only get you so far

• Installation mechanisms have come a long way – no longer does on need to stick a disk inside the drive of each client. Concord consortium has made nice progress towards a bootstrapping model where the initial install is small/light, and does all the rest of the work.
  • Our goal is make a mechanism where the user:
    1. opens a browser on the client machine
    2. navigates to a trusted site (TELS, or similar)
    3. Tells the browser to "trust" the site
    • the last step is one that certain clients, when fully locked down, will need special dispensation for. However, the argument to the system administrator shouldn't be hard to make, since TELS should be trusted.

• We want to make a "browser only mode" for our LE. Features will gracefully degrade, meaning you can get part of the way towards a "full-featured course" in the browser.
  • With more development work, we can make it so that browser-only is closer to the "full-featured course".
  • The instructor/design MUST NOT be forced to author for two different modes!
  • By allowing for both modes, mmany complexities will arise with syncronization across sessions, collaboration between students in different modes, etc. The simplest (for the developer) way is to have an "export" to a browser only version – but there are lots of complexities
  • As such, this won't be something we focus on early, or concern ourselves with during the SAIL design process. To do so would restrict "cool things" that we can dream up, which is bad.

Requirements on Learner Clients

• access to a fast (local) storage
  • note, local storage is NOT guarenteed to be persistant – assume client disks will be wiped regularly.
• access to a server (discovered automatically)
• Java runtime 1.3

  ---

• installation needs to be "one-click", " via-browser with a single 'trust me' click"

  ---

  ??

• Browser. Probably we shouldn't require mozilla, but boy wouldn't it be nice
• "Ports" for technology integration (handhelds, graphing calculators
• ? A local area network (do we really care about single-client sites?)
  • ?A net connection at some point, for bootstrapping installation – probably not.

Level 2 Foci

Some things that we decided on day 2 of the retreat.

content versioning

• metadata encodes relations
• notification of upstream and downstream edits
• easy updates and merging of related content

content communities

• repositories
• mutability gradient
• widening of scope, rigor
  • metadata requirements can differ as scope widens
  • review/rating ''

management

• URI for content object (agnostic to access mechanism/location)
• lightweight directories to search and rate these objects
• metadata can emerge from communities
• enable any sort of management policy
• community content management policies can be determined

content objects

• assets are content without a learning goal (eg. a graphic, a simple animation, a question?)
• learning objects (with a learning goal)

Ontology

moved to a separate page

parameterizable POs

• A PO can take parameters that it will use to determine behaviour.
• A PO can expose data to other POs (security issues!)

• At sequence time, exposed data is linked to parameter inputs.
• System objects expose data (e.g., current date) that can be linked to parameter inputs
• "Facilitator objects" can expose data that can be linked...
  • facilitator object!?! Like, the thing that allows the author to halt the LE. ?? Facilitator Wizard??