An Academic Authoring Environment

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:

  1. Git – its ability to version control, clone, fork and commit.
  2. Markdown – as a simpler way of writing content to simplify publishing
  3. 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:

  • collaboration
  • multiple authors
  • multiple institutions
  • publishing as a temporal container
  • versioning, cloning, forking
  • customisation
  • localisation
  • 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.

The main one comes through the arrival of the flat file CMS. Rather than build a monolithic system the flat file CMS just works via files and folders – things like Ghost, Statamic & Kirby. They store your content as simple text files, and use a folder structure for your other components – media, css, javascript. Then using PHP (or similar) your website get put together on the fly. This allows a level of independence from databases and applications to keep things much simpler and manageable.

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.

Additions

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!
About these ads

5 thoughts on “An Academic Authoring Environment

  1. Let me play devil’s advocate and also show some of my biases.

    Some context.

    I’ve used, observed, and led attempts at “institutional” publishing systems/processes over the years. I believe I’m about to have a subset of one inflicted upon me.

    None with the thinking and technology you’ve displayed in the above, but I still think what you’re suggesting will face the same big hurdles as all the other attempts

    A focus on solving downstream problems, rather than immediate (perceived) need of the authors; and
    When an author is writing a paper, learning resource etc, their focus is on the writing process. That’s the hard part. Findability, reuse etc are not at the forefront of their concerns. Hell, when it comes to learning resources they are creating, the idea of someone else using their resources is hugely problematic for many people.

    Requires the authors to change their existing practice.
    e.g. “Throughout 2013 I made the switch to writing everything in Markdown”

    In short, you’re asking people to change their authoring practices to solve problems they don’t even see. Making the problem they are focusing on – writing the thing in the first place – more difficult for the promise of some later pay off that probably doesn’t benefit them (or at least they don’t see it).

    There are of course always people that see the value and use the system. But large-scale adoption without corruption or compliance always seems unlikely.

  2. Thanks David, and to be honest I always like to deal with the devil at this point in time – gets a lot harder down the line!

    I think in general terms this isn’t a technical solution for the current environment nor to meet current practices. I don’t expect it to solve any of the immediate problems because I’m of the opinion that those perceived problems are evolving as we speak.

    So the idea I’m working on is almost pre-emptive because it’s based on my work on pilots which I would say is a good 6-12months ahead of the institution as a whole. What I’m attempting to do is start the ball rolling so that there’s something in place (or being developed) when things break and systems have to change. I wouldn’t expect there to be a huge demand or willingness right now to adopt, but for those working across the globe in the OER and in publishing areas, the holes with current practice and solutions are becoming more and more apparent.

    I actually think the best way forward would be appealing to a global audience might be more relevant than a focus on the institution. I think the numbers are there – just dispersed but also would be of huge benefit in terms of sowing seeds as well as testing and working on some of those things I see as core – collaboration, interoperability, localisation.

    I know that there is changed involved but what I have in my head at the moment is zero friction to publish. The value of such a system is that academics author, click a few buttons and it’s done – there and visible for the world to see. No need to format, template etc – all that work can be automated. Add that to the relative ease of updating, maintaining, collaborating and we start to see technology begin to pull its own weight in the equation for once!

    So at this point in time, the value might not be apparent to all, particularly the mainstream – but I think if you start from the edge you can work your way in!

  3. hey Tim- I just bumped into this post. Great stuff! I wonder if you heard about Authorea (https://authorea.com/)? It is an academic authoring environment very very similar to what you describe. It is built on Git for version control (every article is a Git repo), it renders Markdown and LaTeX to HTML, and of course it is collaborative (multiple authors, etc). As of last month, it can also process and render IPython notebooks and d3.js to allow interactive, data-driven plots to be included in articles.

    Best,
    Alberto

    1. Thanks Alberto! I’ve been having a bit of a play with Authorea after you posted your comment. I think there is a lot to like there – it does a lot of things well and something I would happily recommend to others. I think however it’s a bit focussed on research paper authoring – but my original thinking was about authoring more broadly. I might not have been 100% clear in the post – and might not be 100% clear in my head either :) – but I was aiming to investigate authoring as a process rather than a specific output. So a system capable of authoring any type of content and so a focus on functionality rather than features. Its still something I haven’t really got a solid feel for it as yet but this post is part of the process – forcing the liquid ideas to become more solid with the pressure of trying to explain them!

      I think this http://www.flickr.com/photos/timklapdor/12297100415/ might help explain some of the thinking!

  4. Thanks for the kind words, Tim. Yes, Authorea is certainly for research papers. I bumped into your post since it discussed academic authoring. Indeed research can be considered a subset of academia, and there are not many great tools to write academic (student) papers but a lot of new tools like the ones you mentioned will hopefully move in that direction (e.g. by enabling citation, referencing, some publication workflows, etc) and considering authoring more as a process rather than output, as you mention. We hope to make Authorea more student-friendly too, so stay tuned!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s