Von UI-Kit zu einem Design-System

Erfahrungen des Online-Kinos Ivi

Als wir Anfang 2017 erstmals darüber nachdachten, ein eigenes System zur Bereitstellung von Design in Code zu schaffen, hatten bereits viele darüber gesprochen und einige hatten sogar damit begonnen. Dennoch gibt es bis heute nur wenig Wissen über den Aufbau plattformübergreifender Design-Systeme, und verständliche sowie bewährte Rezepte, die die Technologien und Methoden solcher Transformationen des Implementierungsprozesses von Design in ein bereits funktionierendes Produkt beschreiben, sind nach wie vor rar. Unter "Komponenten im Code" versteht man oft sehr unterschiedliche Dinge.

In der Zwischenzeit hat das Unternehmen von Jahr zu Jahr das Personal verdoppelt – es war notwendig, die Designabteilung zu skalieren und die Prozesse zur Erstellung und Weitergabe von Layouts an die Entwicklung zu optimieren. Wenn wir all das mit dem "Zoo" an Plattformen multiplizieren, die unterstützt werden müssen, entstehen Zustände, die einfach nicht in der Lage sind, "normal" zu arbeiten und Einnahmen zu generieren. Die Entwicklung der Plattformen verlief oft parallel, sodass dieselbe Funktionalität auf unterschiedlichen Plattformen mit einem Abstand von mehreren Monaten verfügbar sein konnte.


Separate Layout-Sets für jede Plattform

Traditionell haben wir mit den Herausforderungen begonnen, die eine Design-System lösen könnte, und haben die Anforderungen für dessen Gestaltung formuliert. Neben der Erstellung einer einheitlichen visuellen Sprache, der Beschleunigung der Prototypen- und Entwicklungsphase sowie der allgemeinen Produktqualität war es von entscheidender Bedeutung, das Design so weit wie möglich zu vereinheitlichen. Dies ist notwendig, um die Entwicklung neuer Funktionen gleichzeitig auf all unseren Plattformen zu ermöglichen: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku — ohne jede von ihnen einzeln bearbeiten zu müssen. Und genau das haben wir erreicht!

Design → Daten

Nachdem die grundlegenden Vereinbarungen zwischen den Produkt- und Entwicklungsteams getroffen waren, begannen wir mit der Auswahl des Technologie-Stacks und der Ausarbeitung der Details des gesamten Prozesses – von den Entwürfen bis zur Markteinführung. Um den Übergang vom Design zur Entwicklung vollständig zu automatisieren, haben wir den Ansatz mit einem Parser für die Parameter der Komponenten direkt aus den Sketch-Dateien mit den Entwürfen untersucht. Es stellte sich heraus, dass es kompliziert und riskant ist, die benötigten Codeabschnitte zu finden und die erforderlichen Parameter zu extrahieren. Erstens müssen die Designer äußerst vorsichtig mit der Benennung aller Schichten der Originaldatei umgehen, zweitens funktioniert dies nur für die einfachsten Komponenten, und drittens stellt die Abhängigkeit von der Technologie und der Code-Struktur des ursprünglichen Sketch-Entwurfs die Zukunft des gesamten Projekts in Frage. Wir haben uns entschieden, an dieser Stelle auf eine Automatisierung zu verzichten. So wurde in dem Team für das Designsystem die erste Person eingeführt, die die Designentwürfe erhält und als Ergebnis Daten liefert, die alle Parameter der Komponenten beschreiben und hierarchisch nach der Methodologie des atomaren Designs angeordnet sind.

Es blieb nur noch die Frage: Wo und wie speichern wir die Daten, wie übergeben wir sie an die Entwicklung und wie interpretiert man sie auf allen von uns unterstützten Plattformen? Der Abend wurde auf einmal viel spannender... Das Ergebnis der regelmäßigen Treffen der Arbeitsgruppe, bestehend aus Designern und Teamleitern jeder Plattform, waren Vereinbarungen über Folgendes.

Wir zerlegen das visuelle Design manuell in seine Einzelteile: Schriften, Farben, Transparenzen, Abstände, Rundungen, Icons, Bilder und Animationsdauern. Daraus erstellen wir Buttons, Eingabefelder, Checkboxen, Kreditkarten-Widgets usw. Den Styles jeder Ebene, mit Ausnahme der Icons, geben wir nicht-semantische Namen, zum Beispiel Städtenamen, Namen von Nymphen, Pokémon, Automarken… Hier gilt eine Regel — die Liste darf nicht enden, bevor die Styles ausgehen — das Show muss weitergehen! Mit der Semantik sollte man jedoch vorsichtig sein, um nicht gezwungen zu werden, einen mittleren Button zwischen „small“ und „medium“ hinzuzufügen.

Visuelle Sprache

Die Entwickler haben darüber nachgedacht, wie Daten gespeichert und übertragen werden können, sodass es für alle Plattformen geeignet ist. Das Design-Team musste Benutzeroberflächenelemente entwerfen, die auf allen unterstützten Geräten sowohl ansprechend aussehen als auch effizient funktionieren.

Zuvor hatten wir bereits die meisten Designelemente in der Anwendung für Windows 10 getestet, die zu diesem Zeitpunkt eine neue Plattform für uns war, was bedeutete, dass eine Neuentwicklung und Gestaltung erforderlich war. Durch diese Arbeiten konnten wir die meisten Komponenten vorbereiten und testen sowie herausfinden, welche in die zukünftige Design-System von Ivi aufgenommen werden sollten. Ohne diese "Spielwiese" wäre eine solche Erfahrung nur durch zahlreiche Iterationen auf bereits funktionierenden Plattformen möglich gewesen, was über ein Jahr gedauert hätte.

Die Wiederverwendung identischer Komponenten auf verschiedenen Plattformen reduziert die Anzahl der Layouts und das Datenvolumen der Designsysteme erheblich. Daher musste das Design eine weitere Herausforderung meistern, die bisher in den Praktiken des Produktdesigns und der Entwicklung nicht behandelt wurde – wie beispielsweise, eine Taste für Telefone und Tablets für Fernseher wiederzuverwenden. Und wie geht man grundsätzlich mit Schriftgrößen und Elementen auf solch unterschiedlichen Plattformen um?

Offensichtlich war es erforderlich, ein plattformübergreifendes modulares Raster zu entwerfen, das uns die benötigten Größen für Texte und Elemente für jede spezifische Plattform vorgibt. Als Ausgangspunkt für das Raster wählten wir die Größe und Anzahl der Filmplakate, die wir auf dem jeweiligen Bildschirm sehen möchten, und basierend darauf formulierten wir die Regel für den Aufbau der Grid-Spalten, wobei die Breite einer Spalte der Breite des Plakats entspricht.

Jetzt müssen alle großen Bildschirme auf die gleiche Layoutgröße gebracht und in ein gemeinsames Raster eingefügt werden. Apple TV und Roku werden auf die Größe 1920×1080 entwickelt, Android TV – 960×540 und Smart TVs variieren je nach Anbieter zwischen diesen Größen und 1280×720. Wenn die Anwendung auf Full HD-Bildschirmen gerendert und angezeigt wird, wird 960 mit 2 multipliziert, 1280 mit 1,33, während 1920 unverändert bleibt.

Um die langweiligen Details zu überspringen, sind wir zu dem Schluss gekommen, dass alle Bildschirme, einschließlich Fernsehern, hinsichtlich der Elemente und ihrer Größen von einem einzigen Design-Layout abgedeckt werden. Alle Fernseher stellen einen speziellen Fall des allgemeinen plattformübergreifenden Rasters dar und bestehen aus fünf oder sechs Spalten, ähnlich einem durchschnittlichen Tablet oder Desktop. Interessierte können die Details in den Kommentaren nachlesen.

Einheitliches UI für alle Plattformen

Jetzt benötigen wir für die Gestaltung neuer Funktionen keine Layouts mehr für jede Plattform, einschließlich der Anpassungsvarianten für jede von ihnen. Es reicht aus, ein Layout und seine Anpassungsfähigkeit für alle Plattformen und Geräte mit beliebiger Breite zu zeigen: Telefone – 320–599, alles andere – 600–1280.

Daten → Entwicklung

