Eines der meist genutzten E-Commerce Systeme, Magento, hat angekündigt mit der Version 2.3 das bestehende Frontend-Template als veraltet zu markieren. Dies hatte zur Folge, dass darüber diskutiert wurde ob das neue Frontend, welches mit React gebaut wird, für kleine und mittlere Unternehmen in der Umsetzung noch erschwinglich ist bzw. ob Magento insgesamt sich damit vom KMU-Markt verabschieden möchte. Ein Kommentar von Flagbit zu der Entwicklung von Magento 2.3 und warum progressive Web Apps für KMUs auch eine Chance sind.

Grundsätzlich lässt sich feststellen das Magento schon seit Jahren als Ziel ausgegeben hat mehr Enterprise Kunden anzusprechen, um damit in die Kundensegmente von den großen Playern wie Hybris, Oracle Commerce, IBM WebSphere etc. vorzustoßen. Im Vorfeld der Übernahme durch Adobe hat Magento viel Aufwand in den Ausbau der eigenen Cloud gesteckt. Diese Cloud Commerce Plattform wurde nach der Übernahme direkt in die Adobe Cloud integriert und wird dort als weiterer Service den Adobe Kunden angeboten. Adobe hat damit seine Produktpalette komplementiert.

Parallel zu dieser Entwicklung sind progressive Web Apps auf dem Vormarsch die Web-Welt zu erobern. Leider denken viele Entwickler und/oder Entscheider in diesem Zusammenhang direkt an „Headless“-Lösungen. Mit „Headless“-Lösungen sind unabhängige Frontend-Lösungen gemeint, welche nur Mittels API-Calls mit dem Backend kommunizieren. Theoretisch kann das Backend oder einzelne Datenstrukturen getauscht werden ohne das Frontend anpassen zu müssen. Eine Headless-Lösung würde zwar den Bau eines progressiven Frontends unterstützen sind aber nicht zwingend Voraussetzung für progressive Web Apps.

E-Commerce Systeme oder Webseiten die sich den Titel „Progressive Web App“ verdienen wollen, müssen die von Google definierten Kerneigenschaften erfüllen. Keine dieser Kerneigenschaften setzt (zwingend) voraus, dass dies Headless erfolgen muss. Google beschreibt diese Kerneigenschaften mit den folgenden Stichpunkten:

• Progressive – Funktioniert für jeden User, egal welchen Browser er verwendet. Neue Funktionen werden, je nachdem ob der Browser diese Unterstützt, auch von der Web App „progressiv“ unterstützt.
• Responsive – Passt in jeden Formfaktor: Desktop, Handy, Tablet oder was auch immer als nächstes kommt.
• Connectivity independent – Mit Hilfe von Service-Workern soll die Web App unabhängiger vom Internet werden, damit sie auch Offline funktioniert und/oder bei schlechter Internetverbindung.
• App-like – Die Webseite soll sich wie eine App anfühlen weil das „App Shell Model“ eine Trennung von Funktionalitäten und Content vorsieht.
• Fresh – Die Progressive Web App soll mit Hilfe des Service Workers immer aktuell sein.
• Safe – Die Seite wird per HTTPS ausgeliefert. Das ist zwingend notwendig damit Service Worker überhaupt genutzt werden können.
• Discoverable – Die Web App soll als solche gefunden und identifizierbar sein. Siehe auch W3C manifest und Service Worker registration process.
• Re-engageable – Der User soll einfach und regelmäßig wieder zur App zurückkehren, dies kann z.B. durch Push-Notifications erreicht werden.
• Installable – Dem User soll es ermöglicht werden die Web App auf seinen Home-Screen zu installieren.
• Linkable – Die App soll per Link geteilt werden können, ohne das ein komplexe Installation notwendig ist.

Wenn wir diese Kerneigenschaften sehr streng auslegen, dann könnte mit Headless der Punkt „App-like“ gemeint sein, weil hier von einer strikten Trennung zwischen Funktionalität und Content gesprochen wird. Allerdings bieten viele Shop-Systeme und/oder auch CMS-Systeme schon sehr lange (Jahrzehnte) von Haus aus eine Trennung zwischen Content und Funktionen.

Als KMU stellt sich nun also die Frage: In welchen Situationen kann ich wie vorgehen, um von den modernen Möglichkeiten der progressiven Web Apps zu profitieren?

Situation 1: Wir sind ein KMU, welches einen gut laufenden Online Shop betreibt und wir sehen aktuell keinen Bedarf für ein Update oder größeres Redesign des Frontends.
Möglicher Lösungsweg für Situation 1: Wir integrieren einzelne Features wie zum Beispiel „Homescreen“ und „Push Notifications“ in unseren aktuellen Store. Die Auswahl der Features welche mit PWA-Technologie umgesetzt werden sollen, sollte anhand der größten Pain-Points der User oder dem größten möglichen Erfolg im Vergleich zum Aufwand gewählt werden.

Situation 2: Wir sind ein KMU, welches zum Beispiel die Geschwindigkeit der Kategorieseite radikal erhöhen möchte. Dazu wurde beschlossen die Kategorieseite komplett neu zu bauen. Möglicher Lösungsweg für Situation 2: Wir verwenden eine externe Middleware (zum Beispiel Lizards&Pumpkins) und bauen nur den Katalog als PWA und integrieren diese neue schnelle Kategorieseite in das E-Commerce System. Kernaussage soll sein, dass als Lösungsweg ein abgeschlossenes Feature als „einfache“ PWA gebaut wird. Denkbar wären auch Bereiche wie Retouren-Management oder Kundenaccount.

Situation 3: Unser KMU hat bereits beschlossen ein großes Update umzusetzen welches ein neues Frontend erfordert.
Möglicher Lösungsweg für Situation 3: Anstatt die komplette E-Commerce Landschaft umzustellen, identifizieren wir einzelne Produktgruppen oder einzelne Stores und setzen für eine kleinere Auswahl die von uns gewünschten PWA Features gerne auch mit Headless um. Kernaussage ist also: Von Grund auf neu, aber mit überschaubarem Scope. Sobald genug Praxiserfahrungen gesammelt wurden, werden die anderen Stores auf die neue E-Commerce Landschaft umgezogen.

Egal welches System Sie verwenden oder welche neue Technologie sich auftut, es gibt immer auch kostengünstige Wege diese für kleinere oder mittlere Unternehmen zu adaptieren. Um Vorreiter in einer bestimmten Branche zu sein wird man allerdings nicht um größere Investitionen herum kommen. Trotzdem sind wir der Meinung, dass KMUs durch geschicktes „Cherry picken“ von Features auch die eigene Kundschaft begeistern und binden können.