Now that there are a number of LMOS/framework-like projects in active development (the Bodington Tetra/Sakai collaboration, Oracle’s AEI, LAMS’ service contract work and, of course, the venerable eFramework and all of its children), I thought it might be interesting to pause for a moment consider how what I’ve learned about Bodington reflects on the challenges of an LMOS-like approach. When we think of frameworks, conversations tend in the direction plugging in tools, as if everything else in the framework itself is fairly straightforward. But the Bodington/Sakai unification project shows that picture to be simplistic. Simply taking Bod’s tooks and plugging them into Sakai’s environment would basically remove everything Bodingtonish about Bodington. Permissions, page layout control (which is related to how tools present themselves in the environment), and UI metaphors all really matter.
So how do we define the territory that needs to be considered in order to make a framework approach work? How do we figure out what’s important? I don’t know that I have answers to those questions, but I think the solution may well start with use cases. What we need is a library of relatively granular descriptions of what teachers and students do in Bodington (for example) so that we can think about the affordances required to support those activities. The use cases might eventually be built into a pattern language. This approach combined with a catalog of tools, tool capabilities, and tool interoperability contracts, would probably give us enough to have meaningful conversations about building common frameworks.
