Johdanto                 Tiivistelmä       Tutkimusmenetelmät
1. Web-käytettävyys      2. Web-tuotanto   3. CASE-kuvaukset
4. Heuristinen arviointi 5. Raatiarviointi 6. Yhteenveto
7. Käytettävyyden tila   Lähteet           Liitteet

6. Yhteenveto

Palveluiden erilaisuudesta ja erikokoisista resursseista huolimatta niistä voidaan tehdä joitain yleistyksiä:
  • tarkka resurssointi on ennakkoon vaikeaa
  • tavoitteiden kirjaaminen ja seuraaminen on oleellista
  • kartoitus ja suunnittelupanokset näkyvät positiivisesti palvelussa
  • eri kohderyhmien huomiointi on vielä alullaan
  • webin käyttömahdollisuuksien hyödyntäminen on vielä alullaan
  • ylläpidon ja päivityksen automatisointi parantaa käytettävyyttä
  • käyttäjäpalautteen hyödyntäminen auttaa palvelun parantamisessa
  • ylläpidon hajauttaminen vaikeuttaa yhtenäisyyden luomista
  • palvelun uusiminen luo helposti käsitteellisesti sekavan liittymän
  • käyttöliittymämetaforan rajoitteet voivat heikentää käytettävyyttä

Näillä on puolestaan joitain ilmeisiä ja toisia vähemmän ilmeisiä vaikutuksia rakennettavan palvelun käytettävyyteen, joita pyrimme purkamaan alla.

6.1. Resurssointi ja tavoitteet epätasapainossa

Kukin palvelu oli luonteeltaan pilotti. Verkkoliitteessä ja Tilastokeskuksessa ei ollut aiempaa kokemusta web-palvelun tuottamisesta, Virtuaalivirtahevon konsepti oli uusi. Kaikissa tuotannoissa tilaaja ja toteuttajat olivat pääosin samasta yhtiöstä tai yhteisöstä (in- house). Tuotannoissa ei käytetty eri osa-alueisiin erikoistuneita alihankkijoita (vrt. Ruokonen & Väänänen 1998), minkä vuoksi tuotantoryhmien piti itse luoda ratkaisut kuhunkin käytettävyyden ja tuotantoprosessin vaiheiden osa- alueeseen. Syinä suureen omaan tuotantoon ei välttämättä olleet pelkät resurssit vaan myös tuotantoryhmien halua oppia ja soveltaa uutta.

Kaikki tuotantoryhmät olivat aliarvioineet tuotantoresurssien tarpeen ja yliarvioineet ideoiden toteutettavuuden eli kuinka paljon aikaa ja työvoimaa kuluu, jolla yksittäinen idea olisi yhteensopiva keskeisimmillä selaimilla ja niiden eri versioilla. Kaikissa ryhmissä oli ideoita, joita kokeiltiin, mutta hylättiin niiden työläyden vuoksi. Samoin toteutuneiden ideoiden työmäärä ylittyi odotetusta. Eli osa tavoitteista jäi toteutumatta ja nekin tavoitteet, jotka toteutuivat, tarvitsivat ajateltua enemmän resursseja.

Yksikään tuotantoryhmä ei tutkituttanut koko konseptin ja kohderyhmän suhdetta ulkopuolisella vaan ne oletettiin toimiviksi lähtökohdiksi, jolle koko prosessi perustuu. Verkkoliite teki ennen julkistusta markkinatutkimuksen, mutta ei konseptista vaan sen toteutukseksta. Virtuaalivirtahevosta todettiin kartoitusvaiheessa, että vastaavaa palvelua ei ollut markkinoilla, mutta yleisesti tavoitteita ohjasi ajatus, että tuottajalla pitää olla web-palvelu, koska muillakin on.

6.2. Kartoitus ja suunnittelu aliarvioitu

Web-projekti voidaan toteuttaa löyhällä projektimallilla ja prosessin eri vaiheissa edetä rinnakkain. Kaikki kolme tapausta kuitenkin osoittivat, että jos kartoitus- ja suunnitteluvaiheisiin olisi käytetty enemmän aikaa, niin lopputulos olisi ollut parempi käytettävyyden näkökulmasta.

