GUI-Redesign nach Continuous-Delivery-Prinzipien
Beim Redesign einer Benutzeroberfläche im Rahmen eines Continuous-Delivery-Prozesses ist auf vieles zu achten, um den Nutzer nicht zu verschrecken. Mit etwas Vorbereitung kann die Umgestaltung jedoch gelingen.
- Martin Aschoff
Die Entwicklung von Software nach den Continuous-Delivery-Prinzipien ist heutzutage nichts Besonderes mehr. Mit bewährten Entwicklungsmustern wie Gradual Feature Release, Feature Toggles oder Branch by Abstraction sowie automatisierten Build-, Test- und Deployment-Prozessen ist die Entwicklung von Software, die jederzeit bereit zur Veröffentlichung ist, mittlerweile vergleichsweise problemlos umsetzbar.
Anders gestaltet sich die Sache allerdings, wenn nicht die Entwicklung einzelner Features, sondern das komplette Redesign einer Anwendungsoberfläche ansteht. Eine GUI lässt sich nicht inkrementell Feature für Feature umstellen und dabei regelmäßig veröffentlichen, denn das Resultat wäre eine unansehnliche Bedienoberfläche mit inkonsistenter Bedienung.
Am Thema GUI-Redesign kommen Entwickler von Software mit grafischer Oberfläche jedoch nicht vorbei. Spätestens nach drei bis fünf Jahren haben sich erfahrungsgemäß die Sehgewohnheiten und die Erwartungen der Nutzer an eine Bedienoberfläche so stark geändert, dass eine Neugestaltung der GUI erforderlich wird. Der Grund dafür ist unter anderem in der ständigen Weiterentwicklung der GUI-Konzepte (Flat Design, Material Design und Card Layouts) und -Patterns (Expandable Inputs, Infinite Lists, Progress Steps, Slideouts und Walkthroughs) und ihrer schnellen Umsetzung durch die Entwickler von Social-Media-Apps und Consumer-Websites zu sehen. Durch das hohe Innovationstempo legen sie die Messlatte für eine moderne Benutzeroberfläche ständig höher.
Nicht nur die steigenden Anforderungen bezüglich Usability und User Experience (UX) sind es, die regelmäßig GUI-Redesigns anstoßen. Auch Trends wie das derzeit angesagte Flat und Material Design wollen berücksichtigt werden, möchten Entwickler mit ihren Projekten nicht einen – zumindest optisch – altbackenen und rückständigen Eindruck vermitteln. Besonders Entwickler von Webapplikationen sind in der Hinsicht gefordert, denn die Updatezyklen der Browserhersteller sind besonders kurz. So soll eine moderne Web-GUI mittlerweile ein responsive Layout mit verzerrungsfreier Skalierung und Icon Fonts bieten, die Bedienung per Touchscreen unterstützen, Daten lokal im Browser persistieren und möglichst auf das Neuladen von Webseiten verzichten. Die technischen Herausforderungen an ein GUI-Redesign sind dementsprechend hoch.
Außerdem bringt Continuous Delivery neue organisatorische und prozessuale Herausforderungen in die moderne Softwareentwicklung. All das darf die Erfahrung der zahlenden Kunden mit der Software jedoch nicht beeinträchtigen. Schließlich lässt sich ihnen schwer vermitteln, dass die Bedienoberfläche in den nächsten Monaten schrittweise umgebaut wird und es daher zu fehlerhaften Darstellungen kommen kann.
Eine Option wäre, das GUI-Redesign durch einen eigenen Entwicklungszweig (Feature Branch) im Rahmen der CD umzusetzen. In ihm können Entwickler in aller Ruhe die neue GUI erarbeiten und den Branch später mit dem Main Trunk zusammenführen. Dabei gibt es jedoch zwei Probleme: Zum einen wird der Feature Trunk mehrere Monate parallel zum Main Trunk laufen, sodass ständig Synchronisationen zwischen beiden Zweigen erforderlich sind, da die Entwicklung der Software während des Redesigns nicht stehen bleibt. Zum anderen werden die Änderungen des GUI-Redesigns so umfangreich sein, dass beim Zusammenführen von Feature Branch und Main Trunk mit jeder Menge Merge-Konflikten zu rechnen ist. Das wiederum kann dazu führen, dass der Main Trunk entgegen der CD-Philosophie über mehrere Wochen nicht für ein Release bereit ist.
Der vorliegende Beitrag behandelt daher ein alternatives Entwicklungsmodell für das GUI-Redesign in einer CD-Umgebung. Es basiert auf den Erfahrungen des Autors mit der Umgestaltung der Bedienoberfläche einer umfangreichen Webapplikation, die als Lizenz- und SaaS-Angebot vertrieben und in einem Continuous-Delivery-Prozess entwickelt wird.
Schlau zerlegt
Ziel muss es sein, das Redesign so weit aufzuteilen, dass der Umfang dessen, was tatsächlich an einem Stück umzustellen ist, so gering wie möglich ausfällt. So lassen sich Inkonsistenzen durch eine partielle Umstellung vermeiden und Entwickler haben die Chance, schnell zur inkrementellen Weiterentwicklung zurückkehren zu können. Bei der Umsetzung können aus der CD-Entwicklung bekannten Design Pattern wie Gradual Feature Release, Feature Toggle und Minimum Viable Product (MVP) helfen.
Ein GUI-Redesign lässt sich in der Regel in zwei voneinander unabhängigen Dimensionen zerlegen: Zum einen in der Breite, die durch den Funktionsumfang der Software bestimmt ist, und zum anderen in der Tiefe, die der Grad des Eingriffs in die bestehenden Schichten des Programmcodes (zum Beispiel View Layer, Business Layer, Data Access Layer und Datenbank) definiert. Für das Aufteilen in der Breite sollte der Zuständige im Sinne des MVP-Pattern zuerst den Mindestfunktionsumfang der Applikation definieren, für die das GUI-Redesign im ersten Schritt durchzuführen ist.
Existiert beispielsweise eine Basic- oder Light-Version der umzugestaltenden Software, bietet es sich an, das GUI-Redesign zuerst nur für deren reduzierten Funktionsumfang umzusetzen. Darauf sollte eine Neugestaltung der Features folgen, die zusätzlich im regulären Funktionsumfang (das heißt in der Standardversion) zu finden sind. Zuletzt können sich die mit dem Redesign betrauten Entwickler Funktionen widmen, die nur einigen Kunden zur Verfügung stehen (Premiumversion). Sollte es darüber hinaus Features geben, die ausschließlich intern für Administrations- oder Monitoringzwecke zum Einsatz kommen, kann man diese danach angehen – interne Nutzer sind in der Regel geduldiger als zahlende Kunden. Durch das Teilen einer Applikation in unterschiedliche Feature Sets lässt sich das GUI-Redesign in zeitlich getrennten Schritten umsetzen, ohne einer Kundengruppe inkonsistente Benutzeroberflächen zu zeigen.
Für die Gliederung in der Tiefendimension sollten sich Entwickler am "Gradual Feature Release"-Pattern orientieren. Dabei entstehen aufeinander aufbauende Stufen, die jeweils tiefer in den bestehenden Code eingreifen. Für ein Redesign wären etwa
- Facelift
- Quick-wins (schnelle Erfolge)
- Usability-Optimierungen
- UX-Verbesserungen
denkbar. In der Regel wächst die Komplexität der Entwicklung von Stufe zu Stufe. Während beispielsweise in der ersten nur Farben und Fonts geändert werden, lassen sich in der vierten Stufe komplette Workflows erneuern oder Features zerlegen und zusammenführen. Zur besseren Verdeutlichung folgen ein paar Beispiele dazu, welche Art von Überarbeitungen welcher Stufe zuzuordnen ist.
