Tenured Radical is asking the question that should be required reading for every CIO, CTO, LMS suitor, and higher ed tech commentator: if computers are such a blessing to higher ed, how come their use is actively extending the working lives of their users to such a damaging degree? The series of events she describes will have elicited low moans of sympathy from all of us working in writing-intensive courses online: an innovative learning task set up to use a system well, driven by good teaching principles and student-centredness and all the rest of it, all going swimmingly until, with a clunk:
Students suddenly became unable to upload the papers that they were expected to share with each other for the following day. Since I became aware of the issue around 6 P.M., when the earliest finishers started trying to deposit their work, I ended up spending an evening on it that I would otherwise have spent preparing the class itself (of course, given that it was long after working hours, I would have preferred catching up with Boardwalk Empire, reading a novel or staring glassily into space.) No technophobe, I opened up the settings to see what was wrong, and there went the rest of the night, with a quick break to warm up something from Trader Joe’s. At one point, I found myself displaying the platform on three separate browsers to compare the settings that had worked to the settings that hadn’t, creating exact parallels between the settings on each browser, and testing each (as if I were a student) to see if what we were dealing with was a browser rather than a software issue.
You need to read the whole post to find out what went wrong and how it was eventually fixed, but the point that can’t be hammered home stridently enough is that this experience is … so … routine.
Something I think many university leaders find hard to grasp as they’re searching for the magical online cloud that will save them from the infrastructure costs of more buildings and services, is that clouds seem easier and quicker to establish, but they really don’t stay still for long. That’s what makes the metaphor so effective: these clouds are moving. Software is constantly being upgraded, and systems are constantly being patched. Each tiny fix and patch risks causing one part of the overall structure to fall out of love with another, a situation made far more acute by the fact that higher education institutions can’t for one second guarantee browser compatibility among their thousands of users. Meanwhile, security, storage and disaster recovery are exceptionally volatile areas of institutional risk: people who are bothering to spend their time engaged in malicious hacking aren’t going to wait for everyone to catch up calmly. It’s a jungle out there.
All this means that what looks like a stable system at the interface, both for your CEO and your average user, is in fact just how things are patched up today. Most of the situations like the one Tenured Radical describes result from one of these tiny background fixes that has a butterfly effect somewhere else in the ecosystem. And this is so often discovered only late at night, on weekends, when students work intensively and academics really should be advised not to try to use this time to catch up on a little online reading or class preparation because this is exactly how we get caught over and over with the emails of panic about assignments that won’t upload, systems that lock out or freeze, or content that won’t download or open.
The realisation that this level of failure is so routine has added to my thinking yesterday about the lack of real competitive energy in the higher education technology market. The leaden nature of contract timing means, frankly, that vendors have become used to being able to disappoint us. We’re locked in and they know it. So again, the significance of the recent wins that Phil Hill has tracked in the emerging LMS vendor market isn’t the size of the institution or the number of users, even though these are truly impressive: it’s the length of the contract, and the time it will take for that institution and its users to come back on the market. Until then, the vendor is more or less safe from the consequences of poor design, and incomplete or stalled development.
Sadly, the real cost of this is swiftly transferred onto the higher education institution trying to manage its own customer relations. Our IT departments are flat out with the running repairs, and not all of this is done in normal office hours, as the systems teams try to find the time of the week when they can take the whole thing down safely for a few hours. In too many cases, this is at 6am on a Sunday morning, but even with this effort and cost, they still can’t save the tech-friendly student-centred academic who’s up late on Sunday night trying to figure out and communicate Plan B to her frantic students.
Momentarily I’ve forgotten why it is that we have all become so used to this, and so accepting of it. If the bricks and mortar showed a similar pattern of instability, I’m not sure we’d go back into the building on Monday, would we?
3 Responses
If the issue is sharing papers, can’t students be directed to Dropbox or a similar service? Google Docs? Many of the student-side functions on an LMS are already done better by third-parties, companies that have real web design ability and don’t force “your browser isn’t supported” messages on every other visitor.
But I realize a piecemeal approach is also problematic for a number of reasons. We can’t force students into public services, especially ones that might track their data (e.g. holding class discussions on Facebook or Google+). And the burden of learning 5 services–albeit stable ones that actually work–as opposed to a single LMS can’t be underestimated. But I always toy with this idea that classes can be scrapped together from wikis, social media, and cloud editing tools rather than asking an overburdened LMS to do all that.
Yes, me too! But I think TR’s point, which is also probably mine, is that the problem is workload for the average lecturer who really just wants to be able to do the things the LMS said it would do. Like you, I’m happy to scrape all sorts of social and public cloud stuff together and see what works, but I’m also aware that this involves a ton of time. And really, the issue is that LMS vendors are still meeting client needs at the tender and specification stage by saying “Oh yes, ours does that” when what they really mean is “sort of, in the demo, providing you don’t actually put much pressure on it” and then what they mean, under all that, is “Anyway, why don’t you use Google Docs?” But they don’t say this at the tender stage because for many institutions third-party dependency is itself a risk, which I’m beginning to think is why they retain so many phantom tools that don’t actually do the job to any meaningful standard.
[…] the weekend, and over the big pond, Music for Deckchairs had two interesting posts that called me out for perhaps being too optimistic on the transformation of LMS markets. The two […]