This is my first post in an attempt to “work out loud” i.e. to be more open in my practice rather than just my output. It’s an attempt to log my current ideas and concepts around a topic to frame it, share it and reflect back at a later date.
One of the things I’ve been interested in over the last decade is the convergence of digital tools with traditional analogue publishing processes. Working in the design field I’ve been at that coalface and published my own fair share of both digital and analogue artefacts.
The last 5 years have seen a massive shift and a chance for digital to move into the analogue print space with viable and attractive alternatives. Smartphones and tablets (and everything in between) offer new opportunities and potential to fundamentally change publishing – how we see it and how we do it.
What’s become abundantly clear though is the lack of tools that can take it to the next level. Most of the popular tools have been co-opted from print and bring with them legacy concepts and constraints. While they may seem adequate they tend to lack the ability to realise the potential of a true digital publishing model.
As part of the mLearn project I’ve been heading up, we investigated what options we have as a university to transition our content to a mobile platform. The results weren’t pretty. Nothing was easy. Conversion was never precise and required manual manipulation to massage it into something viable. This is fine in individual cases but not for the scale we require at Charles Sturt University. What we want as an institution is a way to author once and publish out to many channels, so that our students get to choose how and on what platform they can consume our content. It’s a realisation that our students are diverse, with diverse needs and desires and a one-size-fits-all solution never really fits anyone.
So I’ve been thinking.
The first big idea was the need to start thinking beyond text. Technically text is easy – if you get a properly marked up document you’re fine. Perhaps that ‘if’ is harder to come by in some cases, but what I’m trying to say is that text is not the problem. No, the sticking point is media. Media is all the other ‘stuff’ that’s possible to place in and around the text. The data tables, diagrams, images, video, audio, activities, quizzes – it’s everything else that’s possible with a digital medium. These are where the problems lie, the challenges and the break points. Media brings to the fore the inherent differentiation between print and digital and in many cases defines them as unique and different. However the goal is not to wipe out print and replace everything with digital. I’d rather see but cohabitation – working and publishing to both, to all forms, platforms and spaces – not adversarial but complementary and certainly not the death of analogue.
My skill set and knowledge is something I consider quite unique. I straddle the multiverse, working on the fringes of many realities – analogue & digital, offline & online, web & print, commercial & public. So it’s within this divergent conversation I have been able to pick up on common strands. Twitter has been immeasurably important in this process – allowing me to tap into many new fountains of knowledge and expose my brain to new ideas.
I pick up on the content strategy discussions, with particular resonance are those from Karen McGrane. The thinking around responsive design from Ethan Marcotte. The emergence of new ideas from Brad Frost. The process of Mobile First from Luke Wroblewski. The backend work by guys like Dave Olsen on creating better tools for adaption. The discussions around the Content Management Systems – their pros and cons and place in the new age. Ideas from Jason Grigsby struggling with responsive images that cope with retina and standard displays. The dynamic and active content concepts from Brett Victor.
What I’ve been working through is aligning those ideas. Cherry picking concepts that resonate with my work and trying to formulate those into something we can work on in the project, and I think I’ve got there.
Adaption Through Specialisation
A few weeks ago I had a light bulb moment. I was watching a documentary on metamorphosis and as the narrator described the process and it’s genesis it sparked a Eureka moment! I got pen and paper and started scrawling notes:
Metamorphosis means to change form. It’s an evolutionary model whereby there is conspicuous and abrupt transformation accompanied by changes in habitat or behaviour.
That concept, that idea, that process – I could see vividly how that related to what we want our publishing systems to do. Not just simply respond, but adapt to a specialised form uniquely suited the mode of delivery.
The next big question was how.
The Birth of the Adaptive Media Element
I struggled with this for some time, but the work done by those in the web field, particularly around images was extraordinarily helpful. This is what I came up with:
An Adaptive Media Element (AME) is in essence a meta-object, which contains self-referential information. It is not a single file per se but instead contains more detailed and expressive information that allows logic to be applied. For example an AME might contain a file type reference, the file itself, a weblink to an external source or library, source information of where it came from, reference information, alternative files or metadata, a title, a caption and a description. In the diagram below is an example of what a Video AME could look like – a single element in the authoring environment that links to a library of connected files and information:
This diagram shows how a single AME appears in the editor as well as all the individual components that could make up an AME.
This extra rich information allows logic to be applied and through a predefined profile, pull in and display only the relevant information into the final markup. In the case below I’ve used some the HTML to define the kind of markup that would be created. In this case the DIV would act as a container for the elements inside being written from the library:
The AME is replaced by the individual components relevant to the publishing output. In this example a video AME is converted into a DIV with the associated elements and attributes coming from the library.
To some extent this is possible through customised web solutions, but not to the mainstream, not directly linked to an authoring system and not across many channels and platforms outside the web environment.
… So back to some more thinking. How would this all work, how would it function, what would it look like? At the same time, as anyone who works in a large institution or on the web would know, you need a great acronym to get any traction. So in looking for one I looked up words containing A, D and P (adaptive digital publishing). Not many words but one stood out…
TADPOLE – The Adaptive Digital Publishing Engine
Developing a process based on metamorphosis and that’s a suggested word? C’mon that’s fate, amirite!
So TADPOLE is an attempt to envision a system that would allow you to author and publishing content out to many formats using Adaptive Media Elements. It consists of three elements:
- The Authoring Environment
- The Adaptive Media Elements Library
- The Transformation/Compiler Engine
Describes the three main theoretical components of the system.
While I had this initial model I needed some other voices and opinions and was able to bring in the team. Rob and Rod bought some structure and order to my very sketchy ideas. From there we were able to start to define the functionality of each component.
The authoring environment can look and function however one may see fit – but what it essentially creates is structured content. Text creates the narrative structure required for publishing. The AME Library operates as a database of all the individual components required for each element. Many different types of AMEs can be defined and each would have their own separate components listed. Adding content to the library would be similar to a form with predefined fields. The authoring environment would contain a tool to insert an AME into the narrative so that all elements were contextualised and embedded, rather than hanging off the side. The transformation engine is when the logic is applied (defined as “PHP magic” in our early discussions). It would scan through the document and find each of the AMEs and using a predefined profile insert the relevant components from the library into the markup. Profiles would be defined for each output required, so many could be developed and applied to one source to ensure specialised output. Our initial focus was on three – for print, eBook and Web – but these profiles could be customised and sub divided down much further. Profiles could be developed for specific media, platforms or content restrictions e.g. at CSU we have to deal with separate copyright restrictions depending on delivery via print or online. The compiler would then do the final render out and attach the presentation layer dumping out the finished files and folders.
Illustrates how the profiled markup then goes through the transformation and compiling process to output the finished files.
So Why Do This?
What we tend to do at the moment is simply transcribe content from one format or file type to another. This is incredibly time-consuming and inefficient, and tends to focus resources on manual transcription of content rather than capitalise on the logic inherent in the machine. At the same time there is a drive to provide greater diversity in publishing options. We find ourselves in a quite untenable situation In quite broad terms the world has changed but the tools haven’t kept place. We need better tools and better processes.
Everything outlined above is possible today, but what is available form vendors seems to be either an overly simple authoring tool that lacks the depth required for publishing, or an overly complex authoring tool that alienates everyday users to gain powerful publishing functions. What we are proposing is something that doesn’t need to compromise for two reasons:
- Content is separate from presentation &
- Authoring is separate from publishing.
They co-exist within the same system but there is clear delineation to address quite different requirements. Content should be seen as liquid, but presentation is many faceted and required to conform to certain constraints. In much the same way authoring should be simple and intuitive but publishing needs to be complex and extensible. Through separation of form and function we can achieve a much smarter tool that capitalises on the inherent abilities of machine and human, rather than forcing one to compromise for the other.
What my team and I have tried to envision is an extremely adaptable system. One where:
- content is developed neutral to the delivery method
- shape and form comes from the narrative
- is simple and intuitive for the author to use
- provides complex output options
- automation and logic do the heavy lifting, and
- consolidate disparate production processes
This creates a future friendly system for publishing that will remain adaptable into the future. New components and AMEs can be added as needed and new profiles developed as new standards, formats and platforms are released. Instead of re-encoding, re-creating and translating content into each new format as they arise, the process can be automated and structured based on logic that can automatically be applied to all content. Authors can look after the creation and developers can look after the backend.
At the moment we are only looking at developing a proof of concept, so at this stage we would adopt a static publishing model – so you would need to initiate the process rather than it being dynamic. This is to impose the rigor of form, and using the act of publishing to provides the temporal constraint of a beginning & an end. This minimises the complexity of the system as we won’t be required to maintain versions or host live content. Instead we will leverage our existing systems – a digital repository and LMS – which are far more capable in these areas. Our needs within the university are also centred around the temporal constraints of sessions and semesters, so we want something to remain static for their duration. That said we can envision that the model could be adapted further for use in a dynamic system.
So that’s where we are at the moment. I’ve started to sketch out some of the required AMEs that we need as well as looking at and scoping products are out there that can do what we are proposing. My feeling is that customising an existing CMS might be the way to go, but I am open to ideas.
If you would be interested in collaboration or finding out more please feel free to contact me.