Natürlich, so sehr wir uns auch einen einheitlichen Designansatz wünschen, jede Plattform hat ihre eigenen einzigartigen Eigenschaften. Obwohl sowohl Web- als auch Smart TV-Anwendungen auf dem ReactJS + TypeScript-Stack basieren, wird die Anwendung für Smart TVs auf veralteten WebKit- und Presto-Clients ausgeführt und kann daher keine gemeinsamen Stile mit dem Web verwenden. E-Mail-Newsletter hingegen müssen mit tabellarischen Layouts arbeiten. Keine der Nicht-HTML-Plattformen verwendet oder plant den Einsatz von React Native oder ähnlichen Alternativen, da wir zu viele benutzerdefinierte Layouts mit komplexer Logik für Aktualisierungen, Bildern und Videos haben, was die Leistung beeinträchtigen könnte. Daher ist die gängige Praxis — fertige CSS-Stile oder React-Komponenten bereitzustellen — für uns nicht geeignet. Stattdessen haben wir uns entschieden, die Daten im JSON-Format zu übertragen und die Werte in einem abstrakten deklarativen Format zu beschreiben.

So wird die Eigenschaft rounding: 8 vom Windows 10-Anwendungsclient in CornerRadius="8", im Web — border-radius: 8px, Android — android:radius="8dp", iOS — self.layer.cornerRadius = 8.0.
Die Eigenschaft offsetTop: 12 kann vom gleichen Web-Client in unterschiedlichen Fällen als top, margin-top, padding-top oder transform interpretiert werden.

Die Deklarativität der Beschreibung impliziert auch, dass die Plattform, falls technisch nicht in der Lage, bestimmte Eigenschaften oder deren Werte zu verwenden, diese ignorieren kann. In Bezug auf die Terminologie haben wir eine Art Esperanto-Sprache geschaffen: etwas aus Android, etwas aus SVG, etwas aus CSS.

Für den Fall, dass auf einer bestimmten Plattform Elemente anders dargestellt werden müssen, haben wir die Möglichkeit geschaffen, die entsprechende Datengenerierung in Form einer separaten JSON-Datei zu übermitteln. Zum Beispiel erfordert der Zustand „im Fokus“ für Smart TVs eine Änderung der Textposition unter dem Poster, was bedeutet, dass dieser Komponente auf dieser Plattform im Wert der Eigenschaft „Abstand“ die benötigten 8 Punkte Abstand enthalten wird. Auch wenn dies die Infrastruktur des Design-Systems komplizierter macht, gibt es uns dennoch eine zusätzliche Freiheit und ermöglicht es uns, die visuelle „Unähnlichkeit“ der Plattformen selbst zu steuern, anstatt von der von uns geschaffenen Architektur abhängig zu sein.

Piktogramme

Icons in a digital product are always a substantial and complex sub-project, often managed by a dedicated designer. There are usually many glyphs, each with several sizes and colors, and platforms typically require them in various formats. Therefore, there was no reason not to integrate all of this into a design system.

Glyphs are loaded in vector SVG format, and color values are automatically replaced with variables. Client applications can access them in a ready-to-use state — in any format and color.

Vorschau

On top of the JSON data, we developed a preview tool — a JS application that processes the JSON data through its markup and style generators in real time, displaying various variations of each component in the browser. Essentially, the preview acts just like a client application, working with the same data as the platform applications.

Es ist am einfachsten, zu verstehen, wie ein bestimmtes Bauteil funktioniert, indem man damit interagiert. Daher haben wir uns entschieden, keine Tools wie Storybook zu verwenden und ein interaktives Vorschau zu erstellen – man kann es anfassen, darauf zeigen und klicken… Wenn ein neuer Bauteil in das Design-System integriert wird, erscheint er in der Vorschau, damit Plattformen eine Orientierungshilfe für dessen Implementierung haben.

Dokumentation

