rss feed articles activities all_comments

indeedgeek.de

Florian Eitel

Dokumentenformat der Zukunft

One Format to rule them all

Schaut man in die “analoge” Welt an, so finde ich, Medien werden sehr nach ihrem Zweck dargestellt. Was natürlich auch selbstverständlich ist. Schaut man sich eine Zeitung an so möchte man vielleicht nicht ein Hardcover. Genauso wie man ein 300 Seiten Buch nicht mit vier Zentimeter großen Überschriften auf Zeitungspapier gedruckt wird.

Alles Content

In unserer digitalen Welt ist dies nicht mehr so einfach. Wir möchten WAS wir wollen, WANN wir wollen und WIE wir wollen konsumieren. Keiner würde auf die Idee kommen sein “Zeitungs-Tablet” auszupacken um die TAZ zu lesen oder sein “Bücher-Reader” um den Roman fertig zu lesen. Statt dessen haben wir eine Datei die wir (mal abgesehen von irgendwelchen DRM-Spacken) auf alle Geräte kopieren können. Sei es Ebook-Reader, Laptop, Fernseher, Handy oder wo auch immer. Theoretisch funktioniert das auch wunderbar. Viel öfter scheitert es aber an dem Format in dem die Daten vorliegen.

Man bedenke nur die unterschiedlichen Bildformate. Oder noch schlimmer Videoformate. Verschiedenste Codecs verpackt in einem endlosen Chaos von Containerformaten. Auch wenn die unterschiedlichsten Formate aus technischer Hinsicht vielleicht Sinn machen so tun sie es sicher nicht aus Anwendersicht.

Ich meine sicherlich, die einzelnen Formate werden immer besser. Höhere Auflösung bei Videos. Bessere Komprimierung bei Musik. Mehr Features bei Office-Dokumenten. Gerade bei Videos merkt man dies. Früher ein avi welches einfach ein Video mit Ton abgespielt hat. So ist man übergegangen bei Container-Formaten wie mp4 mehrere Sprachen und Untertitel zu unterstützen. Matroska hingegen unterstützt auch Kapitel, Navigation oder 3D. Und Blurays benötigen zum Teil Java und Internet für chats with the director, Internet games, downloadable featurettes, downloadable quizzes, and downloadable movie trailers (lol, wann habt ihr das letzte mal mit dem Director über eure Bluray gechattet?). Und trotz der vielen Nutzungsmöglichkeiten wird niemand abstreiten, dass eine Bluray ein Film ist.

Worauf ich hinaus will: Warum muss ein Video ein Video sein? Warum ein Bild ein Bild? Kann nicht einfach alles Content sein? Podcasts sind Soundfiles können aber auch Kapitelmarken, Songtexte oder mehrere Sprachen beinhalten. Blurays sind gar ganze Programme mit Internetzugriff.

Geben wir uns kurz der Utopie hin man wäre nicht durch Hard/Software an Restriktionen wie Encodings, Formate und Features gebunden. Was würde eine Kategorisierung nach zum Beispiel Video, Audio und Text noch für ein Sinn machen? Ist nicht alles einfach nur Content? Content bestehend aus Videos und Text und Sound und gar Logik.

Aber dennoch sind wir davon Meilenweit entfernt. Wir versuchen immer noch einen Videoplayer für Videos, einen ebook-Reader für Bücher, ein digitales Zeitungskiosk für Zeitungen zu bauen. Nur das nun unsere Videos navigierbar, unsere Ebooks interaktiv und unsere Zeitungen voller Videos sind. Wäre es nicht befreiend endlich diese analogen Analogien los zu lassen? Content nicht fix nach Umgebung zu betrachten in der er konsumiert wird sondern als Metabeschreibung die je nach Context anders dargestellt wird?

Wie damals mit HTML

Dem ein oder anderen wird es bekannt vorkommen. Eine simple – und anscheinend utopische Vorstellung – von der Trennung des Aussehens, der Logik und dem Semantischen Inhalts. Gerade Webentwickler denken vielleicht zurück an die Kriege warum das emph-Tag besser als das font-Tag ist, warum Tabellenlayouts furchtbar sind, warum pixelgenaue Layouts der Tot und media-Tags im CSS ein Segen sind.

Wir haben die Diskussion schon einmal durch gemacht. Früher unter dem Begriff der Barrierefreiheit und der Suchmaschinen-Optimierung. Heute ist es eher die Mobilversion für Handy’s welche durch unvorhersehbare Größen dynamisches Layout erforderlich macht. Herausgekommen ist in der neusten Version ein Dokumentenformat wie es fast besser nicht sein könnte. Video, Sound, Formeln, Vektorgrafiken, Navigation – alles kein Problem mit HTML. Die Trennung von Logik, Design und Semantik schon fast inhärent (theoretisch). Und doch haben wir aus den Fehlern nicht gelernt.