HS:n Verkkoliite oli - ehkä resurssiensa myötä - kokonaiskäytettävyydeltään onnistunein ilman suunnitelmallisuutta, mutta tutkimuksessa ilmeni voimakasta kritiikkiä itse palvelun konseptin suhteen. Vaikka palvelua pidettiin käytettävyydeltään tutkittujen parhaana, niin sille ei ylipäänsä nähty käyttötarpeita (paperiversion vuoksi) ja sen hankintatapaa toivottiin kokonaan toiseksi (erillisenä paperiversiosta).

Ihmemaan Virtahevon prosessi olisi voinut olla jäsennellympi ja suunnitelmallisempi, mutta prosessiin vaikutti keskeisesti sen epävirallinen luonne ja työskentely oman toimen ohella. Tuotantoryhmän jäsenet totesivat, että prosessin aikana tehdyt päätökset alkoivat vaikuttaa myöhemmin tehtäviin valintoihin, jolloin prosessi alkoi osittain ohjata itseään.

Lopputuloksena on aikuisen näkökulmasta epäyhtenäinen, vaikeasti käytettävä kokonaisuus. Toisaalta prosessissa onnistuttiin löytämään kohderyhmän kannalta olennainen: lapsille ja nuorille elämyksiä synnyttävä palvelu. Lapsien käytettävyys- käsitys on huomattavasti erilainen kuin aikuisilla, eikä Virtahepoon voi soveltaa suoraan samoja kriteereitä kuin muihin tutkittuihin palveluihin.

Tilastokeskuksen palvelussa ei ole yhtenäistä käyttöliittymää tai ulkoasua vaan niitä on useita. Aineistoa on valtavasti, mutta sitä on hankala löytää. Organisaation johdon tuella ja virallisemmalla luonteella tuotantoryhmä olisi voinut paneutua paremmin myös rakenteeseen, käyttöliittymään ja ulkoasuun. Sen sijaan prosessin resursseja käytettiin ensisijaisesti tiedontuottamisen olosuhteiden automatisointiin ja integroimiseen, jotta yli sata tiedontuottajaa voisi siirtää aineistojansa palveluihin.

Toisaalta kukin tuotantoryhmä itsekin tiedosti lopputuloksen ja käytettävyydessä ilmenneitä puutteita korjataan jatkuvasti.

6.3. Lisäkoulutuksen tarve ilmeinen

Kukin prosessi oli yhtäläinen myös koulutuksen ja tausta-aineiston suhteen. Käyttöliittymien ja osin itse palveluiden idea oli hankittu vertailemalla olemassa olevia palveluita ja niiden käyttöliittymiä. Laajasti ajateltuna tämä johtaisi siihen, että kaikkien web-palveluiden käyttöliittymät olisivat toistensa epäsuoria kopioita.

Yksikään tuotantoryhmä ei maininnut hankkineensa erityisesti web-koulutusta hanketta varten tai sen aikana eikä ryhmissä ollut uusmedia-tutkintoja suorittaneita. Eri osa-alueissa edettiin kokeilemalla ja luottamalla omaan vaistoon. Alan tutkimuksia tai oppikirjoja ei hyödynnetty. Lopulliset valinnat käytettävyyden eri osa-alueilla on tehty pääosin sillä perusteella, että ne ovat näyttäneet tai tuntuneet luontevilta tai mielekkäiltä. Tässä suhteessa Verkkoliite on onnistunut muun muassa sijoittamalla kevyesti latautuvan päänavigoinnin jokaisen sivun oikeaan reunaan ja alanavigoinnin ylä- ja alareunaan. Yhtenäisyys käyttöliittymässä ja sisällön nostaminen alkamaan vasemmasta reunasta eivät ole ilmiselviä ratkaisuja.

Jokaisessa projektissa jätettiin vähälle huomiolle suunnittelun ja tuotannon osa-alueet, joita ei hallittu. Tämä on luonnollista, mutta helposti korjattavissa minimikoulutuksella, joka auttaa havainnoimaan erityisosaamisen tarpeen tilannekohtaisesti: web-palvelun tuotannossa ei ole välttämätöntä hallita kaikkia oleellisia osa-alueita, mutta niiden olemassaolo ja tärkeys täytyy tunnistaa

Sekä kartoitus että käyttöliittymäsuunnittelu jäivät projekteissa vähäiselle painoarvolle, koska ne korvattiin pääosin lainaamalla muiden tuottamia ratkaisuja ilman arviointia ratkaisujen soveltuvuudesta. Käyttöliittymäsuunnittelu sekoitettiin myös usein graafiseen suunnitteluun, eikä sitä osattu erottaa omaksi erityisosaamista vaativaksi alueekseen. Tästä johtuen erityisesti palveluiden vuorovaikutuksessa on parannettavaa, vaikka visuaalinen ulkoasu olisikin kohdallaan.

