I’m feeling a little inspired after reading David Wiley’s The Remix Hypothesis and Mike Caulfield’s Paper Thoughts and the Remix Hypothesis. That’s on top of putting together an application for a Shuttleworth Foundation Fellowship where I’ve applied to carry on doing work around adaptive digital publishing. (The pitch video outlines a lot of what I’m going to describe in a pretty simple way – so if you want to know more have a watch and I’m happy to answer any questions). One thing I’m particularly keen to explore in this space is how to improve sharing, collaboration, reuse and remixing – is it possible to build that kind of functionality into a system so that is built for and with open content at its heart?
Over the last couple of years I’ve been playing around with the concept of Adaptive Digital Publishing. A group of us wrote a paper and developed a proof of concept. We shopped it around for funding but other people had other priorities.
Conceptually I think it stands up as the most effective way to publish materials across multiple platforms. It bought together ideas that are only now starting to emerge into the mainstream – e.g., in srcset and picture in HTML – where content is adapted depending on attributes set by the device & browser. The Adaptive Media Element we worked on did that – but in more complex ways and for all types of media – from video, data, images to audio and across print, web and eBooks.
The proof of concept we developed was built on WordPress and used the PressBooks plugin to provide many of the features we required, an easy to use interface and a solid foundation to work from. The ideas were executable more easily within an existing framework, so rather than attempting to build everything from scratch we could focus on our innovations – the AME and the corresponding Publishing Profiles.
Ever since we built that initial proof-of-concept I’ve been toying with how to make it simpler. How can we make it easier to share, collaborate and remix content? Our initial concept didn’t really think about those areas, but they’ve been bugging me ever since.
How to Support Remixing?
One way would be to expose the WordPress system via JSON. This would allow other systems to pull content in to display, but also to commingle, re-contextualised and retooled. My experience over the summer with Federated Wiki has challenged many of my preconceptions about how content, and indeed publishing can look like in a purely digital sense. I’m enthused by the concept of a JSON based system but there are plenty of dependencies and technicalities required to develop things this way.
My other idea is to go simple by removing the need for a database by abstracting authoring into a simple files & folders structure, and then focussing on developing a “generator” to the publishing. So rather than create a contained system we could build something that can be plugged into a file system and live separately locally or online. This idea builds on those already in use in a range of static site generators that leverage markdown, scripting and something like GIT to manage the whole workflow.
By simplifying the system down to the bare minimum the potential is to make content more “forkable”. You reduce the need for specific software in the authoring but also open the process to powerful versioning and management technology. In this way remixing is encouraged but with the ability to merge back the potential is a truly inspiring. This would ensure that the remix doesn’t become another standalone piece of content, but a connected component that might be co-opted back into the main branch. It enables localisation, translation and adaption to specific contexts not just to be made, but tracked, traced and attributed.
The other attraction to this more simplified model is that it also reduces the technical overheads required. It could be run locally or over a simple network. It could run offline and allows for asynchronous editing and collaborative authoring in a manageable format. I’m not sure if this will provide the simplicity or granularity of that the federated wiki has, but it’s definitely a step in the right direction.
This flat file model also means that content can be openly hosted using repository sites like GitHub but also almost any online space, and for educational and research publishing this could be a huge boon. Being openly hosted means that access is greatly improved. The ways that Mike describes data models being accessed and modified could be achieved this way.
The final plus is that switching to a flat file generator model means that there is less reliance on single technology or system . While GitHub, WordPress and certain programming language are the choice today they are also dependancies in the long term. Not relying or depending on certain technologies means that we’re creating more sustainable content that is open to change and evolution as technology and trends change.
Publishing in the digital age needs to embrace the concept of remix as it’s the most significant affordance of being digital. I’m in a state now where I can see that the technology required is getting closer to realising that idea. Once it does we’re going to be in for a ride.