Die Zukunft der Technischen Dokumentation liegt in Apps auf mobilen Endgeräten. Doch welche Technologie bildet die richtige Grundlage, um Apps für die verschiedenen Endgeräte mit unterschiedlichen Auflösungen effizient aufzubereiten?

Autoren: Florian Gust und Dieter Gust*

Einmal mehr versprechen HTML5 und moderne Browser-Technologien die Lösung. Doch zur Euphorie gesellt sich auch grundsätzliche Kritik, wie etwa jene von Mark Zuckerberg, Gründer und Vorstandsvorsitzender von Facebook, im Jahr 2012: „Our biggest mistake was betting to much on HTML5 as opposed to native. Because it just wasn’t there.“

Mark Zuckerberg: Our biggest mistake was betting to much on HTML5 as opposed to native. Because it just wasn’t there.

HTML ist seit 15 Jahren längst ein Standard-Ausgabeformat – auch für die Technische Dokumentation. Neben PDF ist Microsoft HTML Help die klassische Lösung für Online-Hilfen. Um plattformübergreifend verwendbar zu sein, gibt es auch schon lange Methoden unter dem Sammelbegriff „Webhelp“. Damit wird eine zu HTML Help vergleichbare Funktionalität mithilfe von HTML und JavaScript in beliebigen HTML-Browsern auf beliebigen Plattformen bereitgestellt. Und der Weg von Webhelp zur mobilen App ist dank jQuery und jQuery Mobile technologisch gesehen zumindest vordergründig sehr überschaubar.

Die Umsetzung der (Multi-)Touch-Bedienung erfolgt weitgehend automatisch durch die jeweiligen Browser oder die so genannten systemintern zur Verfügung gestellten „Webviews“ (jeweils unterschiedlich für Android, iOS und Windows).

Was auf den ersten Blick wie eine unproblematische Adaption altbekannter HTML-Lösungen für die neue Multitouch-Welt aussieht, erweist sich bei genauerer Betrachtung dann aber doch als „Teufel im Detail“. Das betrifft weniger die eigentliche Umsetzung des klassischen Inhalts in Text- und Bildform. Während XML-Protagonisten gerne den XML-Ansatz als Bedingung des Cross-Media-Publishings (z.B. PDF und HTML) ansehen, ist praktisch „nur“ der strukturierte Ansatz nötig, wie ihn schon eine saubere formatvorlagenbasierte Dokumentgestaltung bietet. Die Herausforderungen dabei lagen jedoch schon immer in der Grafikkonvertierung. Während im DTP durch Rahmenfunktionen Grafiken sehr flexibel gestaltet werden können, fehlt HTML ein vergleichbares Konzept. Ein HTML-Konverter muss also gegebenenfalls sehr intelligent das im DTP-System integrierte, skalierte, beschnittene, durch mehrere überlagernde Grafiken definierte Konstrukt in eine neue Grafik umwandeln.

Wirklich neu bei mobilen Medien ist das für Finger-Touch optimierte Design. Zusätzlich wird ein Responsive Design benötigt, das alle Bildschirmgrößen (im Hoch- und Querformat) bis hin zum Desktop ohne Neukonvertierung dynamisch abdeckt. Dieses Design und auch die Touch-Optimierung werden durch so genannte JavaScript-Frameworks und Cascading Style-Sheets (CSS2/CSS3) bereitgestellt. Das heißt, die eigentliche HTML-Konvertierung kann praktisch auch die 15 Jahre alte Lösung bereitstellen.

Das möglichst automatische Verknüpfen der HTML-Dateien mit den neuen JavaScript-Frameworks ist jedoch eine der Herausforderungen, weil viele HTML-Konverter einen nicht wirklich wartbaren HTML- und JavaScript-Code erzeugen.

Alle mobilen HTML-Browser-Technologien — auch die von Apple — sind leider „mit heißer Nadel gestrickt“. Das wird spätestens dann deutlich, wenn man beim Responsive Design von den hunderten bereitgestellten Parametern auch wirklich Gebrauch machen will, um etwa Videos im Hoch- und Querformat automatisch anzupasssen, Playlists dynamisch einblenden zu können und generell die von Steve Jobs zu Recht beschworenen Feinheiten auch wirklich fehlerfrei einsetzen zu können. Diese sind z.B. folgende:

• sanftes Scrollen
• sanftes Ein- und Ausblenden von Objekten, getriggert durch Wisch- oder Touch-Events oder durch Drehen des Gerätes.

Fast drei Jahre nach Steve Jobs‘ Tod überrascht dann doch folgende Meldung über Apple (im Bild links), die kurz nach der Veröffentlichung von iOS7 zu lesen war: „… for the first time ever we’re disappointed in the execution of iOS software“ (Sencha-Blog, Sept. 2013).

Diese Meldungen stehen für „Killerkriterien“, um termin- und kosteneffizient HTML5-Lösungen anbieten zu können. Ein weiteres Beispiel: Beim Update von Android 2.x auf 3 funktionierten keine HTML-Hyperlinks mehr in der so genannten Android Webview, die Sonderzeichen wie # oder ? enthielten (eine wirklich typische Nutzung der Hyperlinks). Die Webview ist dabei eine von Android bereitgestellte Browser-Engine, um HTML-Inhalte in einer nativen App darstellen zu können. Erst aufwändige Workarounds von HTML-Enthusiasten brachten eine Lösung. Jahre später, in Android 4, wurde das Desaster dann auch von Google beendet.

Ein Problem der HTML5-Programmierung liegt darin, dass hinter dem Modewort HTML5 eine Vielzahl an komplexen Technologien steckt, die insgesamt einer nativen Programmierung nicht oder nur um wenig nachsteht.

Als HTML5 wird zusätzlich das neue Verständnis in der HTML-Anwendung auf unterschiedlichen — vor allem mobilen — Endgeräten definiert (z.B. Stichworte wie „Mobile First“).

Eigentlich konnte man seit vielen Jahren mit JavaScript und mit HTML4 ein Mobile Design planen, denn auch JavaScript ist seit Langem in den Browsern präsent. Neu im Responsive Design ist allerdings die Nutzung der Media Queries aus CSS3. CSS3 gehört zwar zum Umfeld von HTML5, jedoch nicht zur HTML5-Spezifikation.

 

Dennoch hat sich unter HTML das Document-Object-Model (DOM; die interne Repräsentation einer HTML-Seite als Baumstruktur) ebenfalls weiterentwickelt und bietet zum Beispiel die Option für eigene, so genannte Custom-Attribute.

Geschichte von HTML anhand der Spezifikation

Die unten stehende Auflistung zeigt eine kurze Geschichte der HTML-Specs und offenbart dem Kenner, welcher Kampf der HTML-Entwicklung nach HTML4 die letzten zehn Jahre „hinter den Kulissen“ stattgefunden hat: Fast zehn Jahre dauerte das Ringen, die Gründung eines neuen HTML-Normierungsgremiums, WHATWG (Web Hypertext Application Technology Working Group) unter Federführung von Google, das Ende von XHTML und das Zusammenraufen für die Verabschiedung einer HTML-Spezifikation zusammen mit dem W3C, wie die Liste der Autoren zeigt. Dass jedoch Adobe nicht dabei ist, überrascht so manchen.

• TML 2.0, RFC 1866, November 1995,
  Tim Berners Lee, Dan Connolly
• HTML 3.2, W3C Recommendation, 14 January 1997
  Dave Raggett, Author
• HTML 4.01, W3C Recommendation, 24 December 1999
  Dave Raggett, Arnaud Le Hors, Ian Jacobs, Editors
• XHTML 1.0, W3C Recommendation, revised 1 August 2002
  Steven Pemberton et al., Authors
• XHTML™ 1,1 — Module-based XHTML, W3C Recommendation, 31 Mai 2001
  Murray Altheim, Shane McCarron, Editors
• XHTML Basic 1.1 — Second Edition, 23 November 2010
  Shane McCarron, Applied Testing and Technology Inc., Masayasu Ishikawa
• XHTML 1.1 — Module-based XHTML, 23 November 2010
  Murray Altheim, Sun Microsystems, Shane Mc Carron,  Applied Testing and Technology Inc.
• W3C: HTML5 A vocabulary and associated APIs for HTML and XHTML, W3C Candidate Recommendation 4 February 2014
  This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 1 September 2014
  W3C: Robin Berjon, W3C: Steve Faulkner, The Paciello Group: Travis Leithead, Microsoft: Erika Doyle Navara, Microsoft: Edward O’Connor, Apple Inc: Silvia Pfeiffer, WHATWG: Ian Hickson, Google Inc.

