Ein genauerer Blick auf die Mailgun-App: Teil 2 – Eine absolut triumphale Umsetzung

Als wir vor drei langen Jahren mit der Neuentwicklung der Mailgun-App begannen, haben wir viel Zeit in Machbarkeitsstudien, Planung und Tests investiert. Unser oberstes Ziel? Ein App-Erlebnis zu schaffen, das verschiedene Produkte aus unserem Portfolio präsentiert, eine einfache Navigation zwischen ihnen ermöglicht und diese Produkte effizient über eine einzige Infrastruktur unterstützt.

Der Umfang dieses Projekts war so groß, dass wir mehr als einen Beitrag benötigten, um zu beschreiben, was die Neuentwicklung vorangetrieben hat, wie wir vorgegangen sind, was wir gelernt haben und was die Implementierung dieser neuen Technologie für unsere Zukunft bedeutet. Im ersten Teil dieser epischen Reise, „Teil 1: Exzellente Ideen“, sind wir in die Vergangenheit gereist, um unseren Prozess zu beleuchten. Wir haben unsere Überlegungen sowie unsere Gründe für dieses Unterfangen mit Ihnen geteilt und Sie durch die Herausforderungen geführt, von denen wir wussten, dass sie auf uns zukommen würden.

In „Teil 2: Eine absolut triumphale Umsetzung“ werfen wir nun einen Blick hinter die Kulissen und zeigen Ihnen, wie wir dieses Projekt implementiert haben, wie unsere Teams zusammengearbeitet haben und welche Rolle das Design in unseren Überlegungen gespielt hat.  Es gibt Drama, es gibt Migrationen … und wahrscheinlich ein paar Science-Fiction-Anspielungen zu viel. Begleiten Sie uns auf dieser Reise.

Der Anstoß zur Aktualisierung der Mailgun-App ergab sich aus den Einschränkungen unserer bisherigen Infrastruktur, insbesondere unserer Polyrepo-Organisation, bei der jedes Frontend-Projekt über ein eigenes Repository verfügte, ungeachtet der Tatsache, dass sich in vielen Projekten dieselben Aufgaben wiederholten. Was bedeutete das für unsere Teams? Zunächst einmal war das Auffinden von bestimmtem Code oder Fehlern in etwa so einfach wie Deckards Jagd nach abtrünnigen Replikanten in einer dicht besiedelten, dystopischen Stadt.

Die Verwaltung mehrerer Repositories mit redundanten Funktionen verlangsamt die Reaktionszeiten und bindet Ressourcen. Unsere Lösung? Die Umstrukturierung in eine modulare Monorepo-Struktur. Um es mit den Worten von Blade Runner auszudrücken: Anstatt Replikanten in einer riesigen Stadt zu jagen, navigieren wir nun innerhalb einer einzigen Megastruktur, in der Projekte in Modulen organisiert sind und Replikanten durchsuchbar werden.

Dieser Aktionsplan erforderte die Implementierung neuer Tools in unseren Stack, ein neues Erscheinungsbild für unsere Benutzeroberfläche und die Verwaltung großer Mengen an veraltetem Code. Wenn Sie uns eine Paraphrase erlauben: „Der Mensch hat seinen Meister gefunden“ … und jetzt ist es das Problem der Entwicklungsabteilung.

Einer der ersten Schritte bei der Einrichtung unserer neuen App bestand darin, einen Weg zu finden, so viel wie möglich von unserem alten System wiederzuverwenden, damit wir nicht alles neu entwickeln mussten. Wir wollten jedoch nicht weiterhin den Support für all unsere veralteten Abhängigkeiten aufrechterhalten. Wir brauchten eine Möglichkeit, unseren bestehenden Code so zu verpacken, dass er von der neuen Infrastruktur nicht abgelehnt wird.

Module Federation ist eine Methode, um einen Code-Block (in diesem Fall unsere gesamte alte App) als singuläres, importierbares Asset zu definieren, das entweder in sich geschlossen ist oder so eingerichtet werden kann, dass es Assets mit den konsumierenden Anwendungen teilt. Module Federation bot eine Lösung und ermöglichte es uns, den bestehenden Code neu zu verpacken, damit er von der neuen Plattform genutzt werden konnte, ohne Kompromisse bei all den neuen Funktionen einzugehen, die wir geplant hatten. Der Großteil unseres Entwicklungsteams konnte weiterhin Fehler beheben und Aktualisierungen an unserer alten Codebasis vornehmen, und die neue App erhielt diese automatisch mit.

