July 10, 2003
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.
| Type of Tool | with same family | with larger system |
| Management | Low | Medium – High |
| Add-ons | Medium – high | Low |
| Authoring | Medium – high | Low |
| Collaboration | Low-Medium | Low |
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:
| Type of Tool | with same family | with larger system |
| Management | Medium (Low) | Medium – High |
| Add-ons | Medium – high | Medium (Low) |
| Authoring | Medium – high | Medium (Low) |
| Collaboration | Low [political]-Medium | Medium (Low) |