Atomising the news
Recently we’ve been collaborating with Explaain, a new platform for interactive news that displays stories in easily digestible chunks.
Interconnected cards invite readers to explore a story in a much detail as they want, or to skip over reading about elements they are already familiar with, a format which works particularly well on mobile.
Explaain’s singular focus on telling the news entirely as a series of connected cards is unique, and we’ve worked together to come up with a bespoke interface to suit a workflow based around the creation of atomised, re-useable content.
Why create another editing interface?
We felt the challenges were unique and that there value in being able to quickly create and update content rapidly with a UI designed specifically for the task at hand — rather than trying to make do with an existing system designed for a very different publishing model.
We also wanted the content creation interface to resemble the way readers interact with cards so that it’s easier for journalists and editors to create interactive content that flows naturally, so cards are easy to navigate between.
What we did and how we did it
In a period of an afternoon we built our own “CMS for cards” using Bootstrap + jQuery and our open source Structured Data API platform.
There is no server side code required for the editor (although we do use a simple Node.js sever to make it easier to deploy); it’s a single page web app which talks to the same API used by the front end.
The Structured Data API gives us a REST API for creating, updating, deleting and searching and allowed us to define our data structures as easy-to-edit JSON-schema files. It also has a click-to-deploy-to-Heroku button so we were able to get started using it right away without lots of setup or configuration.
We have semantic entities that allow us to create cards for People, Places, Organisations, Events, Quotes and News Articles. Each card can be fetched as both a simple JSON object and as a JSON-LD object.
Having decided on what sort of objects we wanted to store in our database, the API platform took care fetching from and saving to the datastore as well as searching, validation and error handling so we don’t need to spend time time on any of that.
Since the initial afternoon we’ve spent about a week (over the course of a month or two) improving the UI; customising the editing experience, introducing rich text editor, improve the system so it stores text as Markdown on the backend and adding context-sensitive right-click menus so it’s easier to create and edit links between cards.
How it works
Because it’s web based and cloud based, journalists can access it from anywhere and we don’t really have to worry much about about servers or scaling.
As it’s all based on open source software we don’t have to worry about software licensing costs either.
Journalists are able to search for cards by name and description and can have as many cards open at once as they like so they view links in context.
Clicking on a link in the editor navigates to a new card (just like in the app), while right-clicking text in a card brings up a context-sensitive menu that lets curators link to an existing card or instantly create a new card from the selected text.
When a card is saved, in addition to the name and description and optional image being saved, we store an array containing the IDs of every card a card links to.
The ID for a card is a full URL, which contains a Globally Unique Identifer in it. If we want to fetch a card, all we need to know is its ID . If we have an valid API key we can also use the same URL to update or delete that card.
Storing the ID’s of cards we have linked to along with each card allows us to easily pre-fetch all cards that are linked to from a card in the app.
It also allows us to easily extract all the other cards that link back to a card, so we see all the different ways readers might get to a card.
Mobile App Live Preview
The editor also features a preview of the Explaain mobile app embedded on the right of the main window.
Journalists can click an “edit” icon inside the preview window to pop open that card in the editor. Saving changes to a card in the editor instantly updates the preview so they can see their changes take effect immediately.
What we’ve learned
While there’s lots more we want to do to make it easier to visualise relationships between cards and to add new sorts of media to them, an afternoon of prototyping and a weeks worth of iteration has gotten us a working, useable system in a really short space of time (albeit one that’s missing a few things you’d normally see in a production CMS).
Creating custom editing interfaces for content creation and curation isn’t always necessary or desirable, but neither is forcing content creators to use a tool designed for one format to create content designed for another format.
With new forms of content in particular, a small amount of development effort that leverages existing software to create something purpose built has the potential to have a significant impact on journalists in newsrooms — and ultimately on the experience for readers.
Taking an API first approach, leveraging managed hosting and being comfortable with only building infrastructure as it’s needed makes it quicker and easier to iterate, avoids pain points and discussions you don’t need to have just to test out an idea (especially tech led discussions like “how do we deploy this”, “how do we scale it” and “what frameworks should we use”).
How we built it
Over a few days since the first prototype we’ve iterated through a few different libraries and swapped out things that haven’t worked so well.
- Font Awesome
- jQuery UI for draggable cards
- Marked to render Markdown into HTML
- to-markdown to convert HTML to Markdown
- jquery.toTextArea.js a plugin to give us an easy to work with rich editor
- ally.js for accessibility polyfills (like knowing which card has focus)
- toastr for notifications (save/error messages)
- Structured Data API a JSON REST based API for Structured Data
jQuery is an excellent multipurpose tool which makes it really well suited to prototyping and rapid application development.
If the system grows more complicated it might be worth considering a framework like AngularJS, which can increase the the amount of complexity in the codebase but can also make it easier to manage in the long run.
The interface only needs to be used by journalists working for Explaain so we didn’t have to worry about legacy browser support, or even creating an editor that works on mobile, which helped with the quick prototyping.
Using API platform designed specifically for Structured Data has helped promote interpretability with other Structured Data sources and as it’s an open source platform we can run it anywhere (on the Google Cloud Platform, AWS, Heroku, Digital Ocean, etc).
We could equally have used an existing API (if we had one with our own data in it already) or used another open source self-hosted API platform like Parse Server or even a fully managed service like Google’s Firebase or an Amazon Web Service.
We hope you’ve found this interesting and happy to answer questions here on on Twitter at @glitchdigital if you’d like to know more.
glitch.digital specialise in tools for journalists, newsrooms and the media industry. If you have any questions, would like to know more or are interested in working with us, get touch via email@example.com.
If you’d like to checkout Explaain you can sign up for access to the beta over at http://explaain.com.