Um dies zu verwirklichen, mussten wir eine deklarative Routing-Middleware entwickeln, mit der wir den Traffic zwischen der alten und der neuen App steuern konnten. Wir werden den alten Code nach und nach auf die neue Plattform portieren, aber bis dahin bedeutete diese seitenbasierte Routing-Lösung, dass wir nahtlos neue Funktionen einführen konnten – ohne die Kopfschmerzen, alles auf einmal neu schreiben zu müssen. Da wir die Regeln bereits definiert hatten, erleichterte dies die Änderung und Pflege des Routings innerhalb unserer Anwendung.

Zusätzlich zu den groß angelegten Migrationskomponenten mussten wir auch die Migration und Anpassung bestehender Prozesse im Zusammenhang mit Funktionen herausfinden, die in der neuen App für alle, die sie nutzen, weiterhin in gewohnter Weise funktionieren mussten.

Bisher haben wir einige der übergeordneten Elemente wie Speicher- und Ressourcenverwaltung beleuchtet. Bei diesem Projekt handelte es sich jedoch um eine komplette Neuentwicklung der Mailgun-App, die bereits funktionierende, für die Kundschaft bestimmte Prozesse enthielt, die wir entweder schützen oder verbessern mussten.

Der Anmeldeprozess für die App ist ein gutes Beispiel dafür, wie wir aktuelle Modelle evaluieren, teamübergreifend arbeiten und unseren neuen Stack implementieren mussten. Wenn wir ein Projekt für die nächste Aktion aufschlüsseln, stellen wir uns immer ein paar Fragen:

1. Wie planen wir derzeit die Beschaffung der Daten?

Strategie: Dokumentation der aktuellen Anmelde- und Kontoerstellungslogik für den bestehenden Mailgun-Prozess. Dies würde uns nicht nur dabei helfen, unsere bisherigen Prozesse zu archivieren, sondern auch genau zu analysieren, wie wir das aktuelle System verändern würden, um die Grundlage für unser Update zu schaffen.

2. Was sind die Schritte von unserer aktuellen Iteration zu unserem gewünschten Zustand?

Strategie: Nachdem wir unsere Aktionen dokumentiert und geplant hatten, mussten wir unsere Wissensdatenbank verbessern. Wir konzentrierten uns darauf, die Konventionen und Möglichkeiten des React-Frameworks zu erlernen, das wir verwenden wollten, um serverseitiges Rendering und zusätzliche Funktionen zur Unterstützung unserer Effizienz zu ermöglichen.

3. Welche Zuarbeit wird von anderen Teams benötigt?

Strategie: Ausbau der Benutzeroberfläche. Da wir im Grunde zwei eigenständige Produkte zu einer Produktreihe mit gemeinsamer Infrastruktur zusammenführten, mussten wir die Benutzeroberfläche gleichzeitig mit den Produktänderungen ausbauen. Das bedeutete, dass die meisten Updates gleichzeitig auch Redesigns sein würden.

Unser primäres Ziel war es, unsere Produkte – Mailgun und Mailgun Optimize – voneinander abzugrenzen, ohne zwei separate Infrastrukturen für deren Support aufzubauen. Man könnte sich fragen, warum man sie überhaupt trennen sollte. Warum nicht einfach die Produkte zusammenlegen, wäre das nicht einfacher? Nun, nicht wirklich. Unsere Produkte erfüllen ganz bestimmte Zwecke, und der Kauf eines Produkts bedeutet nicht, dass unsere Kundschaft gleich alle kaufen muss. Außerdem war das oberste Ziel bei der Neuentwicklung der Aufbau einer Infrastruktur, die das Hinzufügen weiterer Produkte in der Zukunft unterstützt, ohne die Backend-Funktionalität zu beeinträchtigen oder eine Situation zu schaffen, in der die Produkte für die Nutzerschaft schwer zu navigieren sind.

Die Lösung: Design. Das bedeutete, neue Standards für unsere Mailgun- und Mailgun Optimize-Apps in Bezug auf Illustrationen, Markenfarben und Textformatierung zu setzen. Es bedeutete auch, das Marketing an die Art und Weise anzupassen, wie wir über unsere Produkte sprechen und wie sie zusammenarbeiten.

Als wir mit dem Ausbau des Designprozesses begannen, mussten wir die gemeinsamen Bereiche der App den app-spezifischen Bereichen gegenüberstellen. Funktionen wie die Abrechnung und der Anmeldeprozess wären gemeinsame Bereiche im Gegensatz zu den unabhängigen Bereichen der Benutzeroberfläche, die unseren individuellen Produkten dienen.

