Sticking a Fork in the LMS

I had a moment of panic over the weekend. I was expecting to teach my summer course from June 14 to Aug 5. It turns out that due to an administrative error (which, quick frankly, I should have caught earlier) it was scheduled to start on Monday.

It usually takes me a full eight hour day to really get my course site/D2L site turned over for the new semester. I’m mainly fighting battles with changing due dates and what not. Not to mention summer session requires me switching up content to better fit a 8 week programming schedule instead of 16 weeks. has now been the course site for two full years, five semesters, and seven sections of the course. I’ve never really done a legitimate spring cleaning which makes it a rather bloated application at this point. So after I added the ingredients of little timing and not wanting to battle usual course site, I’ve taken my doctor’s advice and opted for a more nutrious, trimmed approach for the summer season.

This summer, I’m hosting all the course content and assignments in a Github Pages site:

Screen Shot 2016-05-17 at 3.50.34 PM.png

The site is powered by a single file. That’s right–ONE file. One thing that is nice about it being one file is that you can edit it directly in Github, so you don’t have to download the code itself.

Screen Shot 2016-05-17 at 3.46.05 PM.png

One thing I’m always interested in web is load speed. Time will eventually tell what the load time will be for this, but I’ve already moved 7/16 of the course and we’re at 3.7mb in size and at 776 lines of code. I did a load test and here are the early results:


Screen Shot 2016-05-17 at 5.08.23 PM.png

Ok. So, the Github site is larger (again, because we’re loading all the images at once) but it loads more than a full two seconds faster. That’s really quite fascinating considering that the front page of is really just that–a front page. And with the Github Pages site we are loading literally all of the content. It’s also got a much higher “perf. grade” from the site whatever that means. Before my website was 44% faster than other websites. Now its 80% faster! That’s a 36% increase in retention! 🙂

The theme is a very, very basic theme that uses the Jekyll framework. This means that it takes that lonely markdown file (which only has MD and HTML) and processes it through a single layout template file, which spits out this public page with an autogenerated menu based off of the equivalent of H2 and H3 tags. It’s really quite brilliant work. I happened to stumble upon this when I was prepping for the OLC Fork U! session. A course at NYU SPS on Advanced Javascript utilized Github heavily for their courseware and projects, and this happened to be the template for their syllabus.

Of course, this means that you can grab a copy (or “fork”) of the course whenever you’d like. You can also grab multiple versions, say for instance if you want it from a previous semester, as Github is version-controlled.

I’ve also set the site as my homepage in D2L, so the only piece of the course that will be utilizing the native functionality of the LMS will be quizzes and gradebook.

Screen Shot 2016-05-16 at 10.48.41 PM.png

To me, this is what OER for the web should start to reflect. It won’t just be a CC bumper sticker in your website footer. Those really don’t make much more than the text really remixable. We need the web to also be portable.

But is this the perfect solution? Nah, probably not yet. We’ve got a long way to go. As appealling as it is to me to have a course be one single file, there’s still a level of knowledge needed to really interact with it that can be deeply intimidating for someone will little to no web coding experience. I’d be much happier if Github would build a WYSIWIG editor into their web app.

But am I completely out of line in this way of thinking? I don’t quite think so. Github is merely an application built on top of the open-source language of Git. There is nothing saying that there can’t be a “Github-like” application built for education that’s a lot less intimidating and utilizing familiar verbiage. Like, really, do we need to say “Commit changes?” Why can’t we just say “Save?” One example that Alan Levine referred me to is GitBook, which is really slick and integrates quite nicely with Github itself. Here’s a study guide a student put together from his class notes:

Screen Shot 2016-05-17 at 3.59.06 PM.png

This means this students notes are 1.) shared 2.) forkable 3.) as well as downloadable in a variety of formats such as PDF and ePub.

Screen Shot 2016-05-17 at 4.01.48 PM.png

Again, quite brilliant for a student to do this. I’m really liking what I’m seeing from this forkable future! If you are interested in this, seriously, just create a Github account, fork the course site, and tinker with it. You aren’t touching any of my own site (in fact, it’s now YOUR site) and it will give you a sense of how this whole forkable/connected copies/federated world works.

Featured image is a flickr photo shared by othree under a Creative Commons ( BY ) license