Ich war früher immer Javascript sehr skeptisch gegenüber gestanden: “Javascript nur optional – es muss auch ohne benutzbar sein”. Heute richtet sich die Kritik eher auf Web-Apps, welche das Rad im Browser neu erfinden. Aber es fällt mir schwer Gmail, Youtube und Co direkt mit Vorwürfen zu belasten. Sicher, das Internet ist Content. Jede Seite die ich ansehe repräsentiert Daten. Macht da Gmail oder Youtube eine Ausnahme? Oder sind sie viel mehr “Vorreiter” von interaktiven Contents?

Anderes Beispiel: Ebooks – HTML neu erfunden

Ich sehe schon. Der Blogpost wird wieder wie gewohnt wirr. Ok, anders rum: Ebooks. Iteration 1: PDF – Früher waren Bücher in festen Formaten gesetzt: Eine Seite A4 feste Seitenränder, Kopfzeile, Fußzeile. Wie aus Büchern, Briefen, Formularen gewohnt. Wenn ihr mich fragt im Digitalen furchtbar. Auf dem Widescreen pure Platzverschwendung auf dem Handy ständig am scrollen. Iteration 2: epub – Ein ZIP Archiv mit Metainformationen und dem Text in HTML. Dynamische Layouts, Formatierung über CSS. Die Welt ist super. Aber damit zufrieden geben? Logik, Animation, Video? Ganz klar: Iteration 3: epub nähert sich dem HTML. HTML5 wird unterstützt, CSS Animationen, Javascript kann eingebunden werden. Eine wundervolle Welt voller animierter Kinderbücher oder interaktiver Schulbücher steht uns bevor.

Die Frage: Brauchen wir dann überhaupt noch ein Ebook-Viewer? Warum nicht viel mehr ein Content-Viewer? Anscheinend ist doch eh alles miteinander vermischt. Dieser Viewer muss ganz klar alle Formate unterstützen. Und interaktiv damit umgehen können. Warum nicht einfach ein Browser?

Aber nicht nur eBooks. Videos mit Metainformationen. Zusatzinformationen am Rand. Interaktive Kommentare und Bewertungen. Schlichtweg Content. Oder einfach Internet. Theoretisch wird uns genau das schon geboten.

Ich dachte mir erst: So ganz stimmt das nicht. Ein Dokument kann ich einpacken und mitnehmen. Ein Ebook ist in sich geschlossen. Aber es stimmt nicht. Gerade technische Ebooks enthalten viele Links zu Internet-Seiten. Sozusagen ist ein eBook eher ein Teil des Internets. Losgelöst von diesem. Geschlossen zum Mitnehmen. Eine herunterladbare Internet-Seite. Nicht anders bei Podcasts. Wer hat es sich nicht schon gewünscht den Link über den gerade diskutiert wird auf seinem Podcast-Client direkt zu sehen. Ein Foto mit angehängt zu bekommen welches erwähnt wird oder direkt das Musik-Stück angehängt zu bekommen welches als Melodie eingespielt wird?

Wir bewegen uns weg von einem Video, einem Buch oder einem Text hin zu einem ultimativen Dokumentenformat. Hin zu dem Internet.

Sicher man könnte vorbringen nicht jede Webseite ist herunterladbar. Aber vielleicht ist es auch gar nicht notwendig. Vielleicht ist das Herunterladen nur ein fehlgeschlagener Versuch Devices zu benutzen die nicht immer online sind. Schlechte Bandbreite durch Vorladen auszugleichen. Offline-Konsum auf Kosten von Vernetzung.

Der Weg dorthin

Meine Forderung? Seht eure Daten nicht an einen Konsumierungsform gebunden. Der eine liest die Webseite auf dem Fernseher, das Ebook auf dem Handy und vielleicht auch bald ein Video auf dem Ebook-Reader. Es muss ein Universalformat her, nein viel mehr muss das Universalformat auch universal genutzt werden. Verwendet HTML. Baut keinen Ebook-Reader sondern ein Browser, Baut kein Videoplayer sondern ein Browser.

Und unterbewusst geht sogar der Trend dahin. Thunderbird, Spotify, Songbird, Miro, … unzählige Programme integrieren bereits einen Browser. Aber zugegeben noch nicht so ganz wie ich mir das vorstelle. Ich nicht an ein Email-Programm integrierten Browser sondern einen Browser mit spezieller Email-Bedienung.

Notwendig sind dafür anpassbare Browser. Viel mehr als wir sie jetzt haben. Keine kleinen Plugins – wie bisher – die Tabs bunt machen. Minimale Browser mit komplett austauschbaren Interface, Bedienung und Workflows. Aber eines gemeinsam: Anzeige von Webseiten.

