Bodington Review, Part I

Here’s an interesting announcement out of the UK:

The Universities of Oxford, Cambridge, Hull, and the UHI Millennium Institute announce the formation of the Tetra Collaboration, the outcome of a series of meetings and a major summit held at the University of Oxford on the 25th-26th September 2006.

The goal of the Tetra Collaboration is to coordinate activities across the member organisations so as to more efficiently develop and deploy open source enterprise applications of use to UK and European universities and colleges. By working together we can share common solutions to better serve the needs of students and academics, and each of the institutions named is committed to making tangible contributions into the collaboration.

The Tetra Collaboration will work together on projects that address the needs of education, research, technical infrastructure, service oriented architectures (SOA), federated systems, and application frameworks.

Tetra will demonstrate the potential of the JISC’s e-Framework, will be built on open standards and IMS specifications, and is committed to developing sustainable community source solutions for education.

One of the first Tetra projects will be to continue the work of the Bodington (4) open source learning management system to produce Bodington – Next Generation or Bodington NG. This will combine elements of the Sakai open source framework with the pedagogically strong Bodington toolset. A major design goal of Bodington NG is to develop and implement an SOA enterprise e-framework.

So the Tetra Collaboration will be working to develop a standards-based flexible framework, drawing on service-oriented architecture, that will enable federated virtual learning environments. And it will be using Sakai as one of its components. If you’re a regular reader of e-Literate, then you know that I couldn’t possibly resist finding out more about this effort. So, with the help and support of Oxford University’s Paul Trafford, I set out to learn a little bit more about Bodington.At Paul’s suggestion, I spent relatively little time looking at Bod’s individual tools and instead went about trying to understand its access rights system. Now, I have long complained that LMS permissions systems are usually too rigid and narrowly defined. Bodington’s permissions are more flexible than just about any other LMS I’ve ever seen. (It’s possible that dotLRN’s OpenACS-based permisions are as flexible, but if so, then they are hidden deep under the hood–typically out of the reach of most faculty members.) In most systems, you have a few pre-defined roles–teacher, student, administrator, TA, etc. These roles generally have pre-defined permissions. You can create groups that are essentially nested containers, e.g., a student group will always be a strict subset of the class that contains it. Likewise, these groups are often (though not always) mutually exclusive, i.e., a student can’t be a member of both Group A and Group B at the same time.

Bodington works completely differently. Every object–a content bit, a discussion forum, etc.–can have an arbitrary number of groups attached to it, each group can have an arbitrary number of overlapping members, and each group can also have arbitrary fine-grained permissions for the object.

I know. It’s confusing. Maybe an example will help. Let’s say you have an MBA class of sixteen students. You want to do a role play with the class. There are four roles in the role play–manufacturer, supplier A, supplier B, and value-added reseller. Each role should have different information that the others can’t see. And let’s say you wanted to divide the class into 4 different role plays, with each group of 4 students running the same scenario and unable to see what the other groups are doing until after the simulation is complete.

This would be very cumbersome to pull off with at typical LMS’s group capabilities. You’d probably set up one group for each simulation and then email separate packages of information to each student containing the information for his/her role. If a student loses the email, you’d have to resend. And if you want to update the role play in progress with new information, you’d have to email the information to just the appropriate students.

Contrast this with how Bodington works. You could create two sets of groups: Simulation Groups 1-4 and Role Groups 1-4. So, for example, a student could be a member of both Simulation Group 1 and the Manufacturer Group. As you add more documents and activities to the course environment, you simply assign rights to the appropriate groups and students will automatically see only what they ought to see. You can even get more fine-grained. For example, you can create a production report that can be seen by members of the Manufacturer Group but only edited by members of the Supplier A Group. In other words, you can use permissions to reflect the rules of the game. Most groupwork, whether or not it involves simulations, benefits greatly from setting up distinct roles within each group. Bodington’s permissions system ensures that you don’t have to work against the grain of the LMS in order to do so.

Likewise, in non-course research and collaboration, required roles often don’t fit well with simple nested hierarchy. If you take that business simulation and substitute roles for some inter-institutional academic research project, you can quickly see where being able to define cross-cutting matrices of groups and fine-grained permissions could really come in handy. Sometimes you need to give a collaborator more than guest access but less than full access, and exactly what kind of access the person needs is highly dependent on the specific nature of the collaboration. So Bodington’s permissions structure is interesting for research collaboration as well as for a teaching environment. And this is all exposed to the typical teacher or researcher; no administrator would be necessary to set up these specialized access scenarios.

Is there a cost in usability for all that flexibility? I’m not sure. I found it to be fairly intuitive but I have learned that I am not a representative user. I’d like to see usability studies and consider ways to make permissions “bundling” (a role, for example, is a kind of permissions bundle) might make some of this power a bit more intuitive. But on the whole, it strongly appeals to my own gut sense of how a flexible learning environment ought to be designed. In my next Bodington post, I’ll follow up with some discussion of the spacial metaphor and other organizational principles of the system.