The two biggest players in the learning management system world, Blackboard and Angel, will soon be one company, since Blackboard has purchased Angel Learning, Inc. for $95 million.  From a superficial reading of the press release, it appears that Blackboard thinks of itself as having a more technologically innovative product, whereas Angel has a better track record with customers — and Blackboard has the money to pull off the purchase.

I can’t verify any of those claims, but I can say that we switched from Blackboard to Angel at my college a few years ago due to a general dissatisfaction with the quality of the product compared to the price we were paying. I don’t recall Blackboard as being particularly innovative, although admittedly that was 4-5 years ago. Angel has not been much of an improvement, and I’ve blogged before about the maddening UI design decisions that Angel has made. In going from Blackboard to Angel, we basically traded one set of deeply flawed LMS technology for another.

And now we have the situation where the current sub-par LMS technology maker is being bought out by the previous equally-but-differently-subpar LMS technology maker. So who knows what exactly we, the users at my college, are going to end up with. The best-case scenario is that we would get the best of both technologies. There are some things that Angel does  pretty well, well enough at least that I am no longer finding myself forced to roll my own LMS at Wikispaces just to retain my sanity. We shall see.

In the meanwhile, Jon Mott has some excellent thoughts about life post-LMS. I think he’s right that the basic problem isn’t the implementation of the technology (although, as I’ve noted, there are some big problems there with Angel and probably with Blackboard as well) but rather the paradigm on which the technology is based. It makes me wonder if the real LMS that best suits the modern college or university is already out there, in the form of previously-released tools that just need to be cobbled together rather than an expensive proprietary software package that tries to emulate those tools.

Martin Weller of the UK’s Open University notes in this blog posting that there is an emerging cultural conflict between the world of higher education and the world of Web 2.0:

[T]he challenge is this – when learners have been accustomed to very facilitative, usable, personalisable and adaptive tools both for learning and socialising, why will they accept standardised, unintuitive, clumsy and out of date tools in formal education they are paying for? It won’t be a dramatic revolution (students accept lower physical accommodation standards when they leave home for university after all), but instead there will be a quiet migration. The monolithic LMSs will be deserted, digital tumbleweed blowing down their forums. Students will abandon these in favour of their tools, the back channel will grow and it will be constituted from content and communication technologies that don’t require a training course to understand and that come with a ready made community.

It’s difficult to say whether how accurate this is, given that students’ knowledge of, and ability to use, those tools is questionable at best. But I think Weller is right that students — faculty, too — are increasingly aware of and irritated by the clumsiness and inflexibility of the tech tools that higher education currently uses. It wouldn’t bother me at all if the Angels and Blackboards of the world were left behind in favor of simpler, more decentralized tools that can evolve throughout a semester according to the needs and capabilities of the members of a class. (This adaptability is a real strength of using a wiki as a course management system, as I am finding out right now in my summer calculus course. More on that later.)

Universities and colleges do seem to face a twofold mandate from students: not only to get in the game regarding technology in the first place, but also to do so in a way that keeps things simple and flexible and student-centered. That can be a tall order for higher ed, which is used to doing things in a highly top-down kind of way.

So I started my summer calculus class yesterday, which meets three nights a week from 5:30-7:45 PM and consists almost entirely of commuter students. I haven’t taught an evening class since graduate school, nor have I taught a class of non-resident students in nearly as long. Noteworthy thoughts (well, I’m noting them whether they are noteworthy or not): 

• I like teaching evening classes. There’s a kind of “after-hours” vibe to such classes that makes the atmosphere more intimate and relaxed. 
• I like teaching commuter students. Some of these folks are commuting in from nearly an hour away, which means it’s costing some of them between $5 and $10 per class meeting in travel expenses. Many of them have day jobs which consume all their time between 8:00 and 5:00. In other words, the resources that are normally available to students in luxuriant abundance — time to study, time and accessibility for office hours, availability of college resources like computer labs and tutoring services — are a lot more scarce. And therefore the students tend to have a much higher sense of making the most of what’s around them than regular-semester students (even the ones who I have had during the regular semester). I like that. 
• Two of the students in the class are from other local liberal arts colleges, and it’s interesting to see the differences in approach and student culture (even after one class meeting) between them and the students from my school. 
• Angel, our course management system, has been virtually non-functional for the last few days. Sunday night I sat down to put together the Angel site for the course, and it went completely offline 1/3 of the way through. I took that as being the final straw, and I took it upon myself to pull the trigger on Option 1 from the last time I got intolerably tired of Angel. That is, I create this Wikispaces site for my course. I am not entirely sure that I am allowed to do this, since some of my higher-ups balked when I used an off-site wiki hosting service for two course wikis (mainly because of the text ads and the potential for people not related to the college to edit a college-affiliated site). But with this many commuter students, we’ve got to have some sort of reliable, web-based service for posting documents and announcements and links. I’m finding that the Wikispaces site is just what I have been wanting, and there have been some nifty additions in functionality since I used them last. I’m doing a 30-day trial of the non-free version just to eliminate the text ads (because the class will be over in eight weeks) and allow for private viewing. If I were using this during the regular semester with 10 students, which is what I have now, I could simply tack on a course fee of $2 a head and pay for four months of the no-ad version easily. 

