I got a lot of positive feedback on my "Advice for Small Schools on the LMS Selection Process" post, so I'm going to continue the occasional series. You can find all the posts in the series at any time by going to the "small school LMS selection" tag on my site.
To recap, these posts may apply to your school if at least three of the following are true:
- You work at a small school of 3,500 students or less.
- You have a couple of dozen faculty “heroes” who are using the LMS heavily, a bunch more who just stick their syllabus in it, and a substantial number who don’t use it at all.
- You offer a small number of distance learning and/or blended courses, but you don’t have any online degree programs or similar systematic collections of online classes.
- Your school hasn’t migrated to a different LMS in a long, long time. Maybe ever.
- Your LMS is hosted because you don’t have the IT staff to manage it internally.
- Your “integration” between your Student Information System (SIS) and your LMS is to manually export CSV files from the SIS and upload them into the LMS.
- You have been on Blackboard CE since it was WebCT CE version 4 or earlier.
- You’re not sure if you can handle a migration to anything from either a staffing or a budgetary perspective.
In my first post, I wrote both that "all of these systems are pretty good" and that "all of these systems are pretty bad". While that's rhetorically cute (maybe), I realize that it's not terribly helpful without some more explanation. So this post will provide that explanation.
Let's start with the good. One of the questions I heard in response to my point that schools with the profile described above are better off with a small number of easy-to-learn features than a large number of hard-to-learn features was whether they would regret going in that direction as their program grows more sophisticated. It's a good question. For the most part, the answer is "no". If you look at the schools in the U.S. that have some of the largest and most successful distance learning programs---University of Maryland University College, the SUNY Learning Network, Penn State World Campus, etc.---many of them hit their stride over a decade ago and were wildly successful with very simple (some would say primitive) Learning Management Systems. In fact, principles of online pedagogy are really only now beginning to evolve beyond what you can do with nothing more than a basic discussion board, basic file sharing, and a basic homework drop box. While technology can definitely be an enabler, program management (training, help desk, policies, etc.) are much more critical in most cases.
Furthermore, competition keeps these systems at rough parity for a host of features. Think about it this way: if Toyota makes passenger-side airbags or antilock brakes standard in all its models, it would be hard for Honda not to do the same. The company would be at a competitive disadvantage if it didn't try to keep up. That doesn't mean that Toyota will never come out with something that the other car makers don't have, but it does mean that whatever new feature they come out with as a competitive edge is perpetually in danger of being swallowed by the definition of the product category itself. There was a time when air conditioning in a car was a luxury. Now you'd be hard-pressed (at least in the U.S.) to find a car without it. In the LMS world, think of things like course wikis and test question randomization as the equivalents of air conditioners and FM radios in cars. To sum up, all of these systems are going to share a healthy subset of their features, and that subset has been empirically demonstrated to be more than enough for running a robust distance learning program.
Where the car analogy breaks down is in market segmentation. In the car market, you have economy cars that are obviously different in their feature sets than luxury cars. While Mercedes is going to try to compete with BMW on features, KIA is mostly not. You can expect a luxury-class car to have certain amenities---cruise control, heated seats, high-end stereo systems, etc.---that economy-class cars don't have. In the LMS market, there is no clear market segmentation, and cost is not necessarily a good indicator of relative feature-richness (or quality). While these products do have some substantial differences from each other, they can't be generalized into groups of the better/worse or the feature-rich/feature-impoverished. Rather, the differences between the products are idiosyncratic.
This brings me to the bad.
When I say that "all of these systems are pretty bad", I do not mean to imply that the developers are somehow sloppy or incompetent. I personally know people involved with the development of all of these platforms. Most of them are good, smart people. Rather, the issue is that developing a good LMS is pretty hard, for a variety of technical and non-technical reasons:
- Even core applications are hard to design because teaching methods are so diverse: The classic case is the grade book. For every ten teachers, you probably have at least twenty different ways of setting up a grade book. Some use letters, some use numbers, some use points. Some have categories, some don't. Some throw out the bottom two grades. By the time LMS developers add all the features necessary to meet all of these different types of grade book systems, they have basically re-implemented Microsoft Excel and have a positively Byzantine interface. You can say the same thing to a lesser degree for discussion boards, where teachers often have passionate disagreements about the smallest details about how they should be set up because teachers use discussion very differently in their different classes.
- A few applications are genuinely complex to develop: A test engine can account for up to one third of the total lines of code in an LMS. The logic for a full-featured testing system is really hairy. And like a grade book, it's high-stakes. You really don't want to miscalculate a student's test score or final grade because of a software bug. Selective release, where content is made available to students based on other information such as the student's test score or opening and closing dates, can also be complicated, in part because it's hard to provide rich functionality that's easy for the average instructor to figure out how to use.
- Online classrooms need to be as diverse as online teachers and students: If you teach art history, you probably teach with images. So you need an image teaching tool for your online class. But the way in which you teach with images is probably completely different than the way the histology professor teaches with images. So the two of you may very well need different image teaching tools (and maybe different grade books). Students are not widgets, and courses are not generic knowledge assembly lines. Therefore, virtual classrooms can't really be commoditized. The needs are too diverse. Once you get past the basics, there is an infinite variety of options LMS developers can pursue. So each vendor or open source community pursues a slightly different direction based on their own vision and constituency.
- There's a lot of re-inventing of the wheel (and the transmission): We tend to focus on the surface features of the LMS when we evaluate it. But a huge amount of effort goes into what's under the hood. I'm talking about common infrastructure elements that many applications have but that are actually pretty hard to get right. Many of these things go by terms that you might not be familiar with if you are non-technical---like session management and permissions. These deep architectural features can impact usability as well as stability and scalability in far-reaching and non-obvious ways. Because the LMS developers have to split their time between working on these hard foundational issues and keeping up with the ever-expanding list of new features to be added, it's very hard for them to do both well. Remember, none of these development teams are huge.
- Once on the lips, forever on the hips: As with any widely adopted software, it is very difficult for an LMS to shed a feature or way of doing things once it picks it up. Customers get used to the old way and don't want to bear the pain and cost of moving to a new way unless they absolutely have to or unless the benefits of doing so are enormous that they are obviously worth the pain. So all of these systems have parts of them that are obsolete (and parts that were just bad ideas in the first place) that they can't get rid of. To progress a lot more quickly in terms of innovation, LMS vendors would have to throw everything out and start with a clean sheet of paper. Which is expensive, because they'd have to re-invent the wheel and transmission yet again, not to mention that they'd have to put existing adoptees through painful migrations.
- It's hard to keep up with technology---even for technologists: There is a tremendous amount of innovation happening in consumer online software. I'm talking about blogs and wikis, Flickr and Google Docs, Facebook and Twitter, and many more. Clever and adventurous teachers who don't need institutional support are doing all kinds of incredible new things with these tools. It is impossible for LMS vendors to keep up with this innovation, much less to guess which new fads have staying power and broad educational value. There is even a compelling argument that the LMS itself is becoming obsolete and needs to be rethought or thrown out entirely. But that's a different conversation for a different time. It's not going anywhere fast enough that you need to panic or do anything radically different in your current selection process (which is both good and bad). The point is that there are a lot of different pulls on an LMS developer.
So what do you do with all of this good and bad? Here are some simple tips for small schools:
- Focus on ease-of-use.
- Focus on the success (or failure) stories of peer institutions.
- Focus on the quality of the support vendor.
- Try to get a feel for the general vision and roadmap of each LMS, and see if it fits with your own vision of your school's mission and priorities.
- Ask the vendors about how their systems integrate with those whizzy new consumer Web 2.0 tools that all the cool kids have.
- Don't obsess over specific features unless you have compelling reason to believe that they will have a significant impact on a wide range of courses or on a handful of critical programs.
- Don't let your LMS heroes' deep knowledge of one LMS dominate your definition of how an LMS should work.