6.4. Kohderyhmien huomiointi epätasaista

Kukin palvelu huomioi omat kohderyhmänsä hyvin ulkoasun ja sisällön suhteen. Mutta palveluiden navigointi ei juuri huomioi erilaisia käyttäjäryhmiä ja käyttötapoja. Tämä johtuu osin tuotantoprosessista, osin resursseista ja osin alan tutkimusten vähäisestä hyödyntämisestä.

Koska käytettävyydessäkin olisi kussakin palvelussa kehitettävää, niin lopputuloksena on - Verkkoliitettä lukuun ottamatta - että palvelu ei oikein palvele mitään ryhmää. Verkkoliitteenkin kohderyhmänä on sinänsä hyvin heterogeeninen paperiversion lukijat. Kohderyhmän hahmottumattomuuden merkitystä on vaikea mitata, mutta oletettavasti palveluilla olisi enemmän käyttäjiä, jos käytettävyys olisi parempi ja jos palvelut lisäksi huomioisivat eri käyttötapoja.

Kohderyhmien jakamisessa ja näiden tarpeiden palvelemisessa oli myös huomattavaa, että tuotannoissa ei tehty kovin selkeitä jakoja erilaisiin kohderyhmiin tai tarpeisiin. Tästä johtuen palveluita ei selkeästi suunniteltu hyödyntämään mitään tiettyä tarvetta tietyllä tavalla, vaan kukin palvelu pyrkii oman sisältötarjontansa puitteissa tarjoamaan mahdollisimman paljon kaikenlaista sisältöä, keskittymättä mihinkään tarpeeseen. Kohderyhmä- ja tarveanalyysien puutteellisuuden takia palveluita ei myöskään ole hiottu selkeästi käytöstä saatujen tietojen perusteella paremmiksi, joskin joitain muutoksia on toteutettu käyttäjäpalautteen perusteella.

6.5. Webin mahdollisuuksien hyödyntäminen alussa

Kukin palvelu hyödyntää webin lisäarvoja ja on siksi perusteltu web-muodossa. Tämä on sinänsä perustavanlaatuinen kysymys, joka näyttää jääneen monelta pohtimatta yleisessä web-huumassa. Mitä lisäarvoa webiin siirtyminen ylipäänsä tuo ja onko sinne välttämätöntä siirtyä vain siksi, että muutkin siirtyvät?

Verkkoliite tarjoaa todellisen vaihtoehdon printtimedialle sekä hakupohjaisen arkiston, Tilastokeskus tosiaikaisesti päivitettävän massiivisen tietoaineiston ja Virtuaalivirtahepo vuorovaikutteisen ja reaaliaikaisen virtuaalilemmikin.

Vaikka osaa tuotantoryhmien ideoista ei voitukaan toteuttaa, niin siitä huolimatta kuhunkin palveluun voitaisiin lisätä enemmän webiä hyödyntäviä piirteitä, jotka poikkeisivat perinteisestä julkaisuajattelusta. Yleisesti voisi todeta, että web-sivujen ajatteleminen ja työstäminen omana mediana, eikä esimerkiksi painotuotteen korvikkeena, tuottaisi potentiaalisesti käytettävämpiä ratkaisuja. Ainakin tällöin palveluiden vuorovaikutuksellinen ulottuvuus pitäisi paremmin hyödynnettyä.

Käyttäjien omaa tietämystä voitaisiin hyödyntää paremmin tarjoamalla osallistumismahdollisuuksia keskustelufoorumeista yhteisöagentteihin. Virtuaalivirtahevossa on keskustelualueet, mutta esimerkiksi käyttäjien omat virtuaalivirtahevot eivät reagoi mitenkään toisiinsa. Nyt palveluiden sisältö tuotetaan edelleen pitkälti perinteisen joukkoviestinnän tavoin.

Monet web-palvelut (kuten Amazon, Firefly, Internet Movie Database, Viinitupa) ovat osoittaneet, että käyttäjien mielipiteillä on todellista lisäarvoa sekä itse palvelulle että muille käyttäjille. Käyttäjämielipiteet auttavat yksittäistä käyttäjää esivalinnoissa ja vertailuissa. Yksinkertaisimmillaan käyttäjät voivat äänestää esimerkiksi elokuva- tai kirjauutuuksista keskiarvon.