I’m pretty busy right now with writing, administering, and grading midterms — so blogging is light for a day or so more. However, given the recent posts and traffic about course management systems, I wonder if you wouldn’t mind answer a few questions down in the comments area. 

1. Teachers: What do you need a course management system to do? What functionality do you consider essential?
2. Teachers: What are the best ways for a course management system to help make your job of managing a course easy?  
3. Students: Same questions as #1 and #2. 
4. Current CMS software users: What are the three features of your CMS that are the most essential? If you could change three things about the way your CMS works, what would they be and what would you rather have? 

Here’s a little mini-tour through one of the many reasons why Angel, and other course management systems, drive me crazy and basically beg for me not to use them. This has to do with a simple and common course management task: Sending an email to all students in a class.

First of all, if you were using a basic email client to do this task, sending an email would be a matter of creating a distribution list for the students in the class — a one-time startup task — and then the following:

1. Type the name of the list in the To: blank. (Most email clients have an auto-complete feature that doesn’t even require you complete the full name of the recipient.)
2. Type in the subject and text of the email.
3. Hit “Send”.

Three steps, each of which is easy and intuitive.

If you want to do this in Angel, on the other hand, it becomes a seven-step task, which is really nine tasks — each of which, like the tasks required of Hercules or aspiring Zen masters, involves some kind of test of strength and willpower.

Step 1: You have to click on the “Communicate” link at the top of the course web page.

Step 2: You have to locate and click on the “Read and compose course mail messages” link. Note that this is a text link — not an icon, or something that is easy to click on, which is usually the case for a commonly-used action.

Step 3: Once you are in the course email area, you have to locate the “Compose” link. Quick — find it!

How long did it take you? Did your eyes go right to it? Mine either. Another text link, normal-sized font — buried on the page. Then you click on that. Wherever it is.

Step 4: You have to click on the “Add Recipients” link, which is still a text link but at least it’s conveniently located above the To: field.

Steps 5(a), 5(b), and 5(c): Having finally gotten to the place where you add email addresses, you have to click on the subset of recipients that could possibly receive the email (step 5(a)). Then you have to click “To ->” (Step 5(b)). Then you have to click “OK” (Step 5(c)).

There are no shortcuts here, such as double-clicking on the recipient to have that group automatically appear in the “To:” field.

Step 6: Type in the subject and the text of the email.

However: Notice that, at least on my Firefox browser running on Mac OS X, the text field for the email body extends way off to the right and there is no left-right scroll bar available! You have to resize the browser to take up nearly all the horizontal space of the screen, or else the stuff you type near the right end of the line is invisible.

Step 7: Step 7 is to click “Send”, right? Not so fast. In Angel, if you click Send at this point, the email does not go to the recipient’s actual internet email address — it goes to their Angel course mail account which is not an actual email address at all but rather a proprietary messaging system that can only be checked from within Angel. If you want the email (if we can really call it that, at this point) to go to the students’ actual email accounts, you have to scroll down and select a checkbox that is unselected by default:

Then you click Send.

So let’s review:

• Standard email client: One-time startup task of setting up the distribution list; then three intuitive steps to compose and send an email.
• Angel: Nine steps to accomplish the same task, each of which involves some kind of non-intuitive action or madness-inducing design principle.

I’m at a loss as to why the makers of course management systems make their products like this, or why faculty and students are expected to flock to the nine-step non-intuitive way of doing things when there are perfectly good, and free, means of doing the same things with less work.