Groundwork
5 min read
I've been at TWU for almost 5 months now and am excited at what I've been learning and implementing in getting TWU Online off the ground.
Very early on, I managed to secure a subdomain (create.twu.ca) and sign up for an institutional account at Reclaim Hosting. From there it was easy to spin up a multi-site WordPress installation. Today there are 14 sites and 67 users, including the most recent site, a course in our BA Leadership program. The instructor didn't need any convincing after seeing the state of Moodle around here.
Looming in 2017 is the task of revising our MA Leadership program to be a progressive program that is native to the web environment. I am not interested in barfing up a bunch of PDFs onto the web, adding some discussion forums and assignment dropboxes and calling it a day. It's going to be a big project, and it needs to be done for September.
So, I'm going to need, among other things and people, a bombdiggity design, development, and deployment workflow. As a school which has downed the MS Office Kool-Aid, and given the truism that if the only tool you have is a hammer, then every problem looks like a nail, you can guess what the go-to workflow might be.
untitled.docx --> Course ABC.docx --> Course ABC.docx3 --> Course ABC v1 date.doc.docx --> Course HIJ v3 date.pdf.docx
... and so on.
It doesn't take long for your ID to become swamped by just trying to track down and manage all the files being emailed back and forth.
I think I've found a way to avoid not only that problem, but a whole host of document management issues.
If you aren't familiar with git repositories, a little explanation may help clarify. I'm certainly not a power user, but I've tinkered enough to see that this is a significantly powerful model to manage the details and complexities of designing learning environments. Among the most popular git repositories is GitHub, which has grown out of the need to manage the creation of code for programmers. Because it is web based (either their server or your own), you can have multiple people accessing a single central document, rather than sending files back and forth and all around to everyone who needs to see them.
That in itself is a huge glob of grease in the workflow. But that is only the beginning of the magic of git repositories.
Version history is also built into the environment. That means that every time someone saves a version of the document, the previous version is kept as an archive of sorts. So if someone goofs and accidentally deletes a bunch of text, you can easily recover a previous version. In fact, you can recover any previous version.
Not sure what changes were made to the repository since the last time you worked on it? It's also super simple to compare versions. You'll get a side-by-side view with deleted text highlighted in red and new text highlighted in green. There's no need to remember to turn on change tracking in Word. It all happens automagically.
Better still is the fact that you can stick a fork in it. By that I mean that you can create a new branch of a repository and edit the new branch instead of the master, then you can push your changes back to the original by making a request. That way, changes and updates can be vetted and discussed before they are committed to the master.
Forking also allows for multiple versions of the same general content. This might be a boon if you have multiple sections of the same course along with faculty who might want to personalize or localize their particular section.
One drawback to github is that is is visibly designed for people who are immersed in tech fields, and so some of the language and the interface are challenging for newcomers. GitBook seems to have taken that interface and radically simplified the front end so that it looks just like a minimal word processor.
So, for the development process, Gitbook provides a secure, collaborative, version-controlled, forkable word processing environment that is accessible to anyone who knows how to use the most basic tools in MS word.
In my experience with a development process that relies on emailing documents back and forth, this is a huge advantage.
The next step, and another post, is the ability to set up a web environment that reads directly from your GitBook repository, so that updates happen once, in the repository, and they are propagated out to all the spots where the content is being displayed on the web.
I certainly don't have it all figured out yet, but things are looking promising!
