Mikko Tapionlinna
KOMPONENTTIKIRJASTO VERKKOSIVUJEN SUUNNITTELUUN
Tarkastajat: Professori Joni Kämäräinen DI Juhani Mönkkönen Ohjaaja: Tekn. yo. Mikko Heilimo
Lappeenrannan teknillinen yliopisto Teknillistaloudellinen tiedekunta Tietotekniikan osasto
Mikko Tapionlinna
Komponenttikirjasto verkkosivujen suunnitteluun
Diplomityö 2010
46 sivua, 9 kuvaa, 4 taulukkoa ja 2 liitettä Tarkastajat: Professori Joni Kämäräinen
DI Juhani Mönkkönen
Hakusanat: HTML, HTML-elementti, Komponentti, Kirjasto, Suunnittelu
Tärkeänä osana Internet-sivujen toteutusta on niiden huolellinen suunnittelu.
Käyttöliittymäsuunnittelun työvälineinä Internet-sivujen toteuttamisessa käytetään apuna hahmotelmia ja erilaisia prototyyppejä. Näiden avulla sivuston suunnitelmaa selkeytetään yhteistyössä asiakkaan ja tulevien käyttäjien kanssa.
Tässä diplomityössä toteutetaan komponenttikirjasto verkkosivujen suunnitteluun Uoma Oy nimiselle yritykselle. Kirjastoon tulevia komponentteja kartoitetaan analysoimalla toteutettuja projekteja. Työssä myös selvitetään komponenttien laatukriteerit ja toteutetaan kirjaston komponentit. Kirjaston laatua ja tehokkuutta arvioidaan toteuttamalla mallisivusto.
Työ osoittaa, että käyttämällä kirjastoa saadaan sekä laadullista hyötyä että parannetaan tehokkuutta, verrattuna yrityksessä aiemmin käytettyyn tapaan työskennellä. Kirjastoa voidaan käyttää monipuolisesti eri suunnitteluvaiheiden tarpeisiin.
Lappeenranta University of Technology Faculty of Technology Management Department of Information Technology
Mikko Tapionlinna
Component library for designing Web pages
Master’s Thesis 2010
46 pages, 9 figures, 4 tables and 2 appendices Examiners: Professor Joni Kämäräinen
M.Sc. Juhani Mönkkönen
Keywords: HTML, HTML-element, Component, Library, Design
Careful planning is an important part of creating Internet-pages. Various prototypes and sketches are used in user interface design of Web sites. Prototypes and sketches help clarifying site design together with the customer.
In this master’s thesis a component library for designing web pages is built for Uoma Oy company. The components are selected by analyzing previously done Web-site projects. Also the quality requirements for the components are assessed and components implemented. Quality and efficiency of the library is evaluated by creating a sample site.
This thesis shows that by using this library, quality and efficiency of the work are improved as compared to the currently used methods. The library can be used in many stages of the planning work.
Diplomityön toteuttaminen on ollut ajatuksissa opiskelujeni alkuajoista asti. Tätä kyseistä ideaa kypsyttelin liki kaksi vuotta muiden töiden ohessa, kunnes motivaatio ja mahdollisuus työn toteuttamiseen löytyivät. Työn ja valmistumisen jälkeen en usko palaavani koulumaailmaan opiskelijana, vaan opin ja kehityn vapaammin omalla ajalla joka päivä. Yliopiston tärkeimpänä oppina pidän uuden tiedon etsimisen ja löytämisen taitoa. Maailma muuttuu ympärillä, mutta utelias mieli löytää vastaukset.
Haluan kiittää kaikkia ystäviäni, jotka ovat tukeneet työn toteuttamisen aikana. Saamani tuki ja hyvät ohjeet ovat auttaneet jaksamaan työn tekemistä intensiivisellä aikataululla.
Erityisesti haluan kiittää Seppoa, Askoa ja Pukkia kannustamisesta ja tuesta. Töissä toimineet työkaverit auttoivat omalla osallaan työn priorisoinnissa ja ohjeillaan. Kiitos siitä, erityisesti Heilimolle ja Mönkköselle.
Kiitokset kuuluvat myös professori Joni Kämäräiselle ohjeista ja tuesta diplomityön toteuttamisessa. Asioiden tärkeysjärjestyksen säilyttäminen mielessä, vaikka aikataulut kaatuisivat niskaan, on arvokas taito.
Kiitän vanhempiani siitä tuesta ja kannustuksesta, jota olen elämäni varrella ja opiskelussa saanut. Viimeisenä haluaisin kiittää sateista kevätsäätä, sillä kaatosateella oli vaikeampi keksiä tekosyitä karata työn ääreltä ulos.
Helsingissä 13.5.2010 Mikko Tapionlinna
SISÄLLYSLUETTELO
1 JOHDANTO ... 4
1.1 Tausta ... 4
1.2 Tavoitteet ja rajaukset ... 10
1.3 Työn rakenne ... 11
2 VERKKOSIVUJEN SUUNNITTELU ... 12
2.1 Johdanto ... 12
2.2 Käyttöliittymäsuunnittelu ... 13
2.2.1 Käyttöliittymäsuunnittelun ohjeet ... 14
2.2.2 Vuorovaikutusmallit ... 15
2.2.3 Prototyypit ... 16
2.2.4 Paperiprototyypit ... 16
2.2.5 Rautalankamallit ... 18
2.2.6 Muut käytettävyyteen liittyvät ja työssä esiintyvät termit ... 19
2.3 Sivujen tekninen laatu... 20
2.3.1 Semanttisuus ... 20
2.3.2 Suositukset verkkosivustojen saavutettavuuden takaamiseksi ... 21
2.3.3 Mikroformaatit ... 22
2.3.4 HTML-standardit ja -suositukset ... 23
2.3.5 Muut laatuun vaikuttavat seikat ... 24
3 VERKKOSIVUKOMPONENTTIEN VALINTA JA TOTEUTUS ... 25
3.1 Verkkosivujen komponenttien valinta ... 25
3.1.1 Komponenttien tunnistaminen ja kirjaus ... 26
3.1.2 Sivustoja analysoitaessa löytyneet ongelmat ... 27
3.2 Diplomityössä toteutettavat komponentit ... 29
3.3 Komponenttien toteutus ... 30
3.4 Komponenttien käyttötavat ... 32
3.5 Komponenttikirjaston hyödyllisyys ja tehokkuus ... 34
3.5.1 Kirjaston luomiseen käytetty työmäärä ... 35
3.5.2 Kirjaston tuoman tehokkuuden arviointi ... 35
3.5.3 Hyödyllisyys ... 37
3.6 Komponenttikirjaston tulevaisuus ... 38
4 POHDINTA ... 40
5 JOHTOPÄÄTÖKSET ... 42
LÄHDELUETTELO ... 43
LIITTEET ... 47
TERMIT JA LYHENTEET Lyhenteet
AJAX Asynchronous JavaScript And XML
ARIA Accessible Rich Internet Applications
CSS Cascading StyleSheets
HTML HyperText Markup Language
JHS Julkishallinnon Suositus
SEO Search Engine Optimisation
URI Unique Resource Identifyer
WAI Web Accessibility Iniative
XHTML eXtensible HyperText Markup Language
Termit
Korttimenetelmä Card Sorting Käyttäjätarinat User Story Mikroformaatti Microformat Rautalankamalli Wireframe
Vuorovaikutusmalli Interaction Design Pattern
1 JOHDANTO
Internetin yleistyminen yhteiskunnan kaikilla osa-alueilla ja alan kilpailun kiristymisen myötä käyttöliittymäsuunnittelu on muodostunut tärkeäksi osaksi laadukkaiden ja kilpailukykyisten verkkosivujen toteutusta. Käyttöliittymä on tärkeä osa käyttäjän kokemusta verkkosivuston laadusta ja toimivuudesta. Hyvällä suunnittelulla voidaan auttaa positiivisen käyttökokemuksen muodostumista.
Sivustoprojektin käyttöliittymäsuunnittelussa käytetyt menetelmät ja työkalut valitaan siten, että ne soveltuvat kyseisen projektin luonteeseen ja vaatimuksiin.
Kuten työtehtävissä yleensä, myös käyttöliittymäsuunnittelussa kustannustehokkuus on tärkeää. Käyttöliittymäsuunnittelussa voidaan käyttää useita menetelmiä käytettävyyden parantamiseen.
Tässä työssä luodaan uudelleenkäytettävien komponenttien kirjasto ja tutkitaan tehostaako sen käyttö verkkosivujen suunnittelua ja prototyyppien rakentamista.
Kirjaston luomista varten tutkitaan työn tilanneen yrityksen tekemien sivustojen sisältämiä HTML-rakenteita ja etsitään niistä toistuvia rakenteita.
1.1 Tausta
Uoma Oy -niminen yritys toteuttaa asiakkaidensa tilaamia Internet-sivustoja ja sovelluksia. Hyvä käytettävyys ja positiivinen käyttäjän saama kokemus, käyttökokemus, ovat yrityksessä tunnistettu tärkeiksi osiksi projektin toteutusta.
Siksi oleellisena osana sivustojen luomista ja Uoma Oy:n strategiaa on sivujen käyttöliittymä- ja käytettävyyssuunnittelu.
Tyypillinen projekti Uoma Oy:ssä alkaa siten, että ensin asiakkaan kanssa yhteistyössä hahmotellaan kehitettävää sivustoa tai sovellusta. Sivuston hahmottelussa mietitään ainakin sivuston brändiä, sisältöä, liiketoiminnan
tavoitteita ja loppukäyttäjän tavoitteita. Hahmottelussa työvälineenä on käytetty kynää ja paperia, valkotauluja, sekä lehtiö- eli fläppitauluja työssä käsiteltävien asioiden visualisoimiseksi.
Hahmottelun jälkeen projektille on yleensä tehty taustatutkimusta, jossa apuvälineenä on voitu käyttää kilpailija-analyysien, kohderyhmien, testauksen ja työryhmien kaltaisia työvälineitä. Joissain projekteista on yhdessä asiakkaan kanssa tehty käyttäjätarinoita (eng. User Story) kuvaamaan tyypillisiä käyttäjän suorittamia tehtäviä sivustolla. Käyttäjätarinat määrittävät kunkin järjestelmävaatimuksen käyttäen yhtä tai useampaa asiakkaan ymmärtämää lausetta vastaten kysymyksiin: kuka, mitä ja miksi. Yrityksessä ei ole vielä järjestelmällisesti käytetty tässä työssä myöhemmin käsiteltäviä vuorovaikutusmalleja käyttäjien tarpeiden ratkaisemiseksi. Joissakin projekteissa hahmotelmien ja taustatutkimusten pohjalta on tehty seuraavaksi sivuston tärkeimpien osakokonaisuuksien osalta paperimallit, jotka tunnetaan myös nimellä paperiprototyypit. Näiden prototyyppien avulla sivuston rakennetta on hahmoteltu siistimpään muotoon ja varmistettu, että käyttäjätarinoiden määrittämät tehtävät voidaan toteuttaa mallien mukaisella käyttöliittymällä.
Mahdollisten paperiprototyyppien tai suoraan hahmotelmien pohjalta on tehty nk.
rautalankamallit sivusta. Rautalankamalli on ohjelmoimalla tai piirtämällä toteutettu pelkkää hahmotelmaa konkreettisempi esimerkki sivuston rakenteesta ja asettelusta. Rautalankamallit näyttävät sivuston eri osien asettelun visuaalisesti kuitenkaan keskittymättä itse visuaaliseen ilmeeseen [New2000]. Ne ovat kuitenkin visuaalisesti siistimpiä ja siten näyttävämpiä kuin hahmotelmat tai paperimallit ja siksi niitä näytetään asiakkaalle mieluummin kuin hahmotelmia tai paperiprototyyppejä. Kuvassa 1 näkyvä hahmotelma ja kuvassa 2 näkyvä rautalankamalli samasta sivusta havainnollistavat hahmotelman ja rautalangan välistä eroa tarkkuudessa.
Kuva 1. Esimerkki hahmotelmasta
Kuva 2. Esimerkki kuvan 1 hahmotelman avulla tehdystä rautalankamallista.
Rautalankamalleja käytetään apuna asiakkaan kanssa tulevaa sivustoa hahmotellessa, sitä testatessa mahdollisilla käyttäjillä, ja siitä keskusteltaessa.
Useassa projektissa on huomattu jo yksinkertaisen rautalankamallin selkeyttävän keskustelun suuntaa ja yhtenäistävän keskustelijoiden näkökannan konkreettisen esimerkin kautta. Usein eri asiakkaiden sivustoille ja siten myös rautalankamalleihin tulee samanlaisia osia, kuten esimerkiksi navigaatio, sivutus ja sivuston sisäinen haku. Yrityksessä käytetyt rautalankamallit voidaan jakaa karkeasti kahteen ryhmään: kuviin pohjautuvat mallit ja melkein prototyyppien kaltaiset rautalankamallit.
Rautalankamalleja on tähän asti Uoma Oy:llä tehty eri tekniikoilla eikä yhtenäistä ohjenuoraa ole ollut. Vuosituhannen vaihteessa suurin osa yrityksen toteuttamista sivustoista hyödynsi sivustojen elementtien asettelussa taulukoita eli taulukkopohjaista asettelua, mutta se havaittiin semanttisuudeltaan epäkorrektiksi ja työlääksi ylläpitää. Sivun semanttisuus tarkoittaa kuinka hyvin sen sisällön sisältävät elementit kuvaavat sisältöä, eli kuinka hyvin koodi vastaa sisällön rakennetta ja tarkoitusta. Taulukkopohjaisen asettelun tuoma sisällön ja muotoilun yhdistäminen samaan lähdekoodiin teki sivun koodista pitkän ja hankalasti muokattavan. Vielä vuonna 2007 yrityksessä tehtiin prototyyppimäiset mallit aina koodaamalla sivujen eri elementtien asettelu käyttäen Hyper Text Markup Language (HTML) –koodin taulukkoja. Itse sivut toteutettiin rautalankamallien jälkeen käyttäen semanttisesti hyviä HTML-rakenteita ja muotoillen ne Cascading Style Sheets-kielen, eli CSS-kielen avulla.
Taulukkopohjaisesta lähestymisestä on luovuttu sittemmin myös rautalankojen osalta, koska eri lähestymistavat koettiin liian erilaisiksi keskenään. Saman sivun toteuttaminen kahdella eri tekniikalla aiheutti ylimääräistä vaivaa. Prototyyppien kaltaisia rautalankamalleja on yrityksessä sittemmin tehty semanttisesti oikeaoppisemmin kirjoitetulla HTML:llä ja pienemmissä määrin Adoben Flex - ohjelmointikielellä. Kuviin pohjautuvia rautalankoja on tapauskohtaisesti tehty
muun muassa Microsoftin PowerPoint-ohjelmalla, Adoben Photoshop – ja Illustrator – ohjelmilla. Sekä kuviin pohjautuvalla että koodatulla rautalankamallin toteutustavoilla on havaittu omat hyvät ja huonot puolensa.
Staattinen kuva rautalankamallista ei vastaa toiminnaltaan riittävän hyvin oikeaa sivua mallintaakseen eri käyttötilanteita. Ongelmina ovat esimerkiksi mallin visuaalinen skaalautuvuus, tekstikoon muuttaminen ja lomake-elementtien ulkoasu. Visuaalisella skaalautuvuudella tarkoitetaan tilannetta, jossa Internet- selaimen ikkunakoko on suurempi tai pienempi kuin alkuperäisessä mallissa.
Tällöin sivuston tulisi esimerkiksi kuvan 3 esittämällä tavalla skaalautua käyttämään mahdollinen tila mahdollisimman hyvin, säilyttäen silti sisällön luettavuus. Lisäksi kuvapohjaisissa ratkaisuissa on havaittu ongelmalliseksi niiden uudelleenkäytettävyys, sillä vanhan projektin käyttämästä kuvasta voi olla työlästä irrottaa jotain osakokonaisuutta uutta projektia suunniteltaessa.
Kuva 3. Esimerkki visuaalisesta skaalautumisesta ikkunan leveyden kasvaessa
Prototyyppimäisten rautalankojen heikkouksiksi on havaittu hitaampi kokoaminen verrattuna kuviin pohjautuviin malleihin. Osasyynä hitaampaan kokoamiseen saattaa olla se, että prototyyppien HTML-koodin uudelleenkäyttö on ollut vähäistä, eikä yhtenäistä sovittua linjaa ratkaista ongelmat samoin menetelmin ole ollut eri tekijöiden välillä. Vaikka eri sivustojen ulkoasu saattaa vaihdella
keskenään huomattavasti on sivuilla käytettyjen osien HTML-koodi usein koettu samankaltaiseksi eri sivujen välillä. Koodin samankaltaisuuden on oletettu syntyvän HTML-koodaajien käyttämien semanttisten ohjenuorien noudattamisesta. Semanttisuuden ajatuksena on muotoilla tieto sellaisessa hyvin määritellyssä muodossa, että koneet kykenevät ymmärtämään tiedon merkityksen, eivätkä ainoastaan välittämään tietoa [Ber2001].
Kun sivujen visuaalinen ilme ja sisältö ovat selvillä, on toteutettu työvaihe, jota yrityksessä kutsutaan HTML-taitoksi. Tässä vaiheessa HTML-taittaja luo etukäteen laaditun rautalankamallin, suunnitelmien ja visuaalisen ilmeen pohjalta HTML-, CSS- ja kuvatiedostot, joista lopullisten sivujen käyttämät teematiedostot toteutetaan. Nämä taittotiedostot yhdessä muodostavat rajoitetusti toimivan prototyypin. Taittotiedostot eivät sisällä vielä dynaamisia osia sivuista vaan toimivat rautalankamallien kaltaisesti, mutta vastaavat ulkoasultaan lähes täydellisesti lopullista sivustoa. Niitä kutsutaan myös visuaalisen ilmeen sisältäviksi prototyypeiksi. Tällä hetkellä yrityksessä työskentelee kolme henkilöä, joiden yhtenä työnkuvana on HTML-taittotehtävien tekeminen. Nämä henkilöt tekevät pääsääntöisesti kaikki isommat HTML-taittotehtävät ja opastavat muita yrityksessä toimivia ohjelmoijia hyvän HTML-rakenteen muodosta.
Lisäksi yrityksessä työskentelee koodaajia, joiden pääosaamisalueena on muu kuin HTML-taitto. Nämä koodaajat rakentavat valmiiden taittotiedostojen avulla lopullisen toimivan sivuston tai sovelluksen.
Kullakin yrityksessä toimivista HTML-taittotehtäviä tekevällä henkilöllä on omat työtapansa ja oma arkistonsa projekteista. Vaikka taittajien työtavoissa on paljon yhteneväisyyksiä, pieniä eroja on havaittavissa tuotetussa koodissa eri tekijöiden välillä. Siksi koodia ei tällä hetkellä voi täysin ongelmitta kopioida ristiin eri projektien välillä. Lisäksi kertaalleen yrityksessä rakennetut ratkaisut saattavat jäädä hyödyntämättä puuttuvan toimintamallin takia. Tässä diplomityössä suunniteltavaa komponenttikirjastoa ja sitä hyödyntävää toimintamallia
käyttämällä uskotaan, että yrityksen tehokkuutta voidaan parantaa käyttöliittymäsuunnittelun ja prototyyppien luomisen saralla.
1.2 Tavoitteet ja rajaukset
Tämän diplomityön tavoitteena on luoda uudelleenkäytettävien komponenttien kirjasto ja tutkia tehostaako sen käyttö verkkosivujen suunnittelua ja niiden prototyyppien rakentamista. Kirjaston luomista ja priorisointia varten tutkitaan yrityksessä toteutettujen projektien osalta yhteneviä rakenteita ja uudelleenkäytettäviä osakokonaisuuksia. Lisäksi työssä on tavoitteena selvittää tällaisen kirjaston tuomat mahdolliset muut edut käyttöliittymäsuunnittelussa ja HTML-taittotehtävissä yleisellä tasolla.
Työn rajauksena on tarvittavien kirjaston eri komponenttien määrän ja komponenteilta toivottavien ominaisuuksien kartoitus sekä vähintään yleisimpien peruskomponenttien ohjelmoiminen Uoma Oy:lle. Mikäli työn edetessä ilmenee, että jotkin komponenteista voivat toimia pohjana useammille tarvittaville rakenteille, on kyseisten kirjastokomponenttien kehitys etusijalla. Työssä keskitytään verkkosivujen toteutuksen niihin osa-alueisiin, joissa kirjaston komponentteja voidaan todennäköisimmin hyödyntää.
Kirjastoa luodessa tulee ottaa huomioon alalla hyväksi havaitut tavat saavutettavuuden, käytettävyyden, sekä komponenttien uudelleenkäytettävyyden ja laadun takaamiseksi. Hyvä saavutettavuus kertoo erilaisten yleisöjen tarpeiden huomioimisesta yksilöiden erilaisista ominaisuuksista riippumatta. Komponentteja tulisi voida käyttää mahdollisuuksien mukaan prototyyppien luonnissa sekä rautalankojen että taittotiedostojen osalta ilman, että HTML-koodia tarvitsisi muuttaa muuten kuin erikoistapauksien osalta.
1.3 Työn rakenne
Tämän diplomityön johdannossa kerrotaan työn tausta ja mikä nykytilanne on yrityksessä. Johdannossa myös asetetaan työn tavoitteet ja rajaukset ja kerrotaan työn rakenne. Tämän diplomityön toisessa luvussa kerrotaan yleisellä tasolla sivuston suunnittelun eri osa-alueista. Käyttöliittymäsuunnittelun eri apuvälineitä esitellään luvussa 2.2. Luvun 2.3 tarkoituksena on selventää sivujen teknisen laadun vaatimuksia komponenttien toteutusta varten. Kyseisessä luvussa käydään alan eri määrityksiä ja termejä yleisellä tasolla läpi.
Kolmannessa kappaleessa käydään läpi komponenttien valinta ja toteutus niin kuin ne tätä työtä varten on toteutettu. Ensin alikappaleessa 3.1 etsitään vanhoilta sivustoilta mahdollisia komponentteja, sitten komponentit valitaan ja toteutetaan seuraavissa kappaleissa. Komponenttien käyttötapoja pohditaan alikappaleessa 3.4 ja koko komponenttikirjaston hyötyjä alikappaleessa 3.5.
Työn neljännessä kappaleessa pohditaan työssä tehtyjä ratkaisuita ja niiden vaikutusta komponenttikirjastoon myös jatkossa. Viides kappale esittelee työn pohjalta tehdyt johtopäätökset ja lyhyen yhteenvedon jo käsitellyistä asioista.
Työssä on myös kaksi liitettä, jotka tarkentavat aihepiiriä.
2 VERKKOSIVUJEN SUUNNITTELU
World Wide Webistä on nopeasti tullut hallitseva Internet-työkalu, joka yhdistää hypertekstiä ja multimediaa tarjotakseen verkoston monenlaisia resursseja. On tärkeää, että jokainen osa verkkosivustoa on hyödyllinen. Käyttäjä saapuu sivustolle odottaen voivansa suorittaa tietyn tehtävän tai lukeakseen tietyn tiedonmurusen. Verkkosivuston suunnittelussa tulee ottaa huomioon, että käyttäjän tulisi löytää haluttu resurssi nopeasti ja helposti. Jos käyttäjät eivät löydä tietoa nopeasti, niin he saattavat siirtyä toiselle sivulle, josta löytävät haluamansa tiedon.
Kuten Montero et al. toteavat artikkelissaan, löytyy monia verkkosuunnittelun ohjesääntöjä, joita voidaan käyttää verkkosivustojen suunnittelun parantamiseen [Mon2002]. Useimmat ohjeet eivät kuitenkaan pohjaudu tutkimuksiin vaan intuitioon eli ne pohjautuvat suunnittelijan ammattitaitoon [Mon2002].
Perinteisesti käyttöliittymäsuunnittelun kokemuksia kerätään ohjesääntöjen avulla, mutta prototyyppejä voidaan myös käyttää [Mon2002]. Sivustojen lisääntymisen myötä niiden kehityksen yksinkertaistaminen tehokkain menetelmin ja työkaluin muodostuu tärkeäksi kysymykseksi [Des2001].
2.1 Johdanto
Tässä diplomityössä luodaan sivustojen suunnittelua varten komponenttikirjasto.
Tämä kirjasto luodaan erityisesti sivuston käyttöliittymäsuunnittelun eri osa- alueiden tueksi. Sivuston käyttöliittymäsuunnittelussa on useita vaiheita ja menetelmiä, joista kaikkia ei ole järkevä käyttää jokaisessa projektissa, vaan sopivat menetelmät tulee valita projektikohtaisesti. Kirjastosta ei välttämättä ole hyötyä kaikilla käyttöliittymäsuunnittelun osa-alueilla. Tärkeimpiä kirjastoon liittyviä osa-alueita ovat vuorovaikutusmallit, paperiprototyypit, rautalankamallit ja prototyypit. Nämä osa-alueet esitellään yleisellä tasolla tämän diplomityön
teoriaosuudessa. Toteutettavan kirjaston sisältämien komponenttien laatu on tärkeää, koska komponentit muodostavat rungon lopullisen sivun tekniselle toteutukselle. Siten ne päätyvät myös valmiilla Internet-sivustolla vierailevan käyttäjän selaimen käsiteltäväksi ja vaikuttavat siten käyttäjän saamaan käyttökokemukseen. Tässä työssä käsitellään myös sivujen teknistä laatua yleisellä tasolla.
2.2 Käyttöliittymäsuunnittelu
Tiettyyn pisteeseen asti helppokäyttöisyys riippuu tietyn sivuston tarkoituksesta ja tavoiteyleisöstä [Mur1999]. Silti on yleisesti hyväksytty, että helposti käytettävä verkkokäyttöliittymä on sellainen, joka on saavutettava, vetoava, johdonmukainen, selkeä, yksinkertainen, navigoitava ja anteeksiantava käyttäjän virheille [Mur1999]. Käyttäjille käyttöliittymä on yhtä kuin tuote. Jos käyttäjät eivät voi tai halua käyttää käyttöliittymää, niin ei ole väliä kuinka hyvin tuotteen toiminnallisuus on toteutettu. Tuotteet epäonnistuvat huonojen käyttöliittymiensä takia. [Fra2005]
Kuten taulukko 1 havainnollistaa, käyttöliittymäsuunnittelu voidaan jakaa kuuteen osioon projektin edetessä [Usa2006]. Kaikkia taulukossa esiteltyjä käyttöliittymäsuunnittelun metodeita ei ole tarkoituksenmukaista käyttää yhdessä projektissa, vaan taulukosta on tarkoitus valita menetelmiä kyseiseen projektiin soveltuvin osin [Usa2006].
Taulukko 1. Käyttöliittymäsuunnittelun metodit [Usa2006]
Tässä työssä keskitytään pääsääntöisesti kolmanteen taulukossa 1 näkyvään sarakkeeseen: Design. Myös joitakin toisen sarakkeen menetelmiä hyödynnetään diplomityössä.
2.2.1 Käyttöliittymäsuunnittelun ohjeet
Käyttöliittymäsuunnittelun ohjeet (eng. guidelines) tiivistävät hyvät käytännöt ja tukevat käytettävien käyttöliittymien suunnittelussa. Yhtenä osana saavutettavuusvaatimuksia voi olla tiettyjen ohjeiden noudattaminen (esimerkiksi JHS-129). Suunnittelijoiden ja kehittäjien tulisi tällaisessa tilanteessa tutustua tarvittaviin ohjeisiin ja ohjeiden noudattamista tulisi valvoa. [Usa2006]
Planning &
Feasability Requirements Design Implementation Test & Measure Post Release Getting started User Surveys Design guidelines Style guides Diagnostic
evaluation
Post release testing Stakeholder
meeting Interviews Paper prototyping Rapid prototyping Performance testing
Subjective assesment Analyse context Contextual inquiry Heuristic
evaluation
Subjective
evaluation User surveys
ISO 13407 User Observation Parallel design Heuristic
evaluation
Remote evaluation
Planning Context Storyboarding Critical Incidence
Tehcnique Competitor
Analysis Focus Groups Evaluate
prototype Pleasure
Brainstorming Wizard of Oz Evaluating existing
systems
Interface design patterns Card Sorting
Affinity diagramming Scenarios of use
Task Analysis Requirements
meeting
2.2.2 Vuorovaikutusmallit
Yksi yleisesti tunnettu menetelmä käyttöliittymäsuunnittelussa on vuorovaikutusmallien (eng. Interaction Design Pattern tai Interface Design Pattern) käyttäminen määrittelyn apuna. Vuorovaikutusmalleja hyödynnetään käyttöliittymiin liittyvien ongelmien tunnistamisessa ja ratkaisussa.
Vuorovaikutusmallit tai suunnittelumallit ovat joukko lyhyitä kuvauksia erilaisista käyttäjän tarpeista ja niihin liittyvistä hyväksi havaituista ratkaisumalleista [Bec1987]. Monet käyttöliittymämallit soveltuvat hyvin käyttöliittymien tuntemuksen tunnistamiseen uudelleenkäytettävyyden lisäämiseksi [Fen2007].
Suunnittelumallit ovat suuri harppaus ohjelmistoarkkitehtuurissa ja tarjoavat yhtenäisen sanaston ja laajalti tunnetun katalogin ratkaisuja usein eteen tulevien ongelmien ratkaisemiseen [Mey2006]. Suunnittelumallit ohjaavat suunnittelijaa tarjoamalla toimivia ratkaisuja kaikkiin suunnittelun aikana esiin tuleviin tunnettuihin ongelmiin [Bec1987]. Kullakin mallilla on samanlainen rakenne:
ongelman kuvaus, lyhyt kuvaus ongelman esiintymisestä, ja tärkeimpänä kaikesta, ratkaisu, joka toimii kyseisessä tilanteessa [Bec1987]. Alla on yksi esimerkki vuorovaikutusmallista [Wel2010]:
Sivutus
Minkä ongelman tämä malli ratkaisee?
Käyttäjän tulee käydä läpi pitkä lista asioita etsien haluamaansa.
Milloin tätä mallia kannattaa käyttää?
Käyttäjän läpikäytävä lista on liian pitkä mahtuakseen järkevästi yhdelle sivulle. Asiat ovat tyypillisesti tietyssä järjestyksessä ja etsitty asia on suurella todennäköisyydellä listan alkupäässä.
Mikä on mallin tarjoama ratkaisu?
Jaa lista useisiin sivuihin ja tee siirtyminen sivulta toiselle helpoksi käyttäjälle näyttämällä listan sivunumerot navigaatioelementtinä kullakin sivulla.
2.2.3 Prototyypit
Kattavien järjestelmien käyttöliittymäprototyypit palvelevat usein kolmea tarkoitusta [Joh2005]:
Ne välittävät suunnittelun ideat kehittäjille, hallinnolle tai asiakkaille.
Ne tarjoavat pohjan käyttäjätutkimuksille, jotka tehdään usein aloittelevien käyttäjien kanssa suunnitelman käytettävyysongelmien löytämiseksi.
Niiden avulla kerätään tietoa taitavien käyttäjien arvioidusta suorituskyvystä.
Kun päätetään rakennetaanko ja testataanko prototyyppejä, tasapaino kehityskulujen ja saatujen hyötyjen välillä kääntää suunnan monikäyttöisiin ja helposti rakennettaviin prototyyppeihin [Joh2005]. Kun suunnitellaan käyttäjän kokemusta, oleellista on ymmärtää minkälaista prototyyppiä voidaan käyttää tietyssä suunnittelun vaiheessa [Hen2008].
Sefelin et al. vertasivat kahden järjestelmän tietokone-pohjaisia prototyyppejä ja paperiprototyyppejä keskenään. He päättelivät että ”paperi- ja tietokone-pohjaiset matalan tarkkuuden prototyypit johtavat melkein samoihin laadullisiin ja määrällisiin käyttäjämäärityksiin” [Sef2003]. He myös huomasivat, että testihenkilöt suosivat tietokonepohjaisia prototyyppejä paperiprototyyppien sijaan [Sef2003]. HTML ja CSS tarjoavat rajoitetun joukon rakenteita, joka kannustavat sisällön ja sen muotoilun erottamiseen, yhtenäiseen ulkoasuun ja sallivat ulkoasun muuttamisen helposti [Fra2005]. HTML:n ja CSS:n rajoitetut mahdollisuudet kannustavat keskittämään huomion käyttöliittymään [Fra2005].
2.2.4 Paperiprototyypit
Kehittäjät, riippumatta siitä kuinka tietäviä tai hyvää tarkoittavia he ovat, ovat luultavasti huonoimpia arvioimaan suunnittelemiansa käyttöliittymiä [Fra2005].
Myös käyttäjien esimiehet ovat huonoja arvioimaan käyttäjien käyttöliittymiä.
Vain käyttöliittymän käyttäjät voivat arvioida tarvittavalla tasolla käyttöliittymän laatua. Vain testaamalla tulevaa käyttöliittymää he voivat tehokkaasti arvioida kuinka sopiva käyttöliittymä tulee olemaan [Fra2005]. Käyttöliittymien
prototypointi mahdollistaa sen eri osa-alueiden, kuten käyttöliittymän asettelun, sen käyttämien sanamuotojen, asettelun, kokonaisvaikutelman, valikoiden toimivuuden, työkalujen, nappien, kirjasimien ja jopa värivalintojen testauksen ja arvioinnin [Fra2005]. Käyttämällä käyttäjätestauksessa konkreettista yksinkertaistettua mallia ohjelmasta tai jopa paperimallia, antaa laadukkaampaa palautetta kuin pelkästään käyttäjien kanssa keskustelemalla saisi.
Paperiprototyyppejä tai paperimalleja käytetään vaatimusten selkiyttämiseen, mahdollistamaan alustavat vuorovaikutussuunnitelmat, sekä suunniteltujen näyttöjen nopea simulointi ja testaus [Usa2006]. Paperiprototyyppi on joukko paperille tehtyjä luonnoksia käyttöliittymästä, jossa on sen verran yksityiskohtia, että päätökset esimerkiksi tuotteen rakenteesta ja toiminnallisuudesta voidaan tehdä [Sin2002]. Yksi esimerkki sivuston paperiprototyypistä näkyy kuvassa 4.
Kuten Sinkkonen kirjoittaa, paperiprototyypeillä voidaan tarkistaa, että tulevan tuotteen toiminnot sujuvat ja ettei tärkeä toiminto ole liian syvällä navigaatiorakenteessa [Sin2002].
Kuva 4. Esimerkki sivun paperiprototyypistä
2.2.5 Rautalankamallit
Rautalankamallit (eng. wireframes) ovat malleja tietyllä sivulla esiintyvästä tiedosta. Niissä ei yleensä ole kuvia, joskin kuvalle suunniteltua paikkaa saatetaan merkitä tekstillä. Vaikka rautalankamallien tarkoituksena ei ole näyttää miten väriä, kirjasimia tai grafiikkaa käytetään sivulla, niissä itsessään saattaa esiintyä yksinkertaisia värejä, tekstimuotoiluita ja grafiikoita ilmaisemaan muita asioita sivusta. [New2000]
Rautalankamallien avulla asiakkaalle voidaan näyttää sivuston tai sovelluksen rakennetta, asettelua ja yleistä informaatioarkkitehtuuria [New2000]. Näin näitä asioita voidaan suunnitella yhdessä asiakkaan kanssa käyttäjän tarpeita vastaaviksi [New2000]. Liian hiotun mallin tarjoaminen kannustaa asiakkaita keskittymään epärelevantteihin yksityiskohtiin, kuten kirjasimiin, väreihin ja kuviin, kun usein
tarkoituksenmukaisempaa tässä vaiheessa on saada palautetta informaation rakenteesta ja järjestelystä. Vaidyanathan et al. totesi tutkimustensa perusteella, että HTML-koodaus on helppo tapa tehdä prototyyppejä ja evaluoida niitä [Vai1999]. Kuvassa 2 näkyy esimerkki sivun rautalankamallista.
2.2.6 Muut käytettävyyteen liittyvät ja työssä esiintyvät termit
Korttimenetelmä (eng. card sorting) on tehokas ja halpa keino rakentaa tuotteen käytettävyyttä. Korteilla voidaan tutkia käyttäjien käsitehierarkioita ja - ryhmittelyä. Tavoitteena on esimerkiksi tuottaa hyvä navigointirakenne.
Korttimenetelmässä käsiteltävät termit kirjoitetaan kukin erilliselle kortille ja tutkittava käyttäjäryhmä jakaa kortit mielestään loogisiin kokonaisuuksiin.
Kuvassa 5 näkyy esimerkki korttimenetelmän käytöstä, jossa kortit on jaettu kokonaisuuksiin ja kokonaisuudet nimetty. [Sin2002]
Kuva 5. Esimerkki korttimenetelmän käytöstä
Heuristinen arviointi (eng. Heuristic evaluation) on käytettävyyden arvioinnin yksi menetelmä, jossa käytettävyysasiantuntijat arvioivat noudattavatko kaikki käyttöliittymän elementit määriteltyjä nyrkkisääntöjä. Rinnakkainen suunnittelu
(eng. Parallel design) on menetelmä, jossa luodaan vähintään kaksi kilpailevaa käyttöliittymäsuunnitelmaa eri tekijöiden toimesta. Rinnakkaisen suunnittelun tavoitteena on tutkia eri ideoita ennen yhden ratkaisutavan valitsemista.
[Usa2006]
Kuvakäsikirjoitus (eng. Storyboard) on matalan tason prototyyppi, joka muodostaa hahmotelmien avulla etenevän tarinan. Kuvakäsikirjoituksia käytetään pääsääntöisesti multimediaesitysten luonnissa. Ihmemaa Oz:n taikuri (eng.
Wizard of Oz) menetelmänä viittaa näkymättömissä asioihin vaikuttavaan henkilöön. Käyttöliittymäsuunnittelussa tätä menetelmää voidaan käyttää järjestelmän prototyypin testauksessa siten, että testaaja simuloi järjestelmän toimintaa testattavalle. [Usa2006]
2.3 Sivujen tekninen laatu
Sivujen teknistä laatua voidaan arvioida monella tavalla. Sivustojen käyttötavat määrittävät tarpeita sivujen toteutukselle. Se, miten hyvin sivusto palvelee näitä käyttötarpeita, kertoo sivuston laadusta. Sivuston sivuja selataan tätä varten suunnitelluilla selaimilla ja muilla apuvälineillä. Sivustojen pääasiallisina käyttäjinä ovat yleensä ihmiset ja toissijaisena ohjelmat tai koneet. Ihmisillä saattaa olla rajoitteita, kuten jokin vamma, joka saattaa vaikeuttaa normaalia käyttötapaa. Esimerkiksi näkövamma saattaa heikentää tai tehdä kokonaan mahdottomaksi katsella sivustoa visuaalisesti. Tällöin saatetaan turvautua lukijaohjelmiin tai muihin vastaaviin apuvälineisiin. Koneet saattavat tulkita sivustoa johonkin tarkoitukseen. Esimerkiksi hakukone tutkii sivuston sisällön tarjotakseen sitä hakutuloksien kautta.
2.3.1 Semanttisuus
Alkuperäinen Scientific Americanin artikkeli semanttisesta verkosta ilmestyi vuonna 2001. Se kuvasi verkon evoluutiota ajasta, jossa on ihmisille luettavaksi suunnattuja dokumentteja sellaiseen aikaan, jossa dokumentit luettavuuden lisäksi sisältävät tietoa ja informaatiota koneiden käsiteltäväksi [Sha2006]. Semanttinen
Web ei ollut uusi idea. Tim Berners-Lee kuvasi sen jo ensimmäisessä World Wide Web konferenssissa vuonna 1994 [Sha2006].
Kun mietitään dynaamisten verkkosovellusten tietokantojen tietojen pohjalta luotujen sivujen prosentuaalista osuutta nykypäivän netissä, osoittaa se mahdollisesti merkittävän lähteen semanttiselle merkinnälle [Fuc2003]. Kun sivut kuvaavat sisältönsä semanttisesti oikein, pystyvät koneet paremmin lukemaan ja ymmärtämään sivun sisällön ja sen merkityksen. Sivujen parempi semanttisuus siis lisää sivujen koneellista luettavuutta ja siten sivujen teknistä laatua. Osa hakukoneista tarjoaa jo semanttiseen sisältöön liittyviä palveluita.
2.3.2 Suositukset verkkosivustojen saavutettavuuden takaamiseksi
W3C eli World Wide Web Consortium on kansainvälinen yritysten ja yhteisöjen yhteenliittymä, joka ylläpitää ja kehittää WWW:n standardeja [W3C2010]. Web- saavutettavuuden aloite (eng. Web-accessibility initiative eli WAI) on yksi W3C:n projekteista. Hyvä saavutettavuus kertoo erilaisten yleisöjen tarpeiden huomioimisesta yksilöiden erilaisista ominaisuuksista riippumatta. Yksi osa WAI:n osa-alue on saavutettavuuden parantaminen rikkaiden Internet-sovellusten saralla. Saavutettavat, rikkaat Internet-sovellukset (eng. Accessible Rich Internet Applications eli ARIA) määrittelee tavan toteuttaa Web-sisältöä ja Web- sovelluksia saavutettavammiksi vammaisille [W3C2010]. Ohjeistus auttaa eritoten Ajaxilla, HTML:llä, JavaScriptillä ja muilla vastaavilla teknologioilla kehitettyjen dynaamisen sisällön ja monipuolisten käyttöliittymäkontrollien kanssa [W3C2010].
Suomessa julkishallinnolle tarjotaan suosituksia JHS-järjestelmän, eli julkishallinnon suositus - järjestelmän, kautta. Järjestelmän Internet-sivu kuvaa tavoitettaan ja pyrkimyksiään seuraavasti [JHS2010]:
”JHS-järjestelmän tavoitteena on parantaa tietojärjestelmien ja niiden tietojen yhteentoimivuutta, luoda edellytykset hallinto- ja sektorirajoista riippumattomalle
toimintojen kehittämiselle sekä tehostaa olemassa olevan tiedon hyödyntämistä.
Suosituksilla pyritään myös minimoimaan päällekkäistä kehittämistyötä, ohjaamaan tietojärjestelmien kehittämistä ja saamaan aikaan hyviä ja yhdenmukaisia käytäntöjä julkishallintoon ja erityisesti julkisten organisaatioiden tietohallintoon. Suositukset hyväksyy julkisen hallinnon tietohallinnon neuvottelukunta JUHTA ja niiden laatimista ohjaa JUHTAn alainen JHS-jaosto.”
JHS-järjestelmästä löytyy suositus ”Julkishallinnon verkkopalvelun suunnittelun ja toteuttamisen periaatteille”, jonka tunnisteena on ”JHS 129” [JHS2010]. JHS 129 käsittelee asioita, joiden avulla Internet-sivuston saavutettavuus ja käytettävyys voidaan tuoda riittävälle tasolle koko kansan tarpeita varten. Uoma Oy on toteuttanut lukuisia projekteja yhdessä julkishallinnon kanssa ja JHS 129 on yksi tärkeä osa projektin suunnittelua ja laadunvarmistusta.
2.3.3 Mikroformaatit
Mikroformaatit (eng. Microformats) ovat yhteisön kehittämiä standardeja helpottamaan verkkoinformaation koneluettavuutta [Sto2009]. Mikroformaatit koostuvat pienistä pätkistä HTML-elementtien attribuutteihin, kuten ”rel”- ja
”class”-attribuutteihin, lisättyä semanttista tietoa [Sto2009]. Mikroformaatteja ymmärtävät sovellukset, kuten Internet-selaimet ja hakukoneet, voivat sitten lukea XHTML dokumentin rakenteen ja löytää merkitsevää tietoa, kuten lisenssiin liittyvää tietoa, sivuun liittyviä asiasanoja, kontaktitietoa ja kalenteritapahtumia [Sto2009]. Koska mikroformaatit koostuvat pienistä lisäyksistä normaalien verkkosivujen HTML-rakenteeseen, ne edustavat yksinkertaista, mutta tärkeää askelta Tim Berners-Leen kuvaaman ”Semanttisen Webin” suuntaan [Sto2009].
Mikroformaatit lisäävät sivujen koneellista luettavuutta kuvaamalla niiden sisältöä semanttisesti. Näin esimerkiksi hakukoneet voivat hyödyntää sivujen tietoa tehokkaammin ja sivujen laadun voidaan katsoa olevan korkeampi verrattuna sivuihin, joiden sisältöä ohjelmat eivät pysty yhtä helposti ymmärtämään.
2.3.4 HTML-standardit ja -suositukset
Viimeisimmät julkaistut suositukset HTML:lle tulivat versiolle 4.01, joka otettiin käyttöön joulukuun 24 vuonna 1999. Seuraavat merkintäkielen pyrkimykset keskittyivät XML variaatioihin HTML:stä, kuten XHTML 1, XHTML1.1 ja nykyäänkin jatkuva työ XHTML2:n parissa. Ryhmä nimeltään Web Hypertext Application Technology (WHATWG) päätti työstää päivityksen HTML määrittelyille. Tarve tälle päivitykselle syntyi olettamuksesta, että XML-parsinnan vaatimukset XHTML:ssä olivat turhan tiukat ja huonosti valvotut, ja että webin menestymisen salaisuus oli helppokäyttöisyydessä ja anteeksiantavuudessa, jota HTML tarjosi. Tästä työstä syntyi merkintäkieli, joka nykyään tunnetaan nimellä HTML5. HTML5 nähdään Uoma Oy:ssä yhtenä erittäin vahvana ehdokkaana Internetin tulevista teknologioista ja siksi komponentit haluttiin suunnitella HTML5 tekniikoita mahdollisuuksien mukaan hyödyntäen. [Lew2009]
Selainyhteensopivuus kertoo siitä, miten hyvin yhdellä selaimella katsottu sivusto vastaa ilmeeltään ja toiminnaltaan samaa sivustoa toisella selaimella katsottuna.
Selainvalmistajat tarjoavat kukin omia parhaaksi näkemiään laajennuksiaan sivujen koodiin. Nämä laajennukset eivät välttämättä ole yhteensopivia muiden selainvalmistajien tarjoaman kanssa. Osa näistä laajennuksista päätyy aikanaan standardeihin ja suosituksiin myös muiden selainvalmistajien toteutettavaksi. Näin ei kuitenkaan käy kaikille laajennuksille, vaan osa jää selainkohtaisiksi ominaisuuksiksi [Lew2009]. Tällaiset selainvalmistajien tekemät poikkeamat standardista heikentävät selainyhteensopivuutta, koska käyttäjä tarvitsee tietyn selaimen saadakseen sivulla tarjotut ominaisuudet käyttöön. Mikäli laajennus tarjoaa jotain sivun käytölle merkityksetöntä, mutta käyttäjän kokemusta parantavaa toiminnallisuutta, voi sitä käyttää. Tällöin täytyy kuitenkin tiedostaa se, että sivusto ei näytä kaikille käyttäjille samalta. Näiden laajennuksien lisäksi standardeissa saattaa olla väljyyttä aiheuttaen erilaisia tulkintoja siitä, miten sivu kuuluisi näyttää selaimessa [Lew2009]. Vaikka eri selaimet näyttävät sivut erilailla johtuen standardien tulkinta-eroista, tarjoaa standardien noudattaminen parhaat työkalut selainyhteensopivuuden saavuttamiseksi [Lew2009].
2.3.5 Muut laatuun vaikuttavat seikat
Aiemmin melkein kaikki sivustot käyttivät taulukoita asetellakseen sivuille niiden sisältö haluttuun järjestykseen. Nykyään asia on muuttumassa. CSS (Cascading Style Sheets) tarjoaa tehokkaan vaihtoehdon taulukon solujen käyttämisen sijasta sisällön asemoinnissa sivulle. Taulukkopohjaisen asettelun yhtenä ongelmana on sivun sisällön koodissa näkyvä järjestys. Koneellinen sivuston luku ei pysty yhtä vaivattomasti päättelemään ihmisen tavoin sisällön yhteyttä toisiinsa.
Lukuohjelmat lukevat taulukon yhden vaakarivin solut kerrallaan ja näin taulukkomuotoisessa asettelussa sisällön loogisuus tällaisella lukijalla luettuna kärsii, tai katoaa kokonaan. Siksi WAI (Web Accessibility Iniative) suosittelee taulukkomuotoisen asettelun välttämistä mikäli järjestys, jossa se luetaan, ei ole looginen. [Tha2006]
Koneellisen luvun ja saavutettavuuden parantaminen voi auttaa sivustoa myös muilla tavoin. Se, miten hyvin sivusto löytyy hakukoneella, vaikuttaa sivulle tulevien kävijöiden määrään dramaattisesti. Tekemällä sivustosta saavutettavan, voidaan huomattavasti parantaa hakukoneoptimointia (SEO). Joillekin organisaatioille hakukoneoptimointi on iso asia. Tällaisissa tilanteissa saavutettavuuden tuomat lisähyödyt toimivat tärkeänä myyntivalttina, mikäli saavutettavuuden tuomia liiketoiminnallisia hyötyjä täytyy perustella. [Tha2006]
3 VERKKOSIVUKOMPONENTTIEN VALINTA JA TOTEUTUS
Työ aloitettiin etsimällä mahdollisia valmiita kirjastoja. Luvussa 1.2 esiteltyjä työn tavoitteitta vastaavia kirjastoja ei löytynyt. Lähimmäksi suunniteltua komponenttikirjastoa tai työkalupalettia osoittautuivat vuorovaikutusmalleja sisältävät kirjastot. Nämä esittelevät erilaisia komponentteja käyttäjän tarpeen näkökulmasta. Koodia näissä kirjastoissa ei ole, vaan kuvaukset komponenteista ja niihin liittyvät huomiot käytettävyyden, saavutettavuuden, käyttötarkoituksen, ratkaisun, ja käyttötilanteiden suhteen. Oman kirjaston rakentaminen nähtiin etuna, koska sen koettiin lisäävän komponenttien syvällisempää ymmärrystä yrityksessä. Vuorovaikutusmalleja sisältävien kirjastojen vertailun tuloksena päädyttiin valitsemaan oman kirjaston tueksi ja rakenteeksi welie.com Internet- sivulta löytynyt listaus vuorovaikutusmalleista [Wel2010]. Alikappaleessa 2.2.2 on esitelty yksi esimerkki vuorovaikutusmallista.
3.1 Verkkosivujen komponenttien valinta
Työtä varten valittiin 17 Uoma Oy:n toteuttamaa sivustoa. Sivustot valittiin niissä käytetyn ohjelmointitekniikan perusteella. Esimerkiksi yrityksen tekemiä Flex- sovelluksia ei otettu tutkittavien sivustojen joukkoon niissä käytettyjen HTML- pohjaisten komponenttien vähyyden vuoksi. Kullakin sivustolla oli analysoitavaksi muutamasta sivusta kymmeniin sivuihin. Kunkin sivuston osalta tutkittiin rautalankamallit, tehdyt taittotiedostot ja toteutetun kokonaisuuden sivut valmiilta sivustolta. Kaikille sivustoille ei ole tehty rautalankamalleja, ja osa sovelluksista on taitettu suoraan lopulliseen muotoon, tai taittotiedostoja ei ollut saatavilla. Projektin alussa käytettyjä käsin piirrettyjä hahmotelmia ei ollut käytettävissä analyysissä.
Eri sivustojen komponenttien toiminta ja ulkoasu erosivat huomattavasti toisistaan. Tämän oletettiin johtuvan sivustojen toteutusvaiheessa puuttuneesta
ohjeistuksesta, sekä puuttuvasta komponenttikirjastosta. Sivustoja analysoitaessa hyväksyttiin samaksi komponentiksi samaa toiminnallisuutta käsittelevät komponentit.
3.1.1 Komponenttien tunnistaminen ja kirjaus
Kuten taulukosta 2 näkee, analyysin pohjalta löytyi yhteensä 126 erilaista mallia.
Analyysia tehtäessä huomattiin joitakin puutteita welie.comin listauksessa ja listaa täydennettiin puuttuvilta osin lisäten näin mallien joukkoon 17 omaa toiminnallisuutta. Liitteen A mukaisesti listatuista 126 toiminnallisuudesta arvioitiin mahdollisiksi komponenteiksi 96 kpl. Jäljelle jäävät 30 toiminnallisuutta tai vuorovaikutusmallia arvioitiin liian projektikohtaisiksi tai abstrakteiksi, jotta ne toimisivat komponentteina (esim. ”kotisivu”, ”lomake” ja ”tutoriaali”).
Taulukko 2. Sivustojen analyysissa löydetyt mallit
Löydetyt 96 komponenttia analysoitiin tarkemmin ja näistä 13:n hyödyllisyys komponentteina koettiin kyseenalaiseksi (esim. ”apusivu”, ”vaihtuva rivien väritys” ja ”kaupan paikannin”). Jäljelle jäävistä 83 mallista 14:ää ei tunnistettu esiintyvän tutkituilla sivustoilla (esim. ”ikonipohjainen navigaatio”, ”ohjevelho”
ja ”piilotettava navigaatio”). Näin päädyttiin potentiaalisten komponenttien määrässä lukuun 69, kuten taulukko 3 havainnollistaa.
Taulukko 3. Toteutettavien komponenttien rajaus
Pohjana käytettyjä malleja 109
Lisättyjä uusia malleja 17
Projektikohtaiset mallit -30
Lopputulos 96
Malleista mahdollisesti toteutettavia komponentteja 96
Hyödyttömiksi arvioidut komponentit -13
Mallit, jotka eivät esiintyneet sivustoilla -14 Potentiaalisesti toteutettavat komponentit 69
Vaikka esiintymiskertojen laskeminen olisi kertonut tarkemman tiedon komponenttien käytöstä sivustojen suunnittelussa, ei tarkempaa laskentaa katsottu tarpeelliseksi sen vaatiman työmäärän takia. Projektien suunnittelutyössä on ollut vaiheita, joista ei ole jäänyt materiaalia, jota analyysissä olisi voitu käyttää.
Lisäksi, koska sivumäärä suunnitteluvaiheessa on huomattavasti pienempi kuin lopullisessa palvelussa, on komponenttien esiintymistä lopullisessa palvelussa hankala verrata sivuston suunnittelussa käytettyyn aikaan.
Kuten liitteestä A näkyy, yleisin komponentti oli ”Contact details” -malli eli
”yhteystiedot” -malli. Kaikista analysoiduista sivustoista kolmella oli käytetty hCard-mikroformaattia [Sto2009] koneellisen luettavuuden parantamiseksi
”yhteystiedot”-mallin yhteydessä. Analysoinnissa havaittiin kolmen palstan asettelu sivussa sijaitsevalla navigaatiolla olevan yleisin sivupohja. Vaikka sivun asettelu ei ole visuaalisesta ilmeestä selkeästi näkyvä komponentti voi sen kuitenkin koodissa mieltää sellaisena. Sivun asettelua voitaneen täten kuvailla komponentiksi, joka sisältää muita komponentteja ja sisältöä.
3.1.2 Sivustoja analysoitaessa löytyneet ongelmat
Sivustoja analysoitaessa huomattiin ongelmakohtia, jotka olisi voitu korjata pienellä vaivalla mikäli sivustoa kehitettäessä olisi ollut yhtenäinen prosessi ja tarkistuslista käytössä. Useat ongelmat vaikuttivat siltä, että kyseinen asia oli kiireessä unohtunut. Siksi diplomityön ohessa kerättiin yrityksessä toimivilta käyttöliittymäsuunnittelijoilta ja HTML-taittajilta muistilista hyvän sivuston kriteereistä [Liite B]. Tätä listaa käytettiin apuna komponentteja määriteltäessä ja toteutettaessa. Komponenttien toiminta osalla analysoiduista sivuista osoittautui muuttuneen virheelliseksi sivuston ikääntyessä. Esimerkiksi kappaleen 2.2.2 esimerkkinä esitelty sivutus oli joillakin sivuilla kasvanut useamman rivin pituiseksi, koska hakutulosten määrä oli kasvanut sivuston kasvaessa (kuva 6).
Kuva 6. Sivutuskomponentin rivittyminen useammalle riville.
Kun sivutuskomponentin toiminta määritellään kirjastossa ja sen toteutusta valvotaan, voidaan kyseinen ongelma ratkaista jatkossa esimerkiksi kuvan 7 esittämällä tavalla.
Kuva 7. Sivutuskomponentin kehittyneempi ulkoasu.
Molemmat sivutusesimerkit on poimittu analysoiduista sivustoista ja ne havainnollistavat komponenttien standardoinnin ja komponenttikirjaston tuomaa laadullista etua sivustoja kehitettäessä. Kuvan 6 sivutuskomponentissa esiintyvä ongelma on jäänyt huomaamatta kehitysvaiheessa, eikä sitä vielä ole korjattu vaikka sivusto on ollut käytössä jo vuosia. Mikäli komponenttikirjastoon kirjataan tällaiset huomiot jatkossa ja huomiot käydään läpi sivustoa toteutettaessa, niin mahdollisten virheiden määrän voidaan olettaa vähenevän. Kirjaston toteutuksen yhteydessä kerättiin liitteen B mukainen muistilista sivustojen teknistä toteutusta varten.
3.2 Diplomityössä toteutettavat komponentit
Työn yhtenä tavoitteena oli luoda tarvittava määrä komponentteja kirjaston perustamiseksi ja laajentaa kirjastoa myöhemmin asiakkaan maksaman työn ohella. Näin kirjasto kasvaa juuri niillä komponenteilla, jotka ovat tarpeellisia ja tulevat käyttöön. Työssä toteutettavat komponentit valittiin käyttämällä liitteen A tietoa komponenttien esiintymisestä eri projekteissa sekä tietämystä niiden riippuvuudesta toisiinsa. Kerättyjen tietojen avulla diplomityöhön valittiin liitteessä A esitetyt toteutettavissa olevat komponentit (vihreä valintamerkki), jotka esiintyivät tutkituilla sivustoilla (lkm vähintään 1).
Kirjaston komponentit luokiteltiin käyttäen apuna korttimenetelmää. Valittujen komponenttien nimet kirjoitettiin ylös korteille ja lajiteltiin loogisiin kokonaisuuksiin kunkin kirjastoa käyttävän henkilön toimesta. Eri jaotteluvaihtoehdoista neuvoteltiin ja lopputulokseksi muodostettiin taulukon 4 mukainen rakenne. Taulukon 4 mukaisesti rakenteen kaksi viimeistä osaa sisältävät yksittäisten komponenttien sijaan laajempia sivuston ominaisuuksia (esim. malli keskustelualueesta, jne.) ja ohjeita komponentteihin liittyen (esim.
hakukoneoptimointiin liittyvät ohjeet).
Taulukko 4. Komponenttien lajittelurakenne Päätaso Alataso
Components
Small Items Containers Forms Search Navigation Header Footer Skeletons
1 Column 2 Columns 3 Columns
4 Columns or more Features
Guides
3.3 Komponenttien toteutus
Koska kirjasto toimii pohjana kaikille yrityksen jatkossa toimittamille sivustoille, on kirjaston komponenttien laatu tärkeää heti ensimmäisestä projektista lähtien.
Siksi kirjaston komponentit pyrittiin toteuttamaan mahdollisimman hyvien koodauskäytäntöjen mukaisesti. Komponentit suunnataan kokeneille sivustojen koodaajille, joten kaikkea toiminnallisuutta ei tarvitse perustella komponentin yhteydessä.
Kuten aiemmin totesimme, on sivun sisällön hyvä semanttinen kuvaus tärkeää koneellista tulkintaa varten. Koneellisesti sisältöä saatetaan tulkita mm.
hakukoneen, puhesyntetisaattorin tai käyttäjän selaimen toimesta. Komponentteja laadittaessa määriteltiin HTML:n avulla mahdollisimman tarkasti, mitä kyseinen sisältö kuvaa. Saavutettavuutta pyrittiin parantamaan myös noudattamalla WAI- ARIA-suosituksia.
Komponentit toteutettiin siten, että niitä on helppo käyttää sekä rautalankoja tehdessä että taitettaessa sivustoa lopulliseen ulkoasuunsa. Pyrkimyksenä oli ilmaista sisältö mahdollisimman pienellä määrällä semanttisesti sopivia HTML- elementtejä, tarjoten kuitenkin tarpeeksi rakenteita CSS-vaihetta, eli taittoa, varten.
Komponenteille tehtiin kaksi, kuvassa 8 havainnollistettua, eri CSS-tyylitiedosto- versiota. Ensimmäistä on tarkoitus käyttää sivustoa suunnitellessa rautalankojen avulla. Se on tarkoituksella karun näköinen ulkoasultaan. Tämä rautalankatyylitiedosto pyrkii siten keskittämään huomion toiminnallisiin ja rakenteellisiin asioihin visuaalisten seikkojen sijaan. Toinen tyylitiedostoversio on graafisempi. Sen tarkoitus on toimia malliesimerkkinä lopullisesta ulkoasusta ja toimia lopullisen toteuttamisen koodimallina. Tämä jälkimmäinen tyylitiedosto palvelee myös testinä komponenttien joustavuudelle taittoon liittyvissä ongelmissa.
Kuva 8. Sama komponentti rautalankamallina ja ulkoasun mallina.
Diplomityötä tehdessä selvitettiin myös mahdollisuus käyttää HTML-kielen version viisi ominaisuuksia komponenteissa. Kävi ilmi, että suuri osa HTML5:n ominaisuuksista toimii hyvin taaksepäin yhteensopivasti ja on siten soveltuva komponenttikirjaston tarpeisiin. Siksi komponenttikirjasto toteutettiin käyttäen HTML5-suosituksen mukaisia elementtejä. Kirjasto käyttää myös CSS- teknologian kolmannen sukupolven (CSS3) ominaisuuksia niiltä osin, kun selaimet niitä tukevat. Näin modernien selainten tuomat uudet ominaisuudet
parantavat niitä käyttävien käyttäjien kokemusta, tarjoten kuitenkin toimivan sivuston vanhempia selaimia käyttäville. CSS3 tuo muun muassa animaatiot, pyöreät kulmat ja muita visuaalisia parannuksia käyttäjille.
Komponenttikirjaston oheen kirjoitettiin ohjeita, vinkkejä ja ohjenuoria tukemaan suunnittelu- ja taittotehtäviä. Ohjeet sisältävät linkkejä hyviksi havaittuihin lähteisiin, työkaluihin ja muihin työssä käytettäviin resursseihin. Lisäksi komponenttien oheen kirjoitettiin tarvittaessa muistisääntöjä ja sanallisia ohjeita niiden käytöstä. Komponenteista koostettiin myös mallisivuja yleisesti toistuvista sivustojen ominaisuuksista. Yksi tällainen ominaisuus on esimerkiksi yhteystiedot-sivu, kuten aiemmin tehdyssä sivustojen analysoinnissa huomattiin.
Mallisivut toimivat isompina kopioitavina kokonaisuuksina, joiden yksittäisiä komponentteja voi vaihtaa tarpeen mukaan sivustoa suunniteltaessa.
3.4 Komponenttien käyttötavat
Komponenteista rakennettiin HTML-sivuilla toimiva kirjasto, josta koodi on suoraan testattavissa ja kopioitavissa tarvittaviin paikkoihin. Kun komponentit toteutettiin sivurakenteeseen, voitiin dokumentaatio kirjoittaa suoraan komponenttien viereen, eikä erillisiä dokumentteja tarvitse ylläpitää. Kirjasto jaetaan eri käyttäjien välillä käyttäen yrityksen sisäistä versiohallintajärjestelmää.
Näin uudet versiot kirjastosta päivittyvät vaivattomasti versiohallinnan avulla eri kehittäjien välillä.
Yhtenä käytössä olevista koodin kehitystyökaluista Uoma Oy:lla on ollut Aptana- niminen laajennus Eclipse-työkalun päälle. Eclipse on java-pohjainen ohjelmistonkehitystyökalu useille ohjelmointikielille. Aptana tuo Eclipseen HTML-, CSS- ja JavaScript-kielille suunnattuja ominaisuuksia. Yksi Aptanan mukana tuleva ominaisuus on EclipseMonkey-niminen scriptikieli, jonka avulla kehittäjä voi ajaa editorissa JavaScriptillä kirjoittamiaan komentoja. Tämä on pääsääntöinen lähestymistapa koodikirjaston käyttöön. Editorin yhteydessä
käytetävän kirjaston dokumentaatio on HTML-sivuilla ja koodaaja löytää sieltä tarvitsemansa komponentin ja sen käyttöön liittyvät ohjeet. Suunnitellessaan sivuston rautalankamalleja käyttöliittymäsuunnittelija voi nappia painamalla tuoda tarvitsemansa komponentin kirjastosta lähdekoodiin. Ohjelmointikielenä JavaScript on HTML- ja JavaScript-kokonaisuuksia tekeville ihmisille tuttua ja siten muokattavissa tarpeen tullen. Eclipse-pohjaisesta kehitysalustasta on hyötyä myös koska yrityksen käyttämä Flex-kieli toteutetaan vastaavasti Eclipse- pohjaisella editorilla. Flex-kieli on Adobe Systems:in tarjoama ohjelmistokehityspaketti, jolla voidaan toteuttaa Flash-pohjaisia sovelluksia.
Kirjaston ensimmäisestä versiosta tulostettiin myös paperiversio tukemaan tilanteita, joissa kirjaston läpikäynti koneella ei ole mahdollista. Paperiversiota suunnitellaan käytettävän jatkossa myös mahdollisten paperiprototyyppien pohjana, jolloin kaikkea ei tarvitse piirtää käsin. Kirjaston pohjalta syntyvät rautalankamallit ovat kuitenkin suositeltu lähestymistapa, sillä niiden avulla ensimmäiset prototyypit sivustosta syntyvät oikeassa muodossa. Ennen taittoa voidaan rautalankamallien avulla toteuttaa jo toimivia prototyyppejä ja demoja asiakkaan tarpeisiin. Täten lopullista visuaalista ilmettä ei tarvitse lyödä lukkoon käyttäjätestien tekemistä varten, vaan lopullisen ulkoasun voi myöhemmin lisätä testattujen rautalankamallien päälle.
Uoma Oy:llä käytetään ns. ketteriä menetelmiä projektien toteutuksessa. Scrum on projektinhallinnan menetelmä, jota käytetään yleisesti ketterässä ohjelmistokehityksessä. Scrum-menetelmässä sivustoa tai sovellusta kehitetään lyhyissä pyrähdyksissä (eng. Sprint) verrattuna vesiputousmalliin [Sch2007].
Pyrähdyksen päätyttyä toimitetaan asiakkaalle potentiaalisesti toimiva versio sivustosta. Kahden viikon suunnittelu ja koodaus -pyrähdys asettaa tiukat tavoitteet käyttöliittymäsuunnittelulle ja HTML-taitolle, sillä pyrähdyksen päätyttyä toiminnallisuuden tulee olla myös valitulta osatoiminnallisuudeltaan valmis Scrum-mallin mukaisesti. Toiminnallisuuden toteuttava koodaaja voi katsoa komponenttikirjastosta mallikoodia jo heti hahmotteluvaiheen jälkeen,
vaikka rautalankamalleja ei olisi vielä ehditty toteuttaakaan. Näin komponenttikirjastosta on hyötyä muillekin kuin pelkästään käyttöliittymiä suunnitteleville ja taittaville henkilöille.
3.5 Komponenttikirjaston hyödyllisyys ja tehokkuus
Komponenttikirjaston hyödyllisyys selviää vertailemalla sen tuomia hyötyjä sen vaatimaan työn määrään. Hyödyistä hyvin mitattavaksi ja tärkeäksi koettiin kirjaston mahdollisesti tuoma tehokkuus. Vaikeammin mitattava hyöty on laadun paraneminen komponenttien uudelleenkäytettävyyden myötä. Laadun merkitykset heijastuvat Uoma Oy:llä jopa vuosien päähän, sillä toteutetut sivustot ovat tyypillisesti pitkään käytössä. Tämä komponenttikirjasto ei kuitenkaan ole yrityksen ainut toimenpide työtapojen tehostamisessa, joten laadun mittaaminen esimerkiksi takuutyön määrässä ei ole järkevää.
Kirjaston teettämä työ koostuu sen taustatyöhön kuluneesta ajasta, komponenttien ja ohjeiden kirjoittamisesta kirjastoon, kirjaston käyttöönotosta, käytön opettelusta ja ylläpidosta. Taustatyö sisältää tässä diplomityössä käsitellyn vanhojen sivustojen taustatutkimuksen lisäksi perehtymistä alan suosituksiin, WAI-ARIA:n kaltaisiin saavutettavuusohjeisiin, ja kokeellisiin komponenttiversioihin kuluneen ajan. Tällainen perehtyminen voidaan laskea myös hyödyksi yrityksen henkilöstön kouluttautumisena heidän työssään tarvitsemiin asioihin. Koska korkealaatuisten komponenttien kirjoittaminen kirjastoon vie aikaa, tässä työssä keskityttiin tutkitusti useimmilla sivustoilla toistuviin rakenteisiin. Ajatuksena on täydentää kirjastoa normaalin kehityksen yhteydessä siten, että asiakastyön yhteydessä kirjastoon lisätään uusia komponentteja, joita tulevissa projekteissa voidaan hyödyntää. Näin kirjaston komponenttimäärä kasvaa niillä osa-alueilla, joilla tarvetta on ja perustamiskustannukset pysyvät koko kirjaston kerralla kirjoittamista pienempinä.
3.5.1 Kirjaston luomiseen käytetty työmäärä
Kirjaston suunnittelua tehtiin muun työn ohessa kahden vuoden ajan. Suunnittelun tueksi etsittiin teoriamateriaalia luotettavista lähteistä tämän diplomityön alkuvaiheissa. Näin varmistettiin hyvän tieteellisen tavan lähestyminen kirjaston luontiin. Taustatyöhön kuului myös komponenttien käytön tutkiminen jo toteutetuilla sivuilla. Yhteensä taustatyötä arvioidaan tehdyksi noin 50 henkilötyöpäivän edestä.
Komponenttien toteuttamiseen ja ohjeiden kirjoittamiseen kului aikaa yllättävän paljon. Työtä tehdessä löytyi tarkkoja vaatimuksia komponenttien laadulle ja ne haluttiin toteuttaa mahdollisimman korkealla laadulla. Tulevathan ne muodostamaan laadukkaan pohjan työskentelylle kaikissa yrityksen projekteissa jatkossa. Ohjeita kirjoitettiin työn aikana vain vähäinen määrä, mutta niitä kertynee tarpeiden mukaan jatkossa lisää. Kirjaston käyttöönottoon varattiin kehittäjien kesken kaksi tuntia. Sen aikana asennettiin tarvittavat laajennukset editoreihin ja perehdyttiin kirjaston käyttämisen ohjeistukseen. Kirjaston opetteluun kuluvaa aikaa on vaikea arvioida, sillä se tapahtuu muun työn ohessa.
Kattavat perusteet opittiin kuitenkin jo käyttöönoton aikana, joten loppu opettelu lähinnä tehostaa kirjaston käyttöä. Kirjaston ylläpitoa suoritetaan muiden töiden ohella uusien tarpeiden ilmetessä. Toteuttamiseen ja käyttöönottoon arvioitiin kuluneen noin 25 henkilötyöpäivää.
3.5.2 Kirjaston tuoman tehokkuuden arviointi
Kirjaston tehokkuutta käyttöliittymäsuunnittelussa rautalankamallien apuna ja sivun taittoversion eli visuaalisen prototyypin luonnissa arvioitiin toteuttamalla malliprojekti. Malliprojektiksi valittiin tyypillinen esimerkki sivustoprojektista, joka toteutettiin hahmotelmien pohjalta kahdella eri tavalla. Tästä esimerkistä löytyi jo valmiiksi sekä hahmotelmat että kuvassa 9 näkyvä graafikon suunnittelema visuaalinen ilme sivustolle.
Kuva 9. Tehokkuuden mittaukseen käytetyn sivuston etusivu.
Ensin sivusto toteutettiin käyttäen vanhoja menetelmiä. Sivuston rautalankamalli tehtiin käyttöliittymäsuunnittelijan toimesta hänen valitsemallaan tavalla, joko piirtämällä tai koodaamalla se HTML-rautalankamalleiksi. Sitten sivusto taitettiin vanhoin menetelmin, eli kirjoittamalla käsin tarvittavat HTML-rakenteet ja CSS- pohjat. Apuna tässä käsin kirjoittamisessa käytettiin kirjastoa edeltäneen tavan mukaisesti vanhoista projekteista ja Internetistä löytyvistä ohjeista kopioituja HTML-koodin pätkiä. Nämä kopioidut koodin osat ovat usein puutteellisia tai eivät sovellu suoraan käytettäväksi projekteissa, vaan niitä korjaillaan ja testataan tarpeen mukaan.
Seuraavaksi sama sivusto toteutettiin käyttämällä luodun kirjaston komponentteja pohjana rautalankamallin tekemiseen. Komponentteja kopioitiin kirjaston mukana tuleviin sivuston mallipohjiin ja siten koostettiin tarvittavat rautalankamallit.
Näistä HTML-pohjaisista rautalankamalleista otettiin selaimella ruutukaappaukset dokumentteja varten. Sitten rautalankamallien päälle tehtiin haluttu ulkoasu käyttäen CSS-teknologiaa. Kirjaston ollessa vielä tuore, huomattiin kirjaston komponenteissa pieniä puutteita, jotka korjattiin kirjastoon ja levitettiin muille käyttäjille versiohallinnan kautta.
3.5.3 Hyödyllisyys
Mallisivuston rautalankamallien toteuttamiseen ilman kirjastoa kului vähän yli yhden henkilötyöpäivän verran. Vastaava toteutus syntyi kirjaston avulla hieman nopeammin, ajallista säästöä syntyi noin 32 %. Rautalankoja toteutettaessa huomattiin joitakin puutteita kirjaston komponenteissa ja niitä jouduttiin parantelemaan työn ohessa. Testin toistamista ei katsottu tarpeelliseksi, sillä jo näin huomattiin ajallisen säästön olevan merkittävä. Ensimmäisen sivun toteutus nopeutui jonkin verran, ja muiden sivujen toteutus nopeutui huomattavasti.
Mallisivuston prototyypin toteuttamiseen ilman kirjastoa, mutta rautalankamallien pohjalta, kului aikaa kaksi henkilötyöpäivää. Suurin aika toteuttamisessa kului ensimmäisen sivun visuaalisen ilmeen tekemiseen. Seuraavat sivut rakentuivat nopeammin, sillä taustatyö oli jo tehty. Kirjaston kanssa mallisivusto syntyi noin puolessatoista henkilötyöpäivässä. Ajalliseksi säästöksi taittovaiheessa muodostui 16 %.
Kirjaston tuomat hyödyt suunnittelussa ovat näiden tuloksien valossa ilmeisiä.
Tämä korostuu, kun ottaa huomioon, että kirjasto oli ensimmäistä kertaa käytössä käyttäjillä ja komponentteja muokattiin vielä tarpeisiin sopivammiksi. Kirjaston tuoman nopeusedun oletetaan kasvavan jatkossa kun käyttäjät tottuvat uuteen työskentelytapaan ja komponentit vakiintuvat osaksi normaaleja käytäntöjä.
Vertaillessa lopputuloksia ilman kirjastoa ja sen kanssa, huomattiin kirjaston avulla tuotetun materiaalin olevan laadultaan parempaa. Komponentit toimivat mahdollisissa ongelmatilanteissa ennalta arvattavammin ja saavutettavuus oli
huomattavasti paremmalla tasolla. Esimerkiksi WAI-ARIA saavutettavuuden ohjeistusta ei oltu otettu laisinkaan huomioon ilman kirjastoa toteutetussa ratkaisussa. Kirjastoa käyttäneet työntekijät antoivat positiivista palautetta kirjaston toimivuudesta, komponenttirakenteesta ja toiminnan selkeydestä.
Kritiikkiä tuli komponenttien hankalista nimistä, joihin etsittiin ratkaisua tarjoamalla vaihtoehtoisia nimiä komponenttien koodeille. Komponentit on nimetty niiden kategoriakoodin ja juoksevan numeroinnin avulla siten, että eri versiot voidaan tarvittaessa tunnistaa myöhemminkin.
Koska kirjaston luomiseen meni noin 75 henkilötyöpäivää, ja yhteenlaskettu hyöty kirjastosta rautalankamallien ja taittotiedostojen tekemisessä oli noin 23 % ajallinen säästö, voidaan laskea tarvittava aika luomiseen käytetyn ajan säästämisestä takaisin. Mikäli oletetaan että kirjaston tuoma hyöty ei parane yhtään tässä työssä tehdyn testin jälkeen ja yrityksessä työskentelee kolme henkilöä pelkästään näissä mitatuissa tehtävissä, on kirjaston luontiin käytetty aika kuitattu takaisin säästöinä 43 henkilötyöpäivässä eli kolmessa kalenteriviikossa.
3.6 Komponenttikirjaston tulevaisuus
Koska tehokkuudesta saadut tulokset olivat positiivisia, päädyttiin ottamaan kirjasto käyttöön Uoma Oy:n prosesseissa. Kirjastoa kehitetään jatkossa muun työn ohessa, ja olemassa olevia komponentteja korjataan ja päivitetään tarvittaessa. Kirjastoon lisätään ohjeita komponenttien käyttöön, mikäli kysymyksiä tai ongelmia tulee vastaan sen käytön aikana.
Kirjasto on herättänyt positiivista keskustelua myös muiden kehittäjien keskuudessa yrityksessä. Kirjaston toimintaa luultavasti jatkossa laajennetaan myös käyttöliittymäsuunnittelun ja prototyyppien luonnin ulkopuolelle.
Kirjastosta on esimerkiksi suunnitteilla Tridion-nimiseen sisällönhallintajärjestelmään kirjoitettu versio. Samat komponentit, jotka ovat
käytössä rautalankamallien pohjana ja sivuston taitossa, toimivat Tridionin komponenttiajattelua myötäilevästi jo itsessään. Luomalla komponentteja hyödyntävät toiminnallisuudet valmiiksi, tehostuu oletettavasti myös tälle sisällönhallintajärjestelmälle luotujen toiminnallisuuksien tuottaminen. Kirjaston käyttöä myös muiden sisältöhallintajärjestelmien kanssa tutkitaan jatkossa.
Koska kirjasto on rakennettu HTML5-ehdotuksen mukaisella teknologialla, on se yhteensopiva tulevien HTML-rakenteiden kanssa. Kirjaston komponentit käyttävät CSS-kielen kolmannen version (CSS3) ominaisuuksia niiltä osin, kun selaimet tukevat niitä. Kun selaimien tuki kehittyy, paranee myös komponenteilla toteutettujen sivustojen käyttökokemus. Mikäli tekniikka kehittyy suuntaan, joka ei ole kirjaston luomishetkellä nähtävissä, voi kirjaston nykyisellä versiolla toteutettavat komponentit korvata tarvittaessa uusilla helpommin, kuin vakioimattomat komponentit.
Yrityksen käyttämät vaihtoehdot HTML-pohjaisille sivuille ja palveluille, kuten korkeamman tason Flex ja SilverLight omaavat omat kirjastonsa ja menetelmänsä käyttöliittymien suunnitteluun ja prototyyppien luontiin. Koska yksi kirjaston käyttötavoista on Eclipse-pohjaisen editorin avulla sivujen muokkaus, on kirjasto siten lähellä näitä lähestymistapoja. Kirjasto tuo HTML-kehityksen vastaavalle tasolle näiden kahden tekniikan kanssa.
