Friday, August 10, 2018

A sort-of BS follow-up: Alternatives to LMS

Norbert's recent post on the BSification of academic life skipped one particular wart that's at the front of my mind now that I'm in the middle of preparing classes for the coming semester: Learning Management Systems (LMS). In my case, it's Blackboard, but Moddle and Canvas are also common. It is a truth universally acknowledged that every LMS sucks. It's not even mail client territory, where the accepted truth is "all mail clients suck, but the one I use sucks less". LMS are slow, clunky, inflexible, do not support common standards, and quite generally feel like they're designed by people who couldn't cut it at a real software company. They try to do a million things, and don't do any of them well. Alright, this is where the rant will stop. Cathartic as it may be, these things have been discussed a million times. Originally I had an entire post here that explores how the abysmal state of LMS is caused by different kinds of academic BS, but I'd like to focus on something more positive instead: alternatives to LMS that work well for me and might be useful for you, too. If somebody really wants to hear me complain about LMS and the academic BS surrounding them, let me know in the comments and I'll post that part as a follow-up.

In case it wasn't clear from the intro, I don't use LMS much in my teaching. They're both too limiting and too time-consuming for my tastes. But as a computational linguist I'm also fortunate enough that the students who take my courses are more willing to try unfamiliar technology. So I realize that what might be a viable alternative for me might not be a viable alternative for you or your students. Still, you might find some of the things here interesting. They're far from revolutionary, but still rare in linguistics as far as I can tell.


Kind of shocking that this even needs to be brought up, but why do LMS have an announcement page? Email is a perfectly fine tool for distributing announcements to a large group of people. Go to the LMS, export the list of users, extract all the email addresses, and convert it to a contact group in your mail client; if LMS offered decent APIs, you could write a script to do all of that for you at the beginning of each semester, but even as is it only takes a few minutes. Add the course number in the subject (e.g. [lin637]) so that emails can be automatically tagged and/or filtered by the students. That's more reliable than asking students to regularly check the LMS or its partner-app, you can add attachments if necessary, and if you know how to embed remote single-pixel pictures you can even track how many of your students read the announcements (unless they're really old-school and view all mails as plaintext). You can also use a script to automatically send out short reminders at specific times, e.g. 24h before an assignment is due. If you don't want to allow students to reply to these mails, send them from an address that bounces all incoming mail.

Yes, an LMS can do most of that, but it's clunkier, more limited, and has to be done from scratch each time you teach the course. You cannot do things like "send out the notification a day before assignment X is due", only "unlock this notification at this date and time". One year later, all dates have to be readjusted. Waste of time.

Custom domain names

As soon as you step out of the LMS ecosystem, you have to make sure everything stays easily accessible. The best way for that is an easily memorized url with a custom domain name.

Registering your own domain name is fairly easy and cheap. You can just go to a registrar service like namecheap, search for available domain names, and buy one for less than a dollar a month. Each course I teach gets a url of the form For example, redirects you to my course website for Computational Linguistics 2. This makes it much more convenient for the students to find the course materials, and it takes only a second compared to logging into an LMS, picking the right course from a long, long list, and waiting for the LMS to load the course page.


Screencasts are essentially video recordings of what's happening on your screen. They are perfect for teaching students how to install or use a specific piece of software. No more class time wasted on moving around a mouse cursor. Of course you can upload video files to an LMS, too, so this is a general thing that not enough instructors are making use of.

git + Github

I regularly teach Compuational Linguistics 2 at the graduate-level. This class covers a lot of theory and math, but students also have to do weekly Python programming assignments. The whole class is built around git, the most common version control system. A version control system is like a project-wide undo history that keeps track of all the changes and can be easily shared with collaborators. In addition, I use Github, a free (but not open source) cloud-based platform for sharing git projects. This makes the class workflow very similar to current software development practices. The main advantage is that the students not only learn about computational linguistics but also acquire basic skills in team-based software development.

The general workflow in the class is as follows:

  1. The lecture notes are written in Latex and synced with git to a central github repository.
  2. All students have access to this repository. With git, they can always sync the most recent version to their computer, so there's no need to manually download any files.
  3. In addition, each homework is hosted in its own repository. The students get the assignment via git, and push back their solutions to me as a Github pull request.
  4. I look at the code in their pull request and add line-by-line comments directly in the document as necessary. The Github interface makes this very quick and easy, and students can see immediately where I left comments.
Github also offers private repositories, which can only be viewed by users that you have explicitly granted access rights. This makes them ideal for distributing copyrighted materials. Students can sync the private readings repository with a single command to have their own copy of all the readings for the semester --- no cumbersome manual downloading required, nor do you have to spam their mailbox with one attached reading after the other.

Jupyter notebooks

A Jupyter notebook is like an interactive document where text and multimedia (figures, graphs, audio, video) is interspersed with executable code snippets. I use Jupyter notebooks for two of my courses (thanks to Lucas Champollion who brought them to my attention many years ago).

Language & Technology (LIN 120) is a 100-level introduction to computational linguistics and programming in Python. The notebooks teach students the basics of Python but also contain all the assignments they have to hand in. For beginning programmers, notebooks are a lot easier to wrap your head around than coding in a text editor or a shell --- the switch to notebooks really helped for this course. If you're curious, all the course materials are available at The notebooks can be directly viewed (but not run) on github; here's an example.

The other course is Mathematical Methods in Linguistics (LIN 539). This graduate course does not require any programming. Instead, I use Jupyter notebooks as an interactive textbook. Python acts as an automatic exercise generator so that students can self-test their understanding of the material. For example, one Python widget may show the students the randomly generated string aqolrmnn and ask whether lrmn is a substring, a subsequence, both, or neither. This can also be done in the other direction: "here's a string, what's a subsequence of length 5?". More complex examples include testing properties of relations, step-by-step verification of Boolean matrix multiplications, or generating a random finite-state automaton and asking students to provide a string that is (not) accepted by the automaton. The materials can be found at (you guessed it)

Disclaimer 1: The MathMethods materials are total work in progress. Many chapters are still missing, and the existing ones are not as interactive or approachable as I would like. Last semester me and Jon Rawski worked with four undergraduate students on improving the materials (Jessica Ju, Jiaxing Li, Anfernee Rodriques, Michael Tallini). But the changes have not been merged into the current version yet.

Disclaimer 2: The MathMethods notebooks will not display correctly on Github because I changed the theming with a custom css-file that Github refuses to load. They must be viewed on a proper Jupyter notebook server. Thanks to superdude extraordinaire Paul St. Denis, Stony Brook students have access to a preconfigured server through their browser, so no additional software setup is required. But most of you aren't Stony Brook students, so you'll have to deal with the sub-par version on Github or run your own server.

Jupyter notebooks are not a good fit for LMS. None of them support them natively, so students have to download the notebooks and then do something else with them to make them useable. At that point, you might just as well use easier means of distributing files.


One problem with Jupyter notebooks (and git, to some extent), is that they require students to install additional software. No matter how simple the process is, something is bound to go wrong for at least some of them. That's a big issue with Language & Technology which has over 200 students. So this semester, I'll try Cocalc, the successor of SageMath. This is a cloud-based service that already comes with all necessary software preconfigured. Students only need an up-to-date browser like Chrome or Firefox. This means that even tablets and chrome books can be used.

One downside is that performance is abysmal unless students upgrade to a higher tier. The upgrade is 14 bucks for one semester, which I can live with for a course that does not require a textbook. Another issue is that custom css for Jupyter notebooks isn't supported yet, so I can't use Cocalc for my Mathematical Methods course.

Cocalc also has one feature that I can't wait to try: peer grading. Students grade each other's assignments before the TAs get to take a look at it. This allows students to learn from their peers, and it reduces the grading load for the TAs. At least that's the idea, we'll see how well it works in practice. It's telling, though, that the whole process requires only the push of two buttons on Cocalc, whereas even creating an assignment is a more complicated process on Blackboard.

Virtual machines

Virtual machines are another solution to the setup hassle. A virtual machine allows you to run a fully configured operating system like any other program on your computer. So you can, say, run Windows on top of your OS X install, without any rebooting. It's just another program you can start and close whenever you want.

The computer-inside-a-computer aspect of virtual machines can be confusing, though, and after some bad experiences with undergrads I only use them for grad courses now. For Computational Linguistics 2, I provide a Linux-based VM that comes with everything required for the course: Python + useful libraries, Jupyter notebooks, git, tools for working with finite-state machines, various corpora, and so on. The VM is modular and has extensions for Haskell and R, among others, at the cost of increased hardware usage. This makes the VM useful for our other grad courses, too, e.g. Statistics and Computational Semantics. Of course students can still set up everything on their own, but now I can always tell them "use the VM" if something doesn't work the way it should.

A pedagogical advantage of the VM is that it exposes students to the Linux command line, which is a good skill to have for industry jobs. So I really try to get all students in Computational Linguistics 2 to use the VM.

Unsurprisingly, LMS cannot work with VMs at all. It would be ludicrous for an LMS to run a VM. But you cannot even use them to distribute a VM --- the LMS chokes on files that go beyond a few megabytes.


