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) |