Вопыт анлайн-кінатэатра Іві
Калі ў пачатку 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, Androidandroid: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