Wir begannen bereits 2021 damit, uns den Bereich der Abrechnung anzusehen und konzentrierten uns auf die Logik, wie wir damit umgehen wollten, dass die Kundschaft ein einziges Abrechnungskonto haben kann, das die Verwaltung und Anpassung mehrerer Produkte unterstützt. Dies gab die Richtung dafür vor, wie wir vorgehen und Funktionen wie die Abrechnung oder unseren Anmeldeprozess aus der Perspektive der Zusammenführung mehrerer Produkte analysieren würden.

Wir haben alle Touchpoints erfasst, die entweder auf einen gemeinsamen Bereich oder auf einen produktspezifischen Bereich innerhalb der App angewiesen sind. Dazu gehörten Elemente wie eine linke Navigation, die produktspezifisch sein und produktspezifische Einstellungen enthalten sollte, gleichzeitig aber sicherstellte, dass gemeinsame Bereiche innerhalb der App denselben Mustern folgten.

Wir haben umfangreiche Wettbewerbsrecherchen sowie allgemeine Trendanalysen zu Designmustern durchgeführt, um zu sehen, wie der Wechsel zwischen Produkten innerhalb einer einzigen App heute gehandhabt wird und was im Hinblick auf die Anforderungen in der oberen Navigation sinnvoll war.

Nicki Snyder

Als Nächstes haben wir uns Elemente der User Journey angesehen, um die Designstruktur zu entwerfen sowie Farbschemata festzulegen, die dabei helfen würden, das Nutzererlebnis zu optimieren. Wir ließen uns dabei von zwei Fragen leiten:

1. Welchen Flow würde eine Person durchlaufen, wenn sie sich nun in einer einzigen App anstatt in zwei getrennten Apps bewegt?
2. Wie planten wir, den Design-Flow rund um eine bestimmte Funktion in der neuen App zu handhaben und anzupassen?

Wir entwarfen Designs mit unterschiedlichen Farben und Platzierungen, um das Publikum zu Interaktionen innerhalb der App zu leiten, und führten anschließend User-Tests durch, um die Wege der Nutzerschaft zu beobachten und zu validieren. Wohin navigierten die Testpersonen? Was verrieten uns ihre Mausbewegungen über eventuelles Zögern? Was hatten sie erwartet, zu sehen?

Anhand dieser User-Tests konnten wir die Designelemente weiter verfeinern, um die Navigation so zu optimieren, dass sie für unsere Nutzerschaft intuitiv verständlich ist. Danach wurde eine Beta-Version für ausgewählte Personen eingeführt, mit der wir Daten aus echten Sessions sammeln konnten, um zu verstehen, was gut funktionierte und wo noch nachgebessert werden musste.

Der Austausch der visuellen Assets diente einerseits der Navigation und andererseits der Vereinheitlichung. Die Gestaltung der Navigationsmenüs mit unserer markenkonformen Farbpalette mag wie ein rein ästhetisches Bedürfnis erscheinen, aber uns war klar, dass wir damit den gestalterischen Rahmen dafür schufen, wie unsere Produkte künftig innerhalb eines gemeinsamen Bereichs unterschieden werden.

Wir haben eine Navigationsstruktur geschaffen, die nicht nur für Mailgun und Mailgun Optimize skalierbar ist, sondern künftig auch für unsere anderen E-Mail-Produkte.

Nicki Snyder Director of Experience Design, Product

Produkt-Icons ermöglichen eine eigenständige Markenwahrnehmung, ohne dass die Anzeige der vollständigen Logos zur Markenverwirrung führt. Dies würde uns zudem die Möglichkeit geben, die Markenbekanntheit für andere Produkte in unserem Portfolio zu steigern, indem wir über deren Icons auf sie verlinken. Durch das Hinzufügen eines Erkunden-Bereichs (Explore) in der App, in dem Personen zwischen den Produkten wechseln können, sind wir in der Lage, Cross-Selling-Potenziale zu nutzen und auf unser gesamtes Produktangebot aufmerksam zu machen.

Und schließlich fanden wir es als Team großartig, der neuen, frischen Technologie einen ebenso neuen, frischen Look zu verpassen, um die Wirkung all unserer Neuentwicklungen noch weiter zu verstärken.

Anwendungen dürfen nicht stagnieren, und Portal wird sich im Laufe der Zeit weiterentwickeln. Genau das war der Sinn und Zweck, etwas mit einer Logik und Infrastruktur aufzubauen, die auf Skalierbarkeit ausgelegt ist. Welche Änderungen erwarten wir also als Erstes?

