Wer im Shopware-Umfeld arbeitet, begegnet dem Namen inzwischen überall: Das Meteor Design System ist Shopwares offene Sammlung aus Komponenten, Icons, Design Tokens und Gestaltungsregeln, veröffentlicht unter shopware.design und auf GitHub. Es liegt allen Produkten des Herstellers zugrunde, von der Administration bis zu den eigenen Anwendungen.
Der erste Gedanke dazu lautet meist: Ein Thema für Designer, vielleicht noch für das Frontend, jedenfalls nichts, was einen Shopbetreiber betrifft. Diese Einordnung war bis vor Kurzem vertretbar. Mit Shopware 6.7 stimmt sie nicht mehr, denn seitdem entscheidet Meteor darüber, wie eigene Erweiterungen im Backend aussehen und wie lange sie so bleiben.
Was ist ein Design System und wozu dient es
Ein Design System ist eine verbindliche Sammlung wiederverwendbarer Bausteine samt Regeln für ihren Einsatz. Dazu zählen Farben, Abstände, Schriftgrößen, Formularfelder, Schaltflächen und Meldungen. Anders als ein Design Manual beschreibt es nicht einzelne Seiten, sondern die Teile, aus denen sich jede Seite zusammensetzt. Der Nutzen liegt in der Wiederholbarkeit: Wer eine Schaltfläche aus dem System nimmt, bekommt Aussehen, Verhalten und Barrierefreiheit gleich mitgeliefert. Nichts davon muss erneut geklärt werden.
Bausteine statt fertiger Bildschirme
Das Prinzip dahinter ist nicht neu und im Atomic Design seit Jahren beschrieben. Neu ist, wer es betreibt. Ein Design System eines Herstellers ist kein Vorschlag, sondern die Grundlage seines Produkts. Anders als eine hausgemachte Sammlung entwickelt es sich mit jeder Version des Systems weiter und gibt den Takt vor.
Was Meteor in Shopware konkret umfasst
Meteor besteht aus vier Bausteinen, die getrennt veröffentlicht werden. Die Komponentenbibliothek liefert die Oberflächenelemente als Vue-Komponenten. Das Icon-Kit versammelt die Symbole an einer Stelle. Die Design Tokens geben Farben, Abstände und Typografie als CSS-Variablen aus, in einer hellen und einer dunklen Fassung. Das Admin-SDK schließlich dient dazu, eigene Apps in die Administration einzuhängen. Alle vier liegen im öffentlichen Repository auf GitHub. Dazu kommen Figma-Bibliotheken für die Gestaltung und die Schrift Inter als Voraussetzung.
Komponenten, Icons und Design Tokens
Der ganze Bestand steht als Open Source bereit und ist damit auch außerhalb von Shopware nutzbar.
Für die tägliche Arbeit ist ein anderer Punkt wichtiger: Wer eigene Oberflächen in der Administration ergänzt, arbeitet ab sofort mit diesen Bausteinen statt gegen sie. Das verkürzt die Individualentwicklung spürbar, weil Zustände, Fehlermeldungen und Tastaturbedienung bereits geklärt sind.
Warum das Thema mit Shopware 6.7 zur Terminfrage wird
Mit Shopware 6.7 ersetzt der Hersteller eine Reihe der bisherigen Admin-Komponenten durch ihre Meteor-Gegenstücke. Damit Erweiterungen nicht von einem Tag auf den anderen brechen, gibt es eine Brücke. Eine alte Komponente rendert weiterhin die bisherige Fassung, wenn man ihr ausdrücklich das Attribut deprecated mitgibt. Fehlt dieses Attribut, zeigt dieselbe Komponente in 6.7 automatisch die neue Meteor-Variante. Der Upgrade-Guide von Shopware führt das für jede betroffene Komponente einzeln auf.
Die Brücke heißt „deprecated"
Genau darin liegt der Punkt, der aus einem Designthema eine Wartungsaufgabe macht: Eine Erweiterung, an der niemand etwas ändert, sieht nach dem Update anders aus. Manchmal ist das unauffällig. Manchmal verschiebt sich ein Formular oder ein Zustand sieht anders aus als in der Schulung des Kunden. Die Brücke ist außerdem befristet gedacht, nicht als Dauerlösung. Shopware stellt für den Wechsel Anleitungen und ein Kommandozeilenwerkzeug bereit. Die Entscheidung nimmt beides niemandem ab: Umstellen oder bewusst auf der alten Fassung bleiben. Diese Entscheidung gehört in die laufende Betreuung eines Shops, nicht in das nächste Redesign.
Meteor ist damit weniger ein Angebot als eine Richtung, in die sich Shopware bewegt. Wer eigene Erweiterungen betreibt, kann sie mitgehen oder verschieben. Wer sie verschiebt, sollte wissen bis wann. Für Shopware-Projekte heißt das: Ein Design System ist keine Frage des Geschmacks. Es ist ein Fahrplan.