The Methods Behind Moodle Madness: A TLT Expert Contextualizes Bethel’s Technology Choices

by Matt Putz

I have a confession to make. I have some patterns in my work-life for getting things done, and I like them. Maybe “like” is not strong enough. I like them a lot. I’m deeply connected to them. All right, fine – I’m obsessed with some of them. They took a lot to develop, they work well for me, and so please don’t make me change them. People who study how other people get complex things done call these developed behavior patterns “workflows.” I REALLY like my workflows. The trouble with my obsession is that I don’t live and work in a vacuum, and my workflows are connected to other people’s workflows, which I do not control at all. Sometimes someone imposes a change from outside of my system that requires me to change my workflow whether I want to or not, and on my worst days it makes me want to tear my hair out.

Take software upgrades. Occasionally I long for the good old days when I got to decide when I was going to plop my 16-floppy-disk Windows 95 install set into my three-and-a-half-inch disk drive and get my Windows 3.1 environment upgraded. (Actually, “replaced.” Back then, nothing really upgraded in the sense we would use the word today.) If I liked Windows 3.1 and didn’t want to switch, there was nobody making me. Windows 3.1 would run happily along on my computer for the next ten years (or so I thought), and there wasn’t yet anybody lurking who was going to create a virus that could scare me into applying a “security patch.” I had nothing but the carrots of lovely new functionality beckoning, and I could upgrade this year, next year, or never. (Right about now some of you want to get into the conversation about whether Windows 95 was EVER a good idea, but let’s stay on track.)

Now, I’ve got a mini computer in my pocket (AKA my phone) that reminds me every ten minutes that it automagically updated another one of the ten zillion apps I seemingly can’t live without. It also reminds me fifteen more apps need to be updated but can’t be without my explicit permission to allow them access to all sorts of information on my phone that is evidently important enough to ask me about but hasn’t yet become functionally important enough to get me to figure out just exactly what I’m giving the keys away to. It’s a dilemma. And then the update changes that one app that I use all the time and now I don’t know how to use it anymore, and BLAMMO. Somebody messed with my stuff (or moved my cheese, if that bit works for you).

It’s even worse when that app is web-based, like Gmail or Google Drive. Those are the sorts of apps that don’t even ask you if you want to update because they don’t live on your device at all. You go to bed one night and they’re one way, and you wake up in the morning and they’ve changed. Many of us who truly enjoy developing systems to deal with complex but repetitive tasks live in quiet, constant fear that those software features that are central to our workflows will just quietly go away some evening, leaving us stranded in You-Can’t-Get-There-From-Here-Anymore Land, also known as Now-Go-Do-More-Work-Than-You-Expected-To-Today Land. Nuts.

Can you identify with that?

In Teaching and Learning Technology, we work really hard to not do that to you any more than we absolutely have to, because we get just as irritated when that stuff happens to us.  It may not always appear so, but we are deeply concerned about that kind of stress, concerned to the point that we spend hours each month discussing how to assure the decisions we make cause you as little stress as possible.

The Challenge of Moodle

Take Moodle for instance. Moodle is a web-based application, meaning it lives on a web server, which is just a computer that “serves” all of the “clients” (our laptops and phones and desktops and tablets) that come asking it to do things for them, and people generally access it through some sort of a web browser like Chrome or Firefox or Safari. Gmail and Google Drive are also web applications, but the big difference between them and Moodle is that we at Bethel don’t control the web servers they run on or the code that determines how they operate. Google owns and takes care of all of that. We use those applications with Google’s permission. Moodle, on the other hand, is completely under our control. The software itself is open-source, and while a discourse on open-source software is beyond the scope of this writing, it essentially means that we have the right to use it pretty much however we like for no charge. One of the big reasons we moved away from Blackboard in 2010-2011 was because we were paying a lot of money every year to Blackboard, Inc. to use software that we had no control over, and we were frankly tired of both the quality (low) and pace (high) of change in that product. We wanted to make sure that we would have more control not only over what the Bethel community experienced, but also the pace at which that experience changed.

Having complete control of your own Learning Management System is a bit like Spider Man’s curse: With Great Strength Comes Great Responsibility. It means we have a wonderful opportunity to make this thing work the way we want it to. But it also means we don’t get to blame SomeCompany, Inc. for the problems we encounter. To people who like tweaking software, all that flexibility looks really interesting and fun. But I’m sure that bug zappers look interesting and fun to moths as well, so how do we go about making decisions about Moodle in such a way that our value of not introducing change for change’s sake and driving people unnecessarily crazy doesn’t get undermined by the tempting flexibility inherent in our technology?

Hosting

First, we have to be careful about where we put (“host”) it. We value hosting Moodle in an environment that is as reliable as we can possibly afford (so our users can have the best experience possible), that uses our expert technical staff in the most effective way possible, and that gives us control over things we actually need to be able to control. In 2010, that environment was an external company that claimed to be expert at hosting Moodle. After three years of sub-par experiences with that company, including being denied access that we had previously been promised to our own software, we made the difficult decision to move Moodle back to a server hosted on Bethel’s campus where our own staff could manage it more effectively. We hosted it there until this past summer, when we finally moved it to Amazon Web Services, where Amazon staff make sure the hardware runs like it’s supposed to and our staff have full and unfettered access to the software and a whole range of management tools we couldn’t even dream of purchasing or developing ourselves.

So we’ve arrived at the best of both worlds where our staff get to manage the user experience rather than trying to track down broken cables, but it took a while for us to figure out where Moodle lives best. And every time we had to make a hosting change, it required a tremendous amount of coordination to make sure that everybody at Bethel experienced very little downtime. Even after the move to AWS this fall, we experienced a number of teething troubles. But we’re confident it was worth it, and we have high hopes that we’ve landed on a long-term hosting arrangement. Because of this, we may even be able to realize the dream of not needing any downtime for future upgrades.