Käyttäjän profiilia voitaisiin hyödyntää ja rakentaa personoituja sivuja. Yksinkertaisimmillaan tämä voitaisiin toteuttaa automatisoidulla sähköpostilla, joka sisältäisi uutuustiedotteita (palveluun tullut uusi aineisto) käyttäjän profiiliin perustuen. Luonnollisesti tämä edellyttäisi edes jonkinlaisen kohderyhmäjaon ja tarveanalyysin tekemistä.

Pisimmilleen vietynä käyttäjät voivat etsiä samanhenkisiä ihmisiä yhteisöagenteilla, jotka vertailevat käyttäjien profiileja toisiinsa. Perinteisestä käytettävyysnäkökulmasta nämä ovat sovelluksen toiminnallisuuden, eivätkä suoraan käytettävyyden parantamista. On kuitenkin ilmeistä, että web- sovellusten mahdollisuuksien parempi hyödyntäminen vaikuttaa käyttäjän kokonaiskokemukseen siinä missä käytettävyysparannuksetkin.

6.6. Automatisointi vaikuttaa käytettävyyteen

Kaikkien tutkittujen palvelujen osatavoitteena oli toimituksellisen tai tuotannollisen prosessin automatisointiasteen parantaminen hankkeen myötä. Kukin palvelu tuotti joitain toivottuja automatisointeja, mutta yleisesti ottaen automatisoinnin tavoitteet olivat toteutumaa suurempia. Automatisointi sisällön tuotannossa paransi yleensä käytettävyyttä palvelun ylläpidossa ja automatisoinnin luoma yhtenäisyys voisi parantaa myös peruskäyttäjän kokemaa käytettävyyttä.

Automatisointia ei tutkittu erikseen, mutta haastattelujen perusteella se osoittautui huomattavasti oletettua hankalammaksi. Itse automatisointi ei kuitenkaan ollut oletettua hankalampaa, vaan hankalaa oli olemassa olevien tuotantoprosessien ja automatisoinnin välinen tiedonsiirto.

Jotta web-palvelusta ja ohjelmallisesta automaatiosta saataisiin kaikki hyöty, niin olemassa olevia tuotantoprosesseja pitäisi kehittää ensin järkeviksi ja sitten Internet-sovellukseen sopiviksi. Luonnollisesti prosessin pitäisi vaikuttaa pääosin palvelun rakenteeseen eikä päinvastoin, mutta myös prosessissa kannattaa huomioida rakennettavan palvelun ja etenkin sen käytön aikaansaamat muutospaineet. Toimenpiteet alkavat tietovarannon ja sisällön tuottamisesta: esimerkiksi teksti- ja taulukko dokumentit pitäisi tallentaa sellaisessa muodossa, että ne ovat automaattisesti muutettavissa joko suoraan tai myöhemmin HTML- muotoisiksi. Dokumentteihin pitäisi jo luontivaiheessa määritellä esimerkiksi metatieto ja avainsanat sekä linkit liitetiedostoihin.

Laajemmin katsottuna tieto pitäisi eriyttää riittävän hyvin ulkoasusta ja osittain rakenteesta sekä täydentää metatiedolla. Käytännössä tämä tarkoittaa sisältötuotantoprosessin vaiheistamista niin, että varsinaisen sisällön tuotannon jälkeen suoritetaan vielä metatiedon lisääminen, soveltaminen valittuun ulkoasuformaattiin ja rakenteeseen. Sovellustasolla tämä on kuitenkin mahdollista vasta kun HTML, XML ja CSS-määritykset vakiintuvat. Pisimmilleen vietynä organisaation työntekijät eivät enää käyttäisi toimistotyössä perinteisiä tietokoneohjelmia vaan intranet-palvelimen lomakkeita, joissa data tallennetaan lomakekenttiin ja palvelin generoisi esimerkiksi tulostukseen tarvittavan ulkoasun ja tyylimäärittelyt.

Tutkituista palveluista edistyneimmän automaation kehitti Virtahepo, jossa ainoastaan käyttäjäpalaute tarvitsee ihmistyövoimaa. Tilastokeskuksen tuotantoryhmä kertoi muuttaneensa olemassa olevia tuotantoprosesseja yhteensopivimmiksi automaatiohankkeiden kannalta.