Sicher wäre es auch schick Webseiten downloadbar zu machen. Ich möchte eigentlich nicht das Video aus Youtube extrahieren um es mit im Auto anzusehen. Ich möchte die Seite offline speichern. Kommentare, Bewertung alles mit dabei. Unterwegs vielleicht sogar ein Kommentar schreiben und bei der nächsten Internet Verbindung posten. Sicher Ansätze wie Google Gears gab es. Nun gibt es HTML Local Storage. Aber ich rede von keinen komplexen API’s für die man Code schreiben muss. Ich denke eher an einem impliziten Features. So selbstverständlich als würde ich eine statische Webseite lokal speichern. Ein Teil des Internets temporär losgelöst und offline gespeichert. Das wäre mal ein Feature für HTTP 2.0 – und nicht nur schnellere Übertragung. Aber vermutlich sind wir eher mit allen Devices always-on, als dass sich mein Wunschdenken bewahrheitet.

Content Systeme

Bedeutet dies nun Facebook – stellvertretend für viele Webseiten – ist HTML und HTML ist gut. Somit ist es auch gut alle Daten in Facebook zu packen? Lassen wir Datenschutz und ähnliche, übliche Kritikpunkte außen vor. Betrachten wir Facebook als Content-System. So ist mein größter Punkt, dass Facebook die Daten natürlich nur rudimentär zur Verfügung stellt. Sicher, Facebook könnte daran arbeiten. Meinen Wünschen entsprechen. Ich schreibe vielleicht kein Buch und setzte es auf meine Webseite sondern ich schreibe anderweitigen Content und publiziere im Content-System Facebook. Und sei es nur für meinen eigenen Bekanntenkreis. Warum nicht. Auch wenn ich mir vielleicht liberalere Bedingungen vorstellen könnte unter denen mein Content veröffentlicht wird, ein Rechtemodell, dass Content auch wieder extrahiert werden kann und ich nicht den Besitz daran verliere oder keine lästigen Werbebanner auf den Kosten meiner Daten. Wenn mir Facebook als Content-System genügt warum nicht. Sicher gäbe es bessere Möglichkeiten aber Facebook bietet viele andere Vorzüge die für den ein oder anderen ein Grund sind darauf zu “publizieren”.

Fazit

Im Grunde ist es einfach: Als Content-System sollte man sich bemühen den Content auch zugänglich zu machen. Download, Mobile Seiten, vielleicht sogar Bezahlmodelle wie Flattr einbinden. Liberale Bedingungen wären natürlich schön. Zudem sollte der Content im Mittelpunkt stehen (vgl: desktop vs. mobil). Als Content-Ersteller kann ich nur sagen: Schreibt HTML. Macht euren Inhalt als Teil des Internets. Unabhängig von Format. Soweit wie möglich von pixelgenauer Darstellung trennen. Semantik, Design, Logik trennen. Schreibt gutes HTML. Und für Applikations-Ersteller: Schreibt Browser. Anpassbar und spezifisch in der Nutzung. Interoperabel und zukunftsorientiert. Unterstützt HTML mit allen Features und das gesamte Ökosystem welches sich darum gebildet hat.

Versteht man das Internet nicht mehr als eine Ansammlung schlechter Standards, fuchtbarer Programmierer, unzugänglichen Webseiten, Walled-Gardens – getrieben von Kommerz und Werbung – sondern ein Dokumentenformat. Ein Über-Word. Mit all den großartigen Features die uns das Web bringt. Von SVG bis Javascript, von Flattr bis Musicstreaming, von eindeutigen Dokumenten-Pfaden (URL’s) über Dokumentenübergreifenden Verbindungen (Hyperlinks) bis hin zur Maschinelle Verarbeitung – es ergibt sich ein tolles Bild von der Zukunft. Was meint ihr dazu?

Anmerkung: HTML ist primär auf Text ausgerichtet. Man kann Absätze definieren aber Formeln? Noten? Ich habe HTML als Beispiel gewählt. Eigentlich möchte man eine viel generelle Metasprache haben in der man beliebige Konstrukte wie Formeln und Noten beschreiben kann. Auch diese gibt es schon: XML. Über Namespaces kann man andere Beschreibungen einbinden die dann erklären wie eine Note oder Formel zu verstehen ist. MathML, SVG, GraphML, Atom, MusicXML oder auch XHTML sind Beispiele dafür. Allerdings kranken Browser an der Unterstützung von unpopulären Dialekten wie MathML. Schön wäre es wenn man auch gleich ein Standard-Aussehen mit definieren könnte. Dann muss der Browser nicht mehr MathML implementieren sondern nur eine generische Sprache die dann Semantik und Aussehen von MathML beschreibt. Dies kann natürlich beliebig erweitert werden wie zum Beispiel auf eine Metasprache zur Beschreibung von Kapitelmarken in Videos oder so. Beschreiben hatte ich die Idee schon einmal hier.

Comments:

(howto comment?)