HTML — das Modewort für viele Technologien

Der Kreis in dem Diagramm unten mit der Bezeichnung „HTML5-Markup“ bildet die Basis von HTML5. Die so viel gepriesenen neuen „semantischen“ Elemente werden aktuell in HTML-Apps nicht oder kaum verwendet. Eine Ausnahme bildet das Video-Element. Das Video-Element signalisiert, dass nun kein externes Plug-in zur Videoanzeige mehr benötigt wird — die eigentliche kleine Revolution von HTML5.

Die Nutzung der sensationellen Animationsfunktionen von CSS3 gewöhnt man sich zunächst sehr schnell wieder ab, da CSS3 nicht Bestandteil der HTML5-Nominierung ist und im Test die verschiedenen Browser und Webkits keine verlässliche Nutzung erkennen lassen.

Die Herausforderung liegt also im Zusammenspiel der vielen Teilspezifikationen und im  Testen der hunderte von einzelnen Parametern/Optionen im jeweiligen Browser. So sind einerseits spektakuläre Demo-HTML5-Websites zu finden, die suggerieren, dass alles mit HTML5 realisierbar ist. Andererseits kämpft der HTML5-Programmierer permanent mit grundlegenden „Show-Stoppern“ und „Killerkriterien“, weil bei irgendeinem System-Update — sei es iOS, Android oder Windows — viele der unzähligen Parameter nicht getestet wurden.

Eigentlich gilt als Grundlage der sauberen HTML-Programmierung das Model-View-Controller-Prinzip (MVC), also die Trennung zwischen Inhalten (dargestellt durch HTML-Markup), die Präsentation (durch CSS) und Controller (dynamische Funktionen mit Hilfe von JavaScript). Jedoch lassen sich viele Layoutaspekte durch JavaScript oder CSS3 alternativ abdecken, während die Bedeutung der Elemente durch das Klassenattribut und den DIV-Container fast obsolet geworden ist.

Überhaupt scheint das Zusammenspiel aus HTML-Elementen und CSS-Dateien sehr oft „abenteuerlich“ bis „kreativ“ zu sein. FrameMaker12 etwa nutzt bei der neuen HTML5-Konvertierung praktisch nur das P-Elemet aus HTML. Überschriften und Listenelemente werden in P-Elemente konvertiert, über das Klassenattribut gekennzeichnet und per CSS entsprechend formatiert.

So lässt ausgerechnet die neue HTML5-Konvertierung von FrameMaker keine klare Zuordnung von FrameMaker-Formaten und HTML-Elementen zu, wie sie die uralte, noch immer integrierte HTML-Konfiguration kennt. Dass bei der Konvertierung der Formatnamen in entsprechende Klassenattribute gängige Sonderzeichen, wie z.B. der Unterstrich, auch noch einfach geändert werden, macht den Umwandlungsprozess nach HTML fehleranfällig. So war HTML eigentlich nicht gedacht: Reduktion auf eine Element (P) und Variation per Klassenattribut.

Weil HTML so flexibel ist, nutzen viele Konverter auch zusätzlich das DIV-Element (FrameMaker kann in der Konfiguration per User Interface kein DIV zuordnen). DIV steht bekanntlich für „Diverses“ und erlaubt, beliebige Elemente zu klammern und nach Bedarf zu prozessieren. Beide Ansätze — „Klassen- bzw. ID-Attributierung“ und „DIV-Klammerung“ — machen HTML so unglaublich flexibel und zu einem chaotischen Gesamtkonzept.

HTML5-Web-Apps: Kernpunkte einer neuen User Experience

Aus Sicht eines Technischen Redakteurs liegt die eigentliche neue Herausforderung in der neuen User-Experience der mobilen Apps. Die von Steve Jobs 2007 erstmals gezeigten Multitouch-Gesten wie Wischen und Pinch-to-Zoom  bilden das Zentrum der neuen User Experience. Diese Multitouch-Gesten sind so selbstverständlich und intuitiv, dass vielen deren revolutionäre Wirkung auf die Nutzungsmöglichkeiten von technischen Informationen auf mobilen Endgeräten noch nicht klar ist. Und die Verbindung der neuen Multitouch-Gesten mit altbekannten Nutzungsfunktionen einer Online-Dokumentation unter automatischer Berücksichtigung eines Responsive Design für die so unterschiedlichen Bildschirmgrößen von Smartphones, Tablets und Desktop und dazu noch die zahllosen Bugs der Desktop-Browser und HTML5-Umsetzungen in Android und und iOS — all das macht die Programmierung so abenteuerlich und Projekte leider nur schwer kalkulierbar.

