Od zestawu interfejsu użytkownika do systemu projektowego

Ivy kino online

Kiedy na początku 2017 roku po raz pierwszy pomyśleliśmy o stworzeniu własnego systemu dostarczania rozwiązań od projektu do kodu, wielu już o tym mówiło, a niektórzy nawet to robili. Jednak do dziś niewiele wiadomo na temat doświadczeń w budowaniu wieloplatformowych systemów projektowych, nie ma też jasnych i sprawdzonych receptur opisujących technologie i metody takiego przekształcenia procesu realizacji projektu w już działający produkt. A przez „elementy kodu” często mają na myśli bardzo różne rzeczy.

Tymczasem firma z roku na rok podwajała zatrudnienie – konieczne było skalowanie działu projektowego i optymalizacja procesów tworzenia i przekazywania makiet do rozwoju. Mnożymy to wszystko przez „zoo” platform wymagających wsparcia i otrzymujemy pozory babilońskiego pandemonium, które po prostu nie jest w stanie „zrobić tego normalnie” i wygenerować dochodu. Rozwój platform często przebiegał równolegle, a ta sama funkcjonalność mogła zostać udostępniona na różnych platformach z kilkumiesięcznym opóźnieniem.


Oddzielne zestawy układów dla każdej platformy

Tradycyjnie zaczynaliśmy od problemów, które system projektowy pomógłby rozwiązać, i sformułowaliśmy wymagania dotyczące jego projektu. Oprócz stworzenia jednolitego języka wizualnego, zwiększenia szybkości układu i rozwoju oraz ogólnej poprawy jakości produktu, istotne było maksymalne ujednolicenie projektu. Jest to konieczne, aby rozwój funkcjonalności stał się możliwy na wszystkich naszych platformach jednocześnie: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku – bez konieczności pracy nad każdą z nich z osobna. I udało nam się!

Projekt → dane

Po osiągnięciu zasadniczych ustaleń pomiędzy działami produktu i rozwoju zasiedliśmy do wybrania stosu technologicznego i opracowania szczegółów całego procesu - od układu po wydanie. Aby w pełni zautomatyzować proces przekazywania projektu do fazy deweloperskiej, sprawdziliśmy możliwość analizowania parametrów komponentów bezpośrednio z plików Sketch z układami. Okazało się, że znalezienie potrzebnych fragmentów kodu i wyodrębnienie potrzebnych parametrów było przedsięwzięciem złożonym i niebezpiecznym. Po pierwsze, projektanci będą musieli zachować szczególną ostrożność w nazywaniu wszystkich warstw kodu źródłowego, po drugie, działa to tylko w przypadku najprostszych komponentów, a po trzecie, uzależnienie od cudzej technologii i struktury kodu oryginalnego układu Sketch zagraża przyszłości całego projekt. Zdecydowaliśmy się porzucić automatyzację w tym obszarze. Tak oto pojawiła się pierwsza osoba w zespole projektowym systemu, której wejściem są układy projektowe, a wyjściem są dane opisujące wszystkie parametry komponentów i uporządkowane hierarchicznie zgodnie z metodyką projektowania atomowego.

Jedyne, co pozostało do zrobienia, to gdzie i jak przechowywać dane, jak przenieść je do rozwoju i jak je interpretować w fazie rozwoju na wszystkich obsługiwanych przez nas platformach. Wieczór przestał być leniwy... Efektem regularnych spotkań grupy roboczej składającej się z projektantów i liderów zespołów z każdej platformy było uzgodnienie co następuje.

Ręcznie analizujemy obraz na elementy atomowe: czcionki, kolory, przezroczystość, wcięcia, zaokrąglenia, ikony, obrazy i czas trwania animacji. I zbieramy z tego przyciski, wejścia, checkboxy, widżety kart bankowych itp. Stylom dowolnego z poziomów przypisujemy nazwy niesemantyczne, z wyjątkiem ikon, na przykład nazwy miast, nazwy nimf, Pokemonów, samochodów marki... Warunek jest tylko jeden - lista nie powinna być wcześniej wyczerpana, jak skończą się stylizacje - pokaz musi się odbyć! Nie powinieneś dać się ponieść semantyce, abyś nie musiał na przykład dodawać środkowego przycisku między „małym” a „średnim”.

Język wizualny

Programistom pozostało zastanowienie się, jak przechowywać i przesyłać dane w sposób dostosowany do wszystkich platform, a projektanci musieli zaprojektować elementy interfejsu, które dobrze wyglądają i skutecznie działają na całej flocie obsługiwanych urządzeń.

Wcześniej udało nam się już „przetestować” większość elementów projektu w aplikacji na Windows 10, który wówczas był dla nas nową platformą, czyli wymagał renderowania i programowania „od zera”. Rysując go, byliśmy w stanie przygotować i przetestować większość komponentów oraz zrozumieć, które z nich miały znaleźć się w przyszłym systemie projektowym Eevee. Bez takiej piaskownicy takie doświadczenie można by zdobyć jedynie poprzez dużą liczbę iteracji na już działających platformach, a to zajęłoby ponad rok.

