Athena: Revisiting a possible digital publishing flow
From a technical stand point. Web Components and the Polymer Project in particular provide a way to compose larger applications from base components and to provide flexible and powerful APIs to make our applications look great and feel powerful.
What attracted me to Polymer when I first started working with the technology in 2013 was that it’s flexible but still enforces discipline and pushes good coding conventions into your project. It also hides details and complexity of doing things correctly
I’ve written before about what an online reading experience may look like in Books as web apps and about Athena in particular in Athena: What an ofline web reading experience may look like
Jeff Posnick’s offline ereader was an early influence on the ideas and concepts for Athena.
Craig Mod’s work on digital reading and subcompact publishing have informed a lot of my thinking and the ideas behind Athena.
Specs and Standards
The technologies that make web components and their corresponding specifications are:
- HTML Templates in the HTML Living Standard
- HTML Imports Editor’s Draft
- Shadow DOM Editor’s Draft
- Custom Elements Editor’s Draft
These custom elements can be used in multiple works and by multiple authors. Once we create our master elements we can import them and reuse them anywhere we need/want to.
Using web components force us to be strict in the content of our elements and to be clear in the structure of our reading aplications since we have to specifiy the child elements and the structure from the first component we choose to create.
Web components are not an all-or-nothing proposition. You can extend existing tags and use them alongside your regulat content Github does this with their relative time tags. Rather than use a JS library like moment the extended the time element to acomplish the same task. If you look at any
time tags on Github you will see this attribute:
is="time-ago", a type extension custom element. If the browser support custom elements then the browser displays relative time (3 months ago) and if it doesn’t then the browser displays the full date… and the user does not even note the difference.
We also need to look at ServiceWorkers and associated specifications to better understand the capabilities they bring to the table.
- Service Workers Working Draft
- Push API Working Draft
- Web Background Synchronization Unofficial Proposal
One thing that may catch developers by surprise is that some aspects of this project, primarily the Service Worker and related technologies, will only work with secure connections.
Browser vendors are pushing for SSL and understandably so. ServiceWorkers, and other new web features, are very powerful but are easy to abuse and allow malicious users to create man in the middle attacks.
Most browser vendors will flag regular HTTP as insecure in the not too distant future
Working with third party content/code/material
In the case of
marked-element there are two elements in the repository:
The only content of the
marked-import element is a script tag to import the marked library:
Because of this the only thing we need to do in
marked-element is to use an HTML Import to pull
marked-import into our current element:
<link rel="import" href="marked-import.html"/>
This takes care of including the marked.js library and save us from having to remember to add the library in every page that we want to use
Fonts work the same way. The wrapper around the Roboto font simply links to the fonts in the Google font library, like so:
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:400,300,300italic,400italic,500,500italic,700,700italic"/> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto+Mono:400,700"/>q
Once this is done we can import
font-roboto into any component we want to use the font in.
There is another component (font-roboto-local) that does a local
@font-face import for all possible weights and styles of the font. We can use that repository as a model for using our own fonts in web components.
These are the three main uses cases I see for Athena publications. The first two are based on short publication looks. The third use case is based on what media and resources will serve the story best. Enhancing existing content lets us choose which part of the Athena toolkit we’ll use with the content we’re working on… at the very least convert the project into an offline capable application.
Long Form Content
As initally conceived Athena was a long-form content creation tool and that’s where I see its strength. Adding app-like functionality only enhances the reading experience, doesn’t replace it.
Some types of long form content I envision are:
The Early Access Publications idea is based in existing programs like Manning’s MEAP and O’Reilly’s Early Release programs where the book content is published as soon as it’s ready (and sometimes as soon as the author is done writing it.)
The advantage of this kind of publication is that it tightens the feedback loop between readers, reviewers, editors and authors. It also allows for collaborative editing: whoever has access to the git repository can make changes and accept changes coming from the community (whether this repository is public or private.)
Using Service Workers we can update the content seamlessly and use push notifications to alert users of new content without having to worry about last access times.
SERIAL PUBLICATIONS (MAGAZINES AND THE LIKE)
Serials are periodical publications. Magazines are the ones that come to mind fitst but they are not the only ones. Shorter content like Atavist books and stories or the longer content available from O’Reilly Atlas with the added advantage of offline access.
This way a book is never really done. We can continue to work on stories and tell new stories as long as we want to and the stories can get that continual polish that makes for a good reading experience. If we need/want to, we can also provide CSS Paged Media Stylesheets that will allow to create a PDF version of the text/images we make available.
Now the almost impossible is merely difficult. The technologies in those books is available as open web APIs at different levels of standardization and you can create equivalent experiences from the Applications that you run in your mobile devices.
The idea behind the
athena-components repository is to create a set of components to use when creating articles like Snowfall or Climbing Everest. When thre repository is finished we can hand code our content. In a future iteration I hope to use the Polymer Designer as a visual editor for the components we choose to make available.
Although it’s possible to build documetns with the components manually that’s far from an ideal situation. The Polymer Project create Polymer Designer as a demonstration of how to visually compose and create Polymer applications.
With the upgrade to Polymer 1.0 the designer app has lost some elements and gained some elements . It can now be built as either a web-based or a desktop application using Github’s Electron (formerly known as Atom Shell.) that runs on OS X, Linux and Windows machines.
Out of the box the toolset will contain the following components and functionality.
- Master Layout have the basics of the document
- Layout Components
- athena-layout-standard (centered, 1 column)
- athena-layout-multicol (multicolumn, using CSS where supported)
- athena-document (Markdown)
- Data Visualization
- Service Workers and Associated Technologies from Polymer
It is important to realize that these are the default components and can be easily expanded to suit your needs. The component repository can also be the starting point of a community of developers, both as a curated collection of publishing-related components and as a learning experience for all developers involved.