Da viele Programmierer vor ähnlichen Problemen stehen, hat sich ein erstaunlicher Markt für JavaScript-Bibliotheken und HTML-Templates bis hin zu kompletten Frameworks (UI-Design, Animationen, Seitenlayouts) entwickelt, der Fluch und Segen zugleich ist. Einerseits nehmen die Codeschnippsel dem Programmierer unter Umständen viel Arbeit ab, indem die Funktionen mit den unterschiedlichsten Browsern getestet wurden und bereits Workarounds enthalten. Wenn ein Framework aber Fehler enthält, sind diese allerdings noch schwieriger zu debuggen als ohne Framework. Und Anpassungen jenseits der Änderungen für Font, Farben und Buttonumrandungen sind zum Teil nur schwierig oder gar nicht zu realisieren.

Die Grafik links von Templatemonster.com zeigt am Beispiel Bootstrap über Pop-ups sehr schön, was ein Framework umfassen kann.

Seit HTML5 sind für HTML-basierte Dokumentationen zwei alternative Ansätze zu klären:

• Darstellung der gesamten Dokumentation als eine physikalische HTML-Seite, die dynamisch in Topics zerlegt wird
• Klassische Trennung in einzelne Topics-Seiten. Der Vorteil des 1-Seiten-Ansatzes: bessere Manipulierbarkeit des DOM ähnlich wie bei einer nativen App-Lösung. Nachteil: erstmalig längere Ladezeit und Updates von Einzelinformationen sind so nicht möglich. (itl empfiehlt zur Zeit die Zerlegung einer Dokumentation in topic-orientierte HTML-Seiten.)

Als Anregung zu diesem Thema siehe zum Beispiel Sitepoint-Thread „Multipage, Single Page or Hybrid AJAX Application„.

Usability-Funktionen für eine Technische Dokumentation umgesetzt als mobile App

Die an dieser Stelle hinterlegte Tabelle stellt die typischen Usability-Funktionen den jeweiligen möglichen Frameworks und Standardbibliotheken gegenüber.

Das Rad nicht neu erfinden: Templates, Bibliotheken, Frameworks — oder doch alles neu machen?

itl beschäftigt sich seit knapp zwei Jahren mit HTML5-Lösungen und hat dabei die bekannten JavaScript-Framworks und HTML-Template-Konzepte näher betrachtet. Bisher konnten wir uns zu keinem der bekannten Frameworks als Basis durchringen, das uns für nahezu alle Anforderungen als geeignet erscheint. Allerdings ist jQuery immer und bei allen dabei.

Neben den großen Frameworks gibt es inzwischen zahllose zusätzliche JavaScript-Funktionen, die sich zum Teil als Plug-ins zu den Frameworks gesellen. Überschaubar kann man die aktuelle Situation schon lange nicht mehr nennen und moderne, effiziente HTML-Entwicklungen sind letzlich auch immer wieder von kleinen, manchmal auch großen Code-Juwelen abhängig, die plötzlich im Internet bekannt werden.

Als grundsätzliche webbasierte Unterstützungswerkzeuge empfehlen wir außerdem filterbare Unterstützungstabellen für HTML5, CSS und Javascript in den jeweiligen Browsern, wie beispielsweise caniuse.com oder html5please.com. Zum Lernen viel gescholten, von uns jedoch sehr geliebt wird die Website w3schools.com.

*) Florian Gust ist HTML5-, Android- und Java-Developer der itl AG München. Dieter Gust leitet ebenda die Abteilung Forschung und Entwicklung. Der Titel „Der Stand von HTML5 für die Technische Dokumentation: Wunderwaffe oder Rohrkrepierer?“ war Thema eines Vortrages der beiden am 1. Oktober 2014 in Wien. Die itl AG mit Hauptsitz in München und Niederlassungen und Außenstellen in Stutttgart, Cottbus, Kreuzlingen sowie Wien, Graz und Linz ist Full-Service-Dienstleister im Bereich Technisch Dokumentation.