Basierend auf den Daten, die in Form von JSON an die Plattformen geliefert werden, wird automatisch die Dokumentation der Bauteile erstellt. Es wird eine Liste der Eigenschaften und der möglichen Werttypen für jede davon beschrieben. Nach der Autogenerierung kann die Information manuell verfeinert und eine textuelle Beschreibung hinzugefügt werden. Die Vorschau und die Dokumentation sind auf Ebene jedes Bauteils mit Querverweisen miteinander verbunden, und alle Informationen, die in die Dokumentation aufgenommen werden, sind für Entwickler in Form zusätzlicher JSON-Dateien verfügbar.

Deprecator

Eine weitere Notwendigkeit ist die Möglichkeit, bestehende Komponenten im Laufe der Zeit auszutauschen und zu aktualisieren. Das Designsystem hat gelernt, den Entwicklern mitzuteilen, welche Eigenschaften oder sogar ganze Komponenten nicht verwendet werden dürfen und diese zu entfernen, sobald sie auf allen Plattformen nicht mehr genutzt werden. Obwohl in diesem Prozess noch viel manuelle Arbeit steckt, stehen wir nicht still.

Kundenentwicklung

Zweifellos war die Umsetzung der Daten des Designsystems in den Code all unserer unterstützten Plattformen der komplexeste Schritt. Während modulare Raster im Web nichts Neues sind, hatten Entwickler nativer mobiler Anwendungen für iOS und Android eine Menge Arbeit, bevor sie herausfanden, wie sie damit umgehen können.

Für das Design von iOS-Anwendungsoberflächen verwenden wir zwei grundlegende Mechanismen, die iviUIKit bereitstellt: die freie Anordnung von Elementen und die Anordnung in Elementkollektionen. Wir nutzen VIPER, und die gesamte Interaktion mit iviUIKit konzentriert sich auf das View, während der Großteil der Interaktion mit dem Apple UIKit in iviUIKit angesiedelt ist. Die Größen und Positionen der Elemente werden in Kolumnen und syntaktischen Konstruktionen festgelegt, die über den nativen Constraints des iOS SDK funktionieren und sie anwenderfreundlicher machen. Dies hat uns das Leben bei der Arbeit mit UICollectionView erheblich erleichtert. Wir haben mehrere anpassbare Wrapper für Layouts geschrieben, auch für ziemlich komplexe. Der Client-Code ist auf ein Minimum reduziert und ist deklarativ geworden.

Zur Generierung von Stilen im Android-Projekt verwenden wir Gradle, um die Daten des Designsystems in XML-Formatstile umzuwandeln. Dabei haben wir mehrere Generatoren auf unterschiedlichem Niveau:

• Basis. Sie parsen die Daten der primitiven Generatoren für höherstufige Generatoren.
• Ressourcen. Diese laden Bilder, Icons und andere Grafiken herunter.
• Komponenten. Diese werden für jede Komponente geschrieben, wobei die Eigenschaften beschrieben werden und wie sie in Stile übersetzt werden.

App-Releases

Nachdem die Designer eine neue Komponente entworfen oder eine bestehende überarbeitet haben, fließen diese Änderungen in das Designsystem ein. Die Entwickler jeder Plattform passen ihre Codegenerierung an, um die Änderungen zu unterstützen. Danach kann er bei der Implementierung neuer Funktionen genutzt werden, in denen diese Komponente erforderlich ist. So erfolgt die Interaktion mit dem Designsystem nicht in Echtzeit, sondern lediglich zum Zeitpunkt des Builds neuer Releases. Dieser Ansatz erlaubt es auch, den Datenübertragungsprozess besser zu kontrollieren und die Funktionsfähigkeit des Codes in Kundenprojekten zu gewährleisten.

Ergebnisse

Bald jährt sich die Einführung des Designsystems als Teil der Infrastruktur, die die Entwicklung der Online-Videoplattform Ivi unterstützt, und man kann bereits einige Schlussfolgerungen ziehen:

• Es handelt sich um ein großes und anspruchsvolles Projekt, das ständige, dedizierte Ressourcen erfordert.
• Dies hat es uns ermöglicht, unsere einzigartige plattformübergreifende visuelle Sprache zu schaffen, die den Anforderungen des Online-Videodienstes gerecht wird.
• Wir haben keine visuell und funktional zurückbleibenden Plattformen mehr.

Vorschau der Komponenten des Ivi-Designsystems — design.ivi.ru

Quelle: habr.com