Last month we released a brand-new online journal: Maja, “Magazine van de Jonge Academie”.1 Maja’s first issue appeared last year as a print-only publication. As of issue #2, Maja now is available both in print, and as a digital publication on the Web, with a responsive design fit for all (modern) devices and browsers.
Maja’s digital edition still is an experiment, but one which proves that print and online may fraternally co-exist, cater to different audiences and/or several usage scenario’s, and can both offer complementary features. Publishers know that today’s readers increasingly consume written content on their smartphones (during commute, for example), while mostly still preferring to read on paper (back at home, relaxing on the couch). In this article we discuss the advantages of a shared production workflow for both print and online editions, by example of Maja’s case. Both editions were semi-automatically generated from the same source of input documents, with software we are developing in-house.
Building an app for easy cross‑media publishing
In August, we started work on a side-project which, by now, has grown into an almost full-time enterprise. We’re actively developing an application which tightly integrates2 our typesetting and book crafting expertise, our print production and web development know-how, into a modular tool suite for publishers, editors and authors (both the professional writer and the occasional blogger). One and another must culminate into a forward thinking cross-media publishing web service. The ultimate goal of our value proposition is quite straightforward:
- Dump some Word files in your Dropbox.34
- Click “Publish”.
- Have your publication automatically built and instantly deployed online, looking great on all media and devices, sharable, searchable, backward-compatible and future-ready.
We want to make it easy for anyone to publish to the Web, without people needing to go through the baffling and sore procedures of server setup and database configuration, security and load balancing sysadmin, file conversion, metadata extraction, templating and styling, performance optimization, search engine hacking, and so one. We believe writers and publishers should be able to focus on content and reaching readers, and not on the technicalities of delivery. Writing and uploading artwork, should suffice to create a beautiful, modern, professional, multi-media publication, out-of-the-box — with a single click indeed.
Our integrated production workflow enables simultaneous formatting, styling, and typesetting, of both paper and web editions. Development of our platform5 for easy, automated, cross-media publishing is steadily going forward, and we will soon be releasing the functionality of our software as a public web service. Maja is its first application and as a prototype proof-of-concept, it’s a success already, offering a preview on some of the core features of our upcoming service.
From Word over Markdown to InDesign
When last year we designed the grids, styles and templates for Maja, the publisher had in mind a print edition only. During production, our workflow would not be any different from what we mastered from our long time experience with print design best practices. Yet, as we gradually shift from print to digital design, we find ourselves introducing web development tools and best practices into the print production workflow all the more often. As the production flows for both output media, screen and paper, coincide and increasingly share a common source base, automated cross-media publishing starts to become both a reality and a swift experience, with very little extra overhead. Simultaneously going online as the printed issues roll off the presses, is a business opportunity we now can happily offer to all our print clients.
In a previous article I discussed at length how we set up a print production workflow based on the automated conversion of MS Word documents supplied by the client, to linked InDesign templates, using the Markdown format as an intermediary “master” copy of the client’s content. In this article, we go more into the workflow for producing the online edition. However, as mentioned already, both editions are generated from the same single repository of Markdown source files.
Markdown is a relatively new document format, a lightweight markup language with an easy to learn syntax (compared to for example html or xml). If you’re not familiar with Markdown already, then I definitely recommend reading our previous article and have a look at the tutorials we there refer to.
Yet another benefit of using the Markdown document format for the source content, is that Markdown is a robust and widely supported new Web standard, so that going from print to a companion online edition, has become a relatively small extra step to take.
From print to the Web
Sooner or later, I reckoned, Maja’s publisher would indeed want to have the magazine’s content available to online readers too, in an appropriate electronic format.
At their request, last time the printer’s prepress department wrapped our weighty 155 MB, print-optimized, ready-for-press Uncoated FOGRA29 (ISO 12647-2:2004) PDF in some Flash-based website widget.6 Obviously, it’s not been the flawless experience they hoped for: an obsolete technology which renders it all useless on mobile devices and sluggish everywhere else, a cluttered user interface with an irrelevant propensity for skeuomorphic kitsch, like simulacra of flipping pages, drop shadows and fake gloss — nota bene for an edition on uncoated paper! — complete with a toe-curling sythesized audio sample of paper being shredded, rather than the gentle sound of leaves reversed.
In short: wrapping a pdf optimized for print into some gimmicky plugin, naturally yields an unresponsive and everything but pleasant user experience on the Web.7
So, this time around the publisher asked whether we had no better solution, and if, for example, we could deliver the print layouts along with the formatted articles “in php format”, so that they might “import” them into their existing WordPress site… Try to explain that php is a server scripting language, not a document format, let alone a design standard. And then attempt to explain all those many other difficult issues that come with making user-friendly webpages. Well, never mind— But we did have a solution, and one which would perfectly fit their needs at that.
Indeed, the automated publishing software we had been building in-house, matured enough already to give it a try. Thus, when Maja’s publisher asked about getting “php versions”, I felt confident enough to put our prototype-in-progress to the test, and use it in production. For their use case, quite some interventions were needed still: for assisting the automated document and file conversions, for creating custom templates and styles, for the branded deployment on the server using the client’s domain. Step by step, however, we’re scaling these still manual tweaks into a fully automated build process, too. Much of what we’re describing in this article already is available as standard features.
If you’re in the print design business, you will surely appreciate the great extent of control you have over the visual end result. A printed page (or spread) on paper is a finite and static canvas on which art work, images and text frames can be freely drawn and positioned into a handsome layout, exactly as the reader will see it. But the detailed perfection you can achieve while layouting a print publication, requires lots of handy work.
Designing web pages is a whole different matter. Nearly all of the design must be programmed into flexible stylesheets, which do not (generally) offer precise control over the exact looks and positioning of individual elements in the final visual document. Instead, the designer defines style rules for generic element classes, very much like you would create character and paragraph styles in traditional page layout applications like InDesign. But in addition to the looks of individual elements, web designers must also define rules for positioning and sizing. Instead of doing the layout by hand, it is the rendering engine of the user’s web browser, which will eventually do the layouting, conforming to the rules it is given.
Responsive web design (RWD) is the new standard for crafting modern websites to provide for an optimal viewing experience, enhanced usability and standards approach towards accessibility, on all devices (from the traditional desktop PC with a mouse and a physical keyboard, to tablets and smartphones with touch screens), on all platforms (Windows, Mac, Linux, Android, iOS, Windows Phone), and in all browsers (Chrome, Safari, Firefox, Internet Explorer). Many modern-day websites are being made already responsive, but unfortunately, they remain the exception still — something you surely will have noticed while browsing the Web on a smartphone: on many sites, the type size is just too small, lines are too long, you can’t easily click (or tap) on links and buttons, and so on.
Creating responsive websites requires lots of skill and expertise, because the designer must accommodate for all the many possible display ratios of each and every device. Unlike designing editions on printed paper, in web design you simply cannot predict beforehand how the reader will be looking at the webpage, using which device. Still that page must in any case look beautiful and be pleasant to read on each and every screen. While it takes a lot of work to program fully responsive stylesheets, a great benefit, on the other hand, is that as soon as they have been fine-tuned to perfection, typesetting a document can be done fully automated, with no manual intervention needed any longer.
At Rhythmus, we take pride in always developing our websites responsively, and delivering cross-device, cross-platform, cross-browser, progressively enhancing, gracefully degrading reading experiences, not as an optional extra, but by default. That’s quite a lot of technical jargon and marketing buzz-words… The key take-away, however, is that we are building our state-of-the-art responsive layouts right into our publishing software, so that visual perfection and top-notch usability come right off the shelves, without publishers and authors needing to worry about the programming details. Each edition of a publication will always look beautiful, regardless the output medium, be that a mobile touch device, a phone, a tablet, a desktop PC with a huge 5K display, or “just” plain old paper.
Styling the elements on a page — both printed and on the Web — requires those elements to be tagged as being of a particular kind: this is a heading, that is a quote, this phrase of text gets emphasis, another references a link or a note, and so on. Tagging bits of text with the proper content element classes, and placing figures, images, or tables, is the responsibility of the author and her editor. In fact, that’s exactly what you are doing when applying styles in Word. In a previous article we discussed how the correct use of semantic styles (as opposed to inline styling) is crucially important for document portability.
Our software is capable enough to preserve the styles and styling found in the Word documents it is fed, and convert them into proper markup, fit for responsive display on the Web. However, MS Word does not offer lots of built-in styles or content types, while a properly edited and professionally designed publication needs many dozens of them. Large publishing outlets can rely on bloated content management systems (CMSes) and custom rich text editors. Smaller publishers, however, must necessarily outsource editorial tagging to the designer or pre-press department — an unfortunate situation, because it requires a lot of (expensive!) back-and-forth during production.
Since we make use of the Markdown document format, with our publishing system, an enormous range of semantic variety is made immediately accessible to authors, editors and publishers. If you need more control over the final layout and assign other content types than those which Word and other word processors have on offer, then editing directly in Markdown markup is all you need to do.
Editing in Markdown is as easy as adding a few symbols to your text: wrap some text between (single) underscores to
_ (for emphasis), between (double) asterisks to get
** (for strong emphasis). Prepending a paragraph with a hash (
#), turns it into a title; two hashes will nest the heading one level deeper,
### three levels, and so on. Adding a hyperlink is as easy as wrapping text between square brackets (
) and providing the URL between parentheses (
The set of available content types in standard Markdown is limited to about the most commonly used tags in HTML (headings, lists, blockquotes, paragraph breaks, emphasis, links, images, code). There are however extensions and Markdown dialects8 which offer additional support for things like footnotes and tables. But even the most burly implementations do not provide all the many necessary content types which are commonly used in professional publications and which we thus wanted to support in our publishing system.
We went already to great lengths extending the Markdown feature set. Maja, for example, has quite a few content elements and corresponding styles which are very common in magazines and similar publications. With our Markdown extensions, adding a subtitle is as easy as adding a line starting with a colon (
:). The pen symbol (
✒) indicates that the line contains the article’s author(s), optionally followed by their
@username, from which a clickable link will be created automatically. When the article needs an intro text, the first paragraph gets a summary symbol (
∑), while prepending a paragraph with a bold quote mark (
❝), will turn it into a a pull-quote.
We are still adding many more element classes, like mathematical equations, image galleries, slide-shows and interactive graphics. Proper, responsive styles are of course provided, plus all of the necessary program code to create rich interactive experiences.
Including images into a Markdown document is very similar as adding links to text: the URL you put in-between parentheses (
()) is the path to the image file, and the text in-between square brackets (
) will be used to create a caption. Then you tell the program to include the image (instead of just linking to it) by putting an exclamation mark (
!) before the string. Optionally, you may add text between a pair of straight quote marks (
"), from which a tooltip will be generated.
![Figure caption.](url/to/image.png#x50y50r20 "Tooltip text. (c) Image credit.")
While standard Markdown makes inserting images into an ordinary web page easy, for a professional publication it is insufficient. In Maja, for example, images always have an image credit (an attribution to the photographer or copyright holder), which is different from the caption text. More important even, we need several different classes of figures: some images will be used as regular-sized figures in the text, while others need to be rendered full-size, outside of the body text (“bleed” images in the paper edition will translate to screen-filling images in the online edition), yet others will be used as a background for poster-sized pull-quotes. And since we want those figures to look good on all media and devices, regardless the display size, we also need a way to instruct the layout engine on how it needs to fit, crop and position such full-size images, so that they fill the available space, without accidentally chopping off the important parts in the image. We implemented this kind of fine-grained art direction and many other features right into our Markdown extension.
Responsive images not only need art direction, they should also be displayed at the highest possible quality, but without compromising on performance. Most Markdown processors will return a page of html with the images untouched. But that’s not good enough of a solution, because it does not account for the wide variety in downloading speeds. Then you are forced to either provide the original high resolution images, or to scale them down to a more Web-friendly format, with a less heavy downloading footprint. In the first case, readers on mobile connections will experience a very … slowly loading web page. In the latter case, the down-sized images will look (to say the least) on high-resolution “retina” devices and 4K or 5K monitors, which are very likely on a high-speed broadband connection anyway.
Techniques for adaptive, responsively loading images are still young on today’s Web, but websites that have them enabled, will smartly serve both small-size and high-res versions from a single input image file, depending on the end user’s device and connection speed. We started implementing responsive images into our publishing application, so that the technicalities of performant delivery are taken care of, without the author needing to worry. You simply provide the original high-res image file and then our software does any necessary conversion and serves-up the size that perfectly fits the end-user’s device, bandwidth and connection speed.
Building the publication
Like any other magazine, Maja consists of a collection of documents (articles). Unlike the posts of a blog, or the “pages” of most websites, the articles (or chapters) in publications like a book or a magazine do not have a random order. Instead, the publisher (the editor or the author) deliberately arranges them in the order she believes they should be read best, one after the other. (With magazines, readers do not always need to strictly follow the sequence suggested by the editor, but in books, the reading order is especially important.)
We will build the publication from separate files (documents), which contain the article texts. Instead of doing this by hand and achieving the order of appearance wherein the articles and sections should be bundled in the publication manually (arranging pages in a layouting application like InDesign, or coding up a template, as with traditional CMSes like Drupal or WordPress), we want the document assembly to be done automatically. Organizing the article files by putting them in separate folders and subfolders is anyhow a practical way for grouping content into sections, but not so much for arranging them: most computer file systems do not provide the means to arrange a sequence. We therefore created a simple, yet powerful feature, which allows you to both group and order the files (articles, chapters, documents) that will make up the publication.
From the folder tree, we create a provisory hierarchical structure for the publication, which can then be further edited in an
index file, which allows the editor to exclude, hide and re-arrange the articles and sections (nodes on the tree) in any desired order. The resulting outline reflects how the editor believes the contents of the publication will be presented best to the readers, as a both thematically organized and sequentially ordered whole. In fact, this editorial model also functions as a “configuration file”, from which the entire publication will be built and from which both the visible table-of-contents and interactive, navigational menus are generated, fully automatically.
Versioning and continuous delivery
As mentioned before, all source files for Maja were converted from MS Word documents to Markdown files. An immense added benefit of using Markdown as the preferred document format for the master files, is the fact that it is just plain text, which makes it perfectly suitable for automated version control. (Read our previous article to learn more on versioning projects with Git.)
Using Git, we easily added the publication’s entire source into a versioned document repository, which keeps track of all changes made to the files, and provides us with a detailed editing history. This is of course of great convenience during the editorial process, not only because all collaborators involved in the project have at all times the most recent versions at their disposal, but they can also simultaneously work together on the same files, without accidentally overwriting each other’s edits. Moreover, in the rare event mistakes are made nevertheless, rolling back to an earlier version is trivial.
Better still, even after publication the source files may continue to be further edited. In software development, the unceasing improvement and refinement of the live product is known as continuous integration. Once committed to paper, a publication’s print edition is of course immutable. The online edition instead, may be improved and updated indefinitely, just like a web application.
The file repository for Maja’s source contents is publicly available on Github (a Git hosting service), so that the publisher can easily fix such slight errors in the text, without having to call in for our help.
Analytics, SEO and social sharing
Getting content on air is one thing. As a reader, having the ability to pull your phone, connect to a wireless network, and read online during commute, while in the evening, on the couch, you can continue reading in the paper edition — it surely is convenient. Publishers know that wide availability of their content, catering to all sorts of readers and usage scenario’s, undoubtedly improves their reach, and thus, customer relationship, brand awareness and turn-over. But the true added value of going digital, are of course those things you can’t have with paper: user interaction and real-time usage metrics.
Both users and content publishers take the features of the modern Web and similar digital content consumption experiences, for granted. We expect uncluttered, literally touchable menu’s and navigational interfaces, smoothly performing transitions, scrollable image galleries, article-level share links and buttons, for Facebook, Twitter, and what have you. Publishers, on the other hand, expect detailed insights in number of clicks, page views, shares, and overall usage statistics: Which subject matter is read most? Which articles are shared and discussed on social media? What kind of content should we further explore in future editions? Publishers now these sorts of metrics can be available with digital publications, and they expect such features to be available by default. And we all expect it all “just works”, right off the shelves.
Maja’s publisher, too, expected such features as being self-evident. Luckily, our application is equipped to accommodate these needs.
Maja’s online edition has been a successful experiment, showing off only a fraction of what our app is capable of already.
The magazine template is just one of several publication types which we will be supporting. There are templates for books (novels, monographs, syllabi, technical manuals), portfolio sites, and stand-alone documents (like a one-off blog post, a short story, a scholarly paper, or a one-pager website). There are dozens of themes (stylesheets) to choose from, all meticulously crafted to cater for multiple devices and screen sizes. On top of standard Markdown features, many more content types are supported, like footnotes, image galleries, tables, and mathematical notation (equations), to name but a few. Other features are in the pipeline and the list with bug fixes is worked off, day by day. In short: our platform is prepping for prime-time…
If you have a bunch of Word files lingering on your hard disk which just yearn to be published on the Web as a state-of-the-art responsive publication, most likely our app will fit your needs exactly.
As a publisher you don’t need to worry about any of the many technical magic that is going on under the hood: our app does the heavy lifting of fetching and inferring metadata, building pages both client-side and with server-side rendering, scaling and serving visual assets, and so on, and on. Just dump the Word files, click “publish”, and your cutting-edge, cross-device, responsive online publication is built on the fly, right out of the box!
If you’re the publisher of a magazine which exists in print only and don’t know where to start in getting your content online, you should definitely get in touch.
In any case, you should follow me on Twitter @rhythmvs.
The “Jonge Academie” (Young Academia) is the “junior” division of the Royal Flemish Academy of Belgium for Science and the Arts, which commissioned us, here at Rhythmus.be, with the design, typesetting, prepress and the web development of both the paper and online editions of Maja magazine. Maja #1 appeared March 2014; Maja #2 was released in stealth mode, March 2015.↩
Obviously we’re not starting from scratch: over the years we built quite a bunch of frameworks, libraries, modules and packages, which, assembled together, finally start to form a magical organism.↩
Actually, Markdown is preferred over anything else, but our platform happily accepts about anything else, from AsciiDoc, reStructuredText, and Textile, to html, xml, and MS Word .docx files. More on supported document formats, and how we convert them (using Pandoc), can be read in our afore mentioned previous article.↩
We’re working on integration with multiple cloud hosting services, from which to pull your source files, including Dropbox, Google Docs, Google Drive and OneDrive. Alternatively — if you’d rather prefer (like we do) versioned file histories and changelogs — we’ll have post-commit hooks in place, listening to your
git pushes to repo’s on Bitbucket or Github.↩
See for yourself. Apparently it was made with FlippingBook Publisher v2.4.5.↩
Instead of trying to outsmart the Web’s ecosystem with such paperesque booklet-facsimile widgettery, a simple dump on the static file server would have been a way better means of deployment, hard-linking to the pdf’s raw url and having the user’s browser to decide whether and how to render on screen or triggering a download.↩
When lightweight markup languages came around (in the early 2000s) only the most basic of html tags were envisioned and put into the prototype implementations. Markdown suffers highly from fragmentation and fell apart into many “dialects”, precisely because different use cases needed different extensions. Support for footnotes, tables and other dearly needed content types has been built into Markdown “forks” like Github Flavored Markdown (GFM), Kramdown, MultiMarkdown, Pandoc’s Markdown, and PHP Markdown Extra. Still, these Markdown flavors lack many important extensions and content types. Besides Markdown there exist alternative lightweight markup languages with bigger feature sets and much broader support for different content element types, such as AsciiDoc and reStructuredText. Although their user communities are highly dedicated, these alternatives lack wide adoption, and so, I guess, there’s little left but betting on building further on top of Markdown. In order to work towards a standard, guaranteeing interchangeability between different Markdown flavors and backward compatibility, the Common Mark initiative was set up, September 2014. The Common Mark community is lively discussing extensions, syntax and standard behavior of parser implementations. But extra content element types make it very slowly into the official “spec”. At Rhythmus, we have been building on our own extensions to Markdown, adding the widest support for content elements that are required for professional publications.↩