6.7. Käyttäjäpalautteen käsittelyssä kehitettävää

Kaikki tutkitut palvelut osoittivat, että käyttäjäpalaute on webissä yleisempää kuin muussa mediassa. Vaikutusta on palautteen antamisen helppoudella ja kohdentumisella suoraan oikealle henkilölle. Palveluiden ylläpito myös reagoi annettuun palautteeseen ja korjausehdotuksiin. Joissain tapauksissa käyttäjiltä tuli myös suoraan omaksuttavia käytettävyyden parannusehdotuksia.

Palveluiden kohdalla oli kuitenkin yleistä, että palautteen määrä aliarvioitiin karkeasti, eikä sen käsittelemiselle ollut ennalta määriteltyjä ohjeita. Tästä johtuen palautteen saaminen saattaa kestää epäinhimillisen pitkään tai jäädä kokonaan saamatta. Käyttäjän kannalta olisi tärkeää tietää ainakin, että palauta on vastaanotettu ja luettu, vaikka mitään henkilökohtaista vastausta ei palautteeseen lähetettäisikään. Palvelun kokonaiskäytettävyyden kannalta on tärkeää ymmärtää, ettei käytettävyys eikä etenkään käyttökokemus lopu sivujen selaamiseen, vaan jatkuu myös palautekanavien puolelle. Yksikään palveluista ei käyttänyt palautteen käsittelyyn tarkoitettuja automatisointiohjelmistoja.

6.8. Ylläpidon hajauttaminen ongelmallista

Useimpien palveluiden varsinainen työprosessi alkaa vasta palvelun julkistamisen jälkeen, kun palvelun ylläpito ja sisällön tuottaminen alkaa pyörimään tasaisesti. Isommissa organisaatioissa (tässä Helsingin Sanomat ja Tilastokeskus) sisällön tuotanto on usein hajautettua eri osastoille ja tekijöille, mikä puolestaan nostaa hyvän tuotannon organisoinnin merkitystä. Avainasemassa on myös eri työvaiheiden automatisointi, joskin se tulee suorittaa vasta kun varsinainen työvuo on muuten saatu kuntoon.

Tilastokeskuksen kohdalla sisältö tuotetaan hajautetusti eri tilastoyksiköissä ja kullakin sisältöosiolla on usein oma vastaavansa organisaation sisällä. Työvuon ja automatisoinnin keskeneräisyys on kuitenkin johtanut epäyhtenäiseen ulkoasuun sisältösivuilla ja erilaisten osioiden yhteen liittämisen ongelmiin. Vaikka verkkoliitteellä on jo lähtökohtaisesti täysin erilainen tuotantotiimi (enemmän tekijöitä, enemmän ihmisten suorittamaa valvontaa), ei sen sisällöllistä yhtenäisyyttä kannata väheksyä: esisovitus juttuformaatit, esitysrakenteet ja valmiit työpohjat (templates) auttavat tekemään suurestakin tietomassasta yhtenäisen ja käytettävyydeltään miellyttävämmän kokonaisuuden. Näiden reunaehtojen luonnissa on selkeästi hyödynnetty lehtiperinteen esitys- ja organisointitapoja, joiden puuttuminen näkyy puolestaan Klik- ja palvelu-osioiden epäyhtenäisyytenä ja suhteellisesti heikompana käytettävyytenä.

Vahvasti sisältöön nojaavien palveluiden käytettävyyden ja sisällön yhtenäisyyden kannalta onkin siis oleellista suunnitella hyvin myös sisällön tuotannon ja ylläpidon vaiheet huolellisesti. Erityisen tärkeää tämä on palveluissa, joissa varsinaiseen ylläpitoon ei ole varattu kuin minimimäärä henkilöresursseja (usein yksi web- ylläpitäjä) sisältötuotannon lisäksi. Epäyhtenäinen sisältö vaikeuttaa helposti sekä sisällön selaamista että eri sisältöosioiden välillä liikkumista, kuten käy ilmi palveluiden heuristisista arvioista. Sisältöpalveluiden kannattaakin harkita tuotantoprosessinsa osaksi ylläpidon ja sisältötuotannon suunnittelua ja testausta, joiden avulla voidaan varmistaa sisällön suurempi yhtenäisyys.

6.9. Palvelun uusiminen oma ongelmansa

