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. PRPubs.us 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:
The site is powered by a single README.md file. That’s right — ONE file. 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:
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 consider the front page of PRPubs.us 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! :-)
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.
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.
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:
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.
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 and it will give you a sense of how this whole forkable/connected copies/federated world works.
Originally published at Adam Croom.