Im dritten Quartal des letzten Jahres hat das newslab (das damals noch gar nicht offiziell existierte) einen vielbeachteten E-Reading-Feldtest organisiert und durchgeführt. Über einen Zeitraum von drei Wochen haben wir die Inhalte der “Frankfurter Rundschau” und der “Ruhr Nachrichten” auf den einzigen damals im Markt wirklich verfügbaren E-Reader (dem Sony PRS 600) gebracht und das Feedback der Leser untersucht.
Bei “Zeitung Online” Anfang Juni in Düsseldorf haben wir nun einen Prototypen der “Frankfurter Rundschau” auf dem iPad vorgestellt.
Damit ist auch schon das Spektrum der Lösungen gut umrissen, die im Schwerpunkt E-Publishing des newslab entwickelt werden.
In diesem Blogpost versuche ich, die Eckpunkte unseres grundsätzlichen Ansatzes zu beschreiben – und sie damit auch zur Diskussion zu stellen.
Die Eckpunkte
Die Eckpunkte unseres Ansatzes lassen sich kurz und knapp wie folgt beschreiben:
- Unterstützung von Tablets und E-Readern
- Konsequenter Einsatz von Webtechnologien und -standards zur Bereitstellung und Darstellung der Inhalte.
- Darstellung der Inhalte mit nativen Technologien nur dann, wenn diese einen funktionalen Mehrwert bieten oder die Einschränkungen der mobilen Geräte dies notwendig macht
- Einbeziehung von “Digital Replica” und “Digital Magazine” Ansätzen
- Integration von Print- und Online-Inhalten
- Konzentration auf die effiziente und effektive Produktion auf Basis existierender Inhalte und Systeme (Print und Online)
- Sowohl Full Service als auch Arbeit in Kooperationen und Netzwerken
Und damit zu den einzelnen Eckpunkten. Wobei ich mich in diesem Post auf die ersten drei Eckpunkte beschränke. Zu den letzten vier Eckpunkten schreiben Martin Kohls oder ich in Bälde einen weiteren Blogpost.
Tablets und E-Reader
Viele werden sich beim Lesen der Eckpunkte gefragt haben: “Warum Unterstützung von Tablets und E-Readern? Sind E-Reader nicht tot?”
Genauso wie wir schon seid langem daran glauben, dass Tablets als multifunktionale Geräte eine größere Verbreitung im Markt finden werden als E-Reader, sind wir auch davon überzeugt, dass E-Reader als Gerätekategorie nicht so schnell vom Markt verschwinden werden und insbesondere das EPUB-Format für bestimmte Arten von Inhalten noch eine lange Halbwertszeit hat.
So ist EPUB der De-facto-Standard für elektronische Bücher nicht nur auf E-Readern, sondern auch im iBookstore von Apple. Darüber hinaus gibt es auf praktisch allen anderen mobilen Plattformen (z.B. Android) ausgereifte Software zum Erwerben und Lesen von EPUB-Publikationen. Einzige Ausnahme bildet Amazon, die ein eigenes Format einsetzen, das allerdings weitaus weniger kann als EPUB. Aufgrund der Marktverschiebungen erwarte / hoffe ich aber auch, dass Amazon dem wachsenden Druck der Verlage nachgeben wird und auch auf EPUB umstellen wird.
Wenn man sich dann noch EPUB etwas genauer ansieht und feststellt, dass EPUB zu mindestens 80% aus Webtechnologie besteht, dann ergibt es Sinn, auch EPUB zu unterstützen; insbesondere dann, wenn der auch Ansatz für Tablets auf Webtechnologien fußt.
Exkurs: Eine EPUB Datei ist im wesentlichen ein ZIP-Bundle von XHTML und CSS2 Dateien, die durch eine Manifest-Datei zusammengehalten werden. Von der Art und Weise, wie ansonsten Mengen von HTML-Seiten oder anderen Inhalten zusammengehalten werden, ist das ganze also recht ähnlich. Dazu kommt noch eine zweite Struktur für eine inhaltsverzeichnis-basierte Navigation, die EPUB aus früheren E-Book-Standards mehr oder weniger geerbt hat, die aber relativ leicht generiert werden kann und auf die man leicht auch verzichten kann, wenn man im Inhalt selbst Links erlaubt.
Im Wesentlichen wurde im EPUB-Standard, der ja etwas älter ist, auf frühere Versionen von HTML und CSS standardisiert und das ganze um einige buchspezifische Funktionalitäten ergänzt. Hat man die schwachbrüstigen Prozessoren, die in E-Readern damals (und in dedizierten Geräten auch heute) verbaut wurden vor Augen, so wundert es nicht, dass Javascript vom EPUB-Standard nicht unterstützt wird. Allerdings schert sich Apples iBooks nicht darum, wie die Experimente von Liza Daly und Keith Fahlgren zeigen
Aktuell kümmert sich eine Arbeitsgruppe um die Weiterentwicklung des EPUB-Standards, insbesondere in die Richtung Unterstütung von unterschiedlichen Screengrößen und Periodicals. Wir werden sehen, was dabei herauskommt. Meine Empfehlung/Hoffnung: ein sinnvolles Subset von HTML5, Javascript und CSS3. Dabei stellt Javascript die größte Herausforderung dar, da ein vernünftigen Sandbox-Modell gefunden werden muss, damit nicht das Javascript eines “malicious books” die anderen gekauften Bücher zerstört.
Konsequenter Einsatz von Webtechnologien für Bereitstellung und Darstellung der Inhalte, native Darstellung der Inhalte , dann wenn Mehrwert gegeben oder durch Einschränkungen notwendig
Vorbemerkung
Vereinfacht dargestellt, hat man zurzeit die folgenden Möglichkeiten zur Darstellung gestalteter Seiten von Inhalten auf dem iPad:
- Nutzung der eingebauten PDF-Engine zur Anzeige der (in einem anderen Programm gestalteten) Seiten
- Nutzung der Bilderanzeige zur Anzeige der (in einem anderen Programm gestalteten) Seiten. Eigene Implementierung von interaktiven Bereichen.
- Nutzung von CoreText unter Verwendung einer eigenen Textlayout-Engine.
- Verwendung der HTML-Layout & und Rendering-Engine des UIWebView
Die erste Variante wird mittlerweile gern unter dem Begriff “Digital Replicas” zusammengefasst, die zweite Variante ist die zurzeit meistgenutzte in der Kategorie der “Digital Magazine Viewer“, wie sie zum Beispiel von Herstellern wie Woodwing und Adobe zur Zeit angeboten werden.
Insbesondere von Adobe ist zu erwarten, dass sie in ihrer Roadmap irgendwann auch einen Port ihrer InDesign Text Layout Engine oder – noch wahrscheinlicher – einen Port des Flash Text Layout Frameworks (TLF) vornimmt. Da letzeres OpenSource ist, können auch andere Anbieter auf diese Idee kommen. Auf jeden Fall ist die Implementierung einer Text Layout Engine in Objective-C nicht “einfach mal schnell gemacht”. Ich vermute sehr stark, dass die iPad-Apps der New York Times und von USA Today auf dieser Basis gebaut wurden, da sie beide den gleichen Fehler zeigen (einen größeren Durchschuss zwischen vorletzter und letzter Zeile eines Absatzes).
Warum moderne Webstandards als Basis?
Nach dem Vorwort in Richtung EPUB und den obigen Ausführungen ist es nicht mehr verwunderlich, dass wir für unseren eigenen Ansatz zur Realisierung von Applikationen auf dem iPad und weiteren zukünftigen Tablets für die vierte Variante entschieden haben. Wir setzen auf moderne Webtechnologien (insbesondere HTML5, CSS3 und Javascript). Eine ähnliche Ansicht, wenn auch etwas radikaler formuliert vertritt übrigens auch interfacelab.
Dabei ist es unser Ziel und Anspruch, webbasierte Lösungen zu entwickeln, die sich auf Augenhöhe mit der auf der Google I/O vorgestellten HTML5-Version von Sports Illustrated befinden.
Ein einfacher Grund ist, dass praktisch alle angekündigten Tablets auf Webkit als Browsertechnologie / Rendering Engine zurückgreifen und damit eine einheitliche Plattform entsteht, für die entwickelt werden kann. Insbesondere setzen sowohl Android / Chrome als auch Adobe AIR (der HTML Rendering Teil) auf der Webkit Rendering Engine auf, genauso wie u.a. WebOS , Symbian oder der neue Blackberry Browser.
Im Idealfall erhält man also für Tablets eine einheitliche Browserplattform zur Darstellung der Inhalte auf den verschiedensten Endgeräten: eine Browserplattform, die moderne Webtechnologien unterstützt. Klar ist aber auch, dass sich die Browser, auch wenn sie alle auf Webkit basiseren, in der Umsetzung der verschiedenen Aspekte von HTML5 unterscheiden. Aber auch der kleinste gemeinsame Nenner unterscheidet sich fundamental von dem kleinsten gemeinsamen Nenner für Desktop-Browser: leider immer noch IE6.
Aus über 10 Jahren Erfahrung in der Entwicklung für das mobile Internet wissen wir, dass mobile Browser im Vergleich zum Desktop immer noch großen Einschränkungen unterliegen (die im Wesentlichen der deutlich schächeren Hardwareausstattung der mobilen Geräte geschuldet sind). Daher funktionieren viele Dinge, die in einem Desktopbrowser super aussehen, auf einem Tablet nur schlecht oder gar nicht.
Inhalt und Repräsentation
Deswegen unterscheiden wir auch sehr bewusst zwischen der Bereitstellung und Präsentation / Darstellung der Inhalte.
Wir sind gern bereit, aus Gründen eines funktionalen Mehrwertes (und sei es “nur” die bessere Performance, die in unseren Erfahrungen aber oftmals den Unterschied zwischen unbenutzbar und benutzbar ausmacht!) oder einer Browsereinschränkung bestimmte Komponenten zur Präsentation der Inhalte nativ zu implementieren. Dagegen bedarf es deutlich größerer Anstrengungen, uns davon zu überzeugen, warum es sinnvoll sein soll, die Inhalte nicht in einem Webformat bereitzustellen.
Ein gutes Beispiel für die native Präsentation der Inhalte sind die Slideshows in unserem FR-Prototypen. Sie waren zunächst nur mit Webtechnologie implementiert, aber die Kombination aus Performance und Browsereinschränkungen führten dazu, dass wir eine native Slideshowkomponente implementiert haben. Welche Bilder mit welchen Bildunterschriften etc. angezeigt werden sollen, wird aber weiterhin in einem HTML-Dokument bereit gestellt.
HTML5 oder XML
Hier sind wir der Überzeugung, dass HTML5 (insbesondere unter Zuhilfenahme der neuen semantischen Tags, zusammen mit semantischen CSS-Klassen) gut geeignet ist, um (Zeitungs-) Inhalte für die Darstellung auf Tablets bereitzustellen. Sollte uns das aber an einigen Stellen zu konstruiert erscheinen, würden wir zu einer Erweiterung via Namespace greifen.
Andere Ansätze (inbesondere die Digital Magazine Viewer) verwenden zur Übermittlung der Inhalte XML + Bilder. Oder es wird geplant, XML zu übermitteln und dann mit der eigenen Layoutengine zu rendern. Hier erschließt sich für uns nicht der Mehrwert, ein eigenes XML zu definieren und übermitteln. Verwendet man die XML-Serialisierung von HTML5, ist das ganze valides XML. Man verliert nichts in Hinblick auf die Verarbeitbarkeit des XML.
Dafür bekommt man eine Layout und Rendering Engine “for free”. Sie ist vielleicht aus typografischer Sicht nicht optimal, aber im Zweifelsfall ist die Entwicklergemeinde, die diese Layoutengines weiterentwickelt, die größte der Welt.
Textlayout und HTML
Das beste Beispiel für die noch nicht erreichte optimale Darstellung von Text in HTML ist der im Vergleich zu TeX/LateX oder InDesign doch eher rudimentäre Blocksatz von engen Spalten. Ob der Blocksatz von schmalen Spalten generell eine gute Idee für Geräte wie das iPad ist, lassen wir mal außen vor. Oliver Reichenstein von informationArchitects hat da ja eine sehr dedizierte Ansicht, die wir im Prinzip teilen. Für jeden, den es interessiert, kann ich nur die sich anschließende Diskussion empfehlen (die sich interessanterweise auf Flickr entfachte).
Will man die Skalierbarkeit der Schrift nicht verlieren – eine Funktionalität, die insbesondere für die aus unserer Sicht gerade für Zeitungen interessante Verwendung des iPads als “intelligente Leselupe” wichtig ist – muss der Zeilenumbruch auf dem Gerät stattfinden. Für JavaScript-basierte Implementierungen des objektiv besten Zeilenumbruchalgorithmus, der Knuth-Plass Algorithmus ist die JavaScript Engine des Mobile Safari aber (noch) zu langsam, und durch die Verwendung eines Canvas verliert man Copy & Paste. Daher erscheint uns die in dem Artikel vorgestellte CSS Word Spacing Variante interessanter, auch wenn die CSS Property noch nicht unterstützt wird.
Völlig unverständlich für mich ist allerdings, warum – zumindest nach meiner Kenntnis – bislang kein Browser Knuth-Plass nativ implementiert. Kennt einer die Gründe? Für die Silbentrennung gilt im übrigen das gleiche Hier gibt es Javascript-Implementierungen der TeX/LaTeX Algorithmen, aber keine native Unterstützung.
Links, Links, Links
Zu guter Letzt ist für uns das alles überragende Argument für eine HTML5-basierte Lösung, dass wir fest daran glauben, dass für ein “connected, interactive device” wie das iPad (und Tablets im allgemeinen) es nicht die einzige bzw. die beste Lösung sein kann, die Darstellungsform eines gedruckten Produktes mehr oder weniger 1-zu-1 zu übernehmen, wie es die momentan am häufigsten für iPad-Apps genutzten “Digital Replica” oder “Digital Magazine Viewer” Ansätze tun.
Dies hat zur Folge, dass ich in meinem initialen Review von Nachrichtenapplikationen auf dem iPad die Überschrift: “Welcome to the link free zone” gewählt habe. In allen Ansätzen außer einem HTML-basierten Ansatz muss die Funktionalität eines Links implementiert werden. Bei Variante 1 und 2 ist das unmögliche resp. schwierig (der eingebaute PDF-Viewer versteht keine Links in PDF-Dateien, wir haben es ausprobiert), in Variante 3 ist es möglich, muss aber nach meinem Kenntnisstand selbst implementiert werden. In Variante 4 muss man diese Funktionalität selbst deaktivieren 
Eine Publikation die keine Links enthält ist aber nach unserem Verständnis noch nicht auf dem iPad angekommen. Selbst die Printausgaben der Zeitungen enthalten mittlerweile mehr oder weniger oft Verweise auf das eigene Online-Angebot und in das allgemeine Web. Wie will ich den Lesern erklären, dass diese Links in einer iPad-App nicht funktionieren?
). Wenn es in einem Projekt mal eng wird, dann helfe ich gern auch mit Hilfsttätigkeiten aller Art aus oder halte den Projektmitgliedern den Rücken frei.