Websites werden heutzutage immer häufiger nach den Prinzipien von "Responsive Design" entwickelt, und das meist mit einem "Mobile First"-Ansatz. Das heißt, dass Internetseiten erst für mobile Geräte mit kleineren Displays und Touchbedienung gestaltet werden und danach für größere Displays (PC etc.). Die vom World Wide Web Consortium (W3C) zertifizierte Gestaltungssprache CSS 3 (Cascading Style Sheets) erlaubt es, das Layout an die jeweilige Displaygröße anzupassen.
Während auf einem großen Schirm Informationen mehrspaltig und mit Illustrationen dargestellt werden, beschränkt man sich beim Smartphone auf die wichtigsten Inhalte und zeigt diese einspaltig untereinander an. Dies geschieht über sogenannte Media Queries (siehe unten), mit denen man je nach Ausgabemedium andere Stylesheets auf das HTML-Dokument anwenden kann.
HTML5 propagiert nun auch erstmals SVG (Scalable Vector Graphics) als universelles Vektorgrafikformat, was ein weiterer Meilenstein ist beim Rückzug aus pixelgenau erstellten Webseiten, die im Zeitalter der mobilen Geräte nicht immer die idealen Ergebnisse erzielen. Eine kleine Tortengrafik beispielsweise benötigt vielleicht statt 32 KB (als PNG Bitmap) nur noch 4 KB als nichtkomprimierte SVG-Grafik und ist dann erst noch auf beliebige Größen ohne Qualitätsverlust skalierbar. Hochauflösende Displays zu unterstützen ist somit keine allzu große Herausforderung mehr.
Weitere Neuerungen, die mit HTML5 eingeführt wurden, sind unter anderem das Streaming von Audio und Video sowie weitere Schnittstellen (JavaScript-APIs) für Zusatzfunktionen innerhalb des Browsers. Dazu gehören unter anderem die Abfrage der geographischen Position (Geolocation) oder die browserbasierte Ablage von Daten. Diese Features eröffnen ganz neue Perspektiven für Webanwendungen und haben letztlich die Abkehr von Plug-ins wie Flash, welche gerade auf mobilen Geräten oft nicht zur Verfügung stehen, zur Folge.
Auch scheint sich mit HTML5 das Bewusstsein für die Interoperabilität verschiedener Browser stark verbessert zu haben, was die Entwicklungskosten im Web insgesamt merklich reduziert. Kurz: HTML5 und CSS 3 sind maßgeblich daran beteiligt, dass das Internet in der Hosentasche inzwischen allgegenwärtig ist. Wir kaufen unser Bahn- oder Kinoticket immer öfter per Smartphone. Auch kommen ständig neue Zahlungssysteme auf den Markt, die beispielsweise über Bluetooth oder NFC (Near Field Communication) funktionieren. Wir werden wohl in Zukunft immer häufiger mit unserem mobilen „Begleiter“ bezahlen. EC-Karte und das gute, alte Portemonnaie bekommen somit Konkurrenz.
Lesedauer: 5 Min
Doch was bedeutet das für die hochvolumige Dokumentenverarbeitung? Fakt ist: Immer noch werden jedes Jahr Milliarden von A4-Papierseiten produziert. Wir verschicken und erhalten Rechnungen, Lieferscheine, Mahnungen, Versicherungspolicen, Infobriefe etc. in gedruckter Form. Doch im B2B-Bereich wird immer häufiger auf den elektronischen Austausch von Dokumenten einschließlich deren Verarbeitung gesetzt (z.B. mit Formaten wie EDI oder UBL).
In Deutschland beispielsweise hat sich mit ZUGFeRD ein auf dem Format PDF/A-3 fußender Standard für den digitalen Empfang und Versand von Rechnungen etabliert – der übrigens auch im B2C-Bereich von Interesse ist. Das Grundprinzip von ZUGFeRD ist, dass eine PDF-Datei die Rechnung nicht nur visuell darstellt, sondern die Rohdaten des Dokuments in einem maschinell lesbaren, standardisierten XML-Format als Anhang (Attachment) mitführt, auf denen die visuelle Darstellung basiert. So können sowohl Mensch als auch IT die Rechnung ohne größere Anstrengungen interpretieren.
Auch in der Schweiz tut sich einiges in Sachen Digitalisierung. Dort unterstützen heute die meisten Banken den Empfang von E-Rechnungen. Diese kommen nicht mehr als klassischer Brief, sondern werden digital direkt ins eigene E-Banking-System übertragen, wo nur noch die Zahlung freigegeben werden muss. Das PDF der Rechnung kann via Link heruntergeladen werden. Einige Rechnungsteller haben sogar bereits begonnen, zusätzliche Gebühren für die Papierrechnung zu verlangen.
Viele größere Firmen bieten Portale an, auf denen ihre Kunden beispielsweise die letzten Rechnungen einsehen und als PDF herunterladen können. Das Problem dabei: Auch wenn diese Portale für mobile Geräte optimiert sind, muss sich der Kunde doch bei jedem einzelnen Rechnungssteller einen Zugang beantragen. Neben dem Passwort-Dschungel bedeutet das auch ein aufwändiges Zusammensuchen von Dokumenten aus allen möglichen Quellen.
Außerdem: A4 ist bei den geschilderten Beispielen nach wie vor das Basisformat und damit ungünstig, wenn es um mobile Geräte geht. Das Betrachten einer PDF-Datei auf einem Smartphone und auf kleineren Tablets macht eben wenig Spaß. Hier würde sich also die Darstellung des Dokuments mittels HTML5 anbieten. Nur würde das nun bedeuten, dass wir für jedes Dokument dann potenziell drei verschiedene Formate anbieten müssten: XML für Rohdaten, HTML5 für die mobilen Geräte und PDF für den traditionellen A4-Bereich.
Das bedeutet, dass für das HTML-Format zusätzliche Entwicklungskosten entstehen, wenn der Druckkanal wie gehabt weitergepflegt wird. Diese Kosten können in bestimmten Fällen reduziert werden, indem man PDF-Dateien nach HTML umwandelt. Dieser Ansatz wird allerdings nicht in allen Fällen zufriedenstellend funktionieren. Nicht alle Layouts lassen sich automatisch in eine sinnvolle HTML-Darstellung umsetzen.
Wie schön wäre es doch, Dokumente von Anfang an so zu produzieren, dass sie auf sämtlichen Geräten bzw. Kanälen sinnvoll dargestellt werden können? Noch besser: Rechnungen enthalten auch gleich die Zahlungsinformationen in einem standardisierten Format (z.B. ZUGFeRD, XML oder EDI/XML), so dass man die Überweisung direkt von seinem Smartphone veranlassen oder die Datei an ein E-Banking-System weiterleiten kann.
Idealerweise sollen solche Dokumente keinen Zugriff aufs Internet benötigen, da man ein Dokument gegebenenfalls auch in zwei Jahren noch anschauen will, wenn Firma "X" dann plötzlich "Y" heißt und die URL gewechselt hat. Das bedeutet: CSS-Stylesheets, Bilder, Schriften und auch der JavaScript-Code müssten in eine Datei eingebettet werden.
Zudem wäre in diesem Zusammenhang eine digitale Signatur wünschenswert - sowohl zur Verifizierung des Absenders als auch zur Kontrolle, dass die Datei nicht verändert wurde. Außerdem sollte das Dokument auch für Menschen mit körperlichen und kognitiven Einschränkungen voll und ganz zugänglich sein. Mit dem Format ePub („electronic Publication“) gibt es bereits einen Standard, der diese Anforderungen berücksichtigt. Obwohl es hauptsächlich als eBook-Format gesehen wird, wäre es für die multikanalfähige Darstellung von Dokumenten jedes Typs und Formats ideal.
Die aktuelle Version ePub 3.0 erlaubt beispielsweise die Deklaration von alternativen Präsentationsformen ein- und desselben Dokuments (z.B. das visuelle HTML5 und die Rohdaten als XML). Sogar ein PDF könnte man in den ZIP-basierten Container einbetten, auch wenn es keine ernstzunehmende Alternative ist.
Mit anderen Worten: Auf welchem Weg Dokumente versendet werden, ist letztlich nicht so wichtig. Im einfachsten Fall genügt eine E-Mail mit Anhang, allerdings kann der Absender nicht zuverlässig feststellen, ob das Dokument auch angekommen ist. De-Mail, IncaMail oder standardisierte HTTPS-Schnittstellen, die von Online-Archiven zur Verfügung gestellt werden, sind da sicher eine Alternative. Beim Rechnungssteller müsste man dann nur noch eine URL hinterlegen, die den Zielort für die eigenen Dokumente definiert, z.B. "mailto:erika.mustermann@test.org" oder "https://onlinearch.iv/erika.mustermann".
Das geschilderte Szenario ist nur ein Beispiel dafür, wie HTML5 zukünftig das Output-Management beeinflusst. Fakt ist, dass es beim Dokumentenaustausch immer mehr um den Inhalt geht und weniger um die Darstellung, schließlich sind die Daten das Wichtigste. Die Präsentation ist letztlich nur Mittel zum Zweck, und da deckt HTML5 eben sehr viel ab; so viel, dass es das klassische druckorientierte Output-Management unweigerlich auf den Kopf stellen wird.
Scalable Vector Graphics (SVG) ist eine vom W3C empfohlene Spezifikation zur Erstellung von komplexen, zweidimensionalen Vektorgrafiken in Dokumenten. Da SVG ein XML-basiertes Format ist, sind Inhalte von SVG-Dateien für computerunterstützte Übersetzung und andere Weiterverarbeitungen leicht zugänglich Sie können prinzipiell auch direkt mit einem Texteditor bearbeitet werden.
Die Mathematical Markup Language (MathML) ist ein Format zur Darstellung mathematischer Formeln im Internet.
Damit können Programmierer pixelgenaue Grafiken im Browserfenster erzeugen. Ergänzt um JavaScript lassen sich somit komplexe Animationen, Spiele und dynamische Geschäftsgrafiken erstellen, für die zuvor das Adobe-Flash-Format oder andere Plug-Ins notwendig waren.
Mittels des neuen Elements <video> lassen sich Videos in Websites einbetten, ohne externe Plugins wie Apple QuickTime oder Adobe Flash Player benutzen zu müssen.
Die neue JavaScript-Funktion „Geolocation“ ermöglicht es, einer Webseite den Aufenthaltsort eines Besuchers mitzuteilen, der mit einem mobilen Gerät darauf zugreift. Auf diese Weise können ortsbezogene Services angeboten und dem Nutzer der Webseite beispielsweise Geschäfte in seiner Nähe oder seine Position auf einer Karte angezeigt werden.
Mit HTML5 können Websites entwickelt werden, die auch offline nutzbar sind. Dafür muss der Webserver dem Browser des Besuchers lediglich mitteilen, welche Daten er hierfür laden muss. Eine Synchronisierung der Daten erfolgt automatisch, sobald der User wieder online ist.
Dieses Feature stattet Webseiten mit zusätzlichen semantischen Informationen aus und wandelt beispielsweise die Kontaktdaten in eine vCard um.
