Webkomponenten für American Express

Der Guide-Bereich von American Express erklärt Kartenprodukte und Finanzthemen in redaktionellen Seiten. In diese Seiten sollten Werkzeuge eingesetzt werden, die mehr können als Text: vergleichen, rechnen, Produkte übersichtlich zeigen. Die Seiten selbst, ihr Aufbau und ihr Betrieb lagen nicht bei uns.

Daraus folgt die Grundbedingung dieses Falls. Eine Komponente läuft in einem Dokument, das ihr nicht gehört, auf Geräten, deren Breite sie nicht kennt. Jede Komponente bringt deshalb ihr Markup, ihre Darstellung und ihre Daten mit. Was sie von der Zielseite trotzdem erwartet — etwa eine bestimmte Bibliothek —, ist ausdrücklich als Voraussetzung benannt, statt stillschweigend angenommen zu werden.

Batunet war dabei für die technische Umsetzung und Pflege zuständig, eingebunden in eine Projektkette; Vertragspartner von American Express war Batunet nicht. Inhalte, Konditionen und Markenassets kamen nicht von uns.

Ein Vergleich mit fester Reihenfolge beantwortet die Frage des Anbieters. Hier liegt die Gewichtung beim Leser: Für mehrere Kriterien stellt er in drei Stufen ein, wie wichtig ihm jedes ist. Daraus entsteht je Karte ein Punktwert aus Gewicht und Merkmalswert. Zwei Kriterien tragen einen festen Ausgleichsfaktor, damit sie das Ergebnis nicht allein durch ihre Größenordnung bestimmen.

Der Punktwert selbst sagt niemandem etwas. Angezeigt wird deshalb ein Prozentwert gegen die bestplatzierte Karte. Ist nichts gewichtet, greift eine feste Ausgangsreihenfolge statt einer zufälligen. Ein Filter trennt passende von nicht passenden Karten, ohne diese auszublenden — sie erscheinen abgesetzt unter der Trefferliste.

Auf breiten Bildschirmen stehen die Karten nebeneinander und öffnen eine Detailansicht. Auf schmalen Bildschirmen wird die Liste zum Karussell, und der Antragslink folgt der Karte, die gerade in der Mitte steht.

2025 kam ein zweites Werkzeug hinzu: ein Direktvergleich zweier frei gewählter Karten über elf Kategorien, von Gebühren bis zu Reise- und Versicherungsleistungen.

Die amtliche Teuerungsrate beschreibt einen Durchschnittshaushalt. Wer wenig fährt und viel heizt, erlebt eine andere Rate — nicht weil die Zahl falsch wäre, sondern weil sie nach einem fremden Warenkorb gewichtet ist.

Der Inflationsrechner nimmt deshalb die amtlichen Indexreihen, den Gesamtindex und neunzehn Ausgabenkategorien, und gewichtet sie nach den Ausgaben, die jemand selbst einträgt. Für jeden Monat entsteht ein persönlicher Indexwert als gewichtetes Mittel; die Jahresrate ergibt sich aus dem Vergleich mit dem Wert zwölf Monate zuvor. Ein Diagramm zeigt persönlichen und amtlichen Verlauf nebeneinander, auf Wunsch zusätzlich eine einzelne Kategorie.

Der eigentliche Aufwand liegt um die Formel herum. Beträge werden so eingegeben, wie Menschen über Geld denken: in Euro, ohne Nachkommastellen. Zu jeder Kategorie zeigt der Rechner einen Richtwert aus einer Standardgewichtung, bezogen auf die angegebenen Gesamtausgaben. Nicht zugeordnete Ausgaben laufen in eine eigene Restkategorie, und das Ergebnis wird mit jeder Eingabe neu berechnet. Übersteigen die Kategorien die Gesamtausgaben, zeigt der Rechner einen Hinweis statt einer Zahl, die es nicht geben kann.

Die übrigen Bausteine rechnen nicht. Eine Vergleichstabelle stellt mehrere Karten Zeile für Zeile gegenüber und bekommt auf schmalen Bildschirmen einen eigenen Aufbau statt einer verkleinerten Fassung. Eine mobile Produktnavigation klappt am Bildschirmrand auf. Eine fixierte Leiste am unteren Rand öffnet eine Übersicht mit Detailansicht, die sich per Klick, über den Hintergrund oder mit Escape wieder schließt und auf schmalen Bildschirmen als Karussell läuft.

Die Aktionsmodule der ersten Generation waren statisches HTML und CSS in drei Varianten — als Liste, als kompaktes Menü und als Kartenraster. Technisch sind diese Bausteine schlicht. Ihre Kosten entstanden an anderer Stelle: Dieselben Produktangaben standen in mehreren Modulen, jedes in einer eigenen Ablage mit eigener Historie.

Die Antwort war keine weitere Komponente, sondern eine Ebene darunter: eine Anwendung auf Basis von Symfony 7.1, in der Produktangaben und Komponenteninhalte als Daten liegen statt als Quelltext.

Das Modell ist klein gehalten. Ein Produktdatensatz trägt die Angaben, die überall gebraucht werden — Name, Bild, Verweise. Je Komponente gibt es benannte Feldwerte. Welche Felder ein Komponententyp kennt, steht in einer deklarativen Konfiguration, zuletzt für rund zwanzig Typen. Ein neuer Typ bleibt so eine Konfigurationsfrage und wird keine Modelländerung.

Feldwerte können auf Produktangaben verweisen; beim Rendern werden diese Verweise aus dem Produktdatensatz ersetzt. Eine geänderte Angabe wirkt deshalb in jeder Komponente, die sie nutzt, statt in jeder Datei einzeln nachgezogen zu werden.

Ausgeliefert wird serverseitig gerendert: Die Vorlage einer Komponente wird mit ihren Daten zu JavaScript, das die Zielseite einbindet. Davor steht eine Vorschau, die dieselbe Komponente in verschiedenen Bildschirmbreiten zeigt. Gepflegt wird in einer Redaktionsoberfläche mit Anmeldung und Rollenbeschränkung.

Der Übergang lief in Stufen. Zuerst wurden Inhalte per CSV-Datei importiert, später in einem Datenmodell mit Redaktionsoberfläche gepflegt. Bestehende Bausteine, darunter der Kreditkartenvergleich, wurden in die Anwendung übernommen — ihre Rechenlogik blieb, die Daten kommen seitdem vom Server.

Die Arbeit verlief nicht als Projekt mit Anfang und Abnahme, sondern als laufende Weiterentwicklung. Die Versionshistorie reicht vom 7. Dezember 2022 bis zum 17. März 2026 und zeigt zwei Generationen: zuerst eigenständige Einbettungskomponenten, dann eine zentrale Anwendung, in die bestehende Komponenten übernommen wurden.

Rückblickend ist nicht der einzelne Baustein der interessante Teil, sondern der Übergang. Für eine Handvoll Module wäre eine eigene Verwaltungsanwendung überzogen gewesen: Sie kostet Betrieb, Pflege und Einarbeitung, bevor sie etwas spart. Mit mehreren Komponenten, die dieselben Produktangaben tragen und sich laufend ändern, kippt die Rechnung.

Übernommen wurde schrittweise, Komponente für Komponente, über mehrere Monate. Möglich war das, weil die Bausteine schon vorher getrennt vorlagen. Die Rechenlogik des Vergleichs etwa blieb beim Umzug unverändert; ausgetauscht wurde die Herkunft der Daten.