A distributed, multi-client courseware

At yesterday’s THATCamp I attended a session, facilitated by Steve Ramsay, entitled “All Courseware Sucks”. You can read the blog post that served as the inspiration for the session at the THATCamp blog. Steve started the session by framing the issue in a way that ended up being quite helpful: he had us list the features of courseware that we’d used, and then to talk about whether they were all crucial. The problem is that almost all of them were crucial to at least someone in the room. Moreover, some of the items that certain individuals found the most useful (say, a gradebook where students could track their progress) seemed the most expendable to others. Listening to that discussion, I thought to myself: This must be what happens in Blackboard focus groups. Gödel’s Second Theorem of LMSes: Any learning management system with a vocabulary rich enough to do interesting work can be shown to be bloatware.

If it’s not the functionality of courseware that we dislike, then, what is it? Well, the basic complaint seems to be that the interface is terrible. And not just terrible in an aesthetic way, though certainly most courseware is absolutely devoid of whimsy. The deeper problem is that software design decisions about how courseware conceives of a course – its hierarchy, its ontology, the vocabulary used to describe its objects, its workflow, its presentation – constrain the instructional design decisions that the professor can make about how the course will be taught.

How do you design a courseware interface that jibes with the aesthetic and instructional predilictions of instructors from math, biology, French Lit, and everywhere between? Answer: You don’t. There are dozens and dozens of well-developed, general purpose content management systems out there. Each has an interface that its users are comfortable with. Why not take advantage of this fact? If students sometimes prefer Blackboard because at least with Bb they know what they’re getting into, why not just let them use whatever they’re already comfortable with?

The idea in a nutshell: Abstract the content from the platform, so that individual students and professors can use whatever platform they’d like as an interface. Existing CMSes like Blackboard, Moodle, WordPress, Drupal, Joomla, and so forth become clients that sync with a central data repository hosted by the school or by a third party.

There are about a trillion details that need to be filled in to make this viable. But here’s a very rough-n-ready explanation of how it might work in a particular case. Let’s imagine that Jack is the professor, using Drupal as client software, and Sally is the student, using WordPress as her preferred client. Jack is going to assign a blog post, and Sally’s going to complete it.

  1. Jack logs into his Drupal installation. This could be on his own server or on a centralized installation hosted by his school. On this installation there will be a module that creates a number of new content types in addition to the default Story and Page. Let’s imagine the content type is called Assignment, which contains fields for content, subject, due date, and whatever other metadata you might like.
  2. Jack writes the assignment and saves it. It saves to the Drupal database as a native Drupal item.
  3. After the save, a hook is triggered by a Bridge module. Bridges are client-specific translators that send and fetch information to and from the central repository. The Bridge module translates the Drupal content type into an XML or JSON document that is formatted according to the agreed-upon standard data format for Assignments.
  4. The Bridge module sends the document to the central Server. The Server can be connected to the student information and registrar systems in much the way that Blackboard is. The Server recognizes Jack’s signature on the document, and furthermore knows that the file is associated with Jack’s particular course. The document is translated into a Server database object and saved, keyed by Jack’s user id, the course id, etc. The Server could be set up to send out email notifications to students at this time, alerting them of a new assignment.
  5. The next time Sally logs into her WordPress installation, her WP Bridge plugin (another piece of translating software, this one WP-specific) pings the Server. The Server knows that Sally is in Jack’s class, so it looks through the database to see if any new assignments have been posted in that class since Sally last logged in. It finds the blog assignment that Jack posted, translates it to a JSON or XML doc, and sends it to Sally’s WordPress installation. The Bridge then parses the document and saves it as a WordPress-native item in the database of Sally’s WordPress installation, perhaps as an instance of a custom post type or something like that.
  6. Sally visits the course page in her WP installation. This could be an admin panel on the Dashboard, or a front-end page. It shows the new assignment, to write a new blog post.
  7. Sally writes a new blog post using the native blog functionality of WP (different content types that aren’t so WP-friendly would need a bit of interface or theme work. Discussion forums, for instance, could easily be stored as custom post types and skinned to look like a traditional forum thread). She might indicate, using a certain tag or category or postmeta checkbox, that this blog post belongs to a particular class, or is a response to a particular assignment. The post is saved to the WP database, and, as above, the Bridge plugin then kicks in, translates the post, and sends it back to the Server, where the process will repeat the next time that Jack logs into his installation.

As I’m writing this, I realize that it seems really simple and obvious, and I’m sure that there are a hundred reasons why something like this would be hard to actually implement. But it’s worth exploration, as this model enjoys the huge advantage of letting the user choose whichever of a number of interfaces suits their fancy.

A few complications to mull over, off the top of my head:

4 thoughts on “A distributed, multi-client courseware

  1. Luke

    Wow, Boone, a lot to think about here.

    Two concerns immediately come to my mind about a model like this as an “enterprise solution,” and I’m curious what folks thought about these ?s at THATcamp.

    The first is that this model presupposes both the desire and the ability for students to make a critical choice about how online they want to do their coursework. Should we expect it of all of them? Only some? If so, which ones, and when? You could address this by having a default platform, but as we all know, defaults are privileged.

    The second is that it absolves faculty members of making a choice for the platform through which students engage with course material, and switches that burden to students. There are definite arguments for this, but one argument against it is that the process of choosing a platform is often pedagogically generative for faculty members. If the underlying argument is that the differences between CMS platforms will and should be flattened by bridging, then does that fact ultimately devalue the presence of a choice in the first place?

    These points aside, your proposal creates all sorts of new and valuable questions that could certainly trump these concerns.

  2. Boone Gorges Post author

    Thanks for the thoughts, Luke.

    I think that a default system is the beginning of the answer to your question about critical platform choice. You’re right that defaults are privileged, but certainly no more so than *sole* options. Platform-sampling might be built into a first-semester curriculum, and students could be encouraged to revisit and rejustify their choice periodically throughout their careers. I might start with the default, move to WP as a sophomore, and then to Drupal as a senior, for instance. I’d still reap the benefit of not having to platform hop within a given term, without suffering lockin.

    I agree with the spirit of your comment about the value of platform choice. I should note that my proposal, prima facie at least, shifts the generative process from faculty members making curricular decisions to students in a learning environment, which seems like a good trade off. Still, I can appreciate the force of what you’re saying. In some cases it will be recommended and perhaps even necessary for a faculty member to require a given platform for a certain class. That might happen, for instance, in a publishing class, or a design class. But it wouldn’t have to happen in every class, which I think is a good thing – while I’m all for reflection and critical engagement with media, I don’t think that the wheel needs to be reinvented for every semester or every professor or every class. There is some real value in being able to elide over this decision in certain kinds of classes.

  3. Pingback: » Evolution of Education Damon Cook

  4. Pingback: The Results of an Unconference - ProfHacker - The Chronicle of Higher Education

Leave a Reply

Your email address will not be published. Required fields are marked *