От UI-кит до система за проектиране

Ivy онлайн кино изживяване

Когато в началото на 2017 г. за първи път си помислихме да създадем собствена система за доставка от дизайн към код, мнозина вече говореха за това, а някои дори го правеха. Въпреки това, към днешна дата се знае малко за опита от изграждането на системи за проектиране на различни платформи и няма ясни и доказани рецепти, описващи технологии и методи за такава трансформация на процеса на внедряване на дизайна във вече работещ продукт. И под „компоненти в кода“ те често имат предвид много различни неща.

Междувременно компанията удвоява персонала си година след година - беше необходимо да се мащабира дизайнерският отдел и да се оптимизират процесите на създаване и прехвърляне на оформления за разработка. Умножаваме всичко това по „зоологическата градина“ от платформи, които трябва да бъдат поддържани, и получаваме подобие на вавилонски пандиз, който просто не е в състояние да „го прави нормално“ и да генерира доходи. Разработването на платформи често протичаше паралелно и една и съща функционалност можеше да бъде пусната на различни платформи със закъснение от няколко месеца.


Отделни комплекти оформления за всяка платформа

Традиционно започнахме с проблеми, които една система за проектиране би помогнала да разреши и формулирахме изисквания за нейното проектиране. В допълнение към създаването на унифициран визуален език, увеличаване на скоростта на оформление и разработка и подобряване на качеството на продукта като цяло, беше жизненоважно да се унифициран дизайнът, доколкото е възможно. Това е необходимо, за да стане възможно разработването на функционалност на всички наши платформи едновременно: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - без да работим върху всяка от тях поотделно. И го направихме!

Дизайн → данни

Когато бяха постигнати основните споразумения между продуктовия и развойния отдел, ние седнахме да изберем технологичен стек и да изработим детайлите на целия процес - от оформлението до пускането. За да автоматизираме напълно процеса на прехвърляне на дизайна към разработката, проучихме опцията за анализиране на параметри на компонент директно от Sketch файлове с оформления. Оказа се, че намирането на нужните части от код и извличането на нужните параметри е сложно и опасно начинание. Първо, дизайнерите ще трябва да бъдат изключително внимателни при именуване на всички слоеве на изходния код, второ, това работи само за най-простите компоненти, и трето, зависимостта от нечия друга технология и структура на кода на оригиналното оформление на Sketch застрашава бъдещето на целия проект. Решихме да изоставим автоматизацията в тази област. Така се появява първият човек в екипа на системата за проектиране, чийто вход са дизайн оформления, а изход данни, описващи всички параметри на компонентите и йерархично подредени според методологията на атомния дизайн.

Единственото нещо, което оставаше да се направи, беше къде и как да се съхраняват данните, как да се прехвърлят към разработката и как да се интерпретират в разработката на всички платформи, които поддържаме. Вечерта престана да бъде вяла... Резултатът от редовните срещи на работната група, състояща се от дизайнери и ръководители на екипи от всяка платформа, беше споразумението за следното.

Ние ръчно анализираме визуалното на атомарни елементи: шрифтове, цветове, прозрачност, отстъпи, закръгляния, икони, картини и времетраене на анимациите. И ние събираме от тези бутони, входове, квадратчета за отметка, джаджи за банкови карти и т.н. Ние присвояваме несемантични имена на стиловете на всяко от нивата, с изключение на иконите, например имена на градове, имена на нимфи, покемони, кола марки... Има само едно условие - списъкът да не е изчерпан преди това, как стиловете завършват - show must go! Не трябва да се увличате по семантиката, за да не се налага да добавяте среден бутон между „малък“ и „среден“ например.

Визуален език

Разработчиците бяха оставени да мислят как да съхраняват и прехвърлят данни по начин, който да отговаря на всички платформи, а дизайнът трябваше да проектира интерфейсни елементи, които да изглеждат добре и да работят ефективно в целия парк от поддържани устройства.

Преди това вече успяхме да „тестваме“ повечето от елементите на дизайна в приложение за Windows 10, което по това време беше нова платформа за нас, тоест изискваше изобразяване и разработка „от нулата“. Като го начертахме, успяхме да подготвим и тестваме повечето от компонентите и да разберем кои от тях трябваше да бъдат включени в бъдещата дизайнерска система Eevee. Без такава пясъчна среда такъв опит може да се получи само чрез голям брой итерации на вече работещи платформи и това ще отнеме повече от година.

Повторното използване на едни и същи компоненти на различни платформи намалява няколко пъти броя на оформленията и масива от данни на системата за проектиране, така че дизайнът трябваше да реши още един проблем, който преди това не беше описан в практиките за проектиране и разработка на продукти - как, за например, може ли бутон за телефони и таблети да се използва повторно на телевизори? И какво да правим с размерите на шрифтовете и елементите на толкова различни платформи?

Очевидно беше необходимо да се проектира междуплатформена модулна решетка, която да задава размерите на текста и елементите, от които се нуждаем за всяка конкретна платформа. Като отправна точка за решетката избрахме размера и броя на филмовите плакати, които искаме да видим на определен екран, и въз основа на това формулирахме правило за конструиране на колони от мрежата, при условие че ширината на една колона е равна до ширината на плаката.

Сега трябва да приведем всички големи екрани в еднакъв размер на оформлението и да ги поставим в обща мрежа. Apple TV и Roku са проектирани в размер 1920x1080, Android TV - 960x540, Smart TV, в зависимост от доставчика, са еднакви, но понякога 1280x720. Когато приложението се изобразява и показва на Full HD екрани, 960 се умножава по 2, 1280 се умножава по 1,33, а 1920 се извежда така, както е.

Пропускайки скучните подробности, стигнахме до извода, че като цяло всички екрани, включително телевизионните екрани, по отношение на елементите и техните размери, са обхванати от едно оформление на дизайна и всички телевизионни екрани са специален случай на общата крос-платформена мрежа, и се състои от пет или шест колони, като среден таблет или настолен компютър. Който се интересува от подробности, да пише в коментарите.

Един потребителски интерфейс за всички платформи

Сега, за да начертаем нова функция, не е нужно да рисуваме оформления за всяка платформа, плюс опции за адаптивност за всяка от тях. Достатъчно е да се покаже едно оформление и неговата адаптивност за всички платформи и устройства с всякаква ширина: телефони - 320-599, всичко останало - 600-1280.

Данни → развитие

Разбира се, колкото и да ни се иска да постигнем напълно унифициран дизайн, всяка платформа има свои собствени уникални характеристики. Въпреки че и мрежата, и Smart TV използват стека ReactJS + TypeScript, приложението Smart TV работи на наследени клиенти WebKit и Presto и следователно не може да споделя стилове с мрежата. И имейл бюлетините са напълно принудени да работят с таблично оформление. В същото време никоя от не-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 диктува промяна в позицията на текста под плаката, което означава, че за тази платформа този компонент в стойността на свойството „indent“ ще съдържа нужните 8 точки на отстъп. Въпреки че това усложнява инфраструктурата на системата за проектиране, то дава допълнителна степен на свобода, оставяйки ни възможността сами да управляваме визуалната „несходство“ на платформите, а не да бъдем заложници на създадената от нас архитектура.

Пиктограми

Иконографията в един дигитален продукт винаги е обемен и не е най-простият подпроект, често изискващ отделен дизайнер. Винаги има много глифове, всеки от тях има няколко размера и цвята, а платформите обикновено се нуждаят от тях в различни формати. Като цяло нямаше причина да не вкараме всичко това в системата за проектиране.

Глифовете се зареждат във векторен формат SVG, а стойностите на цвета се заменят автоматично с променливи. Клиентските приложения могат да ги получат готови за използване – във всякакъв формат и цвят.

предварителен преглед

В допълнение към JSON данните, ние написахме инструмент за предварителен преглед на компоненти - JS приложение, което предава JSON данни в движение през своите генератори за маркиране и стил и показва различни варианти на всеки компонент в браузъра. По същество preview е точно същият клиент като приложенията на платформата и работи със същите данни.

Най-лесният начин да разберете как работи даден компонент е като взаимодействате с него. Затова не използвахме инструменти като Storybook, а направихме интерактивен преглед - можете да докоснете, посочите, щракнете... Когато добавяте нов компонент към системата за проектиране, той се появява в прегледа, така че платформите да имат върху какво да се фокусират, когато внедряването му.

Документация

Въз основа на данните, предоставени на платформите под формата на JSON, автоматично се генерира документация за компонентите. Описан е списък със свойства и възможни типове стойности във всяко от тях. След автоматично генериране информацията може да се изясни ръчно и да се добави текстово описание. Визуализацията и документацията се препращат една към друга на ниво всеки компонент и цялата информация, включена в документацията, е достъпна за разработчиците под формата на допълнителни JSON файлове.

Депрекатор

Друга необходимост беше възможността за подмяна и актуализиране на съществуващи компоненти с течение на времето. Системата за проектиране се е научила да казва на разработчиците кои свойства или дори цели компоненти не могат да бъдат използвани и да ги премахва веднага щом вече не се използват на всички платформи. Все още има много „ръчен“ труд в този процес, но ние не стоим на едно място.

Развитие на клиента

Несъмнено най-сложният етап беше интерпретацията на системните данни за проектиране в кода на всички платформи, които поддържаме. Ако, например, модулните мрежи в мрежата не са нещо ново, тогава разработчиците на собствени мобилни приложения за iOS и Android са работили усилено, преди да разберат как да живеят с тях.

За оформление на екрани на iOS приложения ние използваме два основни механизма, предоставени от iviUIKit: свободно оформление на елементи и оформление на колекции от елементи. Ние използваме VIPER и цялото взаимодействие с iviUIKit е концентрирано във View, а по-голямата част от взаимодействието с Apple UIKit е концентрирано в iviUIKit. Размерите и подредбата на елементите са определени по отношение на колони и синтактични структури, които работят върху собствените ограничения на iOS SDK, което ги прави по-практични. Това особено опрости живота ни при работа с UICollectionView. Написахме няколко персонализирани обвивки за оформления, включително доста сложни. Имаше минимум клиентски код и той стана декларативен.

За генериране на стилове в проекта за Android ние използваме Gradle, превръщайки данните от системата за дизайн в стилове в XML формат. В същото време имаме няколко генератора на различни нива:

• Основен. Данните на примитивите за генератори от по-високо ниво се анализират.
• Ресурс. Изтеглете снимки, икони и други графики.
• Компонент. Те са написани за всеки компонент, който описва какви свойства и как да ги преведете в стилове.

Издания на приложения

След като дизайнерите са начертали нов компонент или са преработили съществуващ, тези промени се въвеждат в системата за проектиране. Разработчиците на всяка платформа прецизират своето генериране на код, за да поддържат промените. След това може да се използва при внедряването на нова функционалност, където този компонент е необходим. По този начин взаимодействието със системата за проектиране не се случва в реално време, а само по време на сглобяване на нови версии. Този подход също така позволява по-добър контрол върху процеса на прехвърляне на данни и гарантира функционалност на кода в клиентски проекти за разработка.

Резултати от

Измина една година, откакто системата за проектиране стана част от инфраструктурата, поддържаща развитието на онлайн киното Ivy, и вече можем да направим някои изводи:

• Това е голям и сложен проект, който изисква постоянни специални ресурси.
• Това ни позволи да създадем наш собствен уникален междуплатформен визуален език, който отговаря на целите на онлайн видео услугата.
• Вече нямаме визуално и функционално изоставащи платформи.

Предварителен преглед на системните компоненти на Ivy design - design.ivi.ru

Източник: www.habr.com