Tag Archives: LMS

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:

  • Certain content is likely not to translate very well between platforms, especially content whose visual presentation is central to its effect. In those instances, the content could be rendered using the client software of the author and linked to in addition to/instead of being transcoded.
  • File storage. Where do you store images, zip files, etc? On the author’s client installation, on the Server, or both?
  • Security. How do you ensure that only Jack is able to download assignments for his course? What prot

Parsing the box

My friend Matt blogged this morning about how the concept of the Learning Management System is misguided. I agree with the gist of what he says there, but there are some ways in which I think that the anti-LMS rhetoric can be easily overgeneralized. The metaphor of the LMS as a “box” is telling: quite unpleasant indeed, but somewhat ambiguous in just what the problems of the LMS really are. From my point of view, there are different ways in which LMSs function like boxes, and not all of them are equally bad, or at least not bad in the same way.

First, there is the sense in which LMSs fossilize a certain teacher-centered model of learning, preventing both the instructor and the student from pursuing a different kind of learning model. In this sense, the box keeps people enclosed, and this does indeed seem like a bad thing.

Second, the box keeps other people out – this is the box’s tendency away from openness. LMSs are by and large closed to people not directly involved in the class. Generally speaking, openness is a worthwhile thing to aspire to, but surely it must be granted (by anyone who takes seriously the idea of teaching our students the intricacies of identifying and reacting to audience) that there are some classroom scenarios in which pedagogical goals can only be met in a closed space. Aside from this pedagogical consideration, there are more legalistic reasons for wanting a walled garden – the reproduction of copyrighted materials for educational purposes, for example. Now, I realize that there are ways to replicate this feature of the LMS outside of the LMS proper, ways that make closedness optional. Moreover, I think there’s a tendency on the behalf of many educators to default to the closed system out of fear or laziness, and this tendency should be challenged. Yet there remain some cases where the closed boxiness of the LMS is – at least in theory – something to be desired.

Third, the LMS is a box in the same way that this is a box, bringing together a bunch of popular material into one relatively convenient set. The purist will always argue that you’re better off buying the individual albums, that there’s so much richness you lose when you lose the context of the record. But the purist already owns every Zeppelin album and thus has already gone through the learning process, while the intended market for the box set has not. Likewise, the WP purist will always argue that Wordpress (or whatever the pet tech happens to be) is so much better than the bundled version. Like the Zep purist, the WP purist will almost always be right about the superiority of “the real thing”. But the purist is a geek, and speaks from the geek’s point of view. For the non-geek, there are lots of practical reasons to prefer the ease and convenience of the box. And even the staunchest purist would never wish to deprive the neophyte of Stairway to Heaven just because the neophyte doesn’t want to buy every Zeppelin record.

There are lots of reasons to want to rid oneself and one’s university of the LMS. But just because LMSs are, on balance, pretty awful doesn’t mean that everything about them is awful.