• Verfeinerung der Deployment-Architektur: In „Teil 1: Exzellente Ideen“ haben wir über die Menge an Code gesprochen, den wir im letzten Jahrzehnt geschrieben haben – tausende von Zeilen – und genau wie die schrittweise Portierung dieses Codes Zeit in Anspruch nehmen wird, braucht es auch Zeit, unsere bisherigen Deployment-Prozesse einzustellen. Das bedeutete, dass wir Portal so entwickeln mussten, dass es mit zwei Deployment-Prozessen funktioniert: unseren alten Prozessen und unserem neuen Build mit Cockpit – was natürlich das einfachste Unterfangen aller Zeiten war … Es war ein Albtraum, zwei Deployment-Prozesse. Wir sind eben durch und durch ambitioniert.
• Verwaltung mehrerer Codebasen: Während wir daran arbeiten, unseren Code schrittweise zu portieren, müssen wir weiterhin mehrere Codebasen verwalten und Code aus verschiedenen Produktbereichen übertragen, bevor wir eine Vereinheitlichung erzielen können.

Portal durchlief sowohl User-Tests als auch die Beta-Phase, sodass wir alle Fehler finden und beheben konnten – das hat noch nie jemand in der Softwareentwicklung behauptet.

Das Redesign der App wurde durchgeführt, um sowohl unserer Nutzerschaft zu dienen als auch unseren internen Teams, die die App verwalten, das Leben zu erleichtern. Daher implementieren wir Feedback aus internen und externen Beobachtungen sowie Kommentaren. Wir sind mit der Absicht angetreten, dass sich kein Prozess verschlechtern würde und dass das App-Update nicht einen Prozess auf Kosten der Qualität eines anderen priorisiert. Und wir sind zuversichtlich, dass alles genauso gut ist – oder sogar besser – als in unserer alten Version.

Wie beendet man einen Beitrag, wenn das Projekt noch andauert? Die Mailgun-App hat die Beta-Phase erst vor Kurzem verlassen, und wir nehmen regelmäßig kleinere Verbesserungen vor, während wir größere Releases planen, die von dieser anfänglichen Neuentwicklung unterstützt werden. Bill und Ted würden sagen: Seid exzellent zueinander und feiert schön weiter. Im Entwicklungsjargon bedeutet das: Wir machen weiter und wir iterieren.

Dieses Projekt markiert einen wichtigen Meilenstein bei der visuellen Trennung unserer Produkte Mailgun und Mailgun Optimize innerhalb der App. Es bedeutet außerdem einen technologischen Wandel und eine neue Herangehensweise an unsere Frontend-Entwicklung. Es geht aber nicht nur um ein schönes Design – wir haben uns auch auf die Leistung konzentriert, um unsere Releases klein und agil zu halten. Die mit dieser Neuentwicklung eingeführten Änderungen sind das Ergebnis einer großartigen Teamleistung, die es uns ermöglicht, uns von unserem veralteten Frontend-Monolithen zu verabschieden.

Ohne die Hilfe unseres unglaublich talentierten Teams hätten wir das nicht geschafft, und wir wollten diese Serie nicht beenden, ohne ihnen unseren besonderen Dank auszusprechen.

• Core-UI-Team: Nando Peña, Matt Leong, Matthew Prestlien
• Growth-Team: Keith Cruz, Ryan Little, Jorge Miramontes, Mazen Abdul
• Mailgun Optimize-Team: David Ortiz, Dannon Gilbert, Jeffrey Jurgajtis, Peter Trinder
• Mailgun-Team: Celeste Rance, Jonathan Kruse, Iqbal Singh, Levi Trejo, John Badali, Chris Farmer, Nicki Snyder (Design)
• Executive Sponsor: Josh Odom

Dieses Projekt begann als Graswurzelbewegung innerhalb von Mailgun und wuchs, als der Funke auf andere Teams übersprang. Heute unterstützt unsere aktualisierte App ein optimiertes Nutzererlebnis und eine verbesserte Developer Experience. Aber wir sind noch nicht fertig. Wir sind nie fertig.

Möchten Sie einen Blick hinter die Kulissen werfen und unsere Geschichten verfolgen, während wir weitere großartige Dinge auf den Markt bringen? Abonnieren Sie unseren Newsletter, um immer auf dem Laufenden zu bleiben.

Autor: Nando Peña Nando Pena is a Software Developer IV at Sinch Mailgun. He is a front end developer focusing on our core UI technology and experiences. He writes to share stories and experiences about developer projects.