Die Grundidee hinter diesem Konzept: Die Trennung der Benutzeroberfläche, mit der die Kunden interagieren, vom Backend, welches sich um die Umsetzung der Funktionen kümmert – beides verbunden über eine flexible API. So sind Unternehmen, sprich Online-Händlern, keine Grenzen gesetzt, was die Customer Experiences angeht. Sie sind in keinster Weise an die Regelungen der Benutzeroberfläche gebunden, deren Ziel ein standardisiertes Web-Erlebnis aus schlichtem alten HTML und CSS im Hintergrund ist. Stattdessen sind sie völlig flexibel in Bezug auf Content, User Experience und sogar SEO.
Wer eine API hat, kann quasi eine unbegrenzte Anzahl von Frontend-Technologien nutzen: von Sprachassistenten oder Chatbots über Social-Media-Anwendungen und IoT-Geräte bis hin zu Autos, die mit dem Internet verbunden sind. Für eine API ist es irrelevant wer oder was die Informationen sendet und von ihr verlangt. Mit anderen Worten: Welche neuen Benutzeroberflächen und Geräte es in Zukunft auch geben wird, Unternehmen können sicher sein, dass ihre Plattform Inhalte an Touchpoints aller Formen und Arten liefern kann. Und: Sie müssen nicht für jeden neuen Touchpoint ein separates System betreiben und Informationssilos bauen.
Nicht jeder braucht (jetzt schon) ein Voice-Skill
Für diejenigen, die in die fabelhafte Welt der neuen Touchpoints eintauchen wollen, sieht die Zukunft rosig und vor allem vielfältig aus. Bei all der Begeisterung gilt es aber auch realistisch zu bleiben. Nicht jeder braucht einen Sprachassistenten für seinen Service – zumindest nicht im Moment. Die meisten Unternehmen werden auf eher „klassische“ Interaktion setzen, wie zum beispiel über den mobilen Webbrowser.
Viele haben argumentiert, dass ein mobiler Browser nur ein kleinerer Abkömmling der Desktop-Version ist. Das ist nicht zuletzt der Grund für den Erfolg und die Beliebtheit dynamischer, responsiver Webseiten in den letzten Jahren. Responsive Webseiten sind so strukturiert, dass sie dynamisch auf den Formfaktor und den Kontext reagieren, in dem sie verwendet werden. Greifen Menschen über einen Desktop-Browser auf eine Webseite zu, so wird diese in maximaler Auflösung angezeigt. Wenn die Kunden auf dem Smartphone oder dem Tablet surfen, werden die Elemente verkleinert und anders angeordnet, so dass sie bequem mit dem Zeigefinger gewählt werden können.
Die Kehrseite der Medaille: Der HTML/CSS-Code, der für die Darstellung dieser Arten von Websites notwendig ist, setzt auf dem Applikationsserver auf. Im E-Commerce werden Produktinformationen und Interface-Elemente wie Formulare und Buttons in Stücke von HTML/CSS-Code umgewandelt, die zum Browser übertragen und dann als Seite aufbereitet werden. Der mobile Browser hat dabei aber keinen großen Einfluss auf die Art und Weise, wie die Informationen dargestellt werden.
Blick auf die Client-Seite: Native Apps
Die nächste Evolutionsstufe für Marken und Händler bildeten native Apps. Diese Apps nutzen die Fähigkeiten der Hardware voll aus, ob Lokalisierungsfunktionen, Kamera oder Push-Nachrichten. Wenn sie nativ auf dem jeweiligen Gerät laufen, können sie Informationen meist schneller vermitteln als mobile Webseiten. Darüber hinaus können sie Daten lokal speichern, was bedeutet, dass diese auch dann verwendet werden können, wenn das Gerät selbst offline ist. In den App-Stores von Apple und Google Play finden sich viele native Apps, meist ergänzend zu der „einfachen“ mobilen Website eines Händlers.
Im Gegensatz zu den oben genannten Server-generierten Front-Ends sind diese Apps selbst Clients, die Design- und Interaktionsregeln sowie Funktionen enthalten. Natürlich brauchen diese Apps nach wie vor ein Pendant, um die nötigen Informationen zu erhalten. Doch anstatt vorgefertigte Stücke von Website-Code zu übertragen werden dort lediglich ‘rohe’, textgestützte Information ausgetauscht. Hier punkten wieder die headless Commerce-Plattformen, denn für sie ist eine native App nur ein weiterer Client, der Daten anfordert. Jedes Mal, wenn eine solche installierte App neue Informationen benötigt, öffnet sie einen Kanal und fordert sie von der API an – die Commerce-Lösung im Hintergrund kümmert sich um den Rest.
Der Vorteil liegt auf der Hand: Die Anwendung läuft schneller und flüssiger, da weniger Informationen ausgetauscht werden müssen und die App direkt auf die Hardware des Geräts zugreift. Die einzige Hürde, die es zu überwinden gilt, ist, dass Nutzer die App erstmal selbst installieren müssen, bevor sie mit der Marke interagieren können.
Progressive Web-Apps: Das Beste aus zwei Welten?
In jüngster Zeit konzentriert sich die Frontend-Entwicklung auf die sogenannten PWAs, progressive Web-Apps, die manchmal auch als Single-Page-Apps bezeichnet werden. Kurz gesagt handelt es sich dabei um Benutzeroberflächen, die die Vorteile von regulären, serverseitigen Websites und clientseitigen Apps vereinen. Sie enthalten JavaScript-Elemente, die sich um die dynamischen Aspekte der Benutzerinteraktion kümmern.
Eine PWA wird geladen, indem man eine Website in einem mobilen Browser öffnet – ganz wie beim Zugriff auf eine andere Seite. Im Gegensatz zu den regulären Seiten laden die PWAs jedoch einen Teil des JavaScript-Codes herunter, der sich wie native Apps verhält:
Zum Homescreen hinzufügen: Nutzer können eine Verknüpfung zur PWA auf dem Homescreen ihres Geräts hinzufügen. Dadurch wird ein App-Icon generiert, über das sie wie auf jede andere (native) App zugreifen können.
Push-Benachrichtigungen: Diese Funktion war lange auf native Apps beschränkt. In PWAs ist es nun auch möglich, Push-Benachrichtigungen zu nutzen, um mit Nutzern zu kommunizieren.
Offline-Funktionalität: PWAs haben einen Cache-Mechanismus, der ermöglicht, Teile der ‘rohen’ Informationen einer Quelle vorab zu laden, z. B. von der headless Commerce-Plattform. Sollte das Gerät die Internetverbindung verlieren, bleibt die PWA nutzbar.
In letzter Zeit hat sich ein gutes Ökosystem rund um diese PWAs entwickelt, so dass Frontend-Entwickler und UX-Ingenieure gleich anfangen können damit zu arbeiten, statt von der Pieke auf anzufangen. Frameworks wie ReactJS, AngularJS und Vue.js werden von Tag zu Tag beliebter. Es handelt sich dabei meist um OpenSource-Bibliotheken, die von Firmen wie Google und Facebook betreut werden. Einige dieser Technologien haben es bereits in den Mainstream geschafft und kommen bei internationalen Webseiten zum Einsatz, beispielsweise bei vielen Services von Google und YouTube, Electronic Arts und Coca-Cola.
Das Beste daran: Brauchen Unternehmen native Apps, können diese mit den gleichen Technologien gebaut werden, die hinter den Kulissen von PWAs arbeiten, indem sie neue Frameworks nutzen, beispielsweise React Native. Mit anderen Worten: Das durch den Bau von PWAs gewonnene Know-how ist in der Welt der IOS- und Android-Apps komplett anwendbar.
Separate Anwendungsschichten für mehr Kundennutzen
Unternehmen, die über digitale Wege neue Kunden anlocken und bestehende Kunden halten wollen, sollten sich die Darstellung nicht von der benutzten Technologieplattform diktieren lassen. Was zu Beginn des E-Commerce funktioniert hat – mit dem Ergebnis von integrierten, monolithischen Full-Stack-Suiten – ist nun ein Stolperstein, der Marken und Handel daran hindert, ihr volles Potenzial zu nutzen.
Vor allem Innovatoren und Visionäre müssen in der Lage sein, ihre Benutzeroberflächen genau so anzupassen, wie sie Markenbekanntheit schaffen wollen. Sie müssen mit neuen Frontends und Interaktionen experimentieren, ohne die Backend-Prozesse zu stören. Einfach gesagt: Sie müssen sich auf eine stabile kopflose Commerce-Plattform mit einer flexiblen API wie commercetools verlassen können, die diese Anwendungen antreibt und das Geschäft zukunftsfähig hält.
Möchten Sie mehr zu diesem Thema wissen? Lesen Sie weiter im Blogpost Wie Headless-Technologie die E-Commerce-Industrie verändert.