MIT alt-i-lab Days 2-3

My final summary from alt-i-lab (since I’m leaving to go home in an hour).

The discussion group I led with Madeline (from WGBH) was charged with answering three questions with regards to interoperability for “Tools for User Interaction” which included everything _but_ repositories, LMS-type systems, and assessment tools. Needless to say, it was a huge chunk. Here’s the list of three questions and pseudo-answers from our group.

*1. What are dimensions of interoperability for tools for user interaction?*
Fragility of interoperability (how soon will it break?)
Effort to interoperate (how hard to build?)
User Interface integration (user view of interoperability)
Behavioral integration (of add-ons / utilities)
Interoperability between tools in the same family (editors, etc.)
Ways to add tool functionality into a broader system
Open support for plug-ins
Open protocols
Open data structures
Reveal programming interfaces
Export in format that is viewable / playable
Export in format that is editable
Import formats
Process integration

*2. What is the state of the art in tools for user interaction?

Table 1. Interoperability of a family of tools with (1) other tools from the same family and with (2) broader systems like LMSs.

*3. Where do we go in the next 12 ? 18 months?*

We discussed three levels of interoperability (although I’m sure there is a canonical version in a CS textbook somewhere I just don’t know about):

1. System A talks directly to system B in real-time (?High?)

2. System A creates a persistent artifact (?file?) which system B knows how to consume (?Medium?)

3. System A creates an artifact which, through miraculous means, can be transformed into something system B knows how to consume (?Low?)

In the next 12 to 18 months we believe that we should aim to:

1. Work toward consensus about how tools fit into pedagogical contexts (not system contexts) and build prototypes
    o How do you build to support broad pedagogies (not implicitly enforce pedagogies)
2. Build communities around tools and specs
    o Blog with regular updates from OKI, IMS, ADL folks
    o OKI could develop a prioritized TODO for the implementer community
    o Wiki on OKI site where individuals can self-register to notify others of efforts
    o RSS / (N)ECHO feeds from IMS, OKI, ADL, etc.
    o Work toward (sub)community consensus around flexibility of UI (e.g., styles, themes, Java XUL Renderer)
    o Plan physical meetings opportunistically; determine online work capabilities for other times for more
    o Participate in virtual plugfests (CETIS)
3. Shut up and build stuff
    o Shorten the feedback loop (build, alter spec, build, alter spec),
    o Documentation and example code / reference implementations of OKI are desperately needed (more than CHEF, CourseWork, KnowledgeStar)
    o Full open source implementations would be nice
    o Domain specific tools (data viz, math, etc.) are necessary to help users get excited and want to change their practice
    o Update ?classic? apps based on new user reqs (e.g., email)
4. Architectural / spec related stuff
    o Harmonization / gate-keeping
    o Abstract Frameworks (specification from IMS)
    o API for small tools to plug into larger environment (LD)
    o Offer conformance testing
5. Vendors and other developers need to:
    o Actually implement Content Packaging (conformance testing) and other specifications (e.g., OKI). How do we reward / encourage / strong arm vendors?
    o Open support for plug-ins (e.g., building blocks)
    o Open protocols
    o Open data structures

If many of these things happen, next year the state of the art might be: