In a recent post, I reviewed the advantages of Bodington’s unusual system of assigning access privileges and mentioned that the Sakai community is planning to support Bodington-like permissions in a future version. There was some follow-up discussion of this on the Sakai pedagogy listserv. In particular, John Norman pointed out that the more flexible permissions structure comes with significant usability challenges. I don’t have any clear-cut solutions to these problems, but I’m going to think out loud here and see where I can get with it all.
The fundamental problem with permissions is that they are abstract affordances. In the physcial world, affordances tend to be fairly obvious, almost by definition. I can tell imediately that a coffee cup affords being picked up because of the handle sticking out. Sometimes this can happen in a digital world as well. How can I tell if text on the screen affords editing? By the blinking cursor. But that doesn’t always work neatly. What if I’m not looking at the contents of the document, but a list of documents? We need some sort of iconic representation to communicate the affordance. And the more abstract the affordance, the harder it is to communicate. How do you communicate that the digital object affords the assignment of permissions? How do you make that intuitive?
In most groupware systems, we deal with the problem of this particular abstract affordance by avoiding it. We don’t attach permissions to objects. Instead, we attach them to people. The fact that I am a teacher means I can access some things and edit other things that students can’t access and edit. That’s a relatively compact and intuitive metaphor, at the cost of being crude. If we want to move to the more elegant system of permissions being attached to objects, then we need a similarly compact and intuitive representation that relatively naive users can grasp quickly. We need to find something familiar whose affordances map well to the onese we are trying to convey.
So. What are we trying to map here? We want to attach permissions to arbitrary semantic objects (documents, meetings, blog posts, tests, group spaces, etc.). Sometimes we want to attach a permission related to a single person. Sometimes we want to attach one related to a group. Sometimes we want to attach permissions related to several groups which overlap. The persons and groups are ad hoc and not reliably heirarchical. What does that sound like?
Tags. It sounds like tags. If we want to attach a permission to an object, we give it a permission tag. In technical terms, we need some sort of tagging namespace (or its equivalent; it doesn’t need to have the same implementation under the hood). From the usability perspective, the first question is whether users can deal with several different kinds of tags, e.g., permission tags and regular search/categorization tags. This is just an intuition, but my best guess is that users can handle more than one tagging namespace but no more than, say, three or four at any given time. You’d have to give visual cues to distinguish tag types (e.g., color), but I’m guessing users could handle this. (We’d want to do some usability testing to confirm.)
Unfortunately, the mapping doesn’t work perfectly. Tags are good for attaching one piece of information to a semantic object, but we need to attach two—what the permission is and who is getting it. So maybe what we really need is two different types of tags and a way to relate them. For people, we need a group tag. Only person objects can be tagged with group tags. On the other hand, digital artifacts (e.g., discussion posts, documents, meeting invites, etc.) can be tagged with permissions, e.g., edit access, read access, etc. Both would necessarily be controlled vocabularies. Permissions in particular would have to be constrained for the set of tags that make sense for a particular digital object type. For example, it might make sense to make a meeting, a work site, or a discussion board “joinable”, but not a discussion post. New permission tags would be definable by programmers only. In contrast, you could imagine allowing a user to create a new group/tag or register a new person/tag. You’d have to account for the differences in the two tagging interfaces, but since there are models for tagging in both open and controlled vocabulary models, this shouldn’t be a problem.
Once we have people able to take group tags and objects able to take permission tags, we need a way to relate them. What we’re really constructing in the end is an RDF-like triple relationship, e.g., “Discussion post X | is editable | by John.” The third item in the triple can be either a person or a group tag. (The latter has the effect of something like chaining triples, but now I’m getting over my head, so nevermind.) What I imagine happening in the user interface is something like adding an item to del.icio.us. When a user clicks on the option to add a permission tag, a dialog appears. The user must first select one or more permission types from a menu of options (e.g., view, edit, etc.). Then the user must pick one or more user or group tags, with an interface that works identically to the del.icio.us type-ahead tagging interface.
Of course, manually creating tags for every object in the system would be prohibitively cumbersome. So we also need mechanisms that auto-generate default tags within a particular context. Most obviously, the creator of an object (e.g., a document) would automatically have certain privileges assigned. Maybe artifacts created within the context of a particular course space could automatically assign privilege sets to different groups associated with a particular course (e.g., the teacher group, the TA group, the student group, the workgroup #1 group, etc.). This effectively approximates the ease of use that comes with role-based permissions while still allowing a lot of fine tuning.
I imagine there will be some edge cases where tagging won’t work for permissions. For example, how would you use tags to set permissions regarding whether a person can create new group tags? But in Sakai 3′s content-centric model, tags could work for a substantial majority of cases.
I’d be curious to hear what you all think about this, particularly if you have experience with Bodington or are working on Sakai 3.