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