Meie õppetunnid Veera disainisüsteemi ehitamisel, 2. osa
Artikli esimeses osas andsime ülevaate Veera disainisüsteemi olemusest ja senise süsteemi kitsaskohtadest. Rääkisime sellest, kuidas sai alguse Veera 1.0.0 projekt ehk kuidas kaardistasime hetkeolukorda ja lahendasime väljakutseid disainikomponentidega. Täna jätkame ligipääsetavuse, koodi komponentide ja sisuloome teemadel.
Ligipääsetavuse tähtsus
Esimeses osas rääkisime, et Veera raamistik on mõeldud avaliku sektori e-teenuste ehitamiseks, millel on ka ligipääsetavuse tagamise kohustus. Ligipääsetavuse eesmärk on tagada kõigile võrdsed võimalused ja muuta veebisisu võimalikult paljudele – sealhulgas erivajadustega inimestele – kasutatavaks. Euroopa Liidu veebi ligipääsetavuse standard seab veebilehtedele nõuded, mis põhinevad suures osas rahvusvahelistel WCAG veebisisu ligipääsetavussuunistel.
Digiligipääsetavuse tagamine osutub asutustele enamasti suureks väljakutseks ning jääb oskuste ja ressursside puudumise tõttu tihti poolikuks. Veerat uuendades oli üks meie eesmärkidest, et ligipääsetavus oleks komponentidesse juba sisse ehitatud.
Ligipääsetavus paistab silma kõigis Veera osades - disainikomponentides, HTML ja CSS komponentides ning dokumentatsioonis:
- Disainikomponendid on loodud arvestades ligipääsetavuse põhimõtteid nagu kõrge värvikontrastsus, klikitava ala piisav suurus, silmapaistev fookus ning klaviatuuritugi. Veera värvipalettide puhul on välja toodud, millised värvikombinatsioonid sobivad teksti esitamiseks hele- ja tumerežiimis.
- HTML ja CSS komponentidesse on ligipääsetavus võimalikult suures osas sisse ehitatud, et säästa arendajate aega ja vaeva. Ligipääsetavuse täielikuks tagamiseks on oluline järgida ligipääsetavuse nõudeid ka JavaScripti lisamisel, mis aga ei olnud paindlikkuse huvides Veera 1.0.0 projekti osa. JavaScripti abil ligipääsetavuse tagamine on hetkel kirjeldatud Veera põhjalikus ligipääsetavuse dokumentatsioonis, kuid tulevikus on soov ja lootus, et Veera saaks jätkuprojektide toel ka erinevate raamistike näited.
- Veera dokumentatsioon on organiseeritud komponentide põhiselt. Iga komponendi kirjeldus sisaldab ligipääsetavusele pühendatud alamlehte, mis sisaldab muuhulgas detailseid klaviatuuri- ja ekraanilugejatoe tagamise juhiseid. Näiteks on välja toodud, kuidas peaks saama komponenti klaviatuuriga aktiveerida ning millised ARIA atribuudid tuleks komponendile lisada. Lisaks on selgitatud, milline peaks olema digikeskkonna ligipääsetavuse avaldus (teatis).
Lisaks Veera disainisüsteemi kasutamisele, tuleb ligipääsetavuse põhimõtteid järgida loomulikult terve arendusprojekti vältel ning kogu lahendust ka põhjalikult testida.
Koodi komponendid
Seisime väljakutse ees, kuidas ehitada platvormi, mis sobiks tööriistana kasutamiseks võimalikult paljudele riiklikke e-teenuseid ehitavatele spetsialistidele. Oluline oli uue lahenduse laialdane kättesaadavus, kasutuslihtsus ning komponentide muutmise ja lisamise paindlikkus.
Minimaalne Veera
Idee oli ehitada Minimum Viable Producti (MVP) asemel Minimum Lovable Product (MLP), mis kataks ära võimalikult palju tuleviku kasutusjuhte. Arvestada tuli samas ka sellega, et arendaja suurim vaenlane on eelmine arendaja ning hea komponenditeegi jaoks on vaja iteratsioone, tagasisidet ja jätkuarendusi. 
Minimum Lovable Product (MLP) on arendusstrateegia, kus toode on kavandatud piisavalt paljude funktsioonidega, et püüda kasutajate tähelepanu ja luua tugev emotsionaalne kaasatus juba esimesest kokkupuutest alates.
Erinevalt Minimum Viable Productist (MVP), mis keskendub toote kõige elementaarsema funktsionaalsuse valideerimisele võimalikult väikse vaevaga, astub MLP sammu edasi, tagamaks mitte ainult toote funktsionaalsust, vaid ka meeldivust ja kaasahaaravust kasutajatele. MLP eesmärk on luua toode, mida kasutajad ei kasuta ainult probleemi lahendamiseks, vaid ka sellepärast, et neile meeldib seda kasutada.
Mida see Veera jaoks tähendab?
Veera tehniline lahendus on loodud nii, et oleks võimalik valida integratsioonisügavust igal tasemel.
Praegu annab Veera omalt poolt kätte:
- kõik tööriistad Veera Figmast tokenite kätte saamiseks;
- kõik tokenitest genereeritud primitiivsed muutujad;
- kõik primitiividest kokku pandud semantilised muutujad;
- kõikidest semantilistest muutujatest kokku pandud CSS muutujad;
- CSS muutujatest kokku pandud komponentide muutujad;
- lisaks veel ka valiku näidiskomponentide ja vaadete HTMLe ja CSSe.
Kui hakata ehitama Veerat kasutavaid teeke erinevatele raamistikele, siis on neil kõigil üks ühine vundament. Veera põhimõte aga on anda kontrolli koodi üle, võimaldades otsustada, kuidas komponendid on ehitatud ja kujundatud ning võtta arvesse erinevaid praeguseid võimalusi. Algust saab teha sobivate vaikeseadetega ja seejärel kohandada komponente vastavalt oma vajadustele.
Disainist automaatselt arendusse
Kuna muutujaid on palju, siis nende käsitsi kokku kogumine ja stiilifailides haldamine oleks väga ajamahukas. Kiirema lahenduse esimene mõte oli kasutada Figma REST APIt. See aga kukkus laualt kiiresti maha, sest nii suure potentsiaalsete kasutajate hulga tõttu pole mõistlik tasulist Figma paketti kliendile soovitada.
Meie õnneks lasi Figma just omalt poolt välja uue muutujate API. Selle kasutamiseks kirjutasime väikse Figma plugina, mille kaudu saab JSON kujul Figmast kõik muutujad kätte. Plugin väljastab muutujad nii W3 spetsifikatsioonide järgi faili, kui ka meie enda jaoks kohandatud struktuuriga faili, mille pealt saame hõlpsamini koodi genereerida.
See tundus hästi töötavat - disainerid said arendajatele jooksvalt muudatusi ja uuendusi ette anda ning arendajad said keskenduda ainult HTMLi ja CSSi ehitamisele. Pikema kasutamisperioodi järel selgub, kas see on ka jäädavalt hea lahendus.
Kihiline nagu sookoll ehk platvorm, mitte toode
Tõhusa disainisüsteemi loomine vajab pidevat tagasisidet. Veera 1.0.0 on alles algus ja selle projektiga seadsime omale eesmärgiks luua Veerale tugeva vundamendi järgnevateks arendusteks. Arvestasime, et pole teada, milliseid veebitehnoloogiaid hakatakse kasutama kuue kuu või kahe aasta pärast.
Just seepärast peab Veera mõju olema võimalikult laiaulatuslik ning süsteem ise peab olema kohandatav ja muudetav, toetudes CSSi muutujatele, mida on lihtne ümber kirjutada. Samuti on oluline, et süsteem oleks raamistikulukuta, sest nii sobib see partnerite erinevate oskuste ja projektides kasutatavate tehnoloogiatega.
Kasutades ainult HTMLi ja CSSi, tagame selle, et järgmistes iteratsioonides (kui lisandub ka näiteks Reacti teek), ei oma tähtsust, millist veebilehe märgendamise keelt kasutatakse (CSSi, CSS mooduleid, SCSSi, Styled-Componentsi vms). Sama põhimõte võiks kehtida ka teiste raamistike kohta nagu Angular, Vue ja Svelte.
Teisalt võib liigne ebamäärasus kaasa tuua olulisi riske ehk „kasulik kõigile“ võib kiiresti muutuda kasutuks, kui otsused põhinevad liiga üldistel abstraktsioonidel ja minimaalsetel ühisnimetajatel.
Kuidas edasi?
Veera taoline platvorm ei ole n-ö one-and-done. Komponendid ja disainisüsteemid kaotavad kiiresti oma mõtte, kui nendega ei tegeleta. Meie varasem kogemus näitab, et jagatud vastutus tähendab vastutuse puudumist ja asi jääb nurka seisma. Seepärast peab ka Veera tiim uue platvormiga jooksvalt tegelema. Erinevatel kasutajatel/arvajatel võib tekkida erinevaid seisukohti, kuid lõplike otsuste tegemisel peab tiim olema filtri rollis ja arvestama, et kõiki soove pole alati otstarbekas rakendada.
Sisuloome juhised
Kasutajale hea kasutajakogemuse pakkumiseks ei piisa ainult heast disainist, vaid ka sisu ehk disainile loodav tekst peab olema kasutaja jaoks vajalik ja abistav, ühtlane ja üheselt mõistetav. Seepärast sai üheks projekti eesmärgiks disainisüsteemi sisuloomejuhiste lisamine.
Suurimaks väljakutseks juhiste kokkupanekul oli, et juhised pidid olema piisavalt üldised, et katta kõikide Veera kasutajate vajadusi, kuid samas ka piisavalt detailsed, et pakkuda kohe rakendatavaid lahendusi. Sisuloome juhiste kokkupanekul kasutasime teadmuspõhist lähenemist, tuginedes pikemate sisutekstide ja pisitekstide kirjutamise juhendi loomisel hetkeseisu analüüsile ning varasematele uuringutele.
Enne juhiste kirja panekut tuli läbi viia vajalikud eeltööd. Esimeseks sammuks oli Veera disainsüsteemi kasutama hakkavate lehtede sisuaudit, kus märkisime üles ebaühtlused ja kitsaskohad, mille põhjal töötada välja konkreetsemad juhised. Kuna Veera päris esimene versioon, mida antud projektis edasi arendasime, põhines e-Maksu- ja Tolliameti stiilijuhisel, pidasime järgmisena oluliseks analüüsida ka kunagist stiilijuhist ja tuua üle info, mis on praegugi veel asjakohane. Lõpetuseks koondasime kokku info kvaliteetse siuteksti kirjutamise põhimõtete ning pisitekstide kirjutamise juhiste kohta.
Ükski sisuloome juhis ei saa üle ega ümber küsimusest, kuidas tekstid peaksid kasutajat kõnetama. Seetõttu otsustasime kõigepealt paika panna üldisemad tekstide kirjutamise põhiprintsiibid ehk kuidas peaks tekstis kodanikke kõnetama, ning selge keele põhimõtted. Põhiprintsiipide aluseks võtsime nii Veera disainsüsteemi kasutavate lehtede analüüsist selgunu kui ka selle, kuidas soovitatakse näidata Eestit väljapoole (vajaliku info saime brand estonia veebilehelt). Kokku saime 6 ühisjoont, mis võiksid riigiasutuste keelekasutust iseloomustada, neile lisasime ka konkreetsed näited, kuidas neid tunnusjooni keelekasutusega edasi anda.
Analüüsi käigus märkasime, et raskusi valmistab sina- või Teie-vormi valik kasutaja poole pöördumisel. Kui pikemad sisutekstid tundusid järgivat näiteks Teie-vormi, siis pisitekstides võis märgata sina-vormi. Kuna iga asutus peab saama ise otsustada, millist vormi nad kasutavad, kas pigem distantseerivat ja viisakat Teie-vormi või sõbralikumat ja soojemat sina-vormi, ei soovinud me teha ettekirjutusi, vaid otsustasime asutusi vormi valikuprotsessis toetada, pakkudes varasemate keeleuuringute põhjal soovitusi, mida otsustamisel aluseks võtta.
Lisaks pikematele sisutekstidele on veebilehtedel oluline roll ka pisitekstidel – funktsionaalsetel tekstidel, mis aitavad kasutajal jõuda takistusteta sinna, kuhu neil on vaja minna. Kuna pisitekstidel on kasutajakogemuse ja kasutatavuse parandamisel suur roll, siis lisasime sisuloome juhiste juurde ka eraldi osa pisitekstide kirjutamise ning kirjutamisprotsessi kohta. Seejärel lisasime juba komponentide juurde konkreetsemalt kirjutamise põhimõtted ja näited, kuidas kirjutada.
Nii sai kokku kompaktne juhis koos näidetega, mille abil on võimalik luua ühtlasemaid ja kasutajasõbralikemaid tekste. Sisuloomejuhis põhineb meie praegustel teadmistel ja parimatel praktikatel, mis võivad siiski sarnaselt ülejäänud IT-maailma teadmistega ajas muutuda. Oluline oli luua loogiline süsteem, mida saab aja edenedes valideerida ja täiendada – on ju Veera näol tegemist elava stiiliraamatuga.
Kokkuvõtteks
Veera uus versioon on varasemaga võrreldes suur edasiminek. Viimaks on tegemist tervikliku tootega, mis vastab hetke parimatele praktikatele. Sellest hoolimata on RIA Veera tiimil ees palju tööd. 19. märtsil toimunud koolitusel (vaata järgi: Teoreetiline osa ja Praktiline osa) jäi kõige selgemini kõlama see, et vaja on ühist kommunikatsioonikanalit, kus saaks kiiresti küsimustele vastused. Nagu see disainisüsteemidega üldiselt on, siis ka Veera puhul tuleb arvestada jätkutöödega. Veebitehnoloogia ja tööriistad arenevad pidevalt ja kindlasti tuleb ka Veerat kasutavatelt tiimidelt palju häid mõtteid, mida paremaks teha.
Trinidad Wisemani tiimi jaoks oli tegemist olulise tähtsusega projektiga, mis mõjutab edaspidi meie kasutajaliideste ehitamise protsessi efektiivsust.
Veera disainisüsteemi leiad siit: veera.eesti.ee
