Last modified: 16 November 2010
Note that this spec was originally written with an eye toward allowing any user to contribute activities which could be safely used by anyone else who opted-in to seeing user-contributed activities without the need for the Khan Academy to review/approve individual activities. If only specific users (e.g. committers) will be allowed to contribute activities, some of the design considerations can be dropped or considered less important and the design simplified.
Generality. The interface should be general enough to include activities as diverse as watching videos, answering machine-graded and human-graded questions, and using simulators.
Extensibility. It should be possible to add support for new
types of activities without needing to rewrite this spec or learning
activities written based on it.
Discovery. The app should be able to determine which activity sections might be of interest to a particular user.
Tracking/Analytics. The app should be able to determine the following information concerning each of a student's interactions with an activity section whenever such information is available: percent complete, time spent, percent of available assistance provided, accuracy. This information allows for the performance of both the student and the activity section to be analyzed.
Reproducability. A coach or developer should be able to reproduce each of a student's interactions with an activity section for diagnostic purposes.
User State Maintenance. If a student leaves an activity and returns later, the student continue from the point of departure.
Security. A malicious activity should not be able to modify information associated with other activities or contact other hosts without permission. This is not required if contributed activities are reviewed before they are made available.
Privacy. An activity should not have access to any of the student's personally identifiable information without the student's permission. This is not required if contributed activities are reviewed before they are made available.
Embedding/Reuse. An activity author should be able to use activity sections from existing activities when creating new activities. Activities should be able to access the tracking data for the activities that they use.
Internationalization/Localization. A non-technical user should be able to translate an activity to a new language/locale without making an entirely new activity and it should require little or no extra effort for activity authors to make such translation possible.
Printability. A user should be able to print multiple activity sections (e.g. a multi-question quiz) without wasting substantial amounts of paper.
Disconnected operation. A user should be able to use activities that don't depend on external servers even without an internet connection from a browser that provides HTML5 offline support, provided they have previously used those activities while online.
Alternate presentations. An activity should be able to allow the app to act as a go-between when interacting with the user, so that the app can provide alternate presentation (e.g. in a game).
Existing Standards. It should be possible to create learning activities which can run SCORM modules or Common Cartridge cartridges. It should also be possible to convert a learning activity into a SCORM module or Common Cartridge, though possibly with some loss of functionality. The existing API is closest to the SCORM model (i.e. modules are blackbox that mostly just report progress). Common Cartridge uses a white-box model that supports finer-grained control and reuse of individual assets (e.g. questions), at the cost of developer flexibility.
The metadata for an activity includes a list of the activity sections and, for each section, the skills that the section requires and provides. This could be achieve using the Learning Object Metadata (LOM) standard. Activity sections are represented by URLs relative to the activity's base URL and skills are represented by absolute URIs in defined elsewhere.
To present an activity section to a student:
To support printability, an activity should use the appropriate media qualifiers in its CSS.
An activity should notify the app whenever a meaningful change occurs to the claimed proficiency level (accuracy %) for any skill or the amount of work performed in the activity section (including units -- e.g. 5 "problems attempted" or 300 "seconds of video watched"). [Note: Streak becomes proficiency level and total done becomes amount of work performed.]
An activity should notify the app whenever a meaningful user interaction occurs. The interaction data consists of the time the interaction started and stopped, an array of tags for the interaction (e.g. ['problem finished', 'correct', 'needed hints'], ['rewind'], or ['next page']), an optional textual description of the interaction, and arbitrary opaque state data representing the state of the activity section after the interaction. The activity section needs to be able to restore that state at a later time. This allows a student to pick up where they left off and allows coaches and developers to replay a sequence of states to follow the student's interactions.