This one is completely invisible to the students, but can make a big difference for the instructor. Markdown is a very simple syntax format for writing structured text files. These text files can be converted to doc, docx, ppt, tex, pdf, html, or epub (and ebook format). It pretty much makes word processors and power point obsolete for general usage. And since students are increasingly working on small-screen devices, it's a good idea to make lecture notes available in a variety of formats to better suit the abilities of different devices.

The notebooks for my Mathematical Methods course are written in Markdown and then converted to notebooks with notedown. For heavy jobs like the lecture notes for Computational Linguistics 2 I still prefer the control Latex gives me. But for lighter tasks I'll gladly use Markdown (or rather, it's extension pandoc). And the best thing: learning Markdown only takes 30 minutes.

If you're sick of word processors but think Latex is too much of a good thing, Markdown or pandoc might be right for you. You get basic things like italics, bold face, headers, numbered and unnumbered lists, embedded lists, code blocks with automatic syntax highlighting, links, images, tables, quotes, floats, and mathematics typesetting (using standard Latex syntax). There's also basic example numbering, but it does not allow for things like (2a) or (2'). Linguists will sorely miss the support for glosses --- I've looked into writing a pandoc extension for this, but haven't had the time yet. I have a custom script for typesetting trees, but it's not production ready yet, either. So yes, it's not the perfect package for linguists yet. Even so, it might still be more pleasant to write your paper/handout/slides in Markdown first, convert to doc/ptt, and then do final touch-ups in that file.

I guess at this point I do not have to mention that Blackboard does not support Markdown for its announcements or discussion boards (I believe Moodle does). Instead, it wants you to write HTML (a total mess), or use the GUI buttons for formatting, which is slow and buggy.

Wrapping up

I'm under no illusion that most of you won't immediately jump on those tools and start ditching your usual routine to do things the way I think they should be done. Many of them require an initial time investment before they start paying off in the long run. Others simply aren't a good fit for, say, an undergrad syntax intro. So yeah, I get why most instructors don't need or don't want to use these things. But if you have a particular itch to scratch and don't know how, maybe one of the above will do the trick.


  1. I really like the idea of using GitHub for course sites and materials!

    I wonder if you could take this a step further using GitHub Pages to make a nice homepage hiding the GitHub interface and cryptic "", as well avoiding the need scroll down past the repository contents to see the actual page. I've used GitHub Pages for hosting a simple Jekyll site, but it looks like plain Markdown should work as well.

    Also, I think it's worth emphasizing the fact that GitHub will automatically render (Github's dialect of) Markdown to HTML for viewing, whether in the form of a GitHub Pages site or a simple ".md" file in a repository. So if you only use Markdown for webpages, no conversion is necessary.

    A further thought: Github repositories also have an optional wiki attached. No need to host your own or use a separate wiki hosting site.

    1. For my own courses I like the students to be exposed to the github interface, it's part of the learning experience. But those are grad-level compling courses. In general, you are completely right, though, github is an easy way to host websites, be it for a course, a workshop, or your personal website. They even support custom domain names.

      The github wiki I couldn't find a good use for. For a while I had students write group summaries of the assigned reading and upload them to the wiki. But the wiki isn't set up for collaborative writing in the web interface, so students would end up overwriting each other's changes. You can clone the wiki as a separate repository and then use git to resolve merge conflicts, but that's too much for an inexperienced student in week 2 of the semester. My lecture notes are too much like a textbook to fit the heavily interlinked style of a wiki. What else is there? A glossary? Syllabus? Git tutorial?

    2. @Kenneth, @Thomas: I suspect you two might find some of the discussion in the slides that are linked to in this tweet interesting. I have no experience with Jupyter, so I'm not totally sure what to make of the points raised in those slides, but I found most of them interesting.

    3. I've never used Jupyter notebooks either, though I've been meaning to try them out. I can see what the slides were getting at, but I don't know how relevant the issues are to the current topic.

    4. @Thomas Regarding wikis, I've had programming courses in the past whose websites contained a lot of miscellaneous reference pages in plain HTML: setup information, how-tos, coding style examples, and so on. I imagine a wiki might add a bit of convenience in organizing all of this.

  2. Thanks for this post; there are a number of interesting ideas here I hadn't thought of. My interactive/code-sharing needs are a lot less extensive than some of the things you mention here. But I did want to endorse simply setting up plain html pages for courses and abandoning the LMS sites (or limiting them to linking to the html page). I finally took this step this week (and set up gmail groups for class emails). It took about an hour and a half per class (and that will be a lot less when I teach these classes again), and I already feel like a weight has been lifted off my shoulders.