Kaikkia tässä tutkimuksessa esiintyviä palveluita on uusittu niiden elinkaaren varrella vähintään kertaalleen. Uudistuksella tarkoitetaan tässä käyttöliittymän, ulkoasun tai rakenteen muuttamista muilta osin kuin vain sisältönsä puolesta. Palvelun uusiminen on hyvin yleistä web-palveluissa jopa alle vuoden väliajoin, kun tekijät oppivat aikaisemmista ratkaisuistaan ja teknologia tarjoaa uusia toteutusmahdollisuuksia. Palvelun uusimisprosessi kannattaa suunnitella siinä missä uusi toteutusideakin, sillä uusien ideoiden toteuttaminen suoraan vanhan päälle johtaa usein kerroksellisuuteen ja käsitteellisesti sekavaan käyttöliittymään.

Palveluista nuorin, Virtahepo, ei ole ehtinyt käymään läpi yhtäkään koko palvelua koskevaa uudistusta, vaan se on kasvanut orgaanisesti pala palalta nykymuotoonsa. Suunnittelematon kasvu voi kuitenkin helposti tuottaa joukon epäyhtenäisiä yhteen liitettyjä palveluosioita kokonaisen palvelun sijaan, kuten Virtahepo palvelusta näkyy. Uusien osien liittäminen jo toimivaan palveluun pitäisi tehdä harkiten, miettien sekä uuden palveluosion tuomia mahdollisuuksia että haittoja, etenkin jo muotoutuneiden käyttötapojen kannalta. Esimerkkinä mainittakoon Virtahevon sähköposti, joka on liitetty hyvin keinotekoisesti ja vain osittain palvelun muihin osioihin. Sähköpostiosion käyttö on tuonut palveluun myös uutta sekavuutta, koska sitä ei ole rakennettu kieleltään ja käytöltään yhtenäiseksi edes aikaisempien, toimivien osioiden kanssa.

Tilastokeskuksen palvelu on myös palvelun uusimisen kannalta mielenkiintoinen. Palvelun tekijät huomauttivat haastattelussa, kuinka sivustoista löytyy päällekkäin ikään kuin kolme eri kerrosta, eri uusintavaiheiden tuotoksina. Tämä näkyy web-sivuilla vaihtelevana navigointi- ja esitysrakenteena, joka ei ainakaan edesauta palvelun käytettävyyttä. Mielekäs ratkaisu palvelun uudistamisessa voikin olla lähteminen ulkoasullisesti tyhjältä pöydältä, säilyttäen kuitenkin jo palvelusta vakiintuneen rakenteellisen mielikuvan ja käyttötavan. Näin päästään helposti eroon aikaisempien ratkaisuiden manerismista, mutta voidaan tukea käyttäjien oppimia käyttötapoja. Tämänkaltainen lähestyminen voisi toimia myös Helsingin Sanomien verkkoliitteen kohdalla, jossa on myös nähtävissä käyttöliittymällistä kerroksellisuutta, etenkin palvelu- ja uutisosioiden välillä.

Palvelun uusimisessa on ensiarvoisen tärkeä muistaa jo saavutetun käyttäjäkunnan tapa käyttää palvelua. Mikäli tämä tapa muutetaan ilman helppoa tapaa omaksua uutta käyttötapaa, on seurauksena usein käytettävyyskatastrofi ja palvelun käyttö laskee dramaattisesti. Hyvä ratkaisu saattaa olla vaihtoehtoisen, tyhjältä pöydältä rakennetun navigointitavan rakentaminen entisen vierelle niin, että se voi hiljalleen korvata entisen. Siirtymäkaudet käyttöliittymätavasta toiseen ovat kuitenkin usein pitkiä, etenkin laajan käyttäjäjoukon palveluissa, joita hyödyntävät sekä rutiinien kautta oppivat aloittelevat käyttäjät että joustavat ammattikäyttäjät.

6.10. Käyttöliittymämetafora rajaa palvelua

Arvioidusta kolmesta palvelusta yksi, Verkkoliite, on pyrkinyt hyödyntämään metaforaa käyttöliittymässään. Metaforan perusajatuksena on tarjota käyttöliittymän toiminnasta käyttäjälle tuttu malli, kuten sanomalehti (Verkkoliite), jonka käyttö on ennestään tuttu. Metaforan käyttö ei kuitenkaan ole automaattisesti hyvä ratkaisu, vaikka se usein helpottaakin palvelun ensikäyttöä. Metaforan avulla voidaan usein tukea opitun siirtämistä aihealueelta toiselle, antamalla käyttäjälle valmis malli palvelun rakenteesta ja toiminnoista. Metafora voi kuitenkin helposti rajata käyttäjän mielikuvaa palvelusta väärin: käyttäjä voi olettaa palvelulta asioita, joita se ei sisällä tai jättää huomioimatta järjestelmän ominaisuuksia, joita metafora ei paljasta (Mohnkern, 1997).

