Graafisen käyttöliittymän tyyliopas ja sen noudattamisen ohjelmallinen valvonta

Henna-Riikka Kari Graafisen käyttöliittymän tyyliopas ja sen noudattamisen ohjelmallinen valvonta Tietotekniikan pro gradu -tutkielma 21. marraskuuta 2024 Jyväskylän yliopisto Informaatioteknologian tiedekunta Tekijä: Henna-Riikka Kari Yhteystiedot: [email protected] Ohjaaja: Tommi Mikkonen Työn nimi: Graafisen käyttöliittymän tyyliopas ja sen noudattamisen ohjelmallinen valvonta Title in English: Graphical UI style guide and programmatic monitoring of its compliance Työ: Pro gradu -tutkielma Opintosuunta: Ohjelmistoja tietoliikennetekniikka Sivumäärä: 101+0 Tiivistelmä: Toimiva ja tyylikäs graafinen käyttöliittymä on tärkeä osa ohjelmistokehitystä ja vaikuttaa merkittävästi käyttäjäkokemukseen ja sen myötä tuotteen laatuun ja kaupalliseen menestykseen. Tehokas käyttöliittymäsuunnittelu puolestaan nojaa toimivaan komponenttikirjastoon ja sen uudelleen käytettäviin, keskenään vuorovaikuttaviin komponentteihin. Kun organisaatiossa useat kehittäjät luovat uusia komponentteja, lopputulos on usein epäyhtenäinen ja kehittäjänsä näköinen. Selkeällä ja ohjelmallisesti testattavalla tyyliohjeistuksella voidaan käyttöliittymien ilmeeseen saada kaivattua yhtenäisyyttä, toimivuutta ja laatua. Tämän suunnittelututkimuksen tuloksena toteutettiin kohdeorganisaatiolle käyttöliittymän tyyliopas ja malli sen visuaalisista regressiotesteistä. Kohdeorganisaatio on keskisuomalainen ohjelmistoalan yritys, joka tuottaa SaaS-palveluja lähinnä energiatoimialan tarpeisiin. Tyyliopas toteutettiin olemassa olevan komponenttikirjaston yhteyteen osaksi suurempaa kokonaisuutta. Se sisälsi joukon organisaatiospesifejä uudelleenkäytettäviä graafisia komponentteja, sekä ohjeet typografiasta, ikoneista, väreistä ja sivumalleista. Tyylinvalvojaksi valittiin Vitest image snapshots, joka soveltuu niin yksittäisten komponenttien kuin kokonaisten sivunäkymien snapshot-testaukseen ja integroituu helposti käytössä olevaan Vite-ympäristöön, jossa toiminnallinen testaus suoritetaan jo Vitest:illä. Tutkimus sisälsi myös ohjeet komponenttikirjaston rekonstruktiolle niin, että tyylioppaasta saadaan elävä ja ylläpidettävä. Tutkimus antaa arvokasta informaatiota ja toimivia esimerkkejä kohdeorganisaatiolle ja toimii mallina myös muille. Avainsanat: pro gradu -tutkielmat, käyttöliittymän tyyliopas, käyttöliittymän visuaalinen testaus, komponenttikirjasto, suunnittelujärjestelmä i Abstract: A functional and elegant graphical user interface is an important part of software development and has a significant impact on user experience and impacts the quality and commercial success of the product. Effective user interface design, in turn, relies on a functional component library and its reusable, mutually interacting components. When several developers in an organization create new components, the result is often inconsistent and looks like its developer. With clear and programmatically testable style guidelines, the desired consistency, functionality and quality can be achieved in the appearance of user interfaces. As a result of this design science research, a user interface style guide and a model of its visual regression tests were implemented for the target organization. The target organization is a central Finnish software company that produces SaaS services mainly for the needs of the energy sector. The style guide was implemented in connection with an existing component library as part of a larger whole. It included a set of organization-specific reusable graphic components, as well as instructions on typography, icons, colors and page templates. Vitest image snapshots was chosen as the tool to control the usage of the style guide, which is suitable for snapshot testing of both individual components and entire page views and easily integrates into the existing Vite environment, where functional testing is already performed with Vitest. The study also included instructions for reconstructing the component library so that the style guide is alive and maintainable. This research provides valuable information and working examples for the target organization and also serves as a model for others. Keywords: Master’s Theses, GUI Style Guide, GUI Visual Testing, Component Library, GUI Design System ii Koodilohkot Koodilohko 1 Korvattava Alert-esiintymä..................................................38 Koodilohko 2 Alert-esiintymänkorvaavakoodi. ..........................................38 Koodilohko 3 Button-esiintymä.............................................................39 Koodilohko 4 Form-esiintymänkorvaavakoodi. ............................................41 Koodilohko 5 Korvattava Menu-esiintymä. ..................................................43 Koodilohko 6 Menu-esiintymänkorvaavakoodi. ............................................44 Koodilohko 7 Korvattava Modal-esiintymä..................................................46 Koodilohko 8 Modal-esiintymänkorvaavakoodi. ..........................................46 Koodilohko 9 Komponentin parametrina saama toimintopainikejoukko. ...................46 Koodilohko 10 Korvattava Popover-esiintymä. .............................................48 Koodilohko 11 Popover-esiintymän korvaava koodi. .......................................49 Koodilohko 12 Korvattava BrandTable-esiintymä. ........................................51 Koodilohko 13 BrandTable-esiintymän korvaava koodi. ..................................51 Koodilohko 14 Korvattava Tooltip-esiintymä. .............................................53 Koodilohko 15 Tooltip-esiintymän korvaava koodi. .......................................53 Koodilohko 16 Vitest-syntaksi, koko sivun testi. ..............................................63 Koodilohko 17 Plawright-syntaksi, koko sivun testi. ..........................................63 Koodilohko 18 Cypress-syntaksi, koko sivun testi.............................................63 Koodilohko 19 Vitest-syntaksi, komponentin testi.............................................64 Koodilohko 20 Plawright-syntaksi, komponentin testi. .......................................64 Koodilohko 21 Cypress-syntaksi, komponentin testi. .........................................64 iii Kuviot Kuvio1.Suunnittelujärjestemä. .................................................................. 7 Kuvio 2. Suunnittelututkimuksen vaiheet Hevner (2007) mallin mukaan, vapaa käännös.....14 Kuvio 3. Komponenttikirjaston tekninen toimintaympäristö. ...................................20 Kuvio 4. Komponenttikirjaston Playground-ympäristö. .........................................21 Kuvio 5. Asiakkaan laskusivun tuottava komponentti Invoices. ............................23 Kuvio 6. Invoices-komponentin rakenne UML-kaaviona....................................24 Kuvio 7. Vaatimusmäärittely: tyylioppaan yleiset vaatimukset. ................................27 Kuvio 8. Vaatimusmäärittely: tyylioppaan tyyleihin liittyvät vaatimukset......................29 Kuvio 9. Vaatimusmäärittely: tyylioppaan komponentteihin liittyvät vaatimukset.............31 Kuvio 10. Vaatimusmäärittely: tyylioppaan malleihin liittyvät vaatimukset....................32 Kuvio 11. Vaatimusmäärittely: tyylinvalvojan vaatimukset. ....................................32 Kuvio 12. Yhden sisällön sivumalli komponentin sisäisen marginaalin kanssa. ...............56 Kuvio 13. Yhden sisällön sivumalli ilman komponentin sisäistä marginaalia. .................56 Kuvio 14. Kahden sisällön sivumalli toisen komponentin sisäisen marginaalin kanssa........57 Kuvio 15. Kahden sisällön sivumalli marginaaliton komponentti korostettuna. ...............57 Kuvio 16. Kahden sisällön sivumalli marginaalia sisältävä komponentti korostettuna. .......58 Kuvio17.Vitest,kokosivuntesti.................................................................65 Kuvio18.Vitest,komponentintesti. .............................................................65 Kuvio19.Playwright,kokosivuntesti. ..........................................................66 Kuvio20.Playwright,komponentintesti.........................................................66 Kuvio21.Cypress,kokosivuntesti. .............................................................66 Kuvio22.Cypress,komponentintesti............................................................66 Kuvio 23. Ensimmäisen varsinaisen testiajon tulokset...........................................70 Kuvio 24. Koko testisivun työpöytä-näkymän poikkeamakuva (T1)............................71 Kuvio 25. Koko testisivun mobile-näkymän poikkeamakuva (T2)..............................71 Kuvio 26. Koko testisivun tablet-näkymän poikkeamakuva (T3). ..............................72 Kuvio 27. Primääripainikkeen ulkoasutestin (T4) poikkeamakuva. ............................72 Kuvio 28. Primäärivärilaatikon ulkoasutestin (T7) poikkeamakuva. ...........................73 Kuvio 29. Infolaatikon hover-testin (T8) poikkeamakuva. ......................................73 Kuvio 30. Dialogitestin (T9) poikkeamakuva. ...................................................74 Kuvio 31. Ponnahdusikkunatestin (T10) poikkeamakuva. ......................................74 Kuvio 32. Infolaatikon hover-testin (T8) toinen poikkeamakuva. ..............................75 Kuvio 33. Dialogitestin (T9) toinen poikkeamakuva. ...........................................75 Kuvio 34. Ponnahdusikkunatestin (T10) toinen poikkeamakuva................................76 Kuvio 35. Dialogitestin (T9) kolmas poikkeamakuva. ..........................................76 Kuvio 36. Evaluointi I, toiminnallisuus: huomiot ja jatkotoimenpiteet .........................79 Kuvio 37. Evaluointi I, käytettävyys: huomiot ja jatkotoimenpiteet ............................80 Kuvio 38. Evaluointi I, tehokkuus: huomiot ja jatkotoimenpiteet ..............................80 Kuvio 39. Evaluointi I, ylläpito: huomiot ja jatkotoimenpiteet .................................81 Taulukot Taulukko 1. Chakra:n Alert-komponenttia käyttävät komponentit. ..........................38 Taulukko 2. Kirjaston Alert-komponenttia kutsuvat komponentit. ...........................39 iv Taulukko 3. Chakra:n Form-komponenttia käyttävät komponentit. ............................41 Taulukko 4. AkamonForm-komponenttiin tarvittavat lisäparametrit...........................42 Taulukko 5. Chakra:n Menu-komponenttia käyttävät komponentit. ............................43 Taulukko 6. AkamonMenu-komponenttiin tarvittavat lisäparametrit...........................45 Taulukko 7. Chakra:n Modal-komponenttia käyttävät komponentit. ..........................45 Taulukko 8. AkamonModal-komponenttiin tarvittavat lisäparametrit. ........................47 Taulukko 9. Chakra:n Popover-komponenttia käyttävät komponentit. .......................48 Taulukko 10. AkamonPopover-komponenttiin tarvittavat lisäparametrit. ...................49 Taulukko 11. Kirjaston Popover-komponenttia käyttävät komponentit. .....................50 Taulukko 12. Chakra:n Table-komponenttia käyttävät komponentit. .........................50 Taulukko 13. AkamonTable-komponenttiin tarvittavat lisäparametrit........................52 Taulukko 14. Kirjaston Tooltip-komponenttia käyttävät komponentit. .....................53 Taulukko 15. AkamonTooltip-komponenttiin tarvittavat lisäparametrit. ...................54 v Sisällys 1 JOHDANTO ................................................................................ 1 2 TUTKIMUKSEN VIITEKEHYS JA MÄÄRITELMÄT ................................. 3 2.1 Komponenttilähtöinen kehitys ja koodin uudelleenkäyttö ......................... 3 2.2 Graafisetkomponenttikirjastot....................................................... 4 2.3 Käyttöliittymäntyyliopas............................................................ 5 2.4 Suunnittelujärjestelmä ............................................................... 6 2.5 Tyylinvalvonta........................................................................ 8 3 TUTKIMUSKYSYMYKSET, TUTKIMUSMENETELMÄ JA SEN SOVELTAMINEN......................................................................................11 3.1 Tutkimuskysymykset.................................................................11 3.2 Tutkimusmenetelmänperiaatteet ....................................................11 3.3 Tutkimusmenetelmän keskeiset vaiheet .............................................14 3.4 Menetelmän käyttö tässä tutkimuksessa ............................................15 3.5 Tutkimuksenvaiheet .................................................................16 3.5.1 Nykytilan kartoitus: täsmällisyyssykli ........................................16 3.5.2 Tavoitetilan kartoitus: relevanssisykli.........................................16 3.5.3 Tyyliopas:suunnittelusykli....................................................17 3.5.4 Ohjeet komponenttikirjaston rekonstruktiolle: suunnittelusykli.............17 3.5.5 Tyylinvalvoja: suunnittelusykli................................................17 3.6 Artefaktinevaluointi .................................................................17 4 TYÖKALUN SUUNNITTELU JA TOTEUTUS SYKLEITTÄIN.......................19 4.1 Täsmällisyyssykli - komponenttikirjaston nykytila.................................19 4.1.1 Modulaarinentuoterakenne ...................................................19 4.1.2 Tekninentoteutus ..............................................................20 4.1.3 Komponenttikirjaston komponentit ...........................................21 4.1.4 Tuoterungot ja komponenttien rakenne .......................................22 4.1.5 Komponenttientyyli...........................................................24 4.2 Relevanssisykli: työkalun vaatimukset ja hyväksymiskriteerit.....................26 4.2.1 Tyylioppaanvaatimukset......................................................26 4.2.2 Tyyleihin liittyvät vaatimukset ................................................29 4.2.3 Tyylioppaaseen sisällytettävät komponentit ja niiden vaatimukset..........30 4.2.4 Malleihin liittyvät vaatimukset................................................31 4.2.5 Tyylinvalvojanvaatimukset ...................................................32 4.3 Suunnittelusykli: tyylioppaan toteutus ..............................................33 4.3.1 Komponentit ...................................................................33 4.3.2 Tyylit ...........................................................................35 4.3.3 Mallit...........................................................................36 4.4 Suunnittelusykli: komponenttikirjaston muutokset .................................37 4.4.1 Komponentit ...................................................................37 4.4.2 Tyylit ...........................................................................54 4.4.3 Mallit...........................................................................55 4.5 Suunnittelusykli: tyylinvalvojan toteutus............................................58 4.5.1 Testaustyökalujenesittely .....................................................59 vi 4.5.2 Työkalujen vertailua ja tyylinvalvojana käytettävän testausympäristön valinta ..........................................................................62 4.5.3 Testaustyökalun käyttöönotto komponenttikirjastossa.......................67 4.5.4 Käyttöliittymän visuaaliset testit ..............................................68 4.5.5 Työkalun soveltuvuus tyylinvalvojaksi .......................................76 5 ARTEFAKTIN EVALUOINTI JA TULOKSET ITERAATIOITTAIN ..................78 5.1 Tyyliopas, ensimmäisen evaluoinnin tulokset.......................................78 5.1.1 Laatuvaatimustentäyttyminen ................................................78 5.1.2 Lähdekoodinevaluointi........................................................81 5.2 Tyyliopas, toisen evaluoinnin tulokset ..............................................81 5.3 Tyylinvalvoja, ensimmäisen evaluoinnin tulokset ..................................83 5.4 Artefaktinkokonaisarvio.............................................................84 6 YHTEENVETOJAPOHDINTA ..........................................................86 LÄHTEET.........................................................................................90 vii 1 Johdanto Graafinen käyttöliittymä (GUI) on digitaalinen käyttöliittymä, jossa käyttäjä vuorovaikuttaa erilaisten graafisten komponenttien kanssa. Tällaisia ovat esimerkiksi kuvakkeet, painikkeet, valikot ja erilaiset lomakkeet. Graafisessa käyttöliittymässä olevat visuaaliset elementit tarjoavat käyttäjälle informaatiota ja mahdollistavat toimintoja, joita hän voi tehdä esimerkiksi lähettääkseen tietoa eteenpäin.(HubSpot 2024) Toimiva ja tyylikäs käyttöliittymä on tärkeä osa ohjelmistokehitystä, vaikuttaa merkittävästi käyttäjäkokemukseen ja tukee ratkaisujen kaupallista menestystä. Graafisten käyttöliittymien suunnittelussa on tasapainoteltava mm. helppokäyttöisyyden, toiminnallisuuden, turvallisuuden ja houkuttelevan ulkoasun välillä. Käyttäjät vaativat yhä dynaamisempia käyttöliittymiä ja odottavat niiden toimivan monenlaisilla laitteilla (Lynch ja Horton 2016). Vaaditaan opittavuutta, johdonmukaisuutta ja saavutettavuutta (HEAVY.AI 2024). Näihin seikkoihin voidaan vaikuttaa käyttöliittymän graafisilla komponenteilla. Suunnittelun tehokkuutta voidaan parantaa tekemällä komponenteista uudelleenkäytettäviä ja järjestämällä ne komponenttikirjastoon. Kohdeorganisaatio Akamon Innovations Oy kehittää ohjelmistotuotteita, joita käyttävät useat asiakkaat. Tuotteet räätälöidään asiakkaan tarpeiden mukaan komponenteista koostetuista tuoterungoista. Asiakastoteutusten toisteisuutta vähentämään on perustettu käyttöliittymäkomponenttien kirjasto, jonka uudelleenkäytettäviä komponentteja toteuttavat useat kehittäjät. Käyttöliittymien yhtenäinen ulkoasu on kuitenkin tämän myötä kärsinyt. On luotava ohjeistus, jonka pohjalta jokainen kehittäjä voi saada aikaan yhtiön ilmeen mukaisia tuotteita. Pelkkä ohjeistus ei kuitenkaan riitä, vaan komponenttien ja niistä koostettujen käyttöliittymien vastaavuus tyylioppaaseen on tarkastettava ohjelmallisesti. Tutkimusongelma on näin ollen olemassa. Tässä tutkimuksessa suunniteltiin ja toteutettiin kohdeorganisaatiolle heidän tarkoitustaan vastaava tyyliohjeistus, joka liitettiin olennaiseksi osaksi olemassa olevaa komponenttikirjastoa. Laadittiin ohjeet kirjaston rakenteen rekonstruoimiseksi niin, että kaikki komponenttien tyylimääritykset löytyvät yhdestä paikasta, jolloin niiden ylläpito helpottuu merkittävästi. Tyylien valvontaa varten rakennettiin malli käyttöliittymän visuaalisista regressiotesteistä. Luvussa 2 esitellään tutkimuksen viitekehys. Puhutaan komponenttilähtöisestä kehityksestä, komponenttien uudelleenkäytöstä ja niiden järjestämisestä kirjastoon. Esitellään käsitteet käyt1 •Mallit asettelevat atomit, molekyylit ja organismit järjestykseen muodostaen sivusuunnitelmia. Esimerkkinä voisi olla vaikkapa etusivun asettelu, jossa hallittu kokonaisuus syntyy useasta osasta. Mallien tarkoitus on pitää yllä komponenttien järjestystä sivulla, ei keskittyä sen sisältöön. •Näkymät muodostuvat, kun malleihin lisätään todellista sisältöä. Lopullisten näkymien perusteella voidaan havaita tarvetta muunnella malleja, jotta kokonaisuudesta saadaan toimiva monenlaisella sisällöllä. Tyylioppaan ja suunnittelujärjestelmän rakentamisessa atomisuunnittelun menetelmästä voi olla hyötyä. Frost muistuttaa, että vaiheiden suoritusjärjestystä ei ole tarkoin säädelty. Tärkeämpää on ajatella menetelmää henkisenä mallina, jonka avulla ymmärrämme paitsi kokonaisuutta, myös pieniä yksityiskohtia. (Frost 2016) 2.5 Tyylinvalvonta Kun suunnittelujärjestelmä on luotu, sen käyttöä tulee myös valvoa. Tyylioppaan ja digitaalisen tuotteen välinen yhteys on näin muodostettu mutta sen hyödyntämisestä ei ole varmuutta. Staattisen tyylioppaan kohdalla sen noudattaminen jää kehittäjän vastuulle. Ohjeiden sisäistäminen ja niiden tarkka soveltaminen paineen alla on yksilöllistä ja epävarmaa. Elävän tyylioppaan tapauksessa tyyliohjeen noudattaminen on pääosin automatisoitua. Mikään ei kuitenkaan teknisesti estä kehittäjää lisäämästä esimerkiksi tyylimäärityksiä käyttämiinsä komponentteihin. On oltava jokin keino, jolla tyyliohjeen noudattamista voidaan valvoa. Graafiseen käyttöliittymätestaukseen kuuluu sekä visuaalista että toiminnallista testausta. Käyttöliittymän toiminnallinen testaus koetaan tärkeänä osana kehitystyötä, koska sillä varmistetaan, että sovellus toimii odotusten mukaisesti. Visuaalinen testaus sen sijaan koetaan usein toissijaiseksi. Sillä on kuitenkin käyttäjäkokemuksen kannalta tärkeä merkitys ja se vaikuttaa suoraan tuotteen laatuun ja uskottavuuteen (Software Testing Help 2023). Tässä tutkimuksessa keskitytään vain käyttöliittymän visuaaliseen testaamiseen ja sen myötä tyylinvalvontaan. Käyttöliittymän visuaalinen testaus tarkoittaa eroavaisuuksien havainnointia sovelluksen sisällössä ja ulkoasussa, eli siinä, mistä elementeistä sivu koostuu, miten ne on aseteltu ja miltä ne näyttävät ja tuntuvat. Sivun sisällön oikeellisuutta arvioidaan elementtien sijainnin, muodon ja koon perusteella. Varmistetaan, etteivät elementit sijoitu päällekkäin ja että ne ovat näkyvissä. Ulkoasun oikeellisuus todennetaan tarkastelemalla mm. värejä, fontteja, kirkkautta ja kont8 rastia. Tänä päivänä oman haasteensa tuovat erilaiset käyttöjärjestelmät, verkkoselaimet, resoluutiot ja lisäksi valtava määrä erilaisia laitteita. Visuaalisen testauksen tavoitteena on myös varmistaa, että sovellus näyttää oikealta ja ulkoasu on yhtenäinen huolimatta käyttäjän valitsemasta yhdistelmästä.(Software Testing Help 2023) Visuaalinen testaus voidaan toteuttaa manuaalisesti, tarkastelemalla kahta tilannekuvaa vierekkäin ja etsimällä poikkeavuuksia (Software Testing Help 2023). Ihmissilmä havaitsee riittävät eroavaisuudet, eikä pikselin tarkkuudelle tarvitse mennä, jos koko tyylioppaan tavoitteena on yhtenäinen ilme. Tällainen testaus on kuitenkin käsityötä ja työn laatu on yksilöllistä. Yksi testaaja havaitsee erot toista tarkemmin. Lisäksi tehtävä vaikeutuu merkittävästi, kun tarkastettavaa sisältöä on paljon, tai kun jokainen mahdollinen näyttöyhdistelmä on tutkittava erikseen. Visuaalinen testaus voidaan toteuttaa myös automaattisesti niin, että ohjelmisto suorittaa elementtien visuaalisen vertailun erilaisissa näyttöyhdistelmissä. Tämä voi tapahtua kahdella tavalla: snapshot-testauksena tai tekoälyalgoritmeihin ja tietokonenäköön perustuvana testauksena (Software Testing Help 2023). Valtaosa markkinoilla olevista visuaalisen testauksen työkaluista käyttää snapshot-tekniikkaa. Siinä ohjelma ottaa testauksen eri vaiheissa käyttöliittymästä kuvakaappauksia, joita verrataan verrokkikuviin. Vertailu tapahtuu tutkimalla kuvien bittikarttoja, käymällä läpi jokainen pikselipari vuorollaan, jolloin virheilmoitus syntyy, kun pikseleiden välillä on eroja. Testauksen jälkeen ohjelma luo raportin, jota testaaja voi analysoida. Tällä tavoin virheitä voidaan löytää tarkemmin, nopeammin ja johdonmukaisemmin kuin ihmissilmällä. Menetelmään liittyy kuitenkin haasteita. Erilaiset selaimet, näytönohjaimet ja resoluutiot, jopa renderöintialgoritmit aiheuttavat merkityksettömiä pikselieroja, eikä kyse ole aidosta visuaalisesta virheestä. Testaajan analyysin varaan jää löytää todelliset virheet, mikä jälleen vaatii manuaalista työtä (Xu 2022). Modernein tapa on tekoälyalgoritmien ja tietokonenäön käyttö visuaalisessa testaamisessa. Kaikesta ohjelmistotestauksessa käytetystä tekoälystä, on visuaalisella AI-testaamisella ollut viime vuosina suurin vaikutus (Volk 2021). Periaate on samanlainen kuin snapshot-testauksessa, kuvakaappauksia otetaan testauksen edetessä, mutta kuvien vertailu tapahtuu tekoälyavusteisesti. Pikselien vertailun sijaan tietokonenäön avulla kone koulutetaan tunnistamaan elementtejä käyttöliittymästä ja käsittelemään visuaalista tietoa kuten ihmisnäkö. Ihmisen näkö perustuu verkkokalvon, näköhermojen ja visuaalisen aivokuoren yhteistoimintaan (Pandey 2022). Tietokonenäkö hyödyntää kameroita, dataa ja algoritmeja suorittaakseen saman toiminnon (Pandey 2022). Tällainen menetelmä luo huomattavasti vähemmän virheellisiä hälytyksiä (engl.false 9 positives) kuin pikselikohtainen vertailu (Battat 2024) ja sillä voidaan analysoida tuhansia kuvia sekunnissa (Pandey 2022). Tämän tutkimuksen puitteissa etsitään parhaiten soveltuva menetelmä ja työkalu kehitettävän tyylioppaan tyylinvalvojaksi. Jos päädytään markkinoilla valmiina olevaan ratkaisuun, on tärkeää, että se taipuu myös käyttöliittymän toiminnalliseen testaukseen huolimatta siitä, että tämä tutkimus keskittyy visuaaliseen testaukseen. Näin valitun työkalun täysi potentiaali on mahdollista hyödyntää jatkossa. 10 3 Tutkimuskysymykset, tutkimusmenetelmä ja sen soveltaminen Tutkimusongelmana on, kuinka säilyttää käyttöliittymän yhtenäinen visuaalinen ilme, kun kehittäjiä on monta ja jokaisella oma tapansa toimia. Keskitytään liikaa toiminnallisuuteen ja visuaaliset seikat jäävät toissijaisiksi, vaikka niillä on tärkeä merkitys tuotteen laatuun ja kaupalliseen menestykseen. 3.1 Tutkimuskysymykset Tutkimusongelman perusteella voidaan asettaa seuraavat tutkimuskysymykset: •TK1: Mitä asioita tyylioppaan täytyy sisältää, jotta varmistetaan käyttöliittymän yhtenäinen ilme ja parannetaan käyttäjäkokemusta? • ATK1: Kuinka tyyliopas tulee rakentaa, jotta se toimii yhdessä olemassa olevan komponenttikirjaston kanssa? • ATK2: Mitä muutoksia kirjaston komponentteihin on tehtävä, jotta tyylimääritysten ylläpito voidaan keskittää yhteen paikkaan? • ATK3: Miten varmistetaan, että eri kehittäjien luomat komponentit vastaavat annettuja tyyliohjeita? •TK2: Mitä vaihtoehtoja on olemassa valvoa komponenteista koostetun käyttöliittymän visuaalista ilmettä ja vastaavuutta tyylioppaaseen? Näistä kysymyksistä ensimmäinen ja viimeinen ovat varsinaiset tutkimuskysymykset ja kiteyttävät tutkimuksen tavoitteen. Alitutkimuskysymyksiä käytetään apuna tutkimuksen osatavoitteiden saavuttamisessa. 3.2 Tutkimusmenetelmän periaatteet Tietojärjestelmätieteen tutkimusta luonnehtivat kaksi toisiaan täydentävää mutta erillistä paradigmaa: käyttäytymistiede (engl. behavioral science) ja suunnittelutiede (engl. design science). Käyttäytymistiede pyrkii kehittämään ja todentamaan teorioita, jotka selittävät tai ennustavat ihmisten tai organisaation käyttäytymistä. Suunnittelutiede sen sijaan pyrkii laajentamaan ihmisten ja organisaatioiden valmiuksia luomalla uusia innovatiivisia työkaluja, artefakteja. 11 (Hevner ym. 2004) Tämän tutkimuksen menetelmänä on suunnittelututkimus (engl. design science research), jonka tuloksena suunnitellaan ja toteutetaan uusi artefakti, työkalu, joka ratkaisee kohdeorganisaation ongelman. Suunnittelututkimus on siis ratkaisukeskeistä tutkimusta, jossa käytännön ongelmaan haetaan toimivaa ratkaisua. Tutkimuksen tuloksena suunnitellaan jokin uusi, innovatiivinen IT-artefakti, joka ratkaisee ratkaisemattoman ongelman, tai tarjoaa tehokkaamman ratkaisun jo aiemmin ratkaistuun ongelmaan. Menetelmän tavoitteena on parantaa sekä teoriaa että käytäntöä kehittämällä artefakteja, jotka vastaavat todellisiin haasteisiin. Suunnittelututkimukseen kuuluu näiden artefaktien rakentaminen, niiden hyödyllisyyden ja tehokkuuden testaaminen sekä edelleen jalostaminen testauksesta saadun palautteen ja arvioinnin perusteella (Hevner ym. 2004; Peffers ym. 2007). Suunnittelun käsite tekniikassa on tuttu jo varhaisilta ajoilta, mutta varsinainen suunnittelututkimus, sen muodollinen tunnustaminen strukturoituna tutkimusmenetelmänä nousi esiin vasta 1990-luvulla, kun haluttiin erottaa puhtaasti teoreettinen työ käytännön ratkaisujen kehittämisestä. Alan Hevnerin ja hänen kollegoidensa vuonna 2004 julkaisemaa artikkelia ” Design Science in Information Systems Research” pidetään akateemisessa kirjallisuudessa laajalti perustavanlaatuisena. Hevner ym. (2004) mukaan suunnittelututkimukselle luonteenomaista on se, että ratkaistavana on ns. viheliäinen ongelma, jolle he tietojärjestelmätieteen osalta määrittelevät seuraavat tunnusmerkit: • epävakaat vaatimukset ja rajoitukset, jotka perustuvat huonosti määriteltyyn kontekstiin • monimutkainen vuorovaikutussuhde ongelman ja sen ratkaisun osakomponenttien välillä • luontainen joustavuus muuttaa suunnitteluprosesseja sekä artefakteja • kriittinen riippuvuus ihmisen kognitiivisista kyvyistä tehokkaiden ratkaisujen tuottamiseksi • kriittinen riippuvuus ihmisen sosiaalisista kyvyistä tehokkaiden ratkaisujen tuottamiseksi. Hevner ym. (2004) mukaan suunnittelutieteen paradigmassa tieto ja ymmärrys vallitsevasta ongelmasta ja sen ratkaisu saavutetaan rakentamalla ja hyödyntämällä suunniteltua artefaktia. Suunnitteluprosessi sisältää sarjan asiantuntijatoimia, joka johtaa innovatiivisen artefaktin luomiseen. Artefaktin evaluointi puolestaan antaa palautetta ja lisää ymmärrystä ongelmasta 12 parantaen näin sekä tuotteen laatua ja että itse suunnitteluprosessia. Tällaista rakenna-evaluoisilmukkaa iteroidaan useita kertoja, kunnes artefakti saa lopullisen muotonsa (March ja Smith 1995). Tällä tavoin suunnittelutieteen tutkija kehittää samaan aikaan sekä suunnitteluprosessia että suunniteltua artefaktia osana tutkimusta (Hevner ym. 2004). Suunnittelututkimusta koskevassa artikkelissaan Hevner ym. (2004) määrittelevät seitsemän ohjenuoraa tutkimusmenetelmän ymmärtämiseen, toteuttamiseen ja arviointiin: 1. Luodaan innovatiivinen ja tarkoituksenmukainen artefakti. Suunnittelututkimuksen tulos on määritelmänsä mukaan tarkoituksenmukainen IT-artefakti, joka on luotu ratkaisemaan tärkeä organisatorinen ongelma. Se on kuvattava tehokkaasti, jotta se voidaan toteuttaa ja soveltaa asianmukaisella tavalla ympäristössä, johon se on suunniteltu. 2. Ongelma on tarkoin määritetty. Koska artefaktin tulee olla tarkoituksenmukainen, sen tulee luoda hyödyllinen ratkaisu määriteltyyn ongelmaan. Tavoitteena on hankkia tietoa ja ymmärrystä, joka mahdollistaa tähän asti ratkaisemattomien, tärkeiden liiketoimintaongelmien teknologiapohjaisten ratkaisujen kehittämisen ja toteuttamisen. Suunnittelutiede lähestyy tätä tavoitetta rakentamalla innovatiivisia artefakteja, joista jokaisen on tarjottava uutta tietoa ja haastettava entiset ratkaisut. Ongelma voidaan määritellä eroiksi tavoitetilan ja järjestelmän nykyisen tilan välillä. Ongelmanratkaisu on etsintäprosessi, jossa etsitään tehokkainta ratkaisua näiden erojen vähentämiseksi tai poistamiseksi. 3. Artefaktin evaluointi on ratkaisevaa. Suunnitellun artefaktin hyödyllisyys, laatu ja tehokkuus on osoitettava tarkasti hyvin toteutettujen arviointimenetelmien avulla. ITartefakteja voidaan arvioida toimivuuden, täydellisyyden, johdonmukaisuuden, tarkkuuden, suorituskyvyn, luotettavuuden, käytettävyyden ja yhteensopivuuden organisaatioon ja muiden asiaankuuluvien laatuattribuuttien perusteella. Arviointivaihe antaa olennaista palautetta suunnitteluprosessin ja kehitettävän tuotteen laadusta. Artefakti on täydellinen ja tehokas, kun se täyttää sen ongelman vaatimukset ja rajoitukset, siinä liiketoimintaympäristössä, jossa sen oli tarkoitus toimia. 4. Tutkimuksen tulee tarjota jokin selkeä panos. Tehokkaan suunnittelututkimuksen on tarjottava selkeä panos joko suunnitteluartefaktiin, suunnittelun perustuksiin ja/tai suunnittelun menetelmiin liittyen. Useimmiten tutkimuksen tarjoama panos on suunniteltu IT-artefakti. 13 5. Artefaktin tulee olla täsmällisesti määritelty, virallisesti esitetty ja johdonmukainen. Täsmällisyys liittyy tapaan, jolla tutkimus suoritetaan. Suunnittelututkimus edellyttää täsmällisten menetelmien soveltamista sekä suunnitellun artefaktin rakentamisessa että sen arvioinnissa. 6. Suunnittelutiede toimii parhaan ratkaisun etsintäprosessina. Suunnittelututkimus on pohjimmiltaan etsintäprosessi tehokkaan ratkaisun löytämiseksi. Ratkaisua haetaan iteroiden, kunnes paras ja optimaalisin tulos saavutetaan. 7. Suunnittelututkimuksen tulokset on kommunikoitava tehokkaasti. Suunnittelututkimuksen tulokset tulee esittää sekä teknologiaorientoituneelle että johtamislähtöiselle yleisölle. Tämä antaa organisaatiolle mahdollisuuden hyödyntää artefaktin tarjoamia etuja ja antaa samalla myös tutkijoille mahdollisuuden rakentaa kumulatiivista tietopohjaa. Näin luodaan ymmärrystä prosesseista, joilla artefakti on rakennettu ja kuinka sitä on arvioitu. 3.3 Tutkimusmenetelmän keskeiset vaiheet Siinä missä Hevner ym. (2004) määrittelevät tutkimusmenetelmän yleiset ohjenuorat, keskittyy Hevner (2007) artikkelissaan analysoimaan tutkimusprosessia kolmen läheisesti toisiinsa liittyvän toimintasyklin kautta, jotka on esitetty kuviossa 2. Kuvio 2. Suunnittelututkimuksen vaiheet Hevner (2007) mallin mukaan, vapaa käännös. 14 Relevanssisyklissä (engl. relevance cycle) määritellään vaatimukset, jotka syntyvät tutkimuksen kontekstuaalisesta ympäristöstä, kuten ihmiset, organisaatio ja tekniset järjestelmät. Samalla pyritään tunnistamaan uusia mahdollisuuksia ja ongelmia kyseisessä ympäristössä. Vaatimusten lisäksi relevanssisyklissä määritellään myös hyväksymiskriteerit tutkimustulosten lopullista arviointia varten. Suunnittelututkimuksen tuotos, artefakti palautetaan ympäristöönsä kenttätestausta varten. Relevanssisyklin toinen iteraatio alkaa palautteella kenttätestauksesta ja etenee tutkimusvaatimusten uudelleenmääritykseen todellisen kokemuksen perusteella. Relevanssisykli yhdistää näin tutkimusprojektin kontekstuaalisen ympäristön suunnittelutieteen toimintoihin. Täsmällisyyssyklissä (engl. rigor cycle) tarkastellaan teorioita ja menetelmiä, alan kokemusta ja asiantuntemusta sekä sovellusalueelta löytyneitä artefakteja ja prosesseja, eli tutkimuksen tietopohjaa. Tutkimuksen aikana syntyvä uusi tieto lisätään olemassa olevaan tietopohjaan. Tällaisia lisäyksiä voivat olla laajennukset teorioihin, uudet artefaktit sekä tutkimuksen perusteella syntyvä kokemus. Näin voidaan arvioida tutkimusprojektin innovatiivisuutta. Tällä tavoin täsmällisyyssykli yhdistää suunnittelutieteen toiminnot tietopohjaan. Suunnittelusykli (engl. design cycle) on jokaisen suunnittelututkimusprojektin sydän. Tässä syklissä iteroidaan varsinaisen artefaktin ja prosessien rakennusja evaluointivaiheita, kunnes haluttu lopputulos saavutetaan. Hevner (2007) pitää tärkeänä ymmärtää suunnittelusyklin riippuvan kahdesta muusta syklistä. Artefaktia arvioidaan sille relevanssisyklissä asetettuja vaatimuksia vastaan. Suunnitteluja evaluointiteoriat ja -metodit puolestaan pohjautuvat täsmällisyyssykliin. Hevner (2007) mukaan näiden kolmen syklin on oltava läsnä ja selkeästi tunnistettavissa hyvässä suunnittelutieteen tutkimusprojektissa. Tämä erottaa suunnittelututkimuksen selvästi muista tutkimusparadigmoista. 3.4 Menetelmän käyttö tässä tutkimuksessa Suunnittelututkimuksen valinta tämän tutkimuksen menetelmäksi on perusteltua, koska tutkimus on selkeästi ratkaisulähtöinen ja on olemassa aito ongelma. Tutkimuksen tuloksena suunnitellaan ja toteutetaan uusi artefakti, työkalu, joka vastaa kohdeorganisaation konkreettiseen haasteeseen. Toteutettavaa artefaktia tutkitaan ja evaluoidaan siinä kontekstissa, jossa sillä on tarkoitus. Samalla tuotetaan uutta ymmärrystä tilanteesta, jossa artefakti vaikuttaa. 15 Kohdeorganisaation ongelma lukeutuu viheliäiseksi. Vuorovaikutussuhde nykyisen komponenttikirjaston komponenttien välillä on monimutkainen, eikä tue tyyliltään yhtenäisen ilmeen muodostusta. Kyseessä on lisäksi ongelma, jonka ratkaisu perustuu ihmisen sekä kognitiivisiin että sosiaalisiin kykyihin. Kun useat kehittäjät luovat komponentteja ilman yhteisiä ohjeita, lopputulos on vahvasti riippuvainen tekijänsä teknisistä taidoista, ajatusmallista ja siitä kuinka hän itse on tehtävän ymmärtänyt. Toteutus riippuu myös ryhmädynamiikasta ja siitä, miten tehokkaasti tiimityötä hyödynnetään parhaan ratkaisun saavuttamiseksi. 3.5 Tutkimuksen vaiheet Tutkimus toteutetaan sykleittäin Hevner (2007) mallia mukaillen. Relevanssisyklissä selvitetään toteutettavan työkalun vaatimukset ja hyväksymiskriteerit. Täsmällisyyssyklissä selvitetään tutkimuksen tietopohja, olemassa olevat ratkaisut, työskentelytavat, tietämys, kokemus ja asiantuntemus. Tutkimuksen tärkein sykli on kuitenkin suunnittelusykli, jota iteroiden suunnitellaan ja toteutetaan työkalu kohdeorganisaation tarpeisiin. Jokaisen iteraation päätteeksi suoritetaan evaluointi. Lopuksi palataan relevanssisykliin arvioimaan, kuinka hyvin asetetut vaatimukset täyttyivät ja täsmällisyyssykliin selvittämään, mitä uutta tietämystä artefakti lisäsi tietopohjaan. 3.5.1 Nykytilan kartoitus: täsmällisyyssykli Ensin on muodostettava kuva kohdeorganisaation tämänhetkisestä toimintatavasta, teknisistä ratkaisuista sekä näihin liittyvistä haasteista. Tutkitaan komponenttikirjaston sisältöä ja poimitaan kaikki se, mikä voisi jollain lailla liittyä käyttöliittymän ilmeeseen. Kuinka laajalti Chakra UI -komponentteja on käytössä ja mitä tyylejä niihin liittyy? Kuvataan esimerkinomaisesti, kuinka tuoterungot rakentuvat kirjaston komponenteista. 3.5.2 Tavoitetilan kartoitus: relevanssisykli Määritellään, mitkä komponentit tulisi sisällyttää tyylioppaaseen ja millaisia variaatioita niistä tulisi olla. Tämän perusteella muodostetaan tyylioppaan tavoitetila. Määritellään myös, miltä osin komponenttien tulisi olla muokattavissa asiakastoteutuksissa ja kuinka tämä tulee toteuttaa. Millaisia asioita tyylinvalvojan halutaan tarkastavan yksittäisistä komponenteista ja edelleen tuoterungoista? Kartoitetaan saatavilla olevien testityökalujen kirjo ja valitaan tutkimuksessa käytettävät työkalut. Päätetään, miten työkalun onnistumista arvioidaan tutkimuksen 16 päätteeksi ja mitkä ovat hyväksymiskriteerit. 3.5.3 Tyyliopas: suunnittelusykli Suunnitellaan ja toteutetaan tyylioppaan sisältö, rakenne, tarvittavat komponentit ja niiden eri variaatiot. Kirjoitetaan niihin liittyvä dokumentaatio sekä yleiset tyyliohjeet. Toteutus evaluoidaan ja tarvittaessa suoritetaan uusi iteraatio. 3.5.4 Ohjeet komponenttikirjaston rekonstruktiolle: suunnittelusykli Nykyisen komponenttikirjaston koko ja rakenne huomioiden täydellisen rekonstruktion toteuttaminen tutkimuksen puitteissa on mahdotonta. Sen sijaan laaditaan ohjeet komponenttikirjaston rekonstruktiolle. Täsmällisyyssyklissä kerättyjen tietojen perusteella ohjeistetaan kohdeorganisaatiota komponenttien tyylimääritysten poistamisessa ja siinä, kuinka viittaaminen tyylioppaan komponentteihin tehokkaimmin tapahtuisi. Ohjataan myös sivumallien käyttöönotossa ja muutoksissa organismikohtaisten näyte-ikkunoiden (Playground) esityksissä. Määritellään toimenpiteet vaiheittain, jotta aikaansaadaan komponenttikirjasto, joka perustuu elävään ja helposti ylläpidettävään tyylioppaaseen. 3.5.5 Tyylinvalvoja: suunnittelusykli Suoritetaan tutkimukseen valittujen testityökalujen vertailu toteuttamalla kullakin työkalulla sama muutaman komponentin testijoukko. Evaluoidaan vertailun tulokset ja valitaan varsinaisessa tyylinvalvojassa käytettävä työkalu. Suunnitellaan ja toteutetaan visuaaliset käyttöliittymätestit. Yksittäisten komponenttien sekä mahdollisuuksien mukaan tuoterunkojen näyteikkunoiden graafinen ulkoasu testataan ohjelmallisesti. Komponenttikirjastoon liitetään raportti visuaalisen testauksen tilasta ja koodikattavuudesta. Toteutus evaluoidaan ja tarvittaessa suoritetaan uusi iteraatio. 3.6 Artefaktin evaluointi Suunnittelusyklien iteraatioiden päätteeksi suoritetaan artefaktin evaluointi. Arvioidaan, täyttääkö suunniteltu ja toteutettu työkalu iteraatiolle asetetut vaatimukset. Arvioidaan myös, kuinka herkkä työkalu on ympäristön muutoksille tai muutoksille itse työkalussa eli kuinka työkalun ja ympäristön vuorovaikutus muuttuu, jos ympäristö tai työkalu itse muuttuu. 17 Kuvio 6. Invoices-komponentin rakenne UML-kaaviona. Invoices-komponentti on hyvä esimerkki tuoterungon yhdestä moduulista, joka toimii itsenäisesti. Se voidaan joko sisällyttää tai jättää pois asiakastoteutuksesta. Samalla periaatteella toimii esimerkiksi Messages-komponentti. Sen toteutukseen tarvitaan 19 kirjastossa olevan komponentin yhteistyötä. Samaan tapaan rakentuvat tuoterungon muutkin moduulit. 4.1.5 Komponenttien tyyli Käyttöliittymän pääasiallinen ilme rakentuu tällä hetkellä Chakra UI -komponenttien ulkoasusta. Kuitenkin vain harvoin, on komponentteja käytetty sellaisenaan. Valtaosa Chakrakomponenteista on jollain tavalla tyylitelty: käytetty tiettyä varianttia, väriä, kokoa, marginaaleja tai välistyksiä. Kaikki nämä tyylimuotoilut on toteutettu kirjaston komponenttien sisällä niin, että jokaisella Chakra-instanssilla saattaa olla erilaiset tyylimääreet. Samat määreet osittain toistuvatkin, mutta toteutustapa selkeästi hankaloittaa tyylin ylläpitoa ja mahdollista muutosta. Esimerkiksi Chakra:n Button-komponentti on käytössä 42 eri komponentissa, joista lähes kaikkien yhteydessä on jonkinlainen muotoilu. Jos painikkeen ulkoasua halutaan yhtenäis24 tää, on muutos tehtävä jokaiseen Button-komponentin instanssiin. Käyttöliittymästä löytyy tällä hetkellä 17 erilaista painiketta, joista useimmilla on edelleen painikkeen tilaan liittyviä, osin toisistaan poikkeavia muotoiluja. Sivujen asettelussa on käytetty monenlaista toteutustapaa. Vaikka yleisilme näyttää yhtenäiseltä, sen takaa löytyy eri komponentein toteutettuja rakenteita. Chakra UI:lla on valmiina mainio ryhmittelykomponentti Stack, josta edelleen on olemassa valmiit VStackja HStack -toteutukset (vertikaalinen ja horisontaalinen). Näitä on käytetty keskimäärin 30 komponentissa kutakin, mutta niiden lisäksi sivuasettelua on toteutettu hämmästyttävän usein Flexja Box-komponentein. Jälkimmäiset toimivat tässä tarkoituksessa kyllä, mutta vaativat enemmän tyylimäärityksiä näyttääkseen samalta kuin valmiit ryhmittelyyn tarkoitetut komponentit. Yhtenäisen ilmeen ja koodin luettavuuden vuoksi olisi hyvä käyttää samoja yhteisesti valittuja komponentteja. Komponenttien responsiivisuus on toteutettu vaihtelevin tavoin. Useimmat komponentit toimivat eri kokoisilla näytöillä, mutta jälleen toteutustapa on erilainen. Osa komponenteista käyttää Chakra:n valmista hookia, useBreakpointValue, jolla elementtien tyyli sidotaan ruudun kokoon muuttujan avulla. Valtaosalla komponenteista responsiivisuus perustuu Chakra:n sisäänrakennettuihin taitekohtiin (engl. breakpoint), jotka voidaan määritellä kullekin projektille teeman yhteydessä. Komponenteille annetaan tällöin kutakin taitekohtaa vastaava tyylimääre. Jos teemassa ei näitä kohtia ole määritelty, käytetään Chakra:n oletusasetuksia. Tällaisen responsiivisuuden voi edelleen toteuttaa taulukkotai olio-syntaksina. Molemmat tavat ovat käytössä tämän hetken komponenttikirjastossa. Jälleen, vähintäänkin koodin luettavuutta helpottaisi yhtenäinen tapa toimia. Elementtien koko voidaan ilmaista useilla eri tavoilla ja mittayksiköillä. Kirjaston komponenteissa kokoja on määritelty ainakin yksiköissä px,rem,vh ja %. Lisäksi Chakra:n elementtikohtaisista koko-ominaisuuksista on käytössä välistyksille ja marginaaleille objektimuoto, esimerkiksi 2, joka vastaa kokoa 0.5rem tai 8px. Tekstin koko on yleensä määritelty Chakra:n oletuskokoja käyttäen, kuten sm,md,lg, mutta poikkeavia tapoja löytyy myös, jopa komponenttien sisältä. Myös tekstin paksuudessa, otsikoiden tyylissä sekä monissa muissa ominaisuuksissa on käytössä erilaisia tapoja saavuttaa jokin lopputulos. Valtaosa komponenttien tyyleistä on siis määritelty kunkin instanssin yhteydessä. Mainittakoon vielä, että tämän lisäksi esimerkiksi DatePicker-komponentilla on täysin oma erillinen CSS-tiedostonsa, josta komponentin ulkoasu haetaan. Myös komponentit, joiden toteutuksessa 25 on käytetty charts.jstai VisX-visualisointia aiheuttavat poikkeuksen toimintatavassa. Näiden osalta määritykset joko haetaan oletuksena käytettävästä kirjastosta tai annetaan vakioina komponentin toteutuksen yhteydessä. Edellä mainitut epäjohdonmukaisuudet ja ylläpitoa hankaloittava rakenne kielii yhteisen tyylioppaan puutteesta. Suurena haasteena projektin onnistumiselle on se, että kirjastossa on jo valtava määrä valmista toimivaa koodia. Tätä tutkimusta tehdessä kirjasto on käytössä ja muuntuu koko ajan. Elävän tyylioppaan sisällyttäminen kirjastoon ja komponenttien nykyisten tyylien ohjaaminen yhteen paikkaan vaatii rakenteen massiivista uudelleen järjestelyä. Uuden toimintatavan hyväksyminen ja sen omaksuminen osaksi rutiinia vaatii organisaatiolta vahvaa sitoutumista ja joustoa. Tarkoitus on lopulta helpottaa kehittäjien työtä, ei hankaloittaa sitä. 4.2 Relevanssisykli: työkalun vaatimukset ja hyväksymiskriteerit Tässä luvussa esitellään tyylioppaalle ja sen valvojalle asetetut vaatimukset. Toteutettavan työkalun tavoitetila määritellään vaatimusmäärittelyn avulla, joka jaetaan kahteen osaan, tyylioppaan ja tyylinvalvojan vaatimuksiin. Tyylioppaan osalta määritellään yleiset vaatimukset, tyyleihin liittyvät vaatimukset sekä toteutettavien komponenttien vaatimukset. Tyylinvalvojan osalta keskitytään työkalun valintaan ja sille määriteltäviin yleisiin vaatimuksiin. Luvussa esitellään myös, miten artefaktin onnistumista arvioidaan tutkimuksen päätteeksi ja mitkä ovat sen hyväksymiskriteerit. 4.2.1 Tyylioppaan vaatimukset Kuviossa 7 on esitetty tyylioppaalle asetetut yleiset vaatimukset, jotka kattavat tyylioppaan sijainnin, rakenteen ja toteutuksen lisäksi vaatimuksia mm. komponenttien nimeämiseen, koodauskäytäntöön ja dokumentointiin liittyen. Myös asiakastoteutuksia varten tarvittava räätälöinti ja sen vaikutukset monikäyttöisiin graafisiin komponentteihin on otettava huomioon tavoitetilaa määriteltäessä. Yleisten vaatimusten yhteydessä asetetaan myös tyylioppaan hyväksymiskriteerit. Tämän tutkimuksen tavoitteena on toteuttaa sellainen osa tyyliopasta, jota voidaan käyttää esimerkkinä työn jatkamisessa kohti täydellistä tyyliopasta ja edelleen suunnittelujärjestelmää. 26 Kuvio 7. Vaatimusmäärittely: tyylioppaan yleiset vaatimukset. Tyylioppaan sijainti, rakenne ja tekninen toteutus olemassa olevaan komponenttikirjastoon nähden on tarkkaan mietittävä. Komponenttikirjasto sisältää jo runsaasti toimivaa koodia, jonka refaktorointi liittyy olennaisena osana tyylioppaan käyttöönottoon, kun toteutetaan elävää tyyliopasta. Sovelluksissa käytettävien komponenttien tulisi voida ongelmitta hyödyntää tyylikirjastoon luotuja komponentteja. Ensimmäinen ajatus on luoda tyyliopas komponenttikirjaston Playground-projektin sisälle. Tyylikirjaston pohja luotaisiin Storybook-ohjelmistolla (Storybook 2024), joka on avoimen lähdekoodin käyttöliittymätyökalu. Storybook:illa voidaan luoda, tarkastella ja testata kom27 ponentteja eristyksissä muusta ohjelmistosta. Storybook:in keskeisin hyöty syntyy automaattisesti muodostuvasta komponenttien katalogimaisesta esityksestä käyttöliittymässä, jossa komponenttien eri variaatioita on helppo selata. Katalogi sisältää myös komponenttikohtaista dokumentaatiota, joka syntyy vaivatta komponenttien luonnin yhteydessä. Kokeiltaessa tällaista toteutusta syntyy ajatus siitä, voisiko tyyliopas korvata koko Playgroundprojektin, joka tällä hetkellä toimii komponenttikirjaston ”näyteikkunana”. Nykyisessä Playground:issa ei esitetä yksittäisiä komponentteja vaan valmiita, monimutkaisia kokonaisuuksia, joista sovelluksen varsinaiset sivut muodostuvat. Storybook:in rakenne voitaisiin määritellä niin, että sen pienimmät komponentit (atomit) muodostaisivat suurempia kokonaisuuksia (molekyylit, organismit) ja edelleen malleja. Nämä moduulit edustaisivat tyylioppaan sisältöä ja olisivat komponenttikirjaston käytettävissä. Kun Storybookin malleihin lisättäisiin dataa, syntyisivät näkymät, jotka esittäisivät käytännössä saman asian, kuin Playground tällä hetkellä. Näin erillistä Playground:ia ei tarvittaisi, vaan Storybook toimisi sekä tyylioppaan, että valmiiden sivujen näyteikkunan roolissa. Vaihtoehtona keskustellaan myös tyylioppaan toteutuksesta ilman erillistä työkalua. Myös tällöin komponenttikirjaston nykyiset komponentit pilkottaisiin pienempiin, uudelleenkäytettäviin osiin, joista suurempia kokonaisuuksia koottaisiin. Ongelmaksi muodostuisi tyylikirjaston komponenttien esittely ja dokumentointi, koska varsinainen katalogi olisi koottava komponenteista erikseen ja tehtävä joko manuaalisesti tai jonkinlaista koodigeneraattoria käyttäen. Rakenne olisi kuitenkin selkeä, komponentit olisivat helposti löydettävissä ilman erillisiä kansioita tai tarvetta erilliselle selainikkunalle. Tyyliopas olisi näin Playground:in sisällä, paikassa, johon kehittäjät ovat jo valmiiksi tottuneet. Lisäksi Playground:issa jo valmiina oleva autentikointi mahdollistaisi datan hakemisen tarvittaessa. Molemmilla tavoilla tyylikomponenttien hakeminen kirjaston monimutkaisimpien komponenttien käyttöön onnistuu. Keskustelujen ja useiden demojen pohjalta päädyttiin lopulta ratkaisuun, jossa tyyliopas perustetaan ilman erillistä työkalua komponenttikirjaston juurikansioon, ja sen visuaalinen eritys osaksi nykyistä Playground-käyttöliittymää. Tyylikomponentit luodaan projektin juureen, components > UI-kansioon. Lisäksi kohdeorganisaation kanssa sovittiin, että tyylioppaan ensimmäinen toteutus olisi suomenkielinen, huolimatta siitä, että koodi on dokumentoitu englanniksi. Organisaation nykyisen rakenteen ja käyttäjäystävällisyyden vuoksi ohjeet on hyvä olla kehittäjien äidinkielellä. 28 4.2.2 Tyyleihin liittyvät vaatimukset Tyylioppaan Tyylit-osiossa käsitellään typografia, ikonit, välistys ja värit. Kuviossa 8 on esitetty tyylioppaan tyyleihin liittyvät vaatimukset. Kuvio 8. Vaatimusmäärittely: tyylioppaan tyyleihin liittyvät vaatimukset. Typografia sisältää käytettävät fontit, sekä ohjeet leipätekstin ja otsikoiden johdonmukaiseen käyttöön. Ikonien osalta vaatimuksia määritellään ainoastaan perusikoneille, koska kuvitusi29 koneita ei toteutuksen tässä vaiheessa tarvita. Välistyksen osalta määritellään tilankäyttöön ja elementtien sijoitteluun liittyvät seikat ja kuinka määriteltyjä arvoja käytetään. Värien käytölle määritellään erilaisia tarpeita, annetaan ehdotus väripalettien käytöstä ja esitellään sovelluksessa tarvittavat väripaletit. Kunkin tyylielementin osalta otetaan myös kantaa teematiedoston räätälöintiin asiakastoteutuksia varten. 4.2.3 Tyylioppaaseen sisällytettävät komponentit ja niiden vaatimukset Keskusteluissa todetaan, ettei tyylioppaassa ole järkevää toistaa kaikkia Chakra UI:n komponentteja, vaan tulee keskittyä niihin, joita halutaan muotoilla eniten. Valtaosa Chakra UI:n komponenteista on käytössä miltei sellaisenaan ja olisi tässä vaiheessa hyödytöntä kopioida jokaista tyylioppaaseen. Toki pidemmälle mietittynä ja riippuvuuden mahdollisen purkamisen vuoksi jokaisen tarvittavan komponentin tulisi olla osana tyyliopasta. Tässä vaiheessa päätetään keskittyä tyylin kannalta olennaisiin komponentteihin. Kuviossa 9 on esitetty tyylioppaan alustavat vaatimukset komponenttien osalta. Joukkoon on valittu vain ne komponentit, joilla arvellaan olevan eniten merkitystä yhtenäisen tyylin luomisessa. Esimerkkikomponentiksi valitaan yksiselitteisesti painikekomponentti Button, jonka merkitys yhtiön ilmeen kannalta on olennaisin. Toteutusvaiheessa voidaan vaatimuksia muokata, jos huomataan jonkin olennaisen komponentin puuttuvan tai jonkin olevan lisäarvoltaan tarpeeton. Painikkeen ja typografian yhteydessä mainittujen otsikon (Heading) ja leipätekstin (Text) lisäksi mukaan valitaan vaatimusmäärittelyvaiheessa heräte (Alert), valikko (Menu), dialogi (Menu), ponnahdusikkuna (Popover) ja lisätietokomponentti Tooltip. Lomakkeen (Form) yhteydessä määritellään erilaiset syötekentät. Lisäksi vaatimuksiin kirjataan tietysti myös taulukkokomponentti (Table). Graafisten, organisaatiospesifien komponenttien toteutus on olennainen osa tyylioppaan suunnitteluja toteutustyötä. Komponenttien monikäyttöisyys erilaisissa yhteyksissä halutaan varmistaa tutkimalla tarkkaan niiden nykyistä käyttötarkoitusta, rajapintoja ja vuorovaikutusta toisten komponenttien kanssa. Tältä osin suunnitteluun varataan enemmän aikaa. 30 Kuvio 9. Vaatimusmäärittely: tyylioppaan komponentteihin liittyvät vaatimukset. 4.2.4 Malleihin liittyvät vaatimukset Kuviossa 10 on esitetty tyylioppaan sivumalleihin liittyvät vaatimukset. Määritellään sivulle raamit ja se, miten sisältö muodostuu. Tyylioppaassa esitellään esimerkinomaisesti erilaisia 31 sivumalleja, joiden responsiivista esitystapaa voi kokeilla pienentämällä ruutukokoa. Kuvio 10. Vaatimusmäärittely: tyylioppaan malleihin liittyvät vaatimukset. 4.2.5 Tyylinvalvojan vaatimukset Tyylinvalvojalle asetetut vaatimukset on esitetty kuviossa 11. Vaatimukset kattavat tyylinvalvojan sijainnin, toiminnan ja toteutuksen lisäksi vaatimuksia mm. testauksen ajoitukseen, virhemarginaaliin ja koodikattavuuteen liittyen. Vaatimusmäärittelyn yhteydessä asetetaan tyylinvalvojalle myös hyväksymiskriteerit. Kuvio 11. Vaatimusmäärittely: tyylinvalvojan vaatimukset. 32 4.3 Suunnittelusykli: tyylioppaan toteutus Vaatimusmäärittelyyn perustuen tyyliopas toteutetaan ilman erillistä työkalua osaksi Playground-käyttöliittymää. Toteutus aloitetaan sivuvalikon muutoksilla. Käyttöliittymän sivuvalikkoon lisätään väliotsikot UI-Komponentit,UI-Tyylit ja UI-Mallit, jotka sisältävät kaikki tyylioppaan osat. Playground:in sivut löytyvät edelleen Sierra-componentsvalikosta. 4.3.1 Komponentit Jotta komponenttien tunnistus valikosta olisi kehittäjille helppoa, niiden nimet jätetään englannin kielelle. Tyylioppaan sivut halutaan pitää yksinkertaisena ja keskenään samanlaisina. Sivun otsakkeen alla on lyhyt kuvaus komponentin tarkoituksesta. Kohdeorganisaation toive on, ettei liian pitkiä dokumentaatioita lisättäisi, koska esimerkit puhuvat paremmin puolestaan. Kehittäjät haluavat löytää hakemansa nopeasti ja visuaalinen versio edesauttaa tätä paremmin. Komponenttien sivulla on kolme välilehteä: Esimerkit, joka esittelee kaiken tarpeellisen komponenttiin liittyvän tekstein ja visuaalisessa muodossa, Propsit, jossa on taulukkomuodossa esitettynä kaikki komponentilla olevat ominaisuudet sekä Parametrit, jossa esitellään komponentin organisaatiospesifit parametrit. Kunkin esimerkin jälkeen käyttäjän on mahdollisuus avata lähdekoodi ja kopioida se leikepöydälle. Button. Esimerkkikomponentiksi valitun Button-komponentin luominen aloittaa tyylioppaan sisällön muodostuksen. Button:ista esitellään variantit, lataustila ja estetty tila. Button:in osalta ajatus organisaatiospesifistä komponentista ei toimi. On helpompi soveltaa Chakra:n Button-komponenttia sellaisenaan ja muodostaa siihen erilaisia variantteja käyttöä varten. Tällainen lähestymistapa on kohdeorganisaation toive, vaikka se rikkoo yhtenäisen linjan toteutustavan suhteen. Alun perin ajatuksena oli mahdollisuus tarvittaessa purkaa vahva Chakra-riippuvuus ja tämä tapa ei tue tuota periaatetta. Chakra:n tarjoama varianttimenettely on kieltämättä toimiva ja tällä voidaan välttää jokaiselle erilaiselle painikkeille oman komponentin luominen. Varianttien muotoilu toteutetaan ohjelmiston teematiedostossa. Kullakin variantilla on nimi, joka annetaan komponentin kutsun yhteydessä. Teematiedosto huolehtii, että variantti on halutunlainen. Variantteja ovat primary,secondary,outline,ghost ja link. Latausja estetty tila näytetään kaikille varianteille. Teematiedosto on muokattavissa, jolloin myös painikkeille saadaan haluttaessa asiakkaan toiveiden mukainen ulkoasu. Input ja Form. Eräs kohdeorganisaatiolle päänvaivaa aiheuttanut seikka on ollut lomak33 _active={{ color: ’white’, bg: ’brand.300’ }} _focus={{ boxShadow: ’none’, color: ’white’, bg: ’brand.300’, }} onClick={onClickReturn} > Takaisin tuotevalintaan </Button> ... Koodilohko 3. Button-esiintymä. Painikkeen leveys on yleisesti annettu ominaisuus, yleensä haetaan täyttä leveyttä. Kannattaa pohtia, olisiko hyötyä variantista, jolle olisi asetettu täysi leveys jo valmiiksi. Oletuksena painike ottaa tekstinsä vaatiman leveyden. Jos halutaan painikkeen täyttävän koko käytössä oleva tila, leveys on annettava erikseen. Painikkeen variantit on kirjattu tiedostoon akamon-chakrabase-theme.ts ja niitä voidaan tarpeen vaatiessa muokata tai luoda lisää. Form. Lomakkeita esiintyy kirjaston 19 komponentissa, joista kahdella on edelleen riippuvuuksia muualla. FormInput-komponenttia käyttää 2 komponenttia ja FormRadiokomponenttia 5 muuta kirjaston komponenttia. Tyylioppaan lomakegeneraattorin sopivuus täytyy tarkistaa komponentti kerrallaan. Tavoitetila on, että kaikki sovelluksen lomakkeet voitaisiin luoda yhteistä lomakegeneraattoria käyttäen eikä erillisiä monikäyttöiseksi tarkoitettuja lomakkeen osia tarvittaisi. Chakra UI:n Form:ia käyttävät komponentit on esitetty taulukossa 3. 40 Komponentin sijaintipolku Komponentin nimi playground/src/components/ AveragePrice src/components/ BasicInformation src/components/.../ AutomaticSignUpCheckbox src/components/.../ ContractInformation src/components/.../ TermsOfSale src/components/.../ ConsumptionInputs src/components/.../ ContractTerminationForm src/components/.../ DatePickerCustomInput src/components/.../ YearlySavings src/components/.../ EtrmFormInput src/components/.../ EtrmManualGsrnSelectModal src/components/.../ EtrmMeteringPointFormSectionConsumption src/components/.../ EtrmOfferSummaryCardSendToEmailModal src/components/.../ FormInput src/components/.../ FormRadio playground/src/components/ Login src/components/.../ MessageForm src/components/.../ NewContactModal src/components/ ProductComparison Taulukko 3. Chakra:n Form-komponenttia käyttävät komponentit. Esimerkkinä muokataan NewContactModal-komponentin Form:ia käyttävää osuutta alla olevan koodilohkon 4 mukaan (lähdekoodin rivimäärän vuoksi lohkossa näytetään vain muutettu osuus). Komponentin käyttämä skeematiedosto löytyy UI/schemas-kansiosta nimellä NewContactSchema.ts. Tyylikomponenttiin tarvittavat lisäparametrit on esitetty jäljempänä taulukossa 4. ... <AkamonForm buttonText={t(’button:submit’)} columns={2} onFormSubmit={() => { console.log(’add handleSubmit-method here’); }} 41 schemadata={{ validationSchema, fieldMetadata, }} /> ... Koodilohko 4. Form-esiintymän korvaava koodi. Parametri Selitys tschemadata: validationSchema: T; fieldMetadata: Record<string, any>; Skeeman tuonti oli aiemmin rakennettu AkamonForm:in sisälle. Nyt se haetaan komponenttia kutsuttaessa ja välitetään parametrina lomakegeneraattorille. Taulukko 4. AkamonForm-komponenttiin tarvittavat lisäparametrit. Muutosten yhteydessä erilaisten skeemojen käyttö on mahdollistettu AkamonFormkomponentin geneerisellä tyypillä. Näin TypeScript osaa dynaamisesti päätellä tarvittavat tyypit skeeman perusteella. Myös renderFormControl-komponentin parametreihin ja niiden tyyppeihin on tehty muutoksia, jotta erilaisten skeemojen käyttö on mahdollista. Lisäksi Input-tyyppi switch on lisätty renderFormControl-komponenttiin. Pohdittavaksi jää, tarvitaanko olemassa olevien lisäksi muita input-tyyppejä. Tarpeellisia voisivat olla ainakin liitteen lataaminen (file) ja liukusäädin (range slider). Tarvittaessa lisätään erilaisia tyyppejä renderFormControl-komponentin case-listaan. onSubmit -tapahtuman käynnistää AkamonForm:illa oleva painike. Jos lomake on sisällytetty dialogiin, onko tarkoitus, että dialogi sulkeutuu lomakkeen lähetyksen yhteydessä? Esimerkkikomponentissa lomakkeen lähetys on liitetty modaalin toimintopainikkeisiin. Olisiko lomake monikäyttöisempi, jos se ei sisältäisi lähetyspainiketta? Lisäksi AkamonForm:illa olevan peruutuspainikkeen teksti on kovakoodattu. Sen voisi tarvittaessa tuoda myös parametrina samaan tapaan kuin lähetyspainikkeen tekstin. Tyylioppaan toisen evaluoinnin jälkeen lomakekomponenttia on muutettu edelleen niin, että skeematiedosto on entistä geneerisempi ja sisältää tiedon tarvittavista sarakkeista. Menu. Kirjaston komponenteista 3 käyttää Chakra UI:n Menu-komponenttia. Pohtia kannattai42 si lisäksi, voisiko joitakin Select-komponentteja muuntaa AkamonMenu-komponenteiksi, jolloin tyyli noudattaisi paremmin yhtenäistä ilmettä. Select-komponentti on käytössä kirjaston 12 komponentissa ja sen muotoilu on huomattavasti rajoitetumpaa, kuin Menukomponentin. Chakra UI:n Menu:a käyttävät komponentit on esitetty taulukossa 5 . Komponentin sijaintipolku Komponentin nimi src/components/.../ AsyncMeteringPointList src/components/.../ EnergyTransitionMeteringPointList playground/src/components/.../ LanguageSelector Taulukko 5. Chakra:n Menu-komponenttia käyttävät komponentit. Esimerkkinä muokataan LanguageSelector-komponenttia alla olevien koodilohkojen 5 ja 6 mukaan. Tyylikomponenttiin tarvitaan lisäparametreja, jotka on esitetty jäljempänä taulukossa 6. Samalla lisätään tyylimuotoilu textTransform: capitalize painikkeen sekä valintavaihtoehtojen tekstiin, jotta tekstit alkavat isolla kirjaimella. Esimerkkikomponentissa on lisäksi tyylimuotoiluja, jotka tässä muutoksessa on jätetty toteuttamatta. Näitä ovat ikonien väritys ja painikkeen kulmien pyöristykset. ... <Menu colorScheme="purple"> <MenuButton w="full" as={Button} variant="outline" borderRadius="sm" leftIcon={ <MdOutlineLanguage color={light || ’white’} /> } color={color || ’gray.700’} rightIcon={ <ChevronDownIcon color={light || ’white’} /> } > {languages.find((lng) => 43 lng.value === selectedLocale)?.label} </MenuButton> <MenuList> {languages.sort().map((lng) => ( <MenuItem isDisabled={lng.value === selectedLocale} key={lng.value} onClick={() => handleLocaleChange(lng.value)} style={{ textTransform: ’capitalize’ }} > {lng.label} </MenuItem> ))} </MenuList> </Menu> ... Koodilohko 5. Korvattava Menu-esiintymä. ... <AkamonMenu menuOptions={optionsList} buttonWidth={’full’} buttonState={ languages.find((lng) => lng.value === selectedLocale)?.label } leftIcon={<MdOutlineLanguage />} variant={’outline’} /> ... Koodilohko 6. Menu-esiintymän korvaava koodi. 44 Parametri Selitys buttonWidth?: string Valinnainen painikkeen leveys, jos halutaan esimerkiksi koko raamin levyinen painike. Oletuksena painikkeen leveys mukautuu tekstin leveyden mukaan. buttonState?: string Valinnainen painikkeessa aloitushetkellä näkyvä teksti, oletuksena ei mitään. leftIcon?: ReactElement Valinnainen ikoni menupainikkeen vasempaan laitaan. Oikeassa laidassa on automaattisesti alasvetovalikon nuoli, vasemmassa laidassa ei mitään. variant?: string Painikkeen valinnainen variantti tyylimuotoilua varten. Oletuksena ei varianttia, jolloin käytetään primary-muotoilua. Taulukko 6. AkamonMenu-komponenttiin tarvittavat lisäparametrit. Modal. Dialogeja käytetään kirjaston 10 komponentissa. Jokainen esiintymä tulee pyrkiä korvaamaan AkamonModal-komponentilla, joka sisällön osalta taipuu moneen eri tarkoitukseen. Komponenttia voidaan muokata, jos huomataan, että lisäominaisuuksille on tarvetta. Chakra UI:n Modal:ia käyttävät alla olevassa taulukossa 7 esitetyt komponentit. Komponentin sijaintipolku Komponentin nimi src/components/ AgeRestriction src/components/ CookieModal src/components/.../ EtrmNavigationBlocker src/components/.../ EtrmManualGsrnSelectModal src/components/.../ EtrmOfferSummaryCardSendToEmailModal src/components/.../ MessageModal src/components/.../ NewContactModal src/components/.../ WeatherStationSelect src/components/.../ ReportModal src/components/ SelectCustomer Taulukko 7. Chakra:n Modal-komponenttia käyttävät komponentit. Esimerkkinä muokataan AgeRestriction-komponenttia koodilohkojen 7 ja 8 mukaan. Esimerkki AkamonModal-komponentin tarvitsemasta toimintopainikejoukosta on esitetty alinna lohkossa 9. Tyylikomponenttiin tarvitaan lisäparametreja, jotka on esitetty taulukossa 8. 45 ... <Modal isOpen={isOpen} onClose={onClose} closeOnOverlayClick={false}> <ModalOverlay /> <ModalContent> <ModalHeader> {t(’header’, { ns: ’ageRestriction’ })} </ModalHeader> <ModalBody> {t(’info’, { ns: ’ageRestriction’ })} </ModalBody> <ModalFooter> <Button {...buttonProps} w="full" onClick={() => onClickClose()}> {t(’confirm’, { ns: ’button’ })} </Button> </ModalFooter> </ModalContent> </Modal> ... Koodilohko 7. Korvattava Modal-esiintymä. ... <AkamonModal isOpen={isOpen} onClose={onClose} closeOnOverlayClick={false} title={t(’header’, { ns: ’ageRestriction’ })} content={t(’info’, { ns: ’ageRestriction’ })} actionButtons={actionButtons} /> ... Koodilohko 8. Modal-esiintymän korvaava koodi. 46 ... const actionButtons = [ { variant: ’primary’, text: t(’confirm’, { ns: ’button’ }), onActionButtonClick: () => { onClickClose(); }, shouldClose: true, width: ’full’, }, ]; ... Koodilohko 9. Komponentin parametrina saama toimintopainikejoukko. Parametri Selitys triggerButton: ReactNode Valinnainen dialogin avaava elementti. Parametrina annettaessa voi olla joko painike, ikoni tai jokin muu elementti. Modal:in avautuminen voi perustua myös ehtolauseeseen, jolloin erillistä triggeriä ei tarvita. onClose: () => void Dialogin sulkeva toiminto annetaan kutsun yhteydessä, koska voi olla tarpeen suorittaa erilaisia toimintoja dialogin sulkeutuessa. Taulukko 8. AkamonModal-komponenttiin tarvittavat lisäparametrit. Toimintopainikkeiden leveys voidaan antaa valinnaisena tietona painikkeiden objektijoukossa, ominaisuus on lisätty ActionButton-tyyppiin. Samoin Dialogin avaava painike on poistettu AkamonModal-komponentin sisältä. On myös lisätty mahdollisuus antaa closeOnOverlayClick-ominaisuus komponenttikutsun yhteydessä. Chakra:n Modalkomponentin oletus on true. Samoin dialogin koko voidaan nyt välittää komponenttikutsussa. Chakra:n oletus on md. Voisi olla hyvä pohtia, mille muille dialogin ominaisuuksille saattaisi olla tarvetta. AkamonModal-komponenttia voidaan muokata käyttötarkoitusten mukaan, kuitenkin niin, että toteutus pysyy monikäyttöisenä. 47 Popover. Ponnahdusikkunoita käytetään neljässä kirjaston komponentissa. Yksi näistä on monikäyttöiseksi komponentiksi tarkoitettu Popover, jota edelleen kutsuu 7 muuta kirjaston komponenttia. Chakra UI:n Popover:ia käyttävät komponentit on esitetty taulukossa 9. Komponentin sijaintipolku Komponentin nimi src/components/.../ PopoverButton src/components/.../ InvoiceStatusPopover src/components/ MarketingApproval src/components/ Popover Taulukko 9. Chakra:n Popover-komponenttia käyttävät komponentit. Esimerkkinä muokataan kirjaston Popover-komponentti käyttämään AkamonPopoverkomponenttia alla olevien koodilohkojen 10 ja 11 mukaan, jolloin siihen sidoksissa olevien komponenttien tulisi korjautua kerralla. Tyylikomponenttiin tarvittavat lisäparametrit on esitetty jäljempänä taulukossa 10. ... <Popover trigger="hover" {...popoverProps}> <PopoverTrigger> {children || <InfoOutlineIcon data-testid="default-popover-icon" />} </PopoverTrigger> <PopoverContent> <PopoverHeader> {header} </PopoverHeader> <PopoverCloseButton /> <PopoverBody textAlign="left"> <Stack> {tooltips?.map((tooltip) => ( <Text key={tooltip}>{tooltip}</Text> ))} </Stack> 48 </PopoverBody> </PopoverContent> </Popover> ... Koodilohko 10. Korvattava Popover-esiintymä. ... <AkamonPopover trigger="hover" triggerButton={ <InfoOutlineIcon margin={0} boxSize="30px" /> } title={header} content={ <Stack> {tooltips?.map((tooltip) => ( <Text key={tooltip}>{tooltip}</Text> ))} </Stack> } {...popoverProps} /> ... Koodilohko 11. Popover-esiintymän korvaava koodi. Parametri Selitys triggerButton: ReactNode Ponnahdusikkunan avaava painike. Parametrina annettaessa voi olla joko painike, ikoni tai jokin muu elementti. trigger: string Toiminto, joka avaa ponnahdusikkunan (click/hover). Tämä parametri sisältyy Chakra:n PopoverProps:iin, joten sitä ei tarvitse erikseen esitellä. Silti, jos halutaan ylikirjoittaa oletustriggeri, se on annettava komponentille kutsun yhteydessä. Taulukko 10. AkamonPopover-komponenttiin tarvittavat lisäparametrit. 49 Monet komponenteista tarvitsevat ympärilleen erilaisia raameja, jotta komponentin sisäisten elementtien asettelu toimii halutulla tavalla. Vaikka komponentin ulommainen raami asetettaisiin sivumalliin ilman erillistä välistystä, taustan ollessa väritön, itse sisältö ei täytä koko tilaa. Komponentit näyttävät olevan aseteltu erilaisin välistyksin ja yhtenäinen ilme hajoaa. Alla olevissa kuvioissa 12 ja 13 on esimerkki samasta komponentista, joista ylemmän raami sisältää vertikaalista marginaalia ja alemman ei. Otsikon ja sivusisällön välistys on tämän vuoksi erilainen ja johtaisi kahden sivun epäyhtenäiseen ulkoasuun. Kuvio 12. Yhden sisällön sivumalli komponentin sisäisen marginaalin kanssa. Kuvio 13. Yhden sisällön sivumalli ilman komponentin sisäistä marginaalia. Myös rinnakkain aseteltuna otsikon ja sisällön väliseen eroon vaikuttaa komponenttiin rakennettu marginaali, mutta rinnakkaiset sisällöt asettuvat samalla lailla keskenään, koska 56 suuremman elementin korkeus määrää sisältörivin korkeuden ja sisältö on keskitetty. Kuvioissa 14, 15 ja 16 vasen komponentti ei sisällä vertikaalista marginaalia ja oikea sisältää. Kuvio 14. Kahden sisällön sivumalli toisen komponentin sisäisen marginaalin kanssa. Kuvio 15. Kahden sisällön sivumalli marginaaliton komponentti korostettuna. 57 Kuvio 16. Kahden sisällön sivumalli marginaalia sisältävä komponentti korostettuna. Sivumallin käyttöönotto ja sen toiminnan hyödyntäminen vaatii sivujen läpikäyntiä yksi kerrallaan. Komponenttien uloimmissa kääreissä olevat marginaalit tulee mahdollisuuksien mukaan poistaa ja sisempien kääreiden välistysominaisuuksien merkitys tarkastella erikseen. Tällä hetkellä sisältörivin elementit on keskitetty vertikaalisesti, jolloin rivi näyttää hyvältä, kun sisällöt ovat keskenään samankaltaiset. Kahden hyvin erilaisen ja erikokoisen elementin sijoittaminen samalle riville voi vaatia keskityksen poistamista. Hyödyllistä olisi myös tutkia, missä kaikkialla välistys-ominaisuutta (engl. spacing ) käytetään ja korvata esiintymät tyylioppaassa esitellyillä välistysarvoilla. 4.5 Suunnittelusykli: tyylinvalvojan toteutus Markkinoilla on runsaasti valmiita visuaaliseen regressiotestaukseen tarkoitettuja ohjelmistoja. Tyylioppaan suunnittelun ja toteutuksen viedessä suunniteltua kauemmin todetaan, ettei tämän tutkimuksen puitteissa ole mahdollista toteuttaa tekoälyyn, tietokonenäköön ja koneoppimiseen perustuvaa visuaalista testausta. Sen sijaan yritetään löytää paras snapshot-tekniikalla toimiva työkalu, joka suorittaa tarvittavat visuaaliset regressiotestit ja taipuu jatkossa mahdollisesti myös toiminnalliseen testaukseen. 58 4.5.1 Testaustyökalujen esittely Esitellään kolme snapshot-tekniikkaan ja pikselivertailuun perustuvaa työkalua vaihtoehtoina tyylinvalvojaksi. Sen lisäksi kerrotaan lyhyesti myös eräästä teköälyä käyttävästä työkalusta, koska on hyödyllistä hieman pohtia myös tekoälyyn perustuvan mallin toimintalogiikkaa, jotta ymmärrys saatavilla olevista vaihtoehdoista lisääntyy. Kohdeorganisaatio voi halutessaan harkita sellaiseen malliin siirtymistä tulevaisuudessa. Vitest image snapshots. Komponenttikirjaston toiminnallista testausta hoidetaan tällä hetkellä Vitest-ohjelmistolla, mikä on erityisesti Vite-projektien käyttöön suunniteltu testausympäristö. Tämän vuoksi Vitest:in taipuvuus visuaaliseen testaukseen halutaan tutkia ensimmäisenä. Vitest:issä on olemassa snapshot-ominaisuus, jossa ohjelmisto ottaa tilannekuvan annetusta arvosta ja vertaa sitä sitten testin rinnalle tallennettuun referenssitiedostoon. Vaikka tekniikkaa käytetään myös koodirivien ja tiedostojen vertailuun, tämän tutkimuksen puitteissa keskitytään nimenomaan kuvien vertailuun keskenään. Kuvien snapshot-testaukseen tarvitaan avuksi Jest-laajennus, jest-image-snapshots, joka luo Puppeteer-kirjastoa käyttäen kuvan testattavasta käyttöliittymästä tai yksittäisestä komponentista ja vertaa sitä pikselitasolla aiemmalla testiajolla muodostettuun referenssikuvaan. Testi epäonnistuu, jos kaksi tilannekuvaa eivät täsmää: joko muutos on odottamaton tai referenssikuva on päivitettävä uuteen versioon. (You 2024b) Käytännössä toiminta on seuraavanlainen: •Tallennetaan referenssikuva. Ensimmäisellä testiajolla Puppeteer navigoi käyttöliittymässä halutulle sivulle ja ottaa kuvan testin kohteena olevasta näkymästä tai yksittäisestä komponentista. Kuva tallennetaan referenssikuvaksi seuraaville testiajoille. •Otetaan kuvakaappaus. Seuraavilla testiajoilla Puppeteer tallentaa uuden kuvan testikuvana, jota jest-image-snapshot sitten vertaa aiemmin tallennettuun referenssikuvaan. •Suoritetaan pikselivertailu. Uutta testikuvaa verrataan referenssikuvaan pikseli pikseliltä. Työkalu laskee pikselierot ja vertaa tulosta annettuun toleranssiin. Toleranssi voidaan määritellä testi kerrallaan ja näin asettaa tiukemmat tai löysemmät rajat testauksen kohteen mukaan. •Esitetään tulokset. Jos toleranssirajat ylittyvät, työkalu tallentaa poikkeamakuvan, jossa muutokset näkyvät korostettuna. Kuva on kolmen kuvan sarja, jossa esitetään vasemmalla odotettu kuva (referenssikuva), oikealla todellinen kuva ja keskellä virheet. Tämän jälkeen kehittäjän täytyy tarkastella tuloksia ja arvioida, onko kyse tahattomasta poik59 keamasta vai halutaanko referenssikuvaa muuttaa. Jos muutos on tarkoituksellinen, referenssikuva päivitetään vastaamaan uutta tilannetta komennolla -u. Koska Vitest on jo käytössä kirjaston toiminnallisessa testauksessa, on luonnollista, että se valitaan yhdeksi vaihtoehdoksi myös visuaaliseen testaukseen. Playwright visual comparisons. Toinen Vite-projektien kanssa hyvin yhteensopiva testausympäristö on Microsoftin kehittämä Playwright Test, joka on tehokas useita selaimia tukeva toiminnalliseen sekä end-to-end -testaukseen soveltuva työkalu. Kohdeorganisaatio on tutkimuksen edetessä esittänyt kiinnostusta tätä ohjelmistoa kohtaan, joten sen taipumista visuaaliseen testaukseen halutaan myös tutkia. Playwright Test tarjoaa samanlaiset toiminnallisuudet snapshot-testaukseen kuin Vitest, joskin erilaisin kirjastoin. Playwright ottaa itse kuvakaappaukset ja käyttää kuvien vertailussa Pixelmatch-kirjastoa. Käytännössä toiminta on seuraavanlainen: •Tallennetaan referenssikuvat. Ensimmäisellä ajolla Playwright luo referenssikuvat ottaen useita kuvia ja kahden peräkkäisen kuvan vastatessa toisiaan, jälkimmäinen tallennetaan referenssikuvaksi. •Otetaan testikuvat. Seuraavilla testiajoilla otetaan uusia kuvakaappauksia verrattavaksi referenssikuviin. Koska kuvakaappaukset vaihtelevat erilaisissa selaimissa ja alustoissa, Playwright-dokumentaatiossa suositellaan ottamaan erilliset kuvat erilaisille ympäristöille. •Suoritetaan vertailu. Pikselivertailun suorittaa Pixelmatch-kirjasto, jolle voidaan määrittää toleranssirajat. Esimerkiksi erilaisten ympäristöjen testaamisessa on hyödyllistä sallia pieniä eroja ilman, että testi epäonnistuu. •Raportoidaan tulokset. Testin epäonnistuessa virheet raportoidaan kolmena kuvana, joista ensimmäinen on referenssikuva, toinen testiajon yhteydessä otettu kuva ja kolmannessa kuvassa esitetään visuaaliset poikkeamat korostettuna. Kuvat on tallennettu erillisinä .png-tiedostoina test-results-kansioon. Näiden vaiheiden jälkeen testaajan on arvioitava testaukset tulokset ja päätettävä korjataanko virhe vai halutaanko referenssikuvaa muuttaa. Uuden referenssikuvan tallentaminen onnistuu vaivatta testiajon yhteydessä annettavalla komennolla -update-snapshots. (Microsoft 2024a) Cypress image snapshot. React-sovellusten kanssa hyvin toimiva ja Vite-sovelluksia tukeva 60 Cypress tarjoaa laajan tuen end-to-endja toiminalliselle testaukselle. Lisäosien myötä myös visuaalinen regressiotestaus on mahdollista. Cypress käyttää snapshot-kuvien ottamiseen lisäosaa cypress-image-snapshot, jolla otetaan kuva koko testattavasta sovelluksesta tai tietystä elementistä. Kuvaa verrataan aiemmin hyväksyttyyn peruskuvaan, kuten edellä esitetyissä työkaluissa. Vaihtoehtona on olemassa myös kaupallinen työkalu, Cypress Visual Testing (Cypress Cloud), joka suorittaa snapshot-vertailun pilvessä ja sisällyttää visuaalisen regressiotestauksen osaksi CI/CD-putkea. (Cypress.io 2024) Käytännön toiminta testauksessa on aivan samanlainen, kuin edellä esiteltyjen työkalujen osalta. Ensimmäisellä ajolla muodostetaan referenssikuva, jota vastaan varsinaisten testiajojen kuvakaappauksia arvioidaan. Virheet testiajossa tuottavat poikkeamakuvan, jossa vasemmalla esitellään odotettu tulos ja oikealla varsinainen testin tulos, erot korostettuina keskimmäisessä kuvassa. Edellisistä työkaluista poiketen Cypressiin kuuluu käyttöliittymätyökalu, jossa testit voidaan ajaa ja niiden tuloksia tarkastella. Cypress:iin, kuten muihinkin suosittuihin testausalustoihin on saatavilla myös visuaaliseen testaukseen suunniteltuja Plugineita. Näistä mainittakoon esimerkkinä Applitools Eyes, jonka toimintaa tarkastellaan seuraavassa. Applitools Eyes. Applitools on suosittu tekoälyavusteinen testausratkaisu, joka integroituu helposti useimpiin nykyaikaisiin testausalustoihin, kuten yllä mainitut Vitest, Playwright ja Cypress. Sen keskeinen komponentti on Applitools Eyes, joka käyttää Visual AI-tekoälyä ja kuvantunnistustekniikoita visuaalisten erojen havaitsemiseksi käyttöliittymän kuvakaappauksissa, jotta niitä voidaan tarkastella ihmissilmän tavoin. Kuvakaappauksia voidaan arvioida useilla eri alustoilla ja laitteilla yhden testiajosarjan aikana. Tekoäly osaa erottaa merkitykselliset visuaaliset erot pienistä renderöintieroista, joihin pikselivertailussa usein takerrutaan. Applitools Eyes:ille voidaan määrittää alueita, esim. päivämääriä ja ilmoituksia, jotka se voi ohittaa. Vaihtoehtoisesti dynaaminen sisältö voidaan ohittaa tekoälyn avulla. Pääasiassa testaus tapahtuu hyvin samalla tavalla kuin perinteisessä snapshot-pikselivertailumallissa, mutta tulokset ovat luotettavampia ja manuaalisen työn määrä vähäisempi. Testauksen vaiheet Applitools Eyes:illa: •Integrointi. Työkalu integroidaan käytössä olevaan testausympäristöön ja testit määritellään ottamaan kuvakaappauksia joko kokonaisista sivuista tai yksittäisistä komponenteista. 61 •Otetaan kuvakaappaukset. Testiajoilla Applitools Eyes tallentaa kuvakaappaukset ja vertaa niitä referenssikuviin. Eroavaisuudet raportoidaan pilvipohjaisessa käyttöliittymässä poikkeamakuvina. •Raportoidaan tulokset. Applitools:in raportointityökalu, Test Manager tarjoaa käyttäjäystävällisen tavan analysoida testien tuloksia. Eyes on jo valmiiksi poistanut vääriä positiivisia hälytyksiä, joten tarkasteltavaa jää kehittäjälle vähemmän. •Hyväksytään tai hylätään muutokset. Uusien referenssikuvien tallentaminen tapahtuu helposti Task Managerin kautta. Tällaisen tekoälyavusteisen työkalun merkitys korostuu siinä, että kehittäjille jää vähemmän manuaalista työtä. Useiden erilaisten laiteselainja alustayhdistelmien sekä erilaisten resoluutioiden testaaminen käy tekoälyltä vaivatta. Visual AI osaa suodattaa merkityksettömät erot oikeista virheistä, tehdä alustariippumattomia vertailuja, huomioida käyttöliittymän mukautumisen erikokoisille näytöille ja ohittaa dynaamisen sisällön aiheuttamat virheet. Tällä tavalla testauksen tarkkuus paranee, testisyklien läpimeno nopeutuu ja voidaan testata yhä suurempia määriä käyttöliittymäkomponentteja samalla ajolla. (Applitools 2024) Markkinoilla on runsaasti myös muita tekoälyyn ja koneoppimiseen perustuvia testaustyökaluja, kuten LambdaTest, Functionize, Testim.io ja Percy sekä lukuisia muita. Ne käyttävät tekoälyä testausprosessin eri vaiheissa testien kirjoittamisesta prosessin automatisointiin. Tätä tutkimusta varten tehty 18 kaupalliseen verkkosivustoon perustuva katsaus kuitenkin nosti Applitools:in useimmin kolmen kärkeen, kun analysoitiin 70 erilaista visuaalisen testauksen työkalua niistä tehtyjen paremmuusvertailujen avulla. Työkaluja ilmestyy markkinoille koko ajan ja käytetyn tekoälyn osuus kasvaa myös visuaalisen testauksen saralla. 4.5.2 Työkalujen vertailua ja tyylinvalvojana käytettävän testausympäristön valinta Työkalujen vertailua varten luodaan uusi React Vite-sovellus, jossa on yksinkertainen profiilitietoja tallentava käyttöliittymäsivu sisältäen lomakkeen syötekenttineen ja tallennuspainikkeineen. Kaikki kolme testaustyökalua asennetaan ja konfiguroidaan tarkoitusta varten tähän sovellukseen, jotta vertailu voidaan suorittaa samanlaisella sisällöllä. Konfigurointi on haastavinta Cypress:issä, Playwright:issa asennus ja käyttöönotto sujuu helpoiten. Luodaan kullakin työkalulla kaksi testiä, toinen, joka tarkistaa kokonaisen verkkosivun ja toinen, joka tutkii yksittäisen painike-komponentin. Testien syntaksi on hyvin samanlainen kaikissa työkaluissa. Koska Vitest käyttää Puppeteer-kirjastoa apuna, on siinä sen vuoksi muutama 62 koodirivi enemmän. Lisäksi snapshotille on Vitest:issa annettava tarkempia parametreja, kuin muiden työkalujen tapauksessa. Koko sivun testissä navigoidaan ensin halutulle verkkosivulle ja otetaan sivusta kuvakaappaus. Alla olevissa koodilohkoissa 16, 17 ja 18 esitetään kullakin työkalulla kirjoitetut testitapaukset. it(’profile’, async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto(’http://localhost:5173/profile’); const imageBuffer = await page.screenshot({ type: ’png’, encoding: ’base64’, fullPage: true }); expect(Buffer.from(imageBuffer, ’base64’)) .toMatchImageSnapshot(); }); Koodilohko 16. Vitest-syntaksi, koko sivun testi. test("profile visual test", async ({ page }) => { await page.goto("http://localhost:5173/profile"); expect(await page.screenshot()) .toMatchSnapshot("profile.png"); }); Koodilohko 17. Plawright-syntaksi, koko sivun testi. it("should match the profile snapshot", () => { cy.visit("/profile"); cy.matchImageSnapshot("profile"); }); Koodilohko 18. Cypress-syntaksi, koko sivun testi. Testatessa yksittäistä komponenttia, hakeudutaan ensin halutulle verkkosivulle, etsitään sieltä testattava html-elementti, josta kuvakaappaus otetaan. Elementtiä voidaan html-tagin lisäksi etsiä myös luokan tai id:n perusteella. Alla olevissa koodilohkoissa 19, 20 ja 21 esitetään syntaksi eri työkaluilla. 63 it(’profilebutton’, async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto(’http://localhost:5173/profile’); const buttonComponent = await page.$(’button’); if (buttonComponent) { const image = await buttonComponent.screenshot({ type: ’png’, encoding: ’base64’ }); expect(Buffer.from(image, ’base64’)) .toMatchImageSnapshot(); } else { throw new Error("Button not found on the page."); } await browser.close(); }); Koodilohko 19. Vitest-syntaksi, komponentin testi. test("profile button component", async ({ page }) => { await page.goto("http://localhost:5173/profile"); const buttonComponent = await page.locator("button"); await expect(buttonComponent) .toHaveScreenshot("profileButton.png"); }); Koodilohko 20. Plawright-syntaksi, komponentin testi. it("should match the button snapshot", () => { cy.visit("/profile"); cy.get("button") .matchImageSnapshot("profilebutton-snapshot"); }); Koodilohko 21. Cypress-syntaksi, komponentin testi. Cypress DevTools -käyttöliittymä on informatiivinen, testien ajo sujuu näppärästi sitä kautta. Muissa työkaluissa ei sellaista ole, vaan testien ajo tapahtuu komentoriviltä. Ensimmäisellä testiajolla kukin ohjelma tallentaa referenssikuvan profiilisivusta ja sillä olevasta painikkees64 ta. Tehdään käyttöliittymään ulkoasuun vaikuttavia muutoksia: kasvatetaan painikkeen kokoa, muutetaan sen tekstiä ja lisätään lomakkeen valintaruutuun tekstiä. Tämän jälkeen testit ajetaan uudelleen. Odotetusti testit epäonnistuvat. Poikkeamakuvat tallentuvat kaikkien ohjelmistojen tapauksessa omaan erilliseen kansioonsa, josta ne ovat helposti löydettävissä. Vitest ja Cypress esittävät poikkeamat kolmen kuvan sarjana, kun Playwright:issa kuvat tallentuvat erillisinä tiedostoina. Kolmen kuvan sarjasta poikkeamat löytyvät helpommin, kun kaikkia kuvia voi katsella samanaikaisesti. Testien tarkkuudessa on eroja. Vitest:in ja Playwright:in ilmoittamat virheet olivat todellisten muutosten aiheuttamia, kun Cypress ilmoitti lisäksi virheistä, jotka eivät olleet todellisia. Kaikissa ohjelmistoissa on mahdollista määritellä toleranssi, jota testiajoissa sovelletaan. Vitest:in poikkeamakuvat profiilisivulle ja painikkeelle on esitetty kuvioissa 17 ja 18. Kuvio 17. Vitest, koko sivun testi. Kuvio 18. Vitest, komponentin testi. Vitest:issä vasemmalle tulostuu referenssikuva, oikealle todellinen kuva ja keskellä näkyvät korostettuna virheet näiden välillä. Testi odotetusti korostaa painikkeen muuttuneen korkeuden, painikkeessa olevan tekstin ja valintaruutuun lisätyn tekstin. Playwright tallensi seuraavanlaiset kolme erillistä kuvaa epäonnistuneiden testien pohjalta (kuviot 19 ja 20). Vasemmalla on todellinen kuva, oikealla referenssikuva ja keskellä näkyvät virheet. Tulos on hyvin samanlainen kuin Vitest:illä. 65 vain 4 pikselin ero korkeudessa. Sallimalla kuvan kokoerot, saataisiin selville tärkeämpää tietoa pikselipoikkeamista. Responsiivinen asettelu voidaan kuitenkin tarkastaa kuviosta 26. Kuvio 26. Koko testisivun tablet-näkymän poikkeamakuva (T3). T4. existence & appearance of a primary button Error: Expected image to be the same size as the snapshot (92x40), but was different (124x64). Painikkeelle annettu täyte näkyy selkeästi kuviossa 27. Painikkeen koko ja tekstin paikka muuttuu. Kuvio 27. Primääripainikkeen ulkoasutestin (T4) poikkeamakuva. T7. existence & appearance of a primary color box Error: Expected image to be the same size as the snapshot (166x130), but was different (166x195). Elementin muuttunut koko nähdään selkeästi myös kuviosta 28. Tähän testiin voisi yhdistää myös komponentin värin tarkastuksen ilman kuvakaappausta, kuten testissä T12. Snapshot-testi paljastaisi muuttuneen värin kuitenkin myös, mutta erillinen väritesti antaisi lisäinformaatiota. 72 Kuvio 28. Primäärivärilaatikon ulkoasutestin (T7) poikkeamakuva. T8. testpage after hovering the tooltip Error: Expected image to be the same size as the snapshot (1200x1300), but was different (1200x1312). Testin tulos on esitetty kuviossa 29. Animaatioiden osalta kannattaa testiin lisätä ajastin tai jollain muulla tavalla varmistaa, että animaatio on valmis kuvaa otettaessa. Luonnollisesti sivulla olevat muutkin virheet näkyvät kuvassa, tarkoituksenmukaisempaa olisi tarkastella komponenttia erillään. Kuvio 29. Infolaatikon hover-testin (T8) poikkeamakuva. T9. modal component after clicking a modal button Error: Expected image to be the same size as the snapshot (448x247), but was different (446x247). Dialogille tehty sijainnin muutos ei paljastu poikkeamakuvassa (kuvio 30), koska testin kohteena on pelkkä komponentti. Kuvaan piirtyy sen sijaan paljon ylimääräistä. Ensimmäisen painikkeen tekstin muutos valitettavasti hukkuu kohinaan. 73 Kuvio 30. Dialogitestin (T9) poikkeamakuva. T10. testpage after clicking a popover button Error: Expected image to be the same size as the snapshot (1200x1300), but was different (1200x1312). Ponnahdusikkunatestin lisäarvo visuaalisen testauksen kannalta on vähäinen, koska testataan jälleen koko sivua, kuten kuviosta 31 nähdään. Toiminnallisuuden osalta voidaan kuitenkin todeta, että ikkuna on avautunut painikkeen painalluksen myötä. Jos muita virheitä ei sivulla olisi, tulos olisi huomattavasti käyttökelpoisempi. Kuvio 31. Ponnahdusikkunatestin (T10) poikkeamakuva. T13. text of the heading AssertionError: expected ’Tyylioppaan testisivu’ to be ’Tyylioppaan testisivu’. Ilman kuvakaappausta toteutetut testit kertovat virheestä sanallisesti. Virheviesti on informatiivinen ja sen avulla päästään virheeseen helposti käsiksi. Korjataan tehdyt muutokset takaisin alkuasetelmaan ja ajetaan testit uudelleen. Nyt kaikkien testien odotetaan onnistuvan. Kuitenkin kolme tapahtumia sisältävää testiä epäonnistuu edelleen (testit T8, T9 ja T10). 74 T8. testpage after hovering the tooltip Error: Expected image to match or be a close match to snapshot but was 0.4953846153846154% different from snapshot (7728 differing pixels). Nyt Vitest raportoi vajaan puolen prosentin pikselipoikkeamasta. Komponentissa ei pitäisi enää olla virhettä, mutta kuviossa 32 kuitenkin korostuu virhe komponentin hover-tilassa. Kuvio 32. Infolaatikon hover-testin (T8) toinen poikkeamakuva. T9. modal component after clicking a modal button Error: Expected image to be the same size as the snapshot (448x247), but was different (446x246). Samoin dialogin osalta raportoidaan edelleen poikkeamasta, jota ei pitäisi enää olla (kuvio 33). Kuvio 33. Dialogitestin (T9) toinen poikkeamakuva. T10. testpage after clicking a popover button Error: Expected image to match or be a close match to snapshot but was 0.008397435897435% different from snapshot (131 differing pixels) Ponnahdusikkunan tapauksessa virhe on niin pieni, että se on tuskin havaittavissa (kuvio 34). 75 Kuvio 34. Ponnahdusikkunatestin (T10) toinen poikkeamakuva. Toisen testiajon kuvista päätellen poikkeamat ovat vääriä hälytyksiä. Virheraportista nähdään myös erojen olevan hyvin pieniä. Kasvatetaan näiden testien osalta virhemarginaalia ja ajetaan testit uudelleen. Modal-komponentin testi (T9) epäonnistuu edelleen, muut menevät läpi. Epäonnistuneen testin poikkeamakuvasta (kuvio 35) kuitenkin nähdään, ettei kyse ole todellisesta virheestä. Kuvio 35. Dialogitestin (T9) kolmas poikkeamakuva. 4.5.5 Työkalun soveltuvuus tyylinvalvojaksi Vitest, jest-image-snapshot:in ja Puppeteer-kirjaston avustuksella voisi toimia käyttöliittymäkomponenttien visuaalisessa regressiotestauksessa, mutta kohdeorganisaation tapauksessa jatkotutkimusta vaaditaan. Epäjohdonmukaiset väärät hälytykset ja vajavainen raportointi vaikuttavat testien luotettavuuteen. Testien syntaksi on kuitenkin selkeää ja esimerkkejä löytyy dokumentaatiosta. Vaikka suurin osa virheistä jää kiinni kokonaisten sivujen kuvissa, on komponentteja kuitenkin syytä tarkastella myös erikseen. Tällöin poikkeamat tulevat selkeämmin esiin ja testiajoja voidaan täsmentää ongelmakohtiin. Tätä tutkimusta varten tehty simulaatio on toki keinotekoinen, koska virheet ovat ennalta tie76 dossa. Väärien virheiden erottaminen todellisista virheistä saattaa ainakin aluksi tuntua työläältä. Toleranssin kasvattaminen testikohtaisesti voi auttaa, kun opitaan tunnistamaan virheet, jotka ovat ihmissilmälläkin havaittavissa. Tekoälypohjaiset ratkaisut vastaavat juuri tähän ongelmaan ja osaavat erotella merkitykselliset visuaaliset erot pienistä renderöintieroista. Vitest soveltuu myös toiminnalliseen testaukseen ja onkin siltä osin jo kohdeorganisaation käytössä. Se on myös integroitavissa yleisesti käytettyihin CI/CD-työkaluihin. Visualisen testaustyökalun tehokkuus ja suorituskyky jatkuvan ohjelmistokehityksen putkessa on kuitenkin arvioitava erikseen. 77 5 Artefaktin evaluointi ja tulokset iteraatioittain Suunnittelusyklien iteraatioiden päätteeksi suoritetaan artefaktin evaluointi. Tässä luvussa esitellään arvioinnin tulokset ja niiden perusteella suoritettavat jatkotoimenpiteet. 5.1 Tyyliopas, ensimmäisen evaluoinnin tulokset Alla kuvataan ensimmäisen evaluoinnin tuloksia laatuvaatimusten täyttymisen ja tyylioppaan lähdekoodin osalta. Tyylioppaalle asetettiin seuraavat laatuvaatimukset: toiminnallisuus, käytettävyys, tehokkuus ja ylläpidettävyys. Toiminnallisuudella tarkoitetaan sitä, että tyyliopas soveltuu käyttöön, johon se on tarkoitettu ja hoitaa sille määritellyt toimenpiteet. Käytettävyys puolestaan tarkoittaa tyylioppaan helppokäyttöisyyttä, eli sitä, että se on riittävän intuitiivinen ja opittava, tehokas ja yksinkertainen käyttää. Tehokkuus tarkoittaa, että tyyliopas ei hukkaa käyttäjänsä aikaa tai järjestelmän resursseja ja toimii tehokkaasti siinä tarkoituksessa, johon se on luotu. Ylläpidettävyys liittyy tyylioppaan elinkaareen ja siihen, ettei se ole kertaluontoinen projekti vaan elää sovelluksen mukana ja pysyy ajan tasalla. Näitä asioita tarkastellaan tyylioppaan toteutusta evaluoitaessa, vaatimusmäärittely mielessä pitäen. Arvioinnin suorittaa kohdeorganisaation ohjaaja. Ensimmäisen evaluoinnin pohjalta toteutetaan toinen iteraatio tyylioppaan kehityksestä, jossa alla mainitut asiat pyritään korjaamaan. Iteraation päätteeksi tyyliopas ja sen lähdekoodi arvioidaan uudelleen. 5.1.1 Laatuvaatimusten täyttyminen Toiminnallisuuden osalta arvioija pitää tyyliopasta selkeänä, uskoo käyttäjän saavan nopeasti yleiskuvan siitä, mitä on tarjolla ja tuovan käyttöliittymäkehittäjien työhön selkeyttä. Organisaatiotasoisten komponenttien valmiiksi rajoitetun spesifioinnin uskotaan helpottavan kaikkien työtä. Jatkotoimenpiteitä aiheuttavat ensimmäisen evaluoinnin perusteella muutamat seikat. Tyylioppaan olisi hyvä olla näkyvillä myös kirjautumattomille käyttäjille. Ensimmäisessä tyylioppaan versiossa esitellään myös joitakin ei-spesifejä komponentteja, kuten Input, joiden tarpeellisuus jää vähäiseksi. Jotta kokonaisuus olisi tiivis, nämä on syytä poistaa. Lisäksi ensimmäisen version lomakekomponentti, vaikkakin toimii yksinkertaisen lomakkeen luontiin, vaatii muokkausta. Käyttökelpoisempi olisi skeemapohjainen lomakegeneraattori, jossa myös sarakkeiden 78 käyttäminen olisi mahdollista. Arvioija mainitsee lyhyesti myös testauksesta, jossa tyylioppaan esimerkkisivun mallia vastaan voitaisiin testata komponenteissa tehtyjä muutoksia. Kyseessä olisi näin ollen visuaalinen regressiotestaus snapshot-tekniikalla. Väripalettiin ja sen käyttöönoton vaikutuksiin on palattava seuraavissa vaiheissa. Ajatuksena on, että Sierra-teemassa määritellään sovelluksen perusvärit käyttäen tyylioppaan jaottelua (primary, secondary jne), jotka voidaan ylikirjoittaa asiakaskohtaisesti teematiedostossa (customTheme). Näiden väripalettien käyttöönotto vaatii merkittäviä muutoksia komponenttikirjaston nykyisessä rakenteessa ja herättää keskustelua uuden, organisaation brändiin perustuvan demosovelluksen luomisesta. Kuviossa 36 on esitetty evaluoinnin tulokset toiminnallisuuden osalta, sekä vaadittavat jatkotoimenpiteet ja toteutus. Kuvio 36. Evaluointi I, toiminnallisuus: huomiot ja jatkotoimenpiteet Käytettävyydestä projektin tässä vaiheessa mainitaan vain, että tyyliopas on selkeä käyttää. Ohjaaja mainitsee dokumentaation löydettävyyden kuitenkin kärsivän tyyliohjeen ollessa pelkästään Github-repositoriossa. Julkaisua ulkoverkkoon voidaan harkita, jolloin tulee arvioida uudestaan myös Webscraper-komponentin käyttö ja alkuperäiset tekijänoikeudet. Tyylioppaan komponenttien esittelyistä puuttuvat koodiesimerkit. Nämä ovat edellytyksenä tyylioppaan käytettävyydelle. Kuviossa 37 on esitetty evaluoinnin tulokset käytettävyyden osalta, sekä vaadittavat jatkotoimenpiteet ja toteutus. 79 Kuvio 37. Evaluointi I, käytettävyys: huomiot ja jatkotoimenpiteet Tehokkuudesta arvioija mainitsee, että kokonaisuus on nopeasti selattavissa ja haettava tieto on helppo löytää. Sivujen jakaminen kehittäjien välillä on mahdollista, koska sovelluksen reitit kulkevat osoiterivillä. Lisäksi arvioija esittää toiveen tyylioppaan sisällön indeksoinnista ja hakutoiminnosta, kun ominaisuuksien määrä kasvaa. Kuviossa 38 on esitetty evaluoinnin tulokset tehokkuuden osalta, sekä vaadittavat jatkotoimenpiteet ja toteutus. Kuvio 38. Evaluointi I, tehokkuus: huomiot ja jatkotoimenpiteet Tyylioppaan ylläpidon arvioija uskoo olevan helppoa, koska kaikki sisältö löytyy saman repositorion sisältä. Hän huomioi kuitenkin ylläpidon olevan manuaalista, johon helpotusta voisi tuoda esimerkiksi automaattinen koodin generointi lähdekoodin perusteella. Kun tyylioppaaseen lisätään komponentteja, niiden esitys ja dokumentaatio on luotava manuaalisesti. Evaluoinnin tuloksia läpikäydessä keskustellaan siitä, mikä tämän ominaisuuden merkitys on. Vaikkei tyyliopasta voitaisi pitää ajan tasalla päivittäin, ajoitettaisi säännöllisesti tyylikomponenttien ja oppaan tarkistus, jolloin kerralla päivitettäisiin vastaamaan toisiaan. Samalla tehtäisiin muutoksia jo olemassa oleviin tyylioppaan sivuihin, mikäli komponentteihin on tehty muutoksia. Kuviossa 39 on esitetty evaluoinnin tulokset ylläpidon osalta, sekä vaadittavat jatkotoimenpiteet ja toteutus. 80 Kuvio 39. Evaluointi I, ylläpito: huomiot ja jatkotoimenpiteet 5.1.2 Lähdekoodin evaluointi Myös tyylioppaan komponenttien lähdekoodi arvioidaan. Osa arvioiduista tiedostoista sisältää tyylioppaan esitykseen liittyvää koodia, mutta valtaosa arvioista kohdistuu kuitenkin organisaatiospesifeihin komponentteihin. Templaattien osalta arvioija ehdottaa oletusvälistyksen määrittelemistä, jolloin komponenttia kutsuttaessa ei välttämättä tarvitsisi antaa välistysarvoa. Herätteestä arvioija mainitsee, ettei status-parametria tarvitsisi erikseen määritellä, koska se kuuluu Chakra UI:n parametreihin. Näin ollen spesifi status-parametri ei anna mitään lisäarvoa. Lisäksi arvioija ehdottaa tyypin RequireAtLeastOne käyttämistä otsikon ja kuvauksen osalta. On kuulemma tavallista, että joissain yhteyksissä käytetään vain toista, jolloin joko otsikko tai kuvaus annetaan. BrandTablen value-ominaisuuteen on jäänyt tyypiksi any, mikä saattaa aiheuttaa ongelmia. Tämä on syytä korjata vastaamaan sallittuja tyyppejä. Lomakekomponentista arvioija kehottaa tekemään skeemapohjaisen version, kuten toiminnallisuuden arvioinnissa mainitaan. Taulukon osalta avaintietona käytetty indeksi saattaa myös aiheuttaa ongelmia. Arvioija ehdottaa kentän nimen käyttämistä avaimena indeksin sijaan. Tyylioppaan esityssivuilla on jonkin verran toistoa, josta on pyrittävä eroon. Samoin kehitysvaiheessa asennetut riippuvuudet, jotka eivät tässä versiossa ole enää käytössä, on syytä poistaa. Esityksessä olevien esimerkkitaulukoiden testidata olisi hyvä muuntaa JSON-muotoon ja siirtää omaan kansioonsa. Näin samaa dataa voitaisiin käyttää myös sovellusta testatessa. Tyylitiedoston osalta toivotaan jaettujen ominaisuuksien määrittelemistä ainoastaan yhdessä paikassa, jolloin niiden ylläpito helpottuu. 5.2 Tyyliopas, toisen evaluoinnin tulokset Toinen evaluointi on luonnollisesti ensimmäistä kevyempi, koska arvioidaan pääasiassa ensimmäisen evaluoinnin perusteella tehtyjä muutoksia. Laatuvaatimusten osalta merkittävimpiä muutoksia ovat seuraavat: 81 jotka toimivat paitsi itsekseen myös hyvänä lisänä snapshot-testaukselle. Tekoälyyn perustuva testaus vähentää merkittävästi manuaalista työtä, jota snapshot-testeihin ainakin aluksi liittyy. Kun opitaan ymmärtämään syyt pikselivertailun aiheuttamille väärille virheille ja määrittelemään oikeanlaiset toleranssit, voi snapshot-testauksestakin olla valtava hyöty. Tämän tutkimuksen yhtenä haasteena oli komponenttikirjaston laajuus ja monimutkaiset keskenään vuorovaikuttavat komponentit. Tutkimussuunnitelmasta jouduttiin tämän vuoksi paikoitellen poikkeamaan. Haasteena oli myös jatkuvasti muuttuva ympäristö kirjaston ollessa käytössä ja kehittyessä koko ajan. Pelkästään nykytilan kartoituksen ja kirjaston rekonstruktion välillä oli uusia komponentteja ilmestynyt runsaasti. Tyylien osalta pohdintaa aiheutti se tosiasia, että Playground-ympäristö on vain kehittäjille tarkoitettu työkalu. Varsinaiset asiakastoteutukset ovat lähes poikkeuksetta räätälöityjä asiakkaan oman tyylin mukaan. Tämä aiheutti hämmennystä etenkin värimaailman suunnittelussa. Tärkeämpää oli luoda värikooditus ja tekninen toteutus sille, että räätälöinti olisi jatkossa helppoa ja tehokasta. Voisi kuitenkin olla järkevää pohtia Playground:in hyödyntämistä demoympäristönä myyntitilanteissa. Tällöin kohdeorganisaation omaan brändiin perustuvalla yhtenäisellä ulkoasulla voisi olla kaupallista merkitystä. Tyylioppaan käyttöönotto vaatii kirjaston rakenteen merkittävää uudelleenjärjestelyä ja yhden universaalin mallin yhteensovittaminen kaikkiin olemassa oleviin käyttötarkoituksiin tuntuu lähes mahdottomalta. Työ kannattaakin aloittaa uusista komponenteista ja pikkuhiljaa siirtyä rekonstruoimaan muita komponentteja. Tässä tutkimuksessa toteutettiin aihio, jota seuraamalla tavoitetilaan on mahdollista päästä. Pohdittavaa jäi siis paljonkin ja jatkotutkimuksellekin on sijaa. Komponenttikirjaston vahva Chakra UI -riippuvuus on olemassa. Vaikuttaako hetki sitten julkaistu uusi versio 3.0 kirjaston komponenttien tai tyylioppaan esityksen toimintaan? Tutkimuksen alussa puhuttiin mahdollisuudesta rajata tämä riippuvuus organisaatiospesifeihin komponentteihin, jolloin tarvittaessa riippuvuus olisi helppo purkaa. Tämä kuitenkin vaatisi huomattavasti laajemman määrän spesifejä komponentteja, joiden rakentamiseen ei tämän tutkimuksen puitteissa ollut mahdollisuutta. Tyylinvalvojan osalta olisi hyödyllistä tutkia tekoälypohjaisia ratkaisuja tarkemmin. Löytyisikö sieltä malli, joka suodattaisi riittävän määrän vääriä virheitä ja toimisi tehokkaasti CI/CDputkessa? Tutkimuksessa esitellyn mallin osalta huolta aiheuttaa testien luotettavuus ja tarvittavan manuaalisen työn määrä. Työkalu antaa kuitenkin kohdeorganisaatiolle mallin, jota edel88 leen kehittämällä voidaan päästä haluttuun lopputulokseen. Tutkimus lisäsi runsaasti uutta informaatiota siitä, kuinka olemassa olevia epäkohtia korjaamalla päästään tavoitetilaan. Se tarjoaa hyvän pohjan käyttöliittymäkehityksen yksinkertaistamiselle ja tehostamiselle kohti yhtenäistä, laadukasta ja harmonista tuoteperhettä. 89 Lähteet Adebayo, Segun. 2024. “Chakra UI Documentation”. Viitattu 19. marraskuuta 2024. https: //chakra-ui.com. Applitools. 2024. “Applitools Documentation”. Viitattu 16. marraskuuta 2024. https://applitoo ls.com/. Battat, Michael. 2024. “What is Visual Testing?” Viitattu 16. helmikuuta 2024. https://applito ols.com/blog/visual-testing/. Coleman, Tom. 2017. “Component-Driven Development: Build UIs in a better way: from the component up”. Viitattu 12. helmikuuta 2024. https://medium.com/@tmeasday/componentdriven-development-ce1109d56c8e. ComponentDriven. n.d. “Component Driven User Interfaces”. Viitattu 12. helmikuuta 2024. https://www.componentdriven.org. Cypress.io. 2024. “Cypress Documentation”. Viitattu 15. marraskuuta 2024. https://docs.cypre ss.io. Delong, Sara. 2020. “Why You Need to Create a Data Visualization Style Guide to Tell Great Stories (Part 1)”. Viitattu 14. helmikuuta 2024. https://depictdatastudio.com/why-you-needto-create-a-data-visualization-style-guide-to-tell-great-stories/. Feather, Ian. 2014. “A Maintainable Style Guide”. Viitattu 15. helmikuuta 2024. https://engine ering.lonelyplanet.com/2014/05/18/a-maintainable-styleguide.html. Fessenden, Therese. 2021. “Design Systems 101”. Viitattu 13. helmikuuta 2024. https://www. nngroup.com/articles/design-systems-101/. Foundation, GraphQL. 2024. “GraphQL Documentation”. Viitattu 19. marraskuuta 2024. https: //graphql.org. Friedman, Vitaly. 2016. “Taking The Pattern Library To The Next Level”. Viitattu 13. helmikuuta 2024. https://www.smashingmagazine.com/2016/10/taking-pattern-libraries-next-level/. Frost, Brad. 2016. Atomic Design. Pittsburgh, PA. Viitattu 14. helmikuuta 2024. https://atomic design.bradfrost.com/table-of-contents/. 90 HEAVY.AI. 2024. “Graphical User Interface (GUI)”. Viitattu 18. marraskuuta 2024. https: //www.heavy.ai/technical-glossary/graphical-user-interface. Hevner, Alan R. 2007. “A Three Cycle View of Design Science Research”. Scandinavian Journal of Information Systems 19 (2): 87–92. Viitattu 7. helmikuuta 2024. http://aisel.aisnet.org/ sjis/vol19/iss2/4. Hevner, Alan R., Salvatore T. March, Jinsoo Park ja Sudha Ram. 2004. “Design Science in Information Systems Research”. MIS Quarterly 28 (1): 75–105. https://doi.org/10.2307/ 25148625. HubSpot. 2024. “What is a GUI?” Viitattu 18. marraskuuta 2024. https://blog.hubspot.com/ website/what-is-gui. Kalia, Anshul ja Sumesh Sood. 2017. “Concerns in Maintaining Reusable Software Components and the Possible Solutions”. Indian Journal of Science and Technology 10 (23): 1–10. https://doi.org/10.17485/ijst/2017/v10i23/108703. Kholmatova, Alla. 2017. Design Systems. Freiburg, Germany: Smashing Media AG. Viitattu 15. helmikuuta 2024. https://www.smashingmagazine.com/provide/eBooks/design-systems. pdf. Lynch, Patrick J. ja Sarah Horton. 2016. Web Style Guide, 4th Edition: Foundations of User Experience Design. 4. painos. London, UK: Yale University Press. March, Salvatore T. ja Gerald F. Smith. 1995. “Design and natural science research on information technology”. Decision Support Systems 15 (4): 251–266. https://doi.org/10.1016/01679236(94)00041-2. Meta. 2024. “React Documentation”. Viitattu 19. marraskuuta 2024. https:/react.dev. Microsoft. 2024a. “Playwright Documentation”. Viitattu 15. marraskuuta 2024. https://playwr ight.dev. . 2024b. “TypeScript Documentation”. Viitattu 19. marraskuuta 2024. https://www. typescriptlang.org. Neville, Kat. 2010. “How To Design Style Guides For Brands And Websites”. Viitattu 14. helmikuuta 2024. https://www.smashingmagazine.com/2010/07/designing-style-guidelines-forbrands-and-websites/. 91 OpenJSFoundation. 2024. “Node.js Documentation”. Viitattu 19. marraskuuta 2024. https:// nodejs.org. Osmani, Addy. n.d. “Components Should Be Focused, Independent, Reusable, Small and Testable (FIRST)”. Viitattu 12. helmikuuta 2024. https://addyosmani.com/first/. Pandey, Sakshi. 2022. “How AI in Visual Testing is transforming the Testing Landscape”. Viitattu 16. helmikuuta 2024. https://www.browserstack.com/guide/how-ai-in-visual-testingis-evolving. Peffers, Ken, Tuure Tuunanen, Marcus A. Rothenberger ja Samir Chatterjee. 2007. “A Design Science Research Methodology for Information Systems Research”. Journal of Management Information Systems 24 (3): 45–77. https://doi.org/10.2753/MIS0742-1222240302. Qureshi, M.R.J. ja S.A. Hussain. 2008. “A reusable software component-based development process model”. Advances in Engineering Software 39 (2): 88–94. Viitattu 12. helmikuuta 2024. https://www.sciencedirect.com/science/article/abs/pii/S0965997807000294. Saring, Jonathan. 2019. “A Guide to Component Driven Development (CDD): Let components drive the development of your applications.” Viitattu 12. helmikuuta 2024. https://itnext.io/aguide-to-component-driven-development-cdd-1516f65d8b55. Software Testing Help. 2023. “Guide To Visual Regression Testing With Visual Testing Tools”. Viitattu 15. helmikuuta 2024. https://www.softwaretestinghelp.com/visual-validation-testing/. Storybook. 2024. “Storybook Documentation”. Viitattu 19. marraskuuta 2024. https://storyboo k.js.org. UPXin. 2023. “What is a Component Library, and Why Should You Use One for UI Development?” Viitattu 13. helmikuuta 2024. https://www.uxpin.com/studio/blog/ui-componentlibrary/. Vale, Tassio, Ivica Crnkovic, Eduardo Santana de Almeida, Paulo Anselmo da Mota Silveira Neto, Yguaratã Cerqueira Cavalcanti ja Silvio Romero de Lemos Meira. 2016. “Twenty-eight years of component-based software engineering”. Journal of Systems and Software 111:128– 148. https://doi.org/https://doi.org/10.1016/j.jss.2015.09.019. 92 Volk, Torsten. 2021. “September 2021 EMA Research Report: Disrupting the Economics of Software Testing Through AI”. Viitattu 15. helmikuuta 2024. https://ewig5qf9cgn.exactdn. com/wp-content/uploads/2021/09/EMA-Applitools-DisruptingTestingEconomics-092121. pdf. Xu, David. 2022. “Everything you need to know about Visual Regression Testing in 2022”. Viitattu 15. helmikuuta 2024. https://david-x.medium.com/the-state-of-visual-regressiontesting-in-2022-5de10ffe8f6f. You, Evan. 2024a. “Vite Documentation”. Viitattu 19. marraskuuta 2024. https://vitejs.dev. . 2024b. “Vitest Documentation”. Viitattu 15. marraskuuta 2024. https://vitest.dev. 93