Viele Herausforderungen begleiteten den Aufbau der Intelligent Business Cloud. Eine bestand darin, unserer Entwicklungsphilosophie treu zu bleiben, die produktübergreifende Konsistenz vorsah.
Außerdem planten wir, verschiedene neue Anwendungen zu entwickeln und in die Cloud zu integrieren. Dafür mussten wir bestimmte Prozesse automatisieren und die Übertragbarkeit von UI-Designs gewährleisten.
Da wir Angular (2+) und TypeScript für unsere Frontend-Anwendungen nutzten, benötigten wir UI-Frameworks, die mit Angular kompatibel sind. Am Anfang hatten wir die Idee, das Material2 Angular Framework von GitHub zu klonen (in sehr frühem Entwicklungsstadium) und hierauf unsere UI aufzusetzen.
Unser Entwicklungsteam war damals sehr von Material Design angetan, weshalb uns Material2 als Library als perfekte Wahl erschien. Die Lage änderte sich jedoch, als unsere Produkte im Laufe der Zeit immer komplexer wurden – und damit auch unsere Anforderungen und Herausforderungen.
Wir entschieden uns, eine eigene Frontend Library auf Basis der Material2-Architektur aufzubauen – so wären wir in der Lage, Komponenten nach unseren eigenen Vorstellungen zu designen. Diese Idee markierte die Geburtsstunde von Emotion.
Unser Team verfasste Richtlinien zur Nutzung bestimmter UI-Elemente wie Buttons, Modals und Forms. Darüber hinaus designten wir einen kompletten Komponentensatz, aus dem inzwischen unser eigenes IBC-Designsystem entstanden ist.
In Emotion fügten wir anfangs nur Komponenten hinzu, für die wir bereits Designs besaßen. Wir begannen mit UI-orientierten Komponenten und gingen dann zu Komponenten mit erweiterter Funktionalität über. Später integrierten wir auch IBC-exklusive Komponenten, wobei es sich im Grunde um Sets bereits vorhandener Emotion-Komponenten handelte.
Da wir unsere Library quelloffen halten und online veröffentlichen wollten, vereinten wir Komponenten mit IBC-Bezug später in einer separaten Library namens Emotion Cloud. Emotion ist als Library völlig unabhängig von Celonis und kann von jeder Person für eigene Projekte genutzt werden.
Unsere Komponenten basieren auf der Atomic Design-Struktur; wir nutzen SCSS für Styles und Angular/TypeScript für das Frontend. Die Komponenten sind wie folgt untergliedert:
Diese Komponenten beinhalten Buttons, Forms, Modals, Listen, Tabellen, Tooltips und mehr.
Ein Molekül bezeichnet eine Gruppe von Atomen. Diese „Cluster“ beinhalten Komponenten wie Item Chooser, Dialoge, Prompts, Tag Inputs, lokale Datenquellen und mehr.
Page Layouts wie Main Layout und ‚Burger‘ Content. Content Layouts wie Panels, Sections, aufklappbare Panels und mehr.
Übergeordnete Komponenten, die auf „Atomen“ oder „Molekülen“ basieren (z. B. Platzhalter). Diese Struktur hilft uns dabei, Komponenten so aufzuteilen, dass auch neue Teammitglieder schnell erfassen, was sie an welcher Stelle erwartet, und das war im Endeffekt ein großartiges Resultat.
Für unser Styling nutzten wir SCSS als CSS Post-Processor. Unsere SCSS-Architektur ist in folgende Teile untergliedert:
Allgemeine Styles, darunter Normalizer, Typografie, Helper und Utilities sowie mehr oder weniger jeder andere Style, den wir schnell verfügbar haben wollten.
// Utilities
@import "../styles/utilities/all_utilities";
// Partials
@import "../styles/partials/normalize";
@import "../styles/partials/grid";
@import "../styles/partials/overlay";
...
Main Styles definieren globale Variablen, Mixins und Funktionen, die einen Großteil unserer globalen Konfiguration für das Designsystem ausmachen, darunter Units, Breakpoints, Sizes und Colors. Unsere main.scss-Datei sieht folgendermaßen aus:
@import "variables";
@import "functions/string"
@import "mixins/animations";
@import "mixins/typography";
@import "mixins/overlay";
@import "mixins/grid";
...
Am Ende generieren wir kein echtes CSS, sondern nutzen die Datei nur, um Zugang zu unserer globalen Konfiguration zu erhalten.
Da Angular dies erlaubt und empfiehlt, ist jeder komponentenbasierte Style in seiner Parent-Komponente enthalten und inbegriffen. So wird die Performanz verbessert, da der Style nur geladen wird, wenn die Komponente auch tatsächlich genutzt wird.
Dank Emotion waren wir in der Lage, viele verschiedene Apps auf Basis desselben Layouts, derselben Designphilosophie und mit leicht wiederverwendbaren Komponenten zu realisieren. User Interfaces ließen sich so zügig einrichten. Darüber hinaus erstellten wir auch eine Emotion-Demo, auf die alle Entwickler in Celonis Zugriff hatten und die der Erkundung von Dokumenten nach Anwendungsbeispielen und APIs diente.
Insgesamt sind wir der Ansicht, dass Emotion unserem Unternehmen großen Mehrwert bietet. Ohne die Library wären wir nicht in der Lage, so viele Apps mit konsistenter UI und User Experience zu entwickeln.
Wir pflegen und aktualisieren Emotion auch weiterhin, indem wir neue Komponenten hinzufügen und die vorhandenen verbessern und erweitern.
Die IBC wächst, genauso wie Emotion – jeden Tag!