I’ve been reading Opening Up Education. So far, I’m impressed. It’s hard to get all the articles in a collection like this to be consistent, coherent, and equally interesting, but the editors seem to have managed to do just that.
I want to comment today on the piece about Bodington by Stuart Lee. Long-time readers know that I have been a fan of this system. In the first part of a multi-part review of the system, I wrote:
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.
At the time, I caught some flack for focusing on what some viewed as trivial aspects of the system. But Stuart’s essay, along with some recent comments to the Sakai discussion boards about the version 3 vision document, show that this stuff really matters.
Stuart argues that the role-based permission system that most LMSs use are fundamentally at odds with the ways in which people work together in an academic environment:
First, the user is usually defi ned as falling into one of three roles—(system) administrator, tutor, or student (or similar nomenclatures)—with the limitations of what one can do in the system defi ned by this role. These are rigidly observed: Once a student, always a student, and never a tutor be. For many people, this may not present a concern. However, if you wish to turn areas over to students so they can lead their learning, create their own learning experiences, or peer-review, it can be problematic. The systems are driven by the Student Record System (SRS) or some external identity management application that then populates the LMS. Understandably, these favour robustness and accuracy over flexibility, but above all simplicity—and a single role per user—is as simple as it comes. These are notorious for running into issues with the variant roles people play in a higher education institution.
This is then perpetuated by the LMS. Taking its feed from the SRS, the pigeonholing becomes established across all areas and functions of the system. Although some commercial systems now claim to accommodate multi-roles for users, this can only be said to be true if a user can choose or be given different access privileges at any point in the system. To simply say you can be both a student and tutor is not enough. Privileges do not map neatly to roles. For example, a “tutor” can wear many hats: teacher, mentor, examiner, administrator, etcetera. In one area tutors may be allowed to do whatever they want (their own area related to their course, for example), but in others it might be more secure to allow them only to read some material, such as exam results, rather than to have editing rights.
Keep in mind that these roles are always used to grant or restrict access to content and functionality. This is about control over access to education. So what happens when you get those controls wrong? Stuart writes,
Apart from the issue of set roles, noted above, it is common to find students logging onto their LMS and being presented with a list of the modules they are registered on. This is presented as “personalization,” which in the confusion of most higher education syllabi can be seen as a good thing for students (who immediately see the information most relevant to them). What would happen, though, if in a seminar the tutor (who may have greater access to the system) detects an opportunity for an interdisciplinary approach and directs the student to resources in other departments? When the student logs on they may well find their way barred, the gates closed, because the system only recognizes them as a student of one discipline. Educational resources then, even within the institution, are not “open.” They are controlled, managed, restricted, and channeled.
So these permissions systems actually discourage academic dialogue—even when that dialogue is sanctioned and supported by the institution. (Oxford, where Stuart comes from, does a lot of this sort of thing.)
Bodington, both because of its different permissions structure and because it is open source and unencumbered by a per-user license, also facilitates the opening of academic content to world outside of the unversity:
Although an instantiation of Bodington will include all members of the institution, the groups themselves are not labeled as student/tutor/admin with associated rights. Instead, at each resource level, like an area of Bodington, the creator is free to select any group or create an ad hoc grouping and say “these people will have these rights in this section.” These rights can be cascaded, but do not affect the rights that the group or individual has elsewhere in the system. Thus by adopting this model, you can easily open the whole system to all users. At other areas you can close it down to specifi c, controllable cohorts like committee members or tutorial groups. More importantly, you do not need to log on to the system until you reach a place with restricted access. Pointing a browser at www.weblearn.ox.ac.uk, for example, allows you to immediately access Oxford University’s instantiation of Bodington, and browse until you reach a restricted area. This provides two benefi ts. First, it allows search engines like Google to index the site up to the point of restriction. Second, suddenly in the same system you can easily have an “open education” area (making certain modules open to visitor access) and a “closed education” area (restricted to students or staff within your institution).
There is a very important yet easy-to-miss element in this particular approach to openness. Bodington doesn’t require faculty to open up their content. They can lock it down any time they want. But by making the content open by default, it means that faculty have to make a conscious choice to close their content, rather than the other way around. Openness becomes the path of least resistance. Cass Sunstein and Richard Thaler have referred to this kind of approach as a “choice architecture” based in “libertarian paternalism” in their provocative book Nudge.
At any rate, one does not have to be a big fan of openness to appreciate the value of Bodington’s approach to permissions. In fact, Ken Romeo, an academic technology specialist and ESL teacher at Stanford, has a somewhat inverse concern, which he talks about in his critique of the Sakai 3 vision document:
Sakai seems to be designed with only a two-dimensional teacher-student interaction in mind, especially when looking at the roles and possible permissions. The proposal’s emphasis on collaboration addresses peer level interactions, but there is no mention of any possibility for establishing hierarchy. However, hierarchy is a reality of education around the world: teachers are often grouped together into units such as grades and departments with administrators such as coordinators and department heads. Curriculum is mandated from above, or shared among instructors, but often delivered to students in a very different form. In the department where I work, we have tried to create a set of permissions that would enable a coordinator, who is in charge of a group of instructors, but we ended up just creating new “resource” sites just for instructors to get mandated material and assignments. Even then, however, the roles are not what we would like: If the instructors are made students in that site they can download documents, but cannot export assignments. Consequently, they are left as instructors, but coordinators have found cases where instructors have accidentally deleted material. Also, coordinators create certain required assignments that instructors import from these resource sites and use for the term, but if they find there is a mistake, they need to have instructors download them again. Ideally, however, if the author makes a change, it should propagate out to all copies. This has been implemented for assignments within a site here, after considerable planning and effort by the developers, but there is no concept of a hierarchy beyond the site.
Here again, the culprit is role-based permissions. We have “teachers” and we have students. If the work relationships don’t fit those categories, you have problems. Now, one could argue that this problem could be solved within the role-based permission structure by simply creating more roles. But Bodington’s approach of attaching permissions to objects rather than people makes creating sophisticated levels of access (which are bound to be ideoscynratic since this is, after all, academia) much easier. It starts with object-level permissions. You can create groups that approximate roles, but it works much more flexibly because of the ways in which the groups can intersect with each other. You then fine-tune by adjusting the permissions at the object level.
This is easier to understand with a concrete example. Consider this example from the first part of my Bodington review:
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.
Really, low-level affordances such as access control are vastly more important to the value of a virtual learning environment than micro-features of individual tools because they have such far-reaching implications for the way everything works. We don’t pay enough attention to them.
I’m happy to report that there are plans to implement Bodington-like permissions into the Sakai 3.x series. I sincerely hope that this effort is given a high priority. In my opinion, it has at least as much potential to be a game changer as an other feature under consideration for the platform, with the possible exception of the widgetization/RESTification effort.
