Frontend developeri i dizajneri, detaljno postavljanje dizajnerskog sustava olakšat će vam svima život!

Frontend developeri i dizajneri, detaljno postavljanje dizajnerskog sustava olakšat će vam svima život!

Dizajneri i frontend developeri do krajnjeg rezultata svog rada dolaze na skroz drugačije načine i često sami dizajn drugačije interno percipiraju. No, ako svoj posao dobro odrade, krajnji rezultat rada frontend developera savršeno će zrcaliti rad dizajnera...

Svaki dizajn analizom možemo rastaviti na proste faktore, uvijek možemo razaznati specifične elemente korisničkog sučelja, obrasce dizajna korisničkog iskustva i dizajn tokene koji se kroz cijeli taj dizajn provlače i ponavljaju. Možemo definirati okvire i ograničenja dizajnerskog sustava (design system) u tome kako se u dizajnu korištene boje, tipografija i sl.

Na neki način svaki dizajn u sebi ima implicitno ugrađen određeni sustav, taj sustav možda nije namjerno, direktno definiran i komuniciran kroz dizajn fazu projekta, ali svejedno, sam po sebi on komunicira svoje specifične obrasce i okvire koji mu daju njegov identitet.

Te obrasce i okvire programeri interpretiraju i oni postaju obrasci i okviri arhitekture koda.

Za većinu manjih projekata eksplicitno definiranje i dokumentiranje dizajnerskog sustava možda nije nužno. Ako su promjene na projektu s vremenom rijetke i nisu zahtjevne, relativno je jednostavno postići da sve ostane u harmoniji sa svim ostalim što se tu već nalazi i sa strane dizajna i sa strane koda.

S druge strane, za velike projekte, koji će se dugo razvijati i evoluirati kako vrijeme bude prolazilo, kako dodajemo nove mogućnosti i dok se dizajneri, programeri i ostali uključeni izmjenjuju u međuvremenu, lako se izgubi konzistencija u dizajnu, izgubi se organiziranosti i održivost koda, a možemo i narušiti dojam identiteta brenda i upotrebljivost aplikacije krajnjim korisnicima.

Pronalaženje zajedničkog jezika

Frontend programeri i dizajneri pronalaze se u zanimljivoj jukstapoziciji, ako svoj posao dobro odrade, na površinskoj razini rezultat rada frontend developera savršeno će zrcaliti rad dizajnera, ali dizajneri i developeri do krajnjeg rezultata svog rada dolaze na skroz drugačije načine i često sami dizajn drugačije interno percipiraju.

“The prickly people are tough-minded, rigorous, and precise, and like to stress differences and divisions between things…. The gooey people are tender-minded romanticist who love wide generalizations and grand syntheses” ~ Alan W. Watts

Kako bi dizajnerski sustav stvarno bio koristan u praksi na našim projektima, dizajneri i frontend developeri trebaju surađivati i ulagati vrijeme u eksplicitno definiranje i dokumentiranje dizajn odluka, obrazaca i drugih elemenata dizajnerskog sustava.

You wouldn’t know what a prickle was unless you knew what a goo was. Because life isn’t either prickles or goo, it’s either gooey prickles or prickly goo.

U ovom članku želim ponuditi ideju inspiriranu “oblicima” u TypeScriptu, ideju za koju mislim da nam može pomoći da bolje komuniciramo i surađujemo na projektima postavljanjem zajedničkog jezika i mentalnog modela za koncepte koji postoje u korisničkom sučelju s obje strane zrcala, sa strane dizajna i sa strane koda.

Ideja je da definiramo “oblik dizajnerskog sustava” kao središnju reprezentaciju ukupnog dizajnerskog sustava koju je jednostavno održavati, unaprjeđivati i mijenjati.

Znači, želim dizajnere učiti typescript?

Ne baš, ali za potrebe ovoga članka ne bi škodilo da kratko objasnim što je to typescript i kako ga mi kao developeri koristimo.

Typescript je superset JavaScripta koji nama kao developerima omogućava da budemo strogi oko tipova podataka s kojima radimo.

S typescriptom možemo definirati recimo da se neka komponenta ne može prikazati bez da joj se dodjeli naslov, mora imati datum objave u specifičnom formatu i može, ali ne mora imati i svoju pripadajuću sliku.

Ako onda negdje pokušamo koristiti našu komponentu bez da joj damo naslov ili ako prekršimo neko drugo pravilo koje smo postavili za njene podatke, typescript će nas upozoriti i naša aplikacija neće raditi dok to ne ispravimo.

Ilustrativan način razmišljanja o ovom konceptu je putem analogije s dječjim igračkama koje uče djecu o oblicima. Djeca pokušavaju shvatiti kako upariti pripadajuće oblike i zaraditi jedno veliko ‘bravo’ kad oblici napokon sjednu na svoje mjesto.

Koncept oblika je jednako jednostavan i s typescriptom u našim komponentama: ako koristimo krivi oblik podataka u našoj komponenti, podatci jednostavno “neće proći” i typescript će nam dati informacije o tome što trebamo ispraviti.

Slične prednosti koje kao developeri dobijemo s typescriptom nam mogu biti korisne ako ih primijenimo ne samo na komponente nego i na cijeli dizajnerski sustav.

Kada definiramo oblike, garantiramo konzistentnost u tome kako se naše komponente mogu koristiti, omogućujemo da više developera može brzo razumjeti kako se komponenta koju je netko drugi razvio može i treba koristiti tako da pogledaju njen oblik (sučelje/interface).

Kada širimo funkcionalnost neke komponente, obično prvo krenemo širenjem njenog oblika, u slučajevima kada vidimo da oblik postaje prenapuhan i ima previše opcija, to nam može biti rani signal da bi trebali razmisliti o restrukturiranju koda.

Izborna traka? Siva traka? Administracijska traka!

Prije nego krenemo s razvojem želimo napraviti inventuru sučelja (interface inventory) – želimo pregledati cijeli dizajn i napraviti plan o tome kako želimo podijeliti stranice, layoute i elemente, kako ćemo ih nazivati i tako dalje.

Frontend developeri su ključni u ovom koraku, jer će producirana struktura biti nacrt za arhitekturu njihovog projekta, ali korisno je da se inventura sučelja radi s raznolikom grupom članova tima.

Najvredniji trenutci budu oni kad se različite perspektive sudare.

Parafrazirat ću primjer koji sam za čuo od Bred Frosta koji daje primjer projekta na kojem je dizajner mislio da je dizajnirao “izbornu traku”. Projekt menadžer je “izbornu traku” uvijek zvao siva traka, a u kodu ju je developer nazvao “administracijska traka”.

Kada inventuru sučelja radimo zajedno kao tim, to nam pomaže da uklonimo ili bar minimiziramo moguća nerazumijevanja koja se mogu pojaviti kasnije u razvoju.

Krajnji “opipljivi” rezultat inventure sučelja bi trebao biti jedan dokument koji je uvijek krajnji izvor istine definicija, naziva, hijerarhije i kategorizacije dijelova i cijele strukture našeg dizajn sistema.

Sljedeći primjer predočava generalnu ideju, ali može biti dodatno razrađen i modificiran za specifične načine koje bi odgovarale drugim timovima.

Prvo da objasnim što se tu gore događa za one koji možda nisu najbolji s typescriptom.

U našoj JSON definiciji jedan UIElement, opisujemo tako da mu damo ime, možemo ga dodati u kategoriju, može imati svoje manje dijelove od kojih se sastoji, možemo ga linkati na originalni dizajn te definirati o kojim drugim unutrašnjim i vanjskim skriptama te komponentama ovisi. UICategory tip nam samo pomaže da možemo rekurzivno definirati strukturu s koliko god levela dubine želimo.

Kao potencijalne dodatne informacije možemo ostaviti opciju dodavanja linkova na cijeli repozitoriji/dizajn/storybook, to kasnije može biti korisno, ali za potrebe ovog članka nije nam toliko bitno.

Prednosti JSON definicije… su mnogobrojne.

Uobičajen zadatak na radionicama izrade inventure sučelja bude da grupa dobije zadatak izrezati škarama elemente raznih stranica web sajta ili aplikacije i organizirati ih u kategorije. Sličan rezultat u digitalnom obliku najlakše možemo postići koristeći artboard bilo kojeg dizajn programa (veliki plus su alati koji omogućavaju kolaboraciju uživo – Figma, Miro…).

Umjesto rezanja škarama, dijelove dizajna možemo screenshotati pa grupirati, nazivati i lijepiti na artboard kako se zajedno dogovaramo tijekom procesa. Ako nakon toga rezultat našeg procesa prevedemo u JSON strukturu to nam otvara nekoliko zanimljivih mogućnosti. Primjerice, možemo kreirati skriptu koja bi nam na osnovi tog JSON-a pomogla pri kreiranju strukture projekta.

U primjeru JSON-a kojeg sam naveo imamo dovoljno informacija da naša skripta može kreirati datoteke svih komponenti, layoutova i stranica u mapama gdje se oni trebaju nalaziti. Ovisno o vašem CSS stacku, iz dizajn tokena možete generirati Sass varijable, tailwind konfiguraciju, custom varijable ili što god vam drugo može zatrebati za apstraktiranje tematskog sloja.

Istim principom taj JSON fajl može nam pomoći napraviti programatski test koji bi provjeravao da su struktura i naming pa čak i korišteni dizajn tokeni unutar projekta u skladu s definicijom u JSON-u i s time u skladu s dizajnerskim sustavom.

Održavanjem definicije dizajnerskog sustava ažurnom, prisiljavamo se da svaku novu izmjenu koju uvedemo, s ostatkom tima vidimo u kontekstu cijelog sustava. To nam pomaže da cijeli projekt ostane organiziran, konzistentan i održiv.

Ako JSON definiciju našeg dizajnerskog sustava držimo u repozitoriju zajedno s kodom, točno ćemo putem povijesti promjena moći vidjeti kako se dizajnerski sustav razvijao kroz vrijeme.

Inventura sučelja minimalan je, a ključan proces

Izradu inventure sučelja preporučio bi za svaki projekt koji se aktivno razvija, bez obzira započinje li tek sada ili postoji već neko vrijeme.

Ako se radi o postojećem projektu, bilo bi najbolje kad bi pokušali zaboraviti kako su različiti dijelovi već nazvani u kodu ili dizajnu i truditi se dokumentirati idealno stanje prema kojemu se želimo kretati, a ne samo dokumentirati ono što je već tu.

Kada se u budućnosti dogodi da se u dizajn primjeni neka nadogradnja ili u razvoju shvatimo da bi mijenjanjem strukture donijela neke prednosti, nove promjene bi trebali uvijek dokumentirati u JSON-u.

Ovisno o raznim faktorima, vrijeme koje ćemo na projektu posvetiti održavanju dizajnerskog sustava naveliko će varirati. Izrade inventure sučelja i održavanje samog JSON dokumenta ažurnim ne iziskuje puno vremena, a samo za sebe nam pomaže naći zajednički jezik među timom i držati projekt sistematiziranim i konzistentnim.

Vrijeme za skaliranje?

Kada bi naš dizajn sistem u svojoj implementaciju bio u potpunosti u skladu s JSON definicijom to bi uključivalo da korišteni design tokeni, komponente i sve njihove varijacije postoje jednako izdvojene, kategorizirane i imenovane i u kodu i u dizajn alatu, te dokumentirane kroz alat kao storybook i tako dalje ovisno koliko duboko u detalje na danom projektu u danom trenutku želimo ići.

Možda nikad ćemo dostići 100% usklađenosti dizajnerskog sustava, dizajna u našim dizajn alatima, u organizaciji koda i na samom živom proizvodu, ali dok god imamo definirano idealno stanje na jednome mjestu, imat ćemo bolju perspektivu iz koje možemo vagati koji dio vremena ulagati u dodatni razvoj i rast samog proizvoda, a koliki u usklađivanje i usavršavanje dizajnerskog sustava kako bi buduća unaprjeđenja bila što jednostavnija.

https://www.netokracija.com/newsletter

Pravila ponašanja

Na Netokraciji za vas stvaramo kvalitetan, autorski potpisan sadržaj i zaista se veselimo vašim kvalitetnim, kontruktivnim komentarima. Poštujmo stoga jedni druge prilikom komentiranja držeći se sljedećih pravila ponašanja:

  • Ne budite 💩: Nema vrijeđanja, diskriminiranja, ni psovanja (osim ako nije osobni izričaj, ali onda neka psovka bude općenita, a ne usmjerena prema nekome)
  • Samo kvalitetna rasprava, manje trolanja: Ne morate se ni sa kim slagati, ali budite konstruktivni i doprinesite raspravi! Svako trolanje, flameanje, koliko god "plesalo" na granici, leti van.
  • Imenom i prezimenom, nismo Anonymous 👤: Autor sadržaja stoji iza svog sadržaja, stoga stojite i vi iza svog komentara. Koristimo ime i prezime (Hrvoje Lončar) ili barem ime i inicijala (Hrvoje L.) te pravu email adresu. Kako koristimo podatke koje tamo ostavljate? Bacite oko na našu izjavu o privatnosti.

Sve ostale komentare ćemo s guštom spaliti, jer ne zaslužuju svoje mjesto na internetu.

Komentari

  1. Borna

    Borna

    20. 07. 2021. u 1:32 pm Odgovori

    Radim front i dizajn već više od 10 godina, ali ja ne razumijem što je pjesnik htio reći. Više mi ovo vuče na teoriju, a manje na stvarna iskustva s dizajnerima i projektima. Nikad mi nije palo na pamet davit dizajnere s typescriptom, pretočim dizajn u dynamic styleguide component library, ali i to samo za veće projekte. Također imenovanje komponenti je moja odgovornost, ne dizajnera, a i to nije znanost jer postoji bootstrap gdje se može može kopirati najbolja praksa imenovanja komponenti za veliku većinu njih ako već idemo u smjeru generičkih naziva tipa “Card”, “Button”, “Footer” itd.

Odgovori

Tvoja e-mail adresa neće biti objavljena.

Popularno

Digitalni mediji

Kroz 3 godine hrvatski mediji morat će odlučiti: Više oglašavanja ili naplata sadržaja!

2020. pamtit ćemo po mnogo toga, ali i po činjenici da je naplaćivanje online sadržaja u Hrvatskoj napokon ozbiljno krenulo, a kakva su iskustva nakon prvog razdoblja provođenja - otkrivamo u razgovoru s 24sata, Telegramom te Večernjim i Jutarnjim listom.

Startupi i poslovanje

Je li primjer Gamechucka, koji hvali Radnička fronta, socijalizam ili klasični startuperski model?

Ako ti Radnička fronta hvali firmu, to je znak da s firmom nešto ne štima! - jedan je od komentara iz burne i zanimljive rasprave koju je u Facebook grupi Developers Hrvatska Relaxed pokrenuo članak objavljen na web stranici Radničke fronte, a u kojem se kao pozitivan primjer hvali poslovanje i organizacija zagrebačkog gejmerskog studija Gamechuck.

Startupi i poslovanje

Vedran Tolić, Q agency: “Zajedno s klijentima radimo na strategiji treba li im određeni proizvod, a ne samo kako ćemo ga napraviti”

Kakve su poslovne strategije i mindset lansirale agenciju Q da od pozicije gdje su značajno usmjereni na turističke projekte dođu do medtecha i fintecha pa i novog konzultantskog tima te dva nova ureda u inozemstvu, otkrivamo u novoj epizodi.

Što ste propustili

Startupi i poslovanje

Hrvatski AdScanner osigurao investiciju od 18 milijuna kuna uz South Central i J&T Ventures

Hrvatski AdScanner, startup posvećen razvoju data-driven sustava za optimizaciju TV oglasa, nastavlja rasti s novom investicijom. U razgovoru s Kristianom Ćurkovićem, Managing Partnerom i su-osnivačem, otkrivamo i koji su planovi za novu rundu.

Startupi i poslovanje

Dok vi druge stvarnosti zamišljate, oni ih žive u Delta Realityju – gdje game dev upoznaje klasičan IT

Delta Reality jedinstvena je tvrtka na hrvatskoj IT sceni. Njihova rješenja temelje se na tehnologijama i kreativnosti jednog game dev studija, dok se pristup projektima i zavidni radni uvjeti mjere s uspješnim IT agencijama. Stručnjaci koji tamo danas rade i sami dolaze iz obe strane industrije, kako rade i zašto biste im se i vi možda htjeli pridružiti - otkrivamo.

Društvene mreže

YouTube Shorts, hoće li novi alat hrvatskim YouTuberima zamijeniti TikTok i Instagram Reels?

Kratke video forme sve su popularnije pa ne čudi što je i YouTube, kako bi ostao u korak s TikTokom i Instagram Reelsima, pokrenuo novi alat.

Digitalni mediji

Kroz 3 godine hrvatski mediji morat će odlučiti: Više oglašavanja ili naplata sadržaja!

2020. pamtit ćemo po mnogo toga, ali i po činjenici da je naplaćivanje online sadržaja u Hrvatskoj napokon ozbiljno krenulo, a kakva su iskustva nakon prvog razdoblja provođenja - otkrivamo u razgovoru s 24sata, Telegramom te Večernjim i Jutarnjim listom.

Startupi i poslovanje

Za svoj low-code alat, hrvatski startup SpectreXR osigurao 200.000 eura od Fil Rouge Capitala

SpectreXR bavi se razvojem softvera i aplikacija u industriji virtualne i mješovite stvarnosti, a posebno se fokusirao na razvoj jedinstvenog alata za Unity 3D platformu koji bi omogućio brži razvoj AR, VR ili MR aplikacija i rješenja.

Digitalni mediji

EU priprema 2 akta koji bi mogli promijeniti kako koristite digitalne platforme – privatno i poslovno

Došlo je vrijeme za ažuriranje starih direktiva koje već dugo nisu u skladu sa stanjem tržišta i potrebama građana. Zbog toga je Europska komisija predložila dva akta o kojima Europski parlament još raspravlja. Evo što se želi mijenjati i kako to može utjecati na građane, ali i tvrtke.