Досвід онлайн-кінотеатру Іві
Коли на початку 2017 року ми вперше замислилися над створенням власної системи доставки дизайну в код, про це вже багато хто говорив і хтось навіть робив. Однак, про досвід побудови кросплатформових дизайн-систем і до сьогодні мало що відомо, а зрозумілих і перевірених рецептів, що описують технології та способи подібної трансформації процесу імплементації дизайну в продукт, що вже працює, як не було, так і немає. Та й під «компонентами в коді» часто розуміють різні речі.
Тим часом компанія з року в рік подвоювала штат — треба було масштабувати відділ дизайну та оптимізувати процеси створення та передачі макетів у розробку. Помножуємо все це на «зоопарк» платформ, які потрібно підтримувати, і отримуємо подобу вавилонського стовпотворення, яке просто не здатне «нормально робити» та приносити дохід. Розвиток платформ часто йшов паралельно, і той самий функціонал міг виходити різних платформах з лагом кілька місяців.
Окремі набори макетів для кожної платформи
Традиційно ми почали з проблем, які б допомогла вирішити дизайн-система і сформулювали вимоги до її проектування. Крім створення єдиної візуальної мови, збільшення швидкості макетування та розробки, підвищення якості продукту загалом було життєво необхідно максимально уніфікувати дизайн. Це потрібно для того, щоб розвиток функціоналу став можливим відразу на всіх наших платформах одночасно: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - не опрацьовуючи при цьому кожну з них окремо . І це в нас вийшло!
Дизайн → дані
Коли принципових домовленостей відділів продукту та розробки було досягнуто, ми сіли за підбір технологічного стеку та опрацювання деталей всього процесу — від макета до релізу. Щоб повністю автоматизувати процес передачі дизайну в розробку дослідили варіант із парсером параметрів компонентів прямо із Sketch-файлів із макетами. Виявилося, що знаходити потрібні нам шматки коду і витягувати потрібні нам параметри - винахід складний і небезпечний. По-перше, дизайнерам доведеться бути вкрай акуратними в іменуванні всіх шарів вихідного коду, по-друге, це працює тільки для найпростіших компонентів, а по-третє, залежність від чужої технології та структури коду вихідного Sketch-макета ставить під загрозу майбутнє всього проекту. Ми вирішили відмовитись від автоматизації на цій ділянці. Так у команді дизайн-системи з'явилася перша людина, на вхід якій подаються дизайн-макети, а на виході дані, що описують всі параметри компонентів та ієрархічно впорядковані методологією атомарного дизайну.
Справа залишалася за малим: де і як зберігати дані, як передавати в розробку і як інтерпретувати в розробці на всіх платформах, що підтримуються нами. Вечір переставав бути важким… Підсумком регулярних зустрічей робочої групи, що складається з дизайнерів і тимлідів від кожної платформи, стали домовленості про наступне.
Вручну розбираємо візуал на елементи-атоми: шрифти, кольори, прозорості, відступи, округлення, іконки, картинки та тривалості для анімацій. І збираємо з цього кнопки, інпути, чекбокси, віджети банківських карток і т. д. Стилям будь-якого з рівнів, окрім піктограм, присвоюємо несемантичні імена, наприклад назви міст, імена німф, покемонів, марки автомобілів… Тут умова одна — список не повинен вичерпатися раніше чим закінчаться стилі - шоу маст гоу він! Семантикою не варто захоплюватися, щоб не довелося додавати середню кнопку між «small» і «medium», наприклад.
Візуальна мова
Розробники пішли думати, як зберігати і передавати дані, щоб це підходило всім платформам, а дизайн мав спроектувати елементи інтерфейсу, здатні однаково добре виглядати і ефективно працювати на всьому парку пристроїв, що підтримуються.
Раніше ми вже встигли «обкатати» більшість елементів дизайну в додатку під Windows 10, яке на той момент було для нас новою платформою, тобто потрібне було малювання та розробка «з нуля». Малюючи його, ми змогли підготувати та перевірити більшість компонентів та зрозуміти, які з них мали увійти до майбутньої дизайн-системи Іві. Без такої «пісочниці» подібний досвід можна було отримати лише великою кількістю ітерацій на платформах, що вже працюють, а на це знадобилося б більше року.
Перевикористання однакових компонентів на різних платформах зменшує кількість макетів і масив даних дизайн-системи в рази, тому дизайн мав вирішити ще одне завдання, яке раніше не описане в практиках продуктового дизайну та розробки — як, наприклад, кнопку для телефонів і планшетів перевикористовувати на телевізорах? І як у принципі бути з розмірами шрифтів та елементів на таких різних платформах?
Очевидно, потрібно було спроектувати кросплатформенну модульну сітку, яка задаватиме потрібні нам розміри тексту та елементів для кожної конкретної платформи. За точку відліку для сітки ми вибрали розмір і кількість постерів фільмів, які хочемо бачити на тому чи іншому екрані і, виходячи з цього, сформулювали правило побудови колонок сітки, за умови - ширина однієї колонки дорівнює ширині постера.
Тепер потрібно привести до одного розміру макета все більші екрани та вписати їх у спільну сітку. Apple TV і Roku розробляються в розмір 1920х1080, Android TV - 960х540, Smart TV, залежно від вендора бувають такими ж, а бувають 1280х720. Коли програма рендерується і відображається на екранах Full HD, 960 множиться на 2, 1280 на 1,33, а 1920 виводиться як є.
Опускаючи нудні подробиці, ми дійшли того, що взагалі всі екрани, включаючи телеекрани з точки зору елементів та їх розмірів, покриваються одним дизайн-макетом, а всі телеекрани є окремим випадком загальної кросплатформової сітки, і складаються з п'яти або шести колонок, як середній планшет або робочий стіл. Кому цікаві подробиці, го в коментарі.
Єдиний UI для всіх платформ
Тепер для малювання нової фічі нам не потрібно малювати макети під кожну з платформ плюс варіанти адаптивності для кожної з них. Достатньо показати один макет та його адаптивність для всіх платформ та пристроїв будь-якої ширини: телефони – 320–599, все інше – 600–1280.
Дані → розробка
Звичайно, як би нам не хотілося дійти абсолютно уніфікованого дизайну, кожна платформа має свої унікальні особливості. Незважаючи на те, що і веб, і Smart TV використовують стек ReactJS + TypeScript, програма Smart TV запускається на застарілих WebKit-і Presto-клієнтах, і тому не може використовувати загальні стилі з вебом. А email-розсилки взагалі змушені працювати з табличною версткою. При цьому жодна з не-html-платформ не використовує і не планує використовувати React Native або якісь її аналоги, побоюючись погіршення продуктивності, оскільки у нас дуже багато кастомних лейаутів, колекцій зі складною логікою оновлення, зображень та відео. Тому для нас не підходить поширена схема – постачати готові CSS-стилі або React-компоненти. Тому ми вирішили надсилати дані у форматі JSON, описуючи значення в абстрактному декларативному вигляді.
Так властивість
rounding: 8програма Windows 10 перетворює наCornerRadius="8", веб -border-radius: 8px, Android -android:radius="8dp", iOS -self.layer.cornerRadius = 8.0.
ВластивістьoffsetTop: 12один і той же веб-клієнт у різних випадках може інтерпретувати якtop,margin-top,padding-topабоtransform
Декларативність опису також передбачає, що якщо платформа технічно не може використовувати будь-яку властивість або її значення, вона може її проігнорувати. З точки зору термінології ми зробили якусь подібність мови есперанто: щось взяли з Android, щось із SVG, щось із CSS.
Якщо на тій чи іншій платформі потрібно буде відображати елементи якось інакше, ми реалізували можливість передачі відповідної генерації даних у вигляді окремого JSON-файлу. Наприклад, стан «у фокусі» для Smart TV, диктує зміну позиції тексту під постером, отже, для цієї платформи даний компонент у значенні властивості «відступ» міститиме необхідні 8 поінтів відступу. Хоча це й ускладнює інфраструктуру дизайн-системи, натомість дає додатковий ступінь свободи, залишаючи нам можливість самим керувати візуальною «несхожістю» платформ, а не бути заручниками створеної архітектури.
Піктограми
Іконографіка в цифровому продукті - це завжди об'ємний і не найпростіший підпроект, що часто має окремого дизайнера. Гліфів завжди багато, кожен з них має кілька розмірів та кольорів, до того ж платформам вони потрібні, як правило, у різних форматах. Загалом не було приводу не завести все це в дизайн-систему.
Гліфи завантажуються у векторному форматі SVG, а значення кольорів автоматично замінюються змінними. Програми-клієнти можуть отримувати їх вже готовими до використання у будь-якому форматі та кольорі.
попередній
Поверх JSON'а з даними ми написали інструмент для перегляду компонентів - JS-додаток, що на льоту пропускає JSON-дані через свої генератори розмітки та стилів, і відображає в браузері різні варіації кожного з компонентів. По суті, перегляд є таким самим клієнтом, як і платформні додатки, і працює з тими ж даними.
Зрозуміти, як працює той чи інший компонент, найпростіше шляхом взаємодії з ним. Тому ми не стали використовувати інструменти, подібні до Storybook, а зробили інтерактивний перегляд – можна помацати, понаводити, покликати… При додаванні в дизайн-систему нового компонента він з'являється в попередньому перегляді, щоб платформам було на що орієнтуватися при його впровадженні.
Документація
На основі тих даних, які у вигляді JSON поставляються платформам, автоматично формується документація компонентів. Описується перелік властивостей та можливі типи значень у кожному з них. Після автогенерації інформацію можна уточнити вручну, додати текстовий опис. Передпроглядання та документація мають перехресні посилання один на одного на рівні кожного компонента, а вся інформація, що потрапляє в документацію, доступна розробникам у вигляді додаткових JSON-файлів.
Депрекатор
Ще однією необхідністю стала можливість згодом замінювати та оновлювати вже існуючі компоненти. Дизайн-система навчилася повідомляти розробникам, які властивості чи навіть цілі компоненти використовувати не можна та видаляти їх, як тільки вони перестають використовуватися на всіх платформах. Поки що у цьому процесі ще багато «ручної» праці, але ми не стоїмо на місці.
Клієнтська розробка
Безперечно, наймасштабнішим за складністю етапом стала інтерпретація даних дизайн-системи в коді всіх підтримуваних нами платформ. Якщо, наприклад, модульні сітки на вебі не є чимось новим, то розробники нативних мобільних додатків під iOS та Android неабияк попотіли, перш ніж придумали, як з цим жити.
Для верстки екранів iOS-додатку ми використовуємо два базові механізми, які надає iviUIKit: вільне компонування елементів та компонування колекцій елементів. Ми використовуємо VIPER, і вся взаємодія з iviUIKit зосереджена у View, а більшість взаємодії з Apple UIKit зосереджена в iviUIKit. Розміри та розташування елементів задаються в термінах колонок та синтаксичних конструкцій, що працюють поверх нативних констрейнтів iOS SDK, що роблять їх більш прикладними. Особливо це спростило нам життя під час роботи з UICollectionView. Ми написали кілька обгорток для лейаутів, у тому числі досить складних. Клієнтського коду вийшло мінімум, і він став декларативним.
Для створення стилів у проекті Android ми використовуємо Gradle, перетворюючи дані дизайн-системи в стилі формату XML. При цьому ми маємо кілька генераторів різного рівня:
- базові. Парся дані примітивів для генераторів вищого рівня.
- Ресурсні. Завантажують картинки, іконки та іншу графіку.
- Компонентні. Пишуться для кожного компонента, де описано які властивості та як перекласти у стилі.
Релізи додатків
Після того, як дизайнери намалювали новий компонент або переробили існуючий, ці зміни потрапляють у дизайн-систему. Розробники кожної із платформ допрацьовують свою кодогенерацію, забезпечуючи підтримку змін. Після цього його можна використовувати для реалізації нового функціоналу, де цей компонент необхідний. Таким чином, взаємодія з дизайн-системою відбувається не в реальному часі, а лише в момент збирання нових релізів. Такий підхід також дозволяє краще контролювати процес передачі даних та гарантує працездатність коду у проектах клієнтської розробки.
Підсумки
Незабаром рік як дизайн-система стала частиною інфраструктури, що обслуговує розвиток онлайн-кінотеатру Іві, і вже можна робити деякі висновки:
- Це великий та складний у реалізації проект, що потребує постійних виділених ресурсів.
- Це дозволило нам створити свою унікальну кросплатформну візуальну мову, що відповідає завданням сервісу онлайн відео.
- У нас більше немає платформ, що візуально і функціонально відстають.
Перегляд компонентів дизайн-системи Іві
Джерело: habr.com