<\/a><\/noindex>Separate Layout-Sets f\u00fcr jede Plattform<\/i><\/p>\n Traditionell haben wir mit den Herausforderungen begonnen, die eine Design-System l\u00f6sen k\u00f6nnte, und haben die Anforderungen f\u00fcr dessen Gestaltung formuliert. Neben der Erstellung einer einheitlichen visuellen Sprache, der Beschleunigung der Prototypen- und Entwicklungsphase sowie der allgemeinen Produktqualit\u00e4t war es von entscheidender Bedeutung, das Design so weit wie m\u00f6glich zu vereinheitlichen. Dies ist notwendig, um die Entwicklung neuer Funktionen gleichzeitig auf all unseren Plattformen zu erm\u00f6glichen: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku \u2014 ohne jede von ihnen einzeln bearbeiten zu m\u00fcssen. Und genau das haben wir erreicht!<\/p>\n
Design \u2192 Daten<\/h2>\n \nNachdem 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 \u2013 von den Entw\u00fcrfen bis zur Markteinf\u00fchrung. Um den \u00dcbergang vom Design zur Entwicklung vollst\u00e4ndig zu automatisieren, haben wir den Ansatz mit einem Parser f\u00fcr die Parameter der Komponenten direkt aus den Sketch-Dateien mit den Entw\u00fcrfen untersucht. Es stellte sich heraus, dass es kompliziert und riskant ist, die ben\u00f6tigten Codeabschnitte zu finden und die erforderlichen Parameter zu extrahieren. Erstens m\u00fcssen die Designer \u00e4u\u00dferst vorsichtig mit der Benennung aller Schichten der Originaldatei umgehen, zweitens funktioniert dies nur f\u00fcr die einfachsten Komponenten, und drittens stellt die Abh\u00e4ngigkeit von der Technologie und der Code-Struktur des urspr\u00fcnglichen 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\u00fcr das Designsystem die erste Person eingef\u00fchrt, die die Designentw\u00fcrfe erh\u00e4lt und als Ergebnis Daten liefert, die alle Parameter der Komponenten beschreiben und hierarchisch nach der Methodologie des atomaren Designs angeordnet sind.<\/p>\n
Es blieb nur noch die Frage: Wo und wie speichern wir die Daten, wie \u00fcbergeben wir sie an die Entwicklung und wie interpretiert man sie auf allen von uns unterst\u00fctzten Plattformen? Der Abend wurde auf einmal viel spannender... Das Ergebnis der regelm\u00e4\u00dfigen Treffen der Arbeitsgruppe, bestehend aus Designern und Teamleitern jeder Plattform, waren Vereinbarungen \u00fcber Folgendes.<\/p>\n
Wir zerlegen das visuelle Design manuell in seine Einzelteile: Schriften, Farben, Transparenzen, Abst\u00e4nde, 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\u00e4dtenamen, Namen von Nymphen, Pok\u00e9mon, Automarken\u2026 Hier gilt eine Regel \u2014 die Liste darf nicht enden, bevor die Styles ausgehen \u2014 das Show muss weitergehen! Mit der Semantik sollte man jedoch vorsichtig sein, um nicht gezwungen zu werden, einen mittleren Button zwischen \u201esmall\u201c und \u201emedium\u201c hinzuzuf\u00fcgen.<\/p>\n
Visuelle Sprache<\/h2>\n \nDie Entwickler haben dar\u00fcber nachgedacht, wie Daten gespeichert und \u00fcbertragen werden k\u00f6nnen, sodass es f\u00fcr alle Plattformen geeignet ist. Das Design-Team musste Benutzeroberfl\u00e4chenelemente entwerfen, die auf allen unterst\u00fctzten Ger\u00e4ten sowohl ansprechend aussehen als auch effizient funktionieren.<\/p>\n
Zuvor hatten wir bereits die meisten Designelemente in der Anwendung f\u00fcr Windows 10 getestet, die zu diesem Zeitpunkt eine neue Plattform f\u00fcr 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\u00fcnftige Design-System von Ivi aufgenommen werden sollten. Ohne diese \"Spielwiese\" w\u00e4re eine solche Erfahrung nur durch zahlreiche Iterationen auf bereits funktionierenden Plattformen m\u00f6glich gewesen, was \u00fcber ein Jahr gedauert h\u00e4tte.<\/p>\n
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 \u2013 wie beispielsweise, eine Taste f\u00fcr Telefone und Tablets f\u00fcr Fernseher wiederzuverwenden. Und wie geht man grunds\u00e4tzlich mit Schriftgr\u00f6\u00dfen und Elementen auf solch unterschiedlichen Plattformen um?<\/p>\n
Offensichtlich war es erforderlich, ein plattform\u00fcbergreifendes modulares Raster zu entwerfen, das uns die ben\u00f6tigten Gr\u00f6\u00dfen f\u00fcr Texte und Elemente f\u00fcr jede spezifische Plattform vorgibt. Als Ausgangspunkt f\u00fcr das Raster w\u00e4hlten wir die Gr\u00f6\u00dfe und Anzahl der Filmplakate, die wir auf dem jeweiligen Bildschirm sehen m\u00f6chten, und basierend darauf formulierten wir die Regel f\u00fcr den Aufbau der Grid-Spalten, wobei die Breite einer Spalte der Breite des Plakats entspricht. <\/p>\n
Um die langweiligen Details zu \u00fcberspringen, sind wir zu dem Schluss gekommen, dass alle Bildschirme, einschlie\u00dflich Fernsehern, hinsichtlich der Elemente und ihrer Gr\u00f6\u00dfen von einem einzigen Design-Layout abgedeckt werden. Alle Fernseher stellen einen speziellen Fall des allgemeinen plattform\u00fcbergreifenden Rasters dar und bestehen aus f\u00fcnf oder sechs Spalten, \u00e4hnlich einem durchschnittlichen Tablet oder Desktop. Interessierte k\u00f6nnen die Details in den Kommentaren nachlesen.<\/p>\n
Einheitliches UI f\u00fcr alle Plattformen<\/i><\/p>\n
Jetzt ben\u00f6tigen wir f\u00fcr die Gestaltung neuer Funktionen keine Layouts mehr f\u00fcr jede Plattform, einschlie\u00dflich der Anpassungsvarianten f\u00fcr jede von ihnen. Es reicht aus, ein Layout und seine Anpassungsf\u00e4higkeit f\u00fcr alle Plattformen und Ger\u00e4te mit beliebiger Breite zu zeigen: Telefone \u2013 320\u2013599, alles andere \u2013 600\u20131280. <\/p>\n
Daten \u2192 Entwicklung<\/h2>\n \nNat\u00fcrlich, so sehr wir uns auch einen einheitlichen Designansatz w\u00fcnschen, 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\u00fcr Smart TVs auf veralteten WebKit- und Presto-Clients ausgef\u00fchrt und kann daher keine gemeinsamen Stile mit dem Web verwenden. E-Mail-Newsletter hingegen m\u00fcssen mit tabellarischen Layouts arbeiten. Keine der Nicht-HTML-Plattformen verwendet oder plant den Einsatz von React Native oder \u00e4hnlichen Alternativen, da wir zu viele benutzerdefinierte Layouts mit komplexer Logik f\u00fcr Aktualisierungen, Bildern und Videos haben, was die Leistung beeintr\u00e4chtigen k\u00f6nnte. Daher ist die g\u00e4ngige Praxis \u2014 fertige CSS-Stile oder React-Komponenten bereitzustellen \u2014 f\u00fcr uns nicht geeignet. Stattdessen haben wir uns entschieden, die Daten im JSON-Format zu \u00fcbertragen und die Werte in einem abstrakten deklarativen Format zu beschreiben. <\/p>\n
So wird die Eigenschaft rounding: 8<\/code> vom Windows 10-Anwendungsclient in CornerRadius=\"8\"<\/code>, im Web \u2014 border-radius: 8px<\/code>, Android \u2014 android:radius=\"8dp\"<\/code>, iOS \u2014 self.layer.cornerRadius = 8.0<\/code>. offsetTop: 12<\/code> kann vom gleichen Web-Client in unterschiedlichen F\u00e4llen als top<\/code>, margin-top<\/code>, padding-top<\/code> oder transform interpretiert werden.<\/code><\/p><\/blockquote>\n\nDie Deklarativit\u00e4t 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. <\/p>\n
F\u00fcr den Fall, dass auf einer bestimmten Plattform Elemente anders dargestellt werden m\u00fcssen, haben wir die M\u00f6glichkeit geschaffen, die entsprechende Datengenerierung in Form einer separaten JSON-Datei zu \u00fcbermitteln. Zum Beispiel erfordert der Zustand \u201eim Fokus\u201c f\u00fcr Smart TVs eine \u00c4nderung der Textposition unter dem Poster, was bedeutet, dass dieser Komponente auf dieser Plattform im Wert der Eigenschaft \u201eAbstand\u201c die ben\u00f6tigten 8 Punkte Abstand enthalten wird. Auch wenn dies die Infrastruktur des Design-Systems komplizierter macht, gibt es uns dennoch eine zus\u00e4tzliche Freiheit und erm\u00f6glicht es uns, die visuelle \u201eUn\u00e4hnlichkeit\u201c der Plattformen selbst zu steuern, anstatt von der von uns geschaffenen Architektur abh\u00e4ngig zu sein.<\/p>\n
Piktogramme<\/h2>\n \nIcons 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.<\/p>\n
Vorschau<\/h2>\n \nOn top of the JSON data, we developed a preview tool \u2014 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.<\/p>\n
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 \u2013 man kann es anfassen, darauf zeigen und klicken\u2026 Wenn ein neuer Bauteil in das Design-System integriert wird, erscheint er in der Vorschau, damit Plattformen eine Orientierungshilfe f\u00fcr dessen Implementierung haben.<\/p>\n
Dokumentation<\/h2>\n \nBasierend 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\u00f6glichen Werttypen f\u00fcr jede davon beschrieben. Nach der Autogenerierung kann die Information manuell verfeinert und eine textuelle Beschreibung hinzugef\u00fcgt 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\u00fcr Entwickler in Form zus\u00e4tzlicher JSON-Dateien verf\u00fcgbar.<\/p>\n
Deprecator<\/h2>\n \nEine weitere Notwendigkeit ist die M\u00f6glichkeit, 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\u00fcrfen 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.<\/p>\n
Kundenentwicklung<\/h2>\n \nZweifellos war die Umsetzung der Daten des Designsystems in den Code all unserer unterst\u00fctzten Plattformen der komplexeste Schritt. W\u00e4hrend modulare Raster im Web nichts Neues sind, hatten Entwickler nativer mobiler Anwendungen f\u00fcr iOS und Android eine Menge Arbeit, bevor sie herausfanden, wie sie damit umgehen k\u00f6nnen. <\/p>\n
F\u00fcr das Design von iOS-Anwendungsoberfl\u00e4chen 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\u00e4hrend der Gro\u00dfteil der Interaktion mit dem Apple UIKit in iviUIKit angesiedelt ist. Die Gr\u00f6\u00dfen und Positionen der Elemente werden in Kolumnen und syntaktischen Konstruktionen festgelegt, die \u00fcber 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\u00fcr Layouts geschrieben, auch f\u00fcr ziemlich komplexe. Der Client-Code ist auf ein Minimum reduziert und ist deklarativ geworden. <\/p>\n
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:<\/p>\n
\nBasis<\/b>. Sie parsen die Daten der primitiven Generatoren f\u00fcr h\u00f6herstufige Generatoren.<\/li>\nRessourcen<\/b>. Diese laden Bilder, Icons und andere Grafiken herunter.<\/li>\nKomponenten<\/b>. Diese werden f\u00fcr jede Komponente geschrieben, wobei die Eigenschaften beschrieben werden und wie sie in Stile \u00fcbersetzt werden.<\/li>\n<\/ul>\n <\/p>\n
App-Releases<\/h2>\n \nNachdem die Designer eine neue Komponente entworfen oder eine bestehende \u00fcberarbeitet haben, flie\u00dfen diese \u00c4nderungen in das Designsystem ein. Die Entwickler jeder Plattform passen ihre Codegenerierung an, um die \u00c4nderungen zu unterst\u00fctzen. 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\u00fcbertragungsprozess besser zu kontrollieren und die Funktionsf\u00e4higkeit des Codes in Kundenprojekten zu gew\u00e4hrleisten.<\/p>\n
Ergebnisse<\/h2>\n \nBald j\u00e4hrt sich die Einf\u00fchrung des Designsystems als Teil der Infrastruktur, die die Entwicklung der Online-Videoplattform Ivi unterst\u00fctzt, und man kann bereits einige Schlussfolgerungen ziehen: <\/p>\n
\nEs handelt sich um ein gro\u00dfes und anspruchsvolles Projekt, das st\u00e4ndige, dedizierte Ressourcen erfordert.<\/li>\n Dies hat es uns erm\u00f6glicht, unsere einzigartige plattform\u00fcbergreifende visuelle Sprache zu schaffen, die den Anforderungen des Online-Videodienstes gerecht wird.<\/li>\n Wir haben keine visuell und funktional zur\u00fcckbleibenden Plattformen mehr.<\/li>\n<\/ul>\n\nVorschau der Komponenten des Ivi-Designsystems \u2014 design.ivi.ru<\/a><\/noindex> habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u043f\u044b\u0442 \u043e\u043d\u043b\u0430\u0439\u043d-\u043a\u0438\u043d\u043e\u0442\u0435\u0430\u0442\u0440\u0430 \u0418\u0432\u0438 \u041a\u043e\u0433\u0434\u0430 \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 2017 \u0433\u043e\u0434\u0430 \u043c\u044b \u0432\u043f\u0435\u0440\u0432\u044b\u0435 \u0437\u0430\u0434\u0443\u043c\u0430\u043b\u0438\u0441\u044c \u043e \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0434\u0438\u0437\u0430\u0439\u043d\u0430 \u0432 \u043a\u043e\u0434, \u043e\u0431 \u044d\u0442\u043e\u043c \u0443\u0436\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438 \u0438 \u043a\u0442\u043e-\u0442\u043e \u0434\u0430\u0436\u0435 \u0434\u0435\u043b\u0430\u043b. \u041e\u0434\u043d\u0430\u043a\u043e, \u043e\u0431 \u043e\u043f\u044b\u0442\u0435 \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u044f \u043a\u0440\u043e\u0441\u0441\u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0435\u043d\u043d\u044b\u0445 \u0434\u0438\u0437\u0430\u0439\u043d-\u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u043f\u043e \u0441\u0435\u0439 \u0434\u0435\u043d\u044c \u043c\u0430\u043b\u043e \u0447\u0442\u043e \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u043e, \u0430 \u043f\u043e\u043d\u044f\u0442\u043d\u044b\u0445 \u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0445 \u0440\u0435\u0446\u0435\u043f\u0442\u043e\u0432, \u043e\u043f\u0438\u0441\u044b\u0432\u0430\u044e\u0449\u0438\u0445 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u0438 \u0441\u043f\u043e\u0441\u043e\u0431\u044b \u043f\u043e\u0434\u043e\u0431\u043d\u043e\u0439 \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0434\u0438\u0437\u0430\u0439\u043d\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35549","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t