Ponowne wykorzystanie tych samych komponentów na różnych platformach znacznie zmniejsza liczbę układów i tablicę danych systemu projektowego, więc projekt musiał rozwiązać jeszcze jeden problem, nieopisywany wcześniej w praktykach projektowania i rozwoju produktu - jak np. czy przycisk do telefonów i tabletów można ponownie wykorzystać w telewizorach? A co zrobić z rozmiarami czcionek i elementów na tak różnych platformach?

Oczywiście konieczne było zaprojektowanie wieloplatformowej siatki modułowej, która ustalałaby rozmiary tekstu i elementów potrzebne dla każdej konkretnej platformy. Jako punkt wyjścia dla siatki wybraliśmy wielkość i liczbę plakatów filmowych, które chcemy zobaczyć na danym ekranie i na tej podstawie sformułowaliśmy zasadę konstruowania kolumn siatki pod warunkiem, że szerokość jednej kolumny jest równa do szerokości plakatu.

Teraz musimy doprowadzić wszystkie duże ekrany do tego samego rozmiaru układu i dopasować je do wspólnej siatki. Apple TV i Roku są zaprojektowane w rozmiarze 1920x1080, Android TV - 960x540, Smart TV, w zależności od dostawcy, są takie same, ale czasami 1280x720. Gdy aplikacja jest renderowana i wyświetlana na ekranach Full HD, 960 jest mnożone przez 2, 1280 przez 1,33, a 1920 jest wysyłane w niezmienionej postaci.

Pomijając nudne szczegóły, doszliśmy do wniosku, że w ogóle wszystkie ekrany, w tym telewizory, pod względem elementów i ich rozmiarów, objęte są jednym układem projektowym, a wszystkie ekrany telewizyjne stanowią szczególny przypadek ogólnej siatki międzyplatformowej, i składa się z pięciu lub sześciu kolumn, jak przeciętny tablet lub komputer stacjonarny. Kto jest zainteresowany szczegółami, niech idzie w komentarzach.

Pojedynczy interfejs użytkownika dla wszystkich platform

Teraz, aby narysować nową funkcję, nie musimy rysować układów dla każdej platformy ani opcji adaptacji dla każdej z nich. Wystarczy pokazać jeden układ i jego możliwość dostosowania do wszystkich platform i urządzeń o dowolnej szerokości: telefony - 320-599, wszystko inne - 600-1280.

Dane → rozwój

Oczywiście, choć bardzo chcielibyśmy osiągnąć całkowicie ujednolicony projekt, każda platforma ma swoje unikalne cechy. Mimo że zarówno Internet, jak i Smart TV używają stosu ReactJS + TypeScript, aplikacja Smart TV działa na starszych klientach WebKit i Presto i dlatego nie może udostępniać stylów w Internecie. Biuletyny e-mailowe są całkowicie zmuszone do pracy w układzie tabelarycznym. Jednocześnie żadna z platform innych niż HTML nie używa ani nie planuje używać React Native ani żadnego z jego analogów, obawiając się pogorszenia wydajności, ponieważ mamy zbyt wiele niestandardowych układów, kolekcji ze złożoną logiką aktualizacji, obrazów i filmów. Dlatego powszechny schemat dostarczania gotowych stylów CSS lub komponentów React nie jest dla nas odpowiedni. Dlatego zdecydowaliśmy się na transmisję danych w formacie JSON, opisując wartości w abstrakcyjnej formie deklaratywnej.

Zatem własność rounding: 8 Aplikacja Windows 10 konwertuje się do CornerRadius="8", sieć - border-radius: 8px, Android - android:radius="8dp", iOS- self.layer.cornerRadius = 8.0.
Nieruchomość offsetTop: 12 ten sam klient sieciowy w różnych przypadkach może interpretować jako top, margin-top, padding-top lub transform

Deklaratywność opisu oznacza również, że jeśli platforma z technicznego punktu widzenia nie może wykorzystać właściwości lub jej wartości, może ją zignorować. Jeśli chodzi o terminologię, stworzyliśmy coś w rodzaju języka esperanto: niektóre zostały zaczerpnięte z Androida, inne z SVG, inne z CSS.

Jeśli na danej platformie potrzebujesz inaczej wyświetlić elementy, wdrożyliśmy możliwość przeniesienia odpowiedniej generacji danych w postaci osobnego pliku JSON. Przykładowo stan „w centrum uwagi” dla Smart TV dyktuje zmianę położenia tekstu pod plakatem, co oznacza, że ​​dla tej platformy ten komponent w wartości właściwości „wcięcie” będzie zawierał potrzebnych 8 punktów wcięcia. Chociaż komplikuje to infrastrukturę systemu projektowego, daje dodatkowy stopień swobody, pozostawiając nam możliwość samodzielnego zarządzania wizualną „odmiennością” platform i nie bycia zakładnikiem stworzonej przez nas architektury.

Piktogramy

Ikonografia w produkcie cyfrowym to zawsze obszerny i nie najprostszy podprojekt, często wymagający osobnego projektanta. Glifów jest zawsze sporo, każdy z nich ma kilka rozmiarów i kolorów, a platformy zazwyczaj potrzebują ich w różnych formatach. Ogólnie rzecz biorąc, nie było powodu, aby nie umieścić tego wszystkiego w systemie projektowym.

Glify ładowane są w formacie wektorowym SVG, a wartości kolorów są automatycznie zastępowane zmiennymi. Aplikacje klienckie mogą otrzymać je gotowe do użycia – w dowolnym formacie i kolorze.

Zapowiedź

Oprócz danych JSON napisaliśmy narzędzie do podglądu komponentów - aplikację JS, która na bieżąco przekazuje dane JSON przez generatory znaczników i stylów oraz wyświetla różne odmiany każdego komponentu w przeglądarce. Zasadniczo podgląd jest dokładnie tym samym klientem, co aplikacje platformy i działa z tymi samymi danymi.

Najłatwiejszym sposobem zrozumienia działania konkretnego komponentu jest interakcja z nim. Dlatego nie korzystaliśmy z narzędzi takich jak Storybook, ale zrobiliśmy interaktywny podgląd - możesz dotknąć, wskazać, kliknąć... Kiedy dodajesz nowy komponent do systemu projektowania, pojawia się on w podglądzie, dzięki czemu platformy mają na czym się skupić wdrażając to.

Dokumentacja

Na podstawie danych dostarczanych do platform w formie JSON, automatycznie generowana jest dokumentacja komponentów. Opisano listę właściwości i możliwe typy wartości w każdej z nich. Po automatycznym wygenerowaniu informacje można doprecyzować ręcznie i dodać opis tekstowy. Podgląd i dokumentacja są ze sobą powiązane na poziomie każdego komponentu, a wszystkie informacje zawarte w dokumentacji są dostępne dla programistów w postaci dodatkowych plików JSON.

Deprecjoner

Kolejną koniecznością była możliwość wymiany i aktualizacji istniejących komponentów w miarę upływu czasu. System projektowy nauczył się mówić programistom, których właściwości lub nawet całych komponentów nie można wykorzystać i usuwać je, gdy tylko przestaną być używane na wszystkich platformach. W tym procesie nadal jest dużo pracy „ręcznej”, ale nie stoimy w miejscu.

Rozwój klienta

Niewątpliwie najbardziej złożonym etapem była interpretacja danych systemu projektowego w kodzie wszystkich obsługiwanych przez nas platform. Jeśli na przykład siatki modułowe w sieci nie są czymś nowym, to twórcy natywnych aplikacji mobilnych na iOS i Androida ciężko pracowali, zanim wymyślili, jak z tym żyć.

Do układania ekranów aplikacji iOS wykorzystujemy dwa podstawowe mechanizmy udostępniane przez iviUIKit: swobodny układ elementów oraz układ kolekcji elementów. Używamy VIPER i cała interakcja z iviUIKit koncentruje się w View, a większość interakcji z Apple UIKit koncentruje się w iviUIKit. Rozmiary i rozmieszczenie elementów są określone w kategoriach kolumn i struktur składniowych, które działają w oparciu o natywne ograniczenia zestawu SDK systemu iOS, dzięki czemu są bardziej praktyczne. To szczególnie uprościło nam życie podczas pracy z UICollectionView. Napisaliśmy kilka niestandardowych opakowań dla układów, w tym dość skomplikowanych. Kod klienta był minimalny i stał się deklaratywny.

Do generowania stylów w projekcie Android używamy Gradle, zamieniając dane systemu projektowego na style w formacie XML. Jednocześnie mamy kilka generatorów o różnym poziomie:

• Podstawowy. Analizowane są dane prymitywów dla generatorów wyższego poziomu.
• Ratunek. Pobierz obrazy, ikony i inną grafikę.
• Część. Są one napisane dla każdego komponentu, który opisuje jakie właściwości i jak je przełożyć na style.

Wydania aplikacji

Po tym, jak projektanci narysowali nowy komponent lub przeprojektowali istniejący, zmiany te są wprowadzane do systemu projektowego. Twórcy każdej platformy dostrajają generowanie kodu, aby wspierać zmiany. Następnie można go wykorzystać do wdrożenia nowej funkcjonalności tam, gdzie ten komponent jest potrzebny. Zatem interakcja z systemem projektowym nie odbywa się w czasie rzeczywistym, a jedynie w momencie montażu nowych wydań. Takie podejście pozwala również na lepszą kontrolę nad procesem przesyłania danych i zapewnia funkcjonalność kodu w projektach rozwojowych klienta.

Wyniki

Minął rok odkąd projektowy system stał się częścią infrastruktury wspierającej rozwój kina internetowego Ivy i już możemy wyciągnąć pewne wnioski:

• Jest to duży i złożony projekt, który wymaga stałych, dedykowanych zasobów.
• Pozwoliło nam to stworzyć własny, unikalny, wieloplatformowy język wizualny, który spełnia cele usługi wideo online.
• Nie mamy już platform opóźnionych wizualnie i funkcjonalnie.

Podgląd komponentów systemu projektowego Ivy - design.ivi.ru

Źródło: www.habr.com