Jiří Cerhan: V SiteOne pracujeme na nástrojích, které propojují svět designu a vývoje

Když byla práce frontendistů na úplném začátku, nebylo zadávání úkolu zrovna ideální. Kvůli zmatkům, nedostatečným podkladům nebo minimálním propojením s backendem bylo tvoření webů pomalejším a řekněme bolestivějším procesem. “Když jsem před deseti lety začínal, přišly mi podklady napsané na psacím stroji, navíc bez diakritiky, a ještě k tomu naskenované, což ten člověk musel udělat na počítači. A aby toho nebylo málo, tak byl JPG v podkladech vzhůru nohama,” popsal Jirka začátky frontendového programování na meetupu.

Pro začátky webového designu se v minulosti využívaly printové nástroje. Ale je jasné, že pokud nástroj vznikl právě pro tyto účely, aplikace do digitálu, přesněji webdesignu, nemůže být žádná velká sláva. Obecně si z toho můžeme vzít ponaučení platné i v současnosti: “Pokud si k tvorbě webu vyberete špatný nástroj, který navíc ještě použijete špatně, nemůžete očekávat dobrý výsledek.”

Narozdíl od printu, pro který vznikají podklady například ve Photoshopu, jsou potřeby webu mnohem širší. Nejde jen totiž o statický obrázek, jde hlavně o systém. Pochopitelně záleží i na vizuální podobě, avšak stěžejní je funkcionalita. Jak šel čas, máme pro tvorbu webdesignu k dispozici stále sofistikovanější nástroje, které umí vytvářet komponenty i jejich instance, poradí si s designovými proměnnými ve smyslu designových tokenů, jsou narozdíl od JPG responzivní a přeskládají se, disponují podobnými možnostmi jako CSS a můžeme v nich prototypovat wireframes, interakce či animace, ale dokonce i interaktivní komponenty.

“A to je to, o čem často mluvím, nástroje, které jsme pro design používali dřív, nám práci moc neulehčovaly. To se ale v současnosti mění. Figma se tedy stává určitou databází pro data související s designem. Pojďme se tedy podívat, co všechno v té Figmě najdeme,” zahájil Jirka popis práce ve Figmě jako v single source of truth frontendového vývoje.

“Na úvod je třeba říct, že řešíme její funkcionalitu ve vztahu k frontentovému vývoji. Rozhodl jsem se vám přiblížit výhody použití Figmy jako single source of truth pro frontendový vývoj. Nechci být ale jednostranný a na konci objasním i nevýhody, na které můžete při jejím použití v tomto kontextu narazit,” upřesnil Jirka.

Figma je ideální nástroj pro přípravu tvorby webu, protože do ní můžeme zanést například rozhraní a strukturu komponent. Navíc lze snadno odvodit další parametry jako například importy a exporty. V kódu totiž mohou komponenty vytvářet instance jiných komponent, ale aby toho byly schopny, musí je naimportovat. Ve Figmě tyhle instance vidíme a můžeme od nich tyto importy odvodit.

Spoustu parametrů může být definováno tak, že budou odpovídat implementaci v kódu 1:1. To potom vývojářům pomáhá rychle se v kódu zorientovat a usnadňuje komunikaci s Designery.

Na proměnné ve smyslu designových tokenů existuje ve Figmě plugin Figma Tokens. Dá se s nimi pracovat velmi podobně jako v kódu. K dispozici je tu i prototypování animací. To je výhodné proto, že animace jsou pak součástí přímo podkladů pro vývojáře, kteří se na ně nemusí doptávat zvlášť, nebo je nenaimplementují jinak, než Designer zamýšlel. “K dispozici jsou vám i nějaká CSS, Figma je i exportuje, ale do toho bych se nepouštěl. Je to stále hodně daleko od toho, co reálně implementujeme a bez ručních zásahů se to neobejde,” doporučil Jirka.

A doplňuje: “To znamená, že design se dneska hodně přibližuje implementaci v kódu a podobá se to nejen vzhledově, ale i datově. Navíc Figma má API, takže z ní data dostanete celkem pohodlně ven. A jakmile máme data a máme programátory, tak je jen otázka času, než se začnou dít velký věci.”

“Co vnímám jako nejtěžší na spolupráci Design oddělení, Frontendu a Backendu, potenciálně Accountů a Project Managerů a samozřejmě klienta, je domluvit se na rozhraních:
- Jaká data a v jaké podobě potřebujeme a jak je budeme seskupovat dohromady?
- Jak budou jednotlivé prvky rozdělené na komponenty a jaké možnosti komponenta má?

- Jakým způsobem organizujeme a používáme design proměnné?
- Kde jedna komponenta končí a kde začíná další?

Když se pořádně nedomluvíme, snadno se stane, že se jednotlivé části na konci nesejdou a bude nám to komplikovat práci. Pokud bychom měli jedno místo, kde se na tomhle můžeme domluvit, hodně nám to pomůže,” hodnotil Jirka.

Pojmout veškerou agendu kolem toho, jak jsme naložili s fungováním Figmy v SiteOne, by, alespoň podle Jirky, vydalo na semestrální kurz. Nicméně i tak její využití přiblížil.

Naše práce je pořád work in progress a ještě nějakou chvíli potrvá, než bude ve finální podobě, ale už teď víme, že má obrovský potenciál. Řekli jsme si, že když máme data a programátory, vytvoříme užitečný nástroj, který už designové oddělení používá na jiných projektech. “Pokud bych ho měl popsat co nejkratším způsobem, řekl bych, že jde o našlapanější scaffolding a výsledek bude takový, že budeme mít vygenerované základní stavební bloky projektu a můžeme začít plánovat vývoj,” řekl Jirka.

“Na obrázku můžete vidět, jak jsme rozdělili plán webu na jednotlivé komponenty,”<span> vysvětlil. </span>“Pak nadefinujeme rozhraní a máme jasno, jak bude podle dat stránka vypadat. Všimněte si, že v tuto chvíli nemusíme mít vůbec hotovou grafiku. Nicméně máme k dispozici rozhraní pro komponenty a jejich datovou potřebu, což ocení i na Backendu. Můžeme se tedy pustit do práce ještě předtím, než je hotová grafika. Na tom můžeme začít pracovat teď, pokud jsme ho neměli nadefinovaný už od začátku. Ať už interně nebo například od klienta,”<span> doplnil.</span>

“Tento postup na vývoji ušetří dost práce. Umožní lepší rozdělení jednotlivých úkolů mezi specialisty. Mohou se na tom podílet lidé, kteří dělají jen HTML a CSS, můžou se připojit ti, kteří pracují jenom na cointainerech nebo to napojují na data, můžeme tam pustit i další kolegy, vzhledem k tomu, že vše důležité máme zakotvené ve vygenerovaných částech kódu, do kterých vývojáři nezasahují,” vysvětlil Jirka.

Díky tomu máme tu možnost dělat více věcí současně ve více lidech. Jde o perfektní podklady pro vývojáře. S tím souvisí i lepší developer experience. Navíc je v práci mnohem větší pořádek, díky generování máme všude jednotnou architekturu a velmi podobně pracujeme s komponentami na více technologiích. Celý Storybook se generuje automaticky, takže nemusíme ručně psát a udržovat stories. Storybook navíc není jenom na správu komponent a dokumentaci, pomůže nám například i s testy.

Podklady ve Figmě musejí být hodně precizně připravené a udržované. V případě, že jde o single source of truth, data musí být v pořádku a celý tým se musí podílet na návrhu. Může se stát, že Graphic Designer nepřipraví podklady tak, jak by si vývojáři představovali, takže na tom musejí spolupracovat. Je to trochu náročnější v rámci postupu práce, ve své podstatě je to ale moc dobře. My v SiteOne jsme zastánci toho, že by spolu měli kolegové komunikovat co nejvíce už při navrhování. Figma samozřejmě nemůže umět všechno, ale dá se to dohnat různými pluginy. A programátoři mají kapacitu si s tím poradit.

Další možnou nevýhodou je fakt, že tento systém klade mnohem více nároků na designery, tím i více času na jejich práci, což se někdy může zdát jako neřešitelná překážka. Na druhou stranu to ušetří dost práce vývojářům, kterých je kritický nedostatek. Navíc designérům může s přípravou komponent někdo pomoci, potom stačí, aby dodržovali domluvený postup a pracovali tak, aby nedocházelo ke změnám připravených rozhraní.

Někdo taky musí napsat a udržovat Code Generators. Update už vygenerovaných částí musí být v souladu s Figmou, nesmí se to měnit samostatně, pokud by někdo začal zasahovat do už vygenerovaných částí, při další aktualizaci by mohlo dojít k znehodnocení hotové práce.

V SiteOne se dále snažíme ve Figmě začít generovat podklady pro řízení projektů, jako jsou různé tasky nebo tabulky pro odhady, které se automaticky založí v ticketovacím systému. Chceme taky další Figma plugin pro metadata, aby nám pomohl s dalším generováním. Určitě chceme rozšiřovat možnosti využití dat. Chceme pracovat s diagramy, aby se pak člověk v celku lépe orientoval, nebo dělat nad daty další užitečné analýzy.

Máme v plánu transformaci stateless komponentů na jinou technologii v tom smyslu, že i když budete mít práci zapsanou v Reactu, stačí jen drobně pozměnit syntax a můžeme tyto stateless komponenty použít i na jiné technologii. Markup, styl i rozhraní zůstávají ekvivalentní nezávisle na technologii. Zatím je to jen myšlenka se kterou si pohráváme, ale v SiteOne to nepovažujeme za nemožné. Cílem je využívat jedny komponenty na různých technologií, přegenerovávat je automaticky.

“Dobře zvolený nástroj dokáže ušetřit spousty práce, což se neobejde bez toho, že s ním umíte velmi dobře pracovat. Je potřeba budovat přesahy a propojovat lidi napříč odděleními, přimět je víc komunikovat, zamyslet se nad tím, s čím a jak pracuje ten druhý. Když se kolegové sladí a funguje to, dost to pomáhá. Do budoucna se bude víc a víc kódu generovat, tohle je teprve začátek. Nástroje na generování se rozjíždějí a no code platforem bude přibývat. Ale nebojím se, že bychom se my, vývojáři, museli bát o práci,” uzavřel Jirka.