Verkkoliitteen journalistinen sisältö on alunperin rakennettu päivälehden metaforan mukaan ns. verkkolehdeksi, joka noudattaa jopa päivälehden osastojakoa. Tämä on hyvä ratkaisu, mutta se rajoittaa käyttöliittymän toteutusta merkittävästi, koska päivälehden sivuilla ei voida toteuttaa verkkoliitteessä olevia dynaamisia palveluita. Tällöin joudutaan poikkeamaan metaforan sanelemasta käyttöliittymästä, mikä voi aiheuttaa sekaannusta sekä suunnittelijalle että käyttäjille: suunnittelija voi pyrkiä pakottamaan palvelun metaforan mukaiseen liittymään ja tehdä palvelun käytettävyydelle näin harmia. Käyttäjä joutuu puolestaan orientoitumaan palvelun epästandardeihin käyttöliittymiin uudestaan, mikäli metaforan mukaista toteutusta ei voida jatkaa. Ratkaisuiksi on usein tarjottu joko kahden metaforan (esim. lehti ja päivystystiski) yhdistämistä tai metaforan laajentamista sisältämään muita aihealueeseen kuuluvia käsitteitä (kuljetusauto, lehdenjakaja, jne.)

6.11. Skaalautuvuuden huomioiminen yksiulotteista

Tutkittuja palveluita pyrittiin kehittämään skaalautuviksi lähinnä niiden verkkopalvelimen osalta. Käytännössä tämä tarkoittaa, että kasvavaan kävijäkuormaan pyrittiin kyllä varautumaan, mutta ei niinkään käyttöympäristön, käyttötavan tai käyttöyhteyden muuttumiseen. Tästä johtuen palvelut eivät kaikilta osin skaalaudu kovin hyvin eri yhteysnopeuksille (kuten modeemeille), eri selaimille tai tarpeille. Skaalautuvuuden huomioiminen olikin kovin yksiulotteista, lähinnä palvelinskaalautuvuuden huomioimista.

Selainsoveltuvuudessa oli merkittävää, että yksikään palvelu ei ollut tehnyt selkeää käsitteellistä jakoa selainyhteensopivuuden ja palvelun koodin oikeellisuuden välillä. Tästä johtuen palveluiden skaalautuvuus eri selaimiin toteutettiin vaihtelevalla selaintestauksella, joka oli hajanaista: yleisimpiä käyttöjärjestelmiä tai selainversioita ei testattu järjestelmällisesti, vaan luotettiin pääosin palautteesta kerättyihin huomioihin. Tämä onkin yleinen tapa siirtää osa palvelun rakentamisesta, eli beeta-testausvaihe, palvelun julkistuksen jälkeen ensikäyttäjien tehtäväksi.

Selainyhteensopivuuden saavuttaminen joko testaamalla tai avoimella beeta-testauksella ei kuitenkaan takaa, että palvelu skaalautuu myös tuleviin selaimiin. Tämä johtuu nykyisten selaimien epästandardeista toteutuksista ja koodivirheiden huomiotta jättämisestä. Standardien siirtyessä kuitenkin yhä keskeisemmäksi web-sovellusten kehityksessä XML-määrityksen myötä, täytyy myös tulevien selainten lukea sivujen koodi tarkemmin. Tämä johtaa helposti sivuihin, jotka lakkaavat toimimasta tai eivät näy toivotulla tavalla selaimessa, kun uudet selaimet tulkitsevat koodin nykyisiä tarkemmin. Jotta palvelut skaalautuisivat tulevaisuudessa, olisikin tärkeeää eriyttää selaintestaus sovelluksen koodin (html, css, javascript, jne.) oikeellisuuden tarkistamisesta. Ainoastaan standardien mukaisen koodin suhteen voi olla varma, että sen avulla rakennetut sivut näkyvät ja toimivat oikein myös tulevaisuudessa.

Sisällysluettelo

5.4 Yhteenveto raatiarvioinnista        7. Web-käytettävyyden tila