Upgrades

Speaking of upgrades, we also have to be thoughtful about how we keep our Moodle instance up to date and supportable. Every six months, the folks at moodle.org put out a major update, and they put out another 10 or so smaller updates in between those, which are mostly small bug fixes and security updates. This is a great example of how we have to balance the need to stay in sync with the rest of the world, but still do it in such a way that it causes as little pain as possible to the Bethel community.

We could choose to never upgrade our system, which would result in a very stable set of workflows for our community but which would also eventually leave us vulnerable to security problems and would not allow us to take advantage of changes in the system that have the potential to significantly change the educational experience for the better. On the other end of the spectrum, we could upgrade every time an update came out (and Moodle officially recommends that we do so), but that would constant workflow changes for Bethel faculty and students all throughout the year and at least some downtime every time we upgraded. So we compromised and made the decision to do one major upgrade once a year. Bethel never really takes a summer break, because our Seminary, CAPS, and GS never stop and CAS has summer courses, but summertime is still the least chaotic space for work like that, and so that’s when it happens.

We also have to keep in mind that Moodle is software created by (fallible) human beings, and that the best way to guarantee you’ll become a human guinea pig is by deploying software that came off the development line yesterday. So we stay one version behind, meaning that in the summer we install the version that came out the previous December. By that time, that version has had six months of user input from people who are evidently less concerned about being experimented on than we are and most of the major bugs have been worked out of it. It’s also still new enough that it will be kept current until at least the next summer when we upgrade again.

Repairs

Occasionally Moodle needs to be “fixed,” and we have to find ways to do this that cause the least amount of stress to the Bethel community, near-term (“How long is this going to take???! But don’t take the system down right now; I have class in 20 minutes…”) and long-term (“Did we fix it properly?”). The software is robust, but its implementation is complex, requiring a web application server, a database server, and a file repository to “talk” to each other and with Bethel’s other systems (some of which are in Amazon Web Services, some of which are hosted at Bethel, and some of which live other places) efficiently and effectively.

A great example of the need for a “fix” occurred just this fall when we found that our Moodle instance was simply not serving pages as quickly as it should have been, especially for pages requiring significant resources like gradebook edits. During a two-hour meeting between Teaching and Learning Technology and ITS, we determined the cause was the result of a database locking process meant to doubly guarantee the database was properly replicating and therefore protecting us from data loss in case of a disastrous failure of the Moodle server environment. The “fix” we agreed to involved giving up about one second of data vulnerability (meaning, worst-case, we could lose a maximum of one second of data in an emergency) for a 10-fold increase in speed for our users. That’s a really good compromise.

Requests

We also have to be appropriately sensitive to the large number of requests we get each year for changes to Moodle from the Bethel community. Over 8000 unique users logged in to Moodle at Bethel last year, and keeping them all happy requires a careful balancing act between the desire of the relatively few to have an environment that perfectly fits their expectations and the desire of the many for stable workflows. So whenever we get one of these requests, we ask some questions. OK – we ask a LOT of questions.

  • Would the change affect anybody else? (Usually this is a “yes.”)
  • Would the change involve a simple administrative setting change or the addition of additional code? If it involves additional code, does that code fit with how we see the system naturally evolving? Who maintains that code, how are they related to the broader Moodle community, and what are their motivations for continuing to maintain it? What are the chances that we would have to eventually choose between maintaining the code ourselves or dumping the feature? (Neither of those are good options.)

Even though we are able to, we don’t install many third-party add-ons in Moodle because taking things away can be more stressful than not providing them in the first place. We want to be reasonably certain that the major features we provide will be around for years to come so that people can rely on them to be central to their workflows. For instance, our plagiarism-detection system (Turnitin) and our enrollment and course-creation manager (LMB Module) are both third-party products with a long history and a reasonably predictable future, and we depend on that when we recommend their use.

  • Would the change involve an increase in individual freedom in the system? If so, would it allow people to create messes that are out of proportion with the good they might perform with this change? Would it allow people to do things that will make their courses more difficult to maintain in the future?

Moodle is a highly creative environment, with thousands of members of the Bethel community creating content in it every day. We want to encourage creative use of the tool while also keeping people from unknowingly doing things they will regret next month or next year. (For example, it may be that using seventeen different colors of text in your course-site isn’t the most sustainable way to develop a course-site that’s functionally accessible for visually impaired persons!)

  • Finally, coming around full-circle, would this change require faculty or students to unnecessarily learn another workflow, when there is clearly already one available that they are used to and that would work for the requestor as well?

We’re always asking the question, “How would this fix/change/upgrade/move affect over 8000 users?”

Help Us Change Well

Please don’t stop asking us to make changes in Moodle or other academic technology at Bethel that you think would be beneficial or even just fun. We love all of the creativity and ideas present here, and many of the good features and applications that are presently available to students and faculty here exist because someone not on the Teaching and Learning Technology team had a great idea that we were able to implement. Keep it coming.

And when you see announcements start appearing for our summer 2016 upgrade to the next version of Moodle, don’t forget that we started planning for that upgrade in December of 2015 (just a few days ago, in fact) because we want it to be as positive an experience as possible for you AND everybody. Even if some of MY workflows have to change – again.

Matthew Putz
Matt is an instructional technologist and instructional designer and directs the Teaching and Learning Technology team at Bethel. He also teaches is several graduate programs in the areas of technology leadership, ethics, and conflict management.

Comments are closed.