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

Startupi i poslovanje

Dvije strane Porscheovog ulaganja u Greyp: Mali ulagači ljuti i nezadovoljni dok se Neufund hvali povijesnim exitom

Iza najave da Porsche preuzima većinski udio u Greyp Bikes krije se priča malih ulagača koji su 2019. u Greyp uložili kroz Equity Token Offering i sad se osjećaju - izigrano i izgurano.

Novost

Developeri, recite što doista želite: šareni ured, pivo petkom, veliku plaću, dobrog šefa….

Traženi, maženi, paženi i razmaženi. Tako mediji i društvo u zadnje vrijeme doživljavaju developere. Zagrebačka IT tvrtka odlučila je provjeriti jesu li doista takvi te pitati developere što oni doista žele.

Tehnologija

Facebook je postao Meta, ali… želimo li stvarno da nam novu digitalnu eru kroji Mark Zuckerberg?

Može jedan metaverse bez Meta? Napredni umreženi virtualni svjetovi naša su budućnost, oko toga nema sumnje, no Mark smatra da će upravo oni biti ti koji će pripomoći da se to dogodi što prije. Koliko imaju u tome šanse i želimo li uopće da Meta u tome predvodi?

Što ste propustili

Startupi i poslovanje

4 hrvatske tvrtke nalaze se u 50 najbržih rastućih tehnoloških tvrtki Srednje Europe

Three of them najbrže je rastuća hrvatska tehnološka tvrtka Deloitteovog natječaja technology Fast 50 Srednje Europe, a uz nju u prvih 50 tu su i Flow and Form, Async Lab i Reactor Studio.

Novost

Plus nudi 30% popusta na hosting pakete za vašu web stranicu

Ako ste čekali pravu priliku da zakupite hosting, nema bolje od Crnog petka.

Startupi i poslovanje

Pametni ormarići kao platforma? Bloq.it uz investiciju od 250 tisuća eura ima klijente od Francuske do Egipta!

Kada bismo i htjeli vezati ovu tvrtku za neku lokaciju, ne bismo mogli. Osnivač Bloq.ita je Slovenac, sjedište tvrtke nalazi se u Lisabonu, a ured je od nedavno otvoren i u Zagrebu. Kako se planiraju natjecati na tržištu koje će buknuti u narednim godinama?

Startupi i poslovanje

Zašto iskusni developeri vole raditi u (Software) Sauni? Jer se manje znoje, a rade na boljim projektima

Kad Finac vodi agenciju u Hrvatskoj, developeri ne preskaču pisanje testova, mogu se prebacivati s tehnologija - i ne manje važno - mogu odbiti projekt.

Startupi i poslovanje

Dvije strane Porscheovog ulaganja u Greyp: Mali ulagači ljuti i nezadovoljni dok se Neufund hvali povijesnim exitom

Iza najave da Porsche preuzima većinski udio u Greyp Bikes krije se priča malih ulagača koji su 2019. u Greyp uložili kroz Equity Token Offering i sad se osjećaju - izigrano i izgurano.

Startupi i poslovanje

Mate Knezović: Kako sam uvjerio i majku i klijente da je agrotech budućnost?

Od korisnika softvera postao je investitor, a od investitora - menadžer. Mate Knezović danas je COO AGRIVI softvera za upravljanje poljoprivrednom proizvodnjom. No, lako je osvojiti mlađe generacije tehnologijom, što je sa starijima - jesu li se okolnosti promijenile u zadnjih par godina?