About layout applications for content first

Today an article of my Swiss college Haeme Ulrich about HTML authoring tools caught my attention: Haeme proclaims that in a content first world HTML based layout applications (like Woodwing Inception or TruAuthor from MEI) are the way to go. While I agree with some of his considerations I don’t agree with the conclusion. I agree with the approach to content first and the major role HTML plays in todays publishing landscape. In fact, content first played a big role in our “Agile Publishing” book and responsive HTML is the main reason why I abandoned all digital publishing solutions (including the ones producing HTML output) in the last years.

My disagreements begin with the assumption that structured content, the foundation of a content first approach, is best being stored in HTML. That’s not the case—HTML is no vehicle for structured content. HTML was never intended to store structured content, the same as InDesign or Word where never intended to do so.

Structured content means that you add semantics to your content that is machine-readable and allows for automatic transformations to different output channels. This describes a platform agnostic way that is very sustain in terms of the ongoing evolvement of media channels. HTML is not designed to do that. While some of the tags in HTML have kind of a “semantic touch” they are merely focused on describing the layout. A <h1> for instance of course says that this is the most important headline of the page but it doesn’t says anything about which kind of headline it is or in which context it stands. Both things that are crucial for transformations to other channels. A lot of the tags used in HTML, like <div> or <span> aren’t semantic at all. And of course there are some semantic tags in HTML5 like <main>, <article> or <header>, but there aren’t many of them, and again their main intention is to structure the layout, not so much the content.

So, what’s the best approach to store structured content? It is, well … structured content. I agree with Haeme on the objections against XML as a user-friendly entry to structured content. But the future of structured content isn’t XML authoring. It is a smarter approach to content management and an API-driven way of distributing the content. Both things seem way better suited for the digital landscape than the idea of authoring HTML in a print-like layout environment. In the last years we have seen interesting developments in the content management area, be it the “de-coupled” usage of Drupal, more agile, database-free systems like Kirby or completely “headless” systems like Contentful. Even WordPress can be used in that way. The principle is the same in each of them: You define a structure for your content and then you provide a nice experience for your editors to enter the content. With that you can simply add an API (programming interface) to the CMS—and voila, your content is free! That’s an entirely different beast than writing XML from scratch in a text editor.

Haeme says that he was long looking for what would be the next kind of layout applications in the digital age. He says that Woodwing Inception or TruAuthor are the beginning of this new area, being HTML-driven and responsive but also friendly to graphic designers. I was myself looking for these kinds of tools for some time and I agree that there might be some appeal to them for a lot of people. But, honestly, I don’t think that the future of layouts are layout applications. Woodwing Inception for instance does a nice job in transforming a web layout into a Facebook Instant Article or the Apple News format. But that’s just a conversion from a proprietary HTML-flavor to other proprietary HTML-flavors. These kind of layouts are not ready for the new things on the horizon: be it virtual reality, wearables or even devices with no interface at all. Content first driven implementations should be able to serve them. That’s what content first is about. And that’s where responsive layout applications and HTML as a storage format fail.

Will HTML become relevant and maybe even serve as layout for print products? Yes, look at pdfChip. Do we need a layout application for content first? I don’t think so. Do we need better authoring interfaces for content first? Definitely, some good things are already out there. Do we need to think more deeply about how smart our content should be and which rules we apply to it? Absolutely.

Georg Obermayr

4 Comments About layout applications for content first

  1. Haeme Ulrich

    Danke Georg für den spannenden Beitrag und deine Sichtweise. Ich gebe dir recht. Jedoch finde ich den Ansatz zu akademisch. So eine Maschine fliegt höchstens bei 20 Prozent unserer Kunden. Die anderen können sich das nicht leisten und folgen dem Konzept “Done is better than perfect”. Und eben hier sehe ich HTML als geeignete Alternative. Ja, klar wurde es nicht dazu erfunden, aber eben: Besser nicht perfekt umsetzen als perfekt scheitern. Ich kenne viele Publishing-Projekte, die genau an dem gescheitert sind und ausser den Nadelstreifen-Beratern niemandem was gebracht haben.

    Eine kleine Sache, die mir noch wichtig ist: Ich schreibe nicht HTML Layout Tools, ich schreibe HTML Authoring Tools. Layout Tools in der herkömmlichen Art brauchen wir wirklich nicht mehr.

    Coole Diskussion – vielen lieben Dank Georg!

    Liebe Grüsse aus Bern
    Haeme

  2. Martin

    Also ich kann mir schon vorstellen, dass HTML funktioniert. Es könnte auch im Word-Format funktionieren (joke). Aber relationale Datenbank klingt für mich naheliegend und irgendwie flexibler und simpler. Von mir aus kann man dafür auch ein CMS oder Redaktionssystem anpassen, um sich Programmierarbeit zu ersparen. Am Ende arbeiten auch diese wieder mit einer Datenbank. Bei der Auswahl sollte man sich ruhig schonmal vorab darüber im Klaren sein, dass eine Migration irgendwann in den nächsten Jahren sowieso wieder anstehen wird, weil sich die Technik, die Medien, die Workflows oder was auch immer weiterentwickeln werden. Welches Benutzerinterface man sich für die Eingabe und Bearbeitung davor bastelt, ist ja fast beliebig gestaltbar, wie auch die erzeugte Ausgabe – solange es dem Zweck gerecht wird. Das könnte auch ein WYSIWIG-Editor sein.

    Warum soll man das Rad hier also neu erfinden, wenn es lediglich darum geht, Daten zu erfassen, zu verarbeiten und sie dann in unterschiedlich aufbereiteten Formaten auszugeben? Eine Art Rohformat bildet hierfür meiner Meinung nach die beste Basis zur dauerhaften Archivierung.

    Die spannendere Frage ist: Was bedeutet hier eigentlich “Content first”? Bei mir hieß es seit langem immer “Reader First”. 🙂

    Und: kann ich das “Agiles Publishing”-Buch auch irgendwo in digitaler Form erwerben? Der Link zum “Beyond Print”-Shop auf Eurer Seite zum Buch stimmt nicht mehr.

    Gruß, Martin

  3. Georg Obermayr

    Hallo Martin,

    Ich glaube grade gar nicht (oder ich verstehe es nicht richtig), dass ich etwas anderes geschrieben habe: Natürlich sind relationale Datenbanken die Grundlage für die Speicherung. Und die Inhalte darin sollten eben in möglichst sinnvolle — semantische! — Felder aufgeteilt werden. Dabei sollte man halt darauf achten, nicht einfach den ganzen Inhalt in ein einziges riesiges Feld (einen “Blob”) zu kippen, sondern das eben möglichst sinnvoll zu zerlegen. Das ist aber ja alles nichts neues, genauso wenig wie die Frage nach dem Interface, das man dann drüber liegt.
    Und natürlich können einzelne Felder in der Datenbank auch formatierten Content enthalten. Und das kann auch gerne HTML sein, genau das ist ja heute auch in vielen System Praxis. Wobei ich in letzter Zeit bei neueren Systemen häufiger Markdown an Stelle von HTML sehen, was mir auch smarter erscheint.
    Wogegen ich mich wehre ist das Statement, das HTML ideal ist für medienneutralen Inhalt. Das ist es nämlich “per Design” eben nicht. Eine Datenbank ist es schon, und davon kann HTML gerne auch wieder ein Teil in einzelnen Feldern sein.

    Ob wir das nun “Content First” nennen oder “Reader First” oder wie auch immer bleibt jeden selbst überlassen. Am Ende meinen wir das wohl das gleiche. Wobei sich Content First als Begriff schon durchsetzen scheint 😉

    Zum Buch: Gut möglich, das der Link zu Beyond-Print nicht mehr geht, da gab es einige Veränderungen. Eine digitale Fassung gab es nie (und wird es auch nicht mehr geben). Ich würde empfehlen das Buch über Amazon oder einen anderen Buchhandelsweg zu beziehen. Danke!

    Viele Grüsse,
    Georg

    PS: Ja, die Kommentare werden wegen Spam moderiert. Ich schaue mir das mit der UX da mal an.

  4. Martin

    Hallo Georg,

    entschuldige bitte, falls es sich anders angehört hat. Ich wollte damit eigentlich nur bestätigen, dass wir uns in allen Punkten, die die Technik betreffen, einig sind… 🙂

    Nur, dass das Wort “ideal” bei Haeme in dieser Form garnicht auftaucht. Ich verstehe eigentlich nur, dass HTML sich einer hohen Beliebtheit erfreut, aber es impliziert nicht, dass es tatsächlich die ultimative Lösung ist. Provoziert hat mich eine ganz andere These, die in seinem Content First/Lorem ipsum Text auftaucht. Deshalb auch die Frage nach “Content first”.

    Neugierig gemacht und zum Nachdenken angeregt habt ihr beide mich jetzt also allemal, selbst wenn mir noch nicht alles einleuchtet. Aber das wird sich vielleicht im Laufe der Zeit noch ergeben. 😉

    Viele Grüße, Martin

Leave a Reply

Your email address will not be published. Required fields are marked *