Ok in a set of somewhat freaky circumstances I seem to have been thinking through some ideas over the summer that a number of others have too. I had just finished sketching out some initial ideas yesterday and today I read through Mike Caulfield’s post A Better Way to Build a EdTech Support Wiki (or, Doctor, Heal Thyself)
and it hints at quite a few of the same kinds of issues I’ve been mulling over. The idea around federation from Ward Cunningham is pretty close to some of the thinking I’ve been doing – although I have to admit I had no idea until I saw Mike’s prior post A Federated Approach Could Make OER More Numerous, Findable, and Attributable about his work in this space.
So I’m coming from the perspective of spending a considerable amount of time last year working on the Publishing phase of content (through our work around TADPOLE) The Adaptive Digital Publishing Engine. While we completed the proof of concept the work is on ice at the moment and in the down time I started to rethink the system and ways we could simplify it, make it easier and make it better. In going through this reflection I started to think more about the authoring side of things – how could we make that better?
How can we write and develop content better?
The first clue was that writing works better through feedback. Getting others to collaborate, read, edit and change your work usually ends up in a better result. The project report and two academic papers I worked on last year were collaborative, but the experience of working this way sucked. The tools we have access to mean that it wasn’t easy to incorporate changes and edits (even finding them is a problem!) and this in turn created a huge number of version control issues. Even for myself, using different software applications meant copying and pasting from app to app – unsure of which was the “Master” copy.
At the same time my team was engaged in software development and it’s through this I became aware of Git. Git provides the backend technology that fosters collaboration between developers and through concepts like clone, fork & commit you are able to develop a custom workflow suited to you and your environment but in a way that actually fosters connection and collaboration. It provides the practical tools for people to actually work together as well as go off independently.
That concept was something missing from my experience writing. What I was using was just a bunch of clunky tools that required a lot of effort from me to mesh and work together – particularly going from authoring through to publication. Rather than simplifying the process the technology tended to get in the way. I quickly came to the realisation that what I needed was to work out how can I get Git working for me.
This coincided with one other big change in my work – Markdown. Throughout 2013 I made the switch to writing everything in Markdown. Occasionally it’s Google docs, but anything I initiate and work through, its Markdown. Why? Well it simplifies the publishing process. With a couple of keystrokes or mouse clicks I can publish my content to almost any format, any tool, any system and do it with clean, simple code. No mess no fuss. Add in a style sheet and I’m done, it’s that simple! This works great for me – but could this become more mainstream?
The last clue in framing my thinking came form some discussions around OERs at the Ascilite conference. In a great symposium session we worked in groups around some of the issues in developing and implementing OERs within institutions. Our group focussed quite a bit on the lack of interoperability of systems, information and published content. Again, despite the best efforts of many smart and talented people – technology was getting in the way.
Looking over what was happening I started to base my thinking around:
- Git – its ability to version control, clone, fork and commit.
- Markdown – as a simpler way of writing content to simplify publishing
- Open Practices – understanding of issues around tech needing to be more interoperable yet understanding of localisation.
Over the summer I’ve been mulling over how and what you could do about this and I came up with this:
An Academic Authoring Environment
The concept here is an Academic Authoring Environment that supports the following core functions:
- multiple authors
- multiple institutions
- publishing as a temporal container
- versioning, cloning, forking
- open & federated access
- a content first approach
- multiple workflow
- system interoperability (API connections)
- distributed hosting (self and institutional)
- self publishing + institutional
How could you do it?
Well I haven’t really worked all of this out in detail (and as I’m not a programmer som I’m unlikely to ever built it myself) but I have a few ideas that I’ve started to sketch out.
So my initial idea is to separate the flat file CMS into 1. an authoring and 2. a publishing function. We borrow the simple folder structure to order content and manage assets from the flat file CMS & setup a simple authoring standard. Writing in markdown would also allow you to use Git to manage the whole management of content and share, contribute and collaborate with version control, cloning and forking available. The publishing arm could be a customised flat file CMS for display on the web or an API pointing to the hosted content so that it can be incorporated directly into an LMS or CMS.
Now the ease of use for such a system, which at the moment looks like a text editor, is pretty low – but there are ways that it could be made better.
- An editing and collaboration interface like that used by Drafts or Editorially could be really useful to ease people into this new method of working. They could actually be incorporated as a optional component of the authoring environment!
- The authoring side can be kept relatively simple for the most part – just using files and folders – and the complex publishing components abstracted away. This can mean publishing a huge tome of work is as simple as telling a system to look at a folder. The technology rather than the person does the heavy lifting.
- Ideas like the Adaptive Media Element (AME) used in out TADPOLE work last year could be incorporated into the system. This would mean that complex and adaptive content is possible. AMEs could also be used to circumvent some of the limitations inherent in Markdown, which tends to err on the simple side of things.
- Once content is marked-up properly its a pretty simple process to convert it to other formats. This means that such as system could be used to populate web sites just as easily as it could be used to create printed books, mobile apps, eBooks and more! This is a huge selling point and broadens the use across an institution – rather than a tool specifically for teaching, research, support or administration.
- A system like this would be able to handle some of the issues that Mike highlighted around attribution – but also findability – a GitHub for academia would be a great idea!