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

3.1. Virtahevon tuotantokuvaus

Kaavio Virtahevon tuotantoprosessista

Ihmemaan Virtahepo on elämyksellinen web-palvelu, joka sisältää myös opetuksellisia osia. Palvelu koostuu mm. virtuaalihevosta (virtuaalilemmikki), sähköpostista, keskusteluryhmistä, aihehakemistosta (linkkikokoelma) sekä vaihtuvista kilpailuista ja käyttäjien tekemien tuotosten näyttelyistä. Kohderyhmänä ovat ensisijaisesti lapset, toissijaisesti myös verkon aloittelevat käyttäjät. Palvelu julkistettiin suunnilleen nykyisessä muodossaan vuonna 1998.

Ihmemaa-hakupalvelun ja tietokannan linkkejä ryhdyttiin ideoimaan kokoelmaksi keväällä 1997. Linkkihakemisto päätettiin suunnata lapsille ja aloitteleville web-käyttäjille. Syksyllä tiedusteltiin yritysten kiinnostusta palveluun ja sen sponsorointiin. Palveluun päivitettiin grafiikat, muutettiin sisältöä ja käyttöliittymä sekä lisättiin virtuaalivirtahepo helmikuussa 1998, jolloin uudistettu palvelu myös julkistettiin. Tämän jälkeen palveluun on lisätty uusia osioita ja sisältöä kuukausittain.

Tavoitteet

Virtahepo-palvelun alkutavoitteet lähtivät Ihmemaa- hakupalvelun aihehakemiston linkkien järjestämisestä ja päivittämisestä automaattisesti. Ensimmäinen tavoite oli siis työn automatisoiminen, jonka kautta huomattiin kuitenkin mahdollisuus uuden sisältöpalvelun tuottamiseen verkkoon.

Virtahevon tavoitteiksi asetettiin elämyksellisen ja viihteellisen Internet-palvelun luominen, käyttäen pohjaratkaisuna olemassa olevaa aihehakemistoa. Viihteellisen sisällön avulla haluttiin laskea Internetin käytön kynnystä etenkin lasten ja aloittelevien käyttäjien keskuudessa ja tarjota samalla mukava ja opettava kokemus Internetin käytöstä. Tekijöiden omana tavoitteena oli lisäksi kokeilla pystyykö Suomeen synnyttämään mielenkiintoisen ja tulevaisuudessa kaupallisesti kannattavan sisältöpalvelun lapsille. Luonteeltaan Virtahepo on siis pilottipalvelu, kuten muutkin tässä tutkitut palvelut.

Kartoitus

Palvelun idea syntyi keväällä 1997 ajatuksesta, kuinka linkkikokoelman ylläpito voitaisiin korvata automaattisella päivityksellä vähentäen siihen kuluvan työn määrää. Tarkoituksena oli tuottaa toimiva erillinen palvelu, joka rakentuisi linkeistä koostuvan aihehakemiston ympärille. Myöhemmin kohderyhmä ja idea tarkentuivat lapsille ja aloitteleville internet- käyttäjille suunnatuksi elämykselliseksi palveluksi, joka sisältää opetuksellista ja viihteellistä sisältöä.

Palvelun ideointivaiheessa ei tehty käyttäjäkartoitusta tarpeista tai potentiaalisista kohderyhmistä, joskin olemassa olevan linkkikokoelman palautekanavan avaamisen kautta käyttäjät antoivat aktiivisesti kehitysehdotuksia.

Virtahepo-projekti on luonteeltaan tekijöiden haluista, eikä analysoidusta markkinatilaisuudesta tai käyttäjätarpeesta, syntynyt palvelukokonaisuus. Se eteni alussa, kuten tällaiset tuotantoprosessit hyvin usein etenevät, ilman tiukkoja raameja tai tavoitteita. On mahdollista, että tämänkaltaista palvelua ei olisi edes syntynyt, ilman projektin osallistujien henkilökohtaisen mielenkiintoa ja panostusta. Projektin lunastettua paikkansa varteenotettavan sisältöpalveluna, on siihen kohdistetut paineet myös kasvaneet, minkä johdosta projekti onkin siirtymävaiheessa ad hoc -pohjaisesta projektimallista tarkemmin määritellyksi jatkuvaksi tuotantoprosessiksi.

Virtahevon projektin alkua kuvaa itse asiassa hyvin innostumisen ja huuman leimaama projekti, joka on ominaista uusilla verkkotuotteille alkuvaiheessa. Yleensä ideaa vetää yksi henkilö, muut ovat innostuneita ajatuksesta ja monet lupaavat tuottaa sisältöä palveluun. Alkuhuuman laannuttua, siirryttäessä päivittäiseen tuotekehitykseen ja sen jälkeen ylläpitoon, resurssit kuitenkin häviävät ja into hiipuu entisestään. Tämä ei suinkaan tarkoita, etteikö innostus olisi hyvä web-projektin alulle panija, vaan sen häviämisestä huolimatta täytyy projektien löytää keinot jatkaa. Usein siirtyminen kuvattuun ja yhdessä sovittuun tuotantoprosessiin on ainoa vaihtoehto palvelun jatkumiselle (Powell, 1998).

Projektiryhmän koostumus oli:
  • projektivetäjä
  • graafikko
  • ideointiin osallistuneita henkilöitä
  • ohjelmointi (toiminnallinen ohjelmointi ulkoistettu)

Ryhmässä kaikki tekivät hieman kaikkien töitä, eikä tarkkoja roolijakoja oltu edes tehty. Projekti eteni pitkälle jokaisen ihmisen käytettävissä olevan (vapaa-)ajan mukaan.

Suunnittelu

Virtahevon tuotantoprosessiin ja lopputulokseen vaikuttivat projektin epävirallisuus yhtiön hankkeena sekä tuotettavan palvelun kokeiluluontoisuus. Työryhmä olisi edennyt suunnitelmallisemmin kaikilla osa-alueilla, jos hanke olisi ollut virallistettu yhtiön sisällä ja resurssit sekä aikataulu olisivat olleet paremmat. Näistä syistä tuotantoryhmä ei ole tyytyväinen syntyneeseen laatuun.

Suunnittelupalavereihin käytettiin usein omaa aikaa kuten myös osaan toteutuksesta. Palvelua ryhdyttiin vain toteuttamaan ilman erityistä projektimallia tai -hallintaa. Vähitellen ideoiden kohdalla jouduttiin tekemään kompromisseja, jotka jäivät osaksi lopullista toteutusta.

Projektin prosessia voisi kuvata termillä "ad hoc", joka viittaa organisoinnin toteuttamiseen lennossa, ilman ohjaavia menetelmiä. Ad hoc -prosessi saattaa toimia hyvin pieniessä projekteissa, joissa myös toteuttava ryhmä on tiivis ja kooltaan pieni (Powell, 1998). Tämänkaltainen malli tuottaa kuitenkin yleensä tulokseksi dokumentoimattoman tuotteen, jonka suunnittelussa tehtyjen ratkaisujen logiikka jää usein ulkopuoliselta piiloon. Myös ohjelmakoodi on ad hoc -prosesseissa usein laadultaan heikkoa. Nämä molemmat seikat vaikeuttavat helposti tuotteen jatkokehittelyä ja uusien ihmisten ottamista mukaan prosessiin, ilman pidempää perehdyttämiskautta.

Ad hoc -malli on hyvin ominainen web-tuotteille, koska rakentamiseen tarkoitetut työkalut yleensä rohkaisevat kokeilemaan ja hyväksymään kokeilun viimeisteltynä tuotteena. Tässä mielessä web-tuotteistus muistuttaa jollain tavoin nopeaa ohjelmistokehitystä (RAD), joskin suunnittelu- ja testausvaiheiltaan lyhennettynä. Web-projektien kohdalla kuuleekin usein määritelmän "toteuta ja julkaise", jolla halutaan kuvat prosessin helppoutta: toteuta ideat ja julkaise ne verkkoon. Tämä verkon alkuvaiheista pesiytynyt malli ei kuitenkaan enää toimi aikana, jolloin yhä useammat palvelut kilpailevat samoista asiakkaista ja vain alusta saakka hyvin toimivat palvelut onnistuvat vetämään kävijät takaisin palveluun. Tämän takia käytettävyyteen panostaminen on noussut etenkin uusille palveluille onnistumisen ehdoksi. Käyttäjät eivät palaa helposti palveluun, jota on vaikea käyttää, jos tarjolla on muitakin palveluita.

Käyttöliittymäsuunnittelua ei eriytetty vaan se syntyi muun suunnittelun ohessa. Käyttöliittymän ideaksi otettiin muissa palveluissa toteutettu, standardinomainen liittymä. Päätavoitteena oli yksinkertaisuus ja helppo opittavuus lapsille. Perusajatus oli, että samankaltaisen käyttöliittymän avulla lapset ja erityisesti vasta-alkajat voisivat hyödyntää myös muita samankaltaisia palveluita.
Käyttöliittymän suunnittelusa on ainakin kaksi tilannetta, joissa suunnittelun puute voi kostautua palvelun käytettävyydessä: käyttöliittymän yksiulotteinen tulkinta ja valmiin käyttöliittymätoteutuksen lainaaminen. Käyttöliittymä nähdään usein kovin yksiulotteisesti vain visuaalisena pintana, joka voidaan liittää toiminnallisuuden päälle. Tämä jättää kuitenkin huomioimatta käyttöliittymän vuorovaikutuksellisen ulottuvuuden, joka pitkälti muodostaa käyttäjälle käytön tuntuman. Käyttöliittymäsuunnittelu ei siis ole sama kuin visuaalinen tai graafinen suunnittelu, joka pitäytyy useimmiten sivujen ulkoasussa, vaan se keskittyy myös sivujen ja eri osioiden käytön vuorovaikutukseen. Käyttöliittymän syntyminen esimerkiksi visuaalisen ilmeen sivutuotteena johtaakin helposti kokonaisuuteen, jossa vuorovaikutuksen osuus käytettävyydessä on jätetty huomioimatta.

Valmiin käyttöliittymämetaforan tai navigaatiomallin lainaaminen voi myös olla ongelmallista. Jos lainataan esimerkiksi muiden vastaavien palveluiden käyttöliittymää, on syytä varmistaa että myös näiden palveluiden toiminnot, rakenne, tavoitteet ja käyttäjien tarpeet ovat vastaavanlaisia. Tämän jälkeen lainattavaa mallia kannattaa toteuttaa johdonmukaisesti: jos päänavigointi laitetaan vasemmalle, on sen sijaittava siellä koko ajan, eikä vaihduttava toisinaan keskelle ja toisinaan alhaalle.

Kannattaa myös olla varovainen jos muutetaan jo muodostuneita käyttöliittymäkonventioita erilaisiksi pelkästään palvelun erottautumisen takia, koska käyttäjien konventiot voivat olla ristiriidassa uusien ratkaisujen kanssa. Onnistuessaan voi saman genren palvelusta siis lainata sopivan käyttöliittymämallin, kunhan se on oikeudenmukainen palvelun tavoitteiden kanssa ja sitä ei muuteta ristiriitaiseksi olemassa olevien käyttötapojen kanssa.

Sisältöä ei lähdetty eriyttämään eri kohderyhmille, vaan kaikille käyttäjille päätettiin tarjota samaa, mutta pääpaino oli lapsissa (etenkin grafiikan suhteen). Lasten vuoksi pidettiin tärkeänä, että opetuksellinen materiaali pitäisi kuin vaivihkaa muun viihdyttävän sisällön lomassa. Kohderyhmälle haluttiin saada aikaan hyvä olo ja piristää heitä, jolloin palveluun palattaisiin myöhemmin uudestaan.

Virtuaalivirtahevon idea oli luotu ennen kuin graafikko liittyi projektiin. Graafikko aloitti tutustumalla tamagotchiin (virtuaalilemmikki) hahmottaakseen paremmin Virtuaalihevon tavoitteen. Lemmikkiä ideoitiin eri palavereissa yhdessä hyvin vapaamuotoisesti.

Valmiin sisältöidean lainaamisen yhteydessä kannattaa harkita lainaako samalla myös valmiin käyttöliittymän. Suosittujen palveluiden kohdalla on usein järkevää lainata sekä idea että sen käytön perusmalli, koska nämä ovat tuttuja käyttäjille. Virtuaalilemmikin kohdalla tämä tarkoittaisi yksinkertaisesti Tamagotchi-lelun syöte/palalute-mallin pikaista analyysiä: milloin voit antaa syötteen lemmikille? Minkälaisen palautteen järjestelmä antaa siihen? Miten tämä vaikuttaa muihin näkyvissä oleviin lemmikin toimintoihin? Milloin järjestelmä on valmis ottamaan uuden syötteen vastaan?
Palvelun kokonaisilmettä lähdettiin tietoisesti suunnittelemaan lapsille: kirkkaat värit ja vähän epäsäännöllisiä muotoja. Kokonaisilmeessä pyrittiin iloisuuteen, tavoitteena kuitenkin välttää turhan räikeää ilmettä. Suunnitteluvaiheessa tärkeitä olivat leiskat, joita piirrettiin useita. Näitä käytettiin idean hahmottamiseen ja kommunikointiin ryhmän sisällä. Niiden käyttö koettiin erityisen hyödylliseksi asioiden konkretisoimisessa.

Toteutus

Graafikon suurin yksittäinen työvaihe oli Virtuaalihevon ja muiden visuaalisten elementtien piirtäminen käsin, siirtäminen koneelle ja animointi.

Graafikon työvälineinä olivat tussit, paperi, kynä, skanneri, Macintosh, Photoshop ja Gifbuilder. Kuvatiedostojen kompressointia ei ehditty testata optimikoon saavuttamiseksi. Mutta koko kuvasuunnittelu noudatti periaatteita, joilla pyrittiin kevyeen grafiikkaan eli pieniin tiedostokokoihin: yhtenäiset väripinnat, värien määrän vähentäminen, animaatioissa edellisten ruutujen muuttumattoman osan hyödyntäminen ja kuvan koon (ruudulla pikseleissä) pienentäminen. Graafikko olisi halunnut myös opiskella uutta työkalua (Flash) animaation tekemiseen, jos tuotantoaikataulu olisi sen sallinut.

Ammattimaisen työvoiman resurssien saaminen oli työlästä, koska yhtiön henkilökunta oli kiinni jo muissa projekteissa ja tuotettava palvelu oli kokeiluluontoinen. Virtuaalilemmikin koodi tilattiin talon ulkopuolelta Tshekistä, josta se saatiin edullisesti ja luotettavasti. Tilattuun työhön oltiin tyytyväisiä sekä prosessin, hinnan että lopputuloksen kannalta.

Palvelulla oli painolastina oli hajautuneisuus useisiin fyysisiin paikkoihin, useille eri palvelimille ja käyttöjärjestelmille. Tämä hankaloitti hieman ylläpitoa, mutta antoi mahdollisuuden käyttää eri palvelinalustoja (esim. Solaris, Linux, etc.) riippuen kunkin alustan erityisominaisuuksista. Sivujen kokoonpanoon käytettiin työkaluina Netscape Composer-ohjelmaa ja HTML-koodaustyökaluja.

Testaus

Yhtiössä testattiin palvelua sisäisesti muutaman viikon ajan ennen sen julkistamista. Palvelua testattiin yhtiön koneille valmiiksi asennetuilla selaimilla, mutta järjestelmällisesti selainsopivuutta ei testattu. Sisäisessä testauksessa virtuaalivirtahepo arvioitiin liian vaikeaksi käyttää. Virtahepo kuoli liian nopeasti ja sen käyttöä tehtiin helpommaksi.
Web-palveluiden testaaminen on työläs prosessi pitkälti käyttöympäristöjen, tarpeiden ja käyttäjien moninaisuuden vuoksi. Mitään web-palvelun käytön osaa ei voi kunnolla standardoida tai rajata, mistä johtuen testaamiseen voi helposti käyttää saman verran aikaa kuin palvelun rakentamiseen. Tämä ei kuitenkaan ole usein kaan mielekästä ja siksi web-testaus pitäisikin suunnitella, vaiheistaa ja priorisoida.

Testauksessa pitäisi keskittyä alkuperäisten (mahdollisesti tuotannossa muutettujen) tavoitteiden, käyttäjien ja heidän tarpeidensa kokonaisuuden testaaamiseen. Käytännössä tämä tarkoittaa kohdeyleisöllä tehtyjä testejä, joissa pyritään varmistamaan, että palvelun alkuperäiset tarpeet toteutuvat, käyttäjien tarpeet saadaan tyydytettyä ja palvelu on käytettävissä kohderyhmälle ominaisessa laitteisto-, ohjelmisto- ja käyttöympäristössä tyydyttävällä tavalla.

Testaamisessa kannattaakin ensin tehdä minimi- ja maksimiympäristöt, joista on määritelty selainversiot, käyttöjärjestelmät, laitteistokokoonpanot ja yhteydet. Tämän jälkeen käyttäjien pyydetään käyttämään palvelua niin kuin he sen kokevat ja ratkaisemaan sillä omia tarpeitaan. Testauksessa tehdyt havainnot täytyy vahvistaa ja ongelmiin täytyy kehittää ratkaisut, jotka täytyy puolestaan toteuttaa ja testata. Testaus onkin usein iteratiivinen prosessi, jossa testaus, havainnointi ja palvelun muuttaminen etenevät sykleissä useita kertoja eteenpäin.

Käyttäjätestauksen lisäksi palvelua voi testata helpommin myös sen toiminnallisuuden ja sisällön osalta. Toiminnallisuustestaus voi koostua eri selaimilla testaamisesta, linkkien oikeellisuuden tarkistamisesta ja kaikkien toimintojen varmistamisesta. Sisältötestaus puolestaan varmentaa grafiikan esityksen, kirjoitusten ja kieliopin oikeellisuuden. Usein nämä eri testaukset kannattaa hajauttaa eri tahoille, jolloin testaus on osittain päällekäistä ja samalla tarkempaa.

Testausvaiheessa päätettiin painottaa julkiseen beta- testaukseen. Palvelu julkistettiin siis tietoisesti ilman laajaa sisäistä testausta ja kerätyn palauteen perusteella korjattiin löydetyt viat.
Avoin beta-testaus on ongelmallinen, koska se edellyttää palvelun sisällön tai käytön olevan niin kiinnostavaa, että käyttäjä on valmis kokeilemaan keskeneräistä ja puutteellista palvelua. Erityisten suurten palveluiden kohdalla avoin beta-testaus voi olla erittäin tehokas testauksen muoto, mutta se edellyttää hyvin organisoituja palautekanavia, tehokasta virheiden paikallistamis- ja korjausrutiinia ja erillistä julkaisua varsinaiseen beta-vaiheen loputtua. Beta-vaiheessa on nimittäin helppo menettää potentiaalisten asiakkaiden luottamus, jättämällä heidän palaute huomioimatta tai korjaamalla palvelua epämääräisesti.
Yrityksen sisäisessä testauksessa ei saatu tuntumaa palvelun emotionaaliseen vaikutukseen tai ihmisten mielenkiintoon, koska yrityksen työntekijät eivät edustaneet kohderyhmää. Palvelun innostavuus tuli ilmi vasta sen julkistuksen jälkeen kohdeyleisön palautteen välityksellä.

Julkistus ja ylläpito

Palvelu julkistettiin lopputalvesta -98. Ennen tehtyjä sisältömuutoksia (virtuaalivirtahepo ja muut palvelut) Virtahepo-palvelusta ladattiin n. 10 000 sivua/päivä, muutoksen jälkeen 43 000 sivua/päivä (helmi- toukokuu 1998).

Palautteen määrä ja innostuneisuus oli tekijöille yllättävää, eikä negatiivista palautetta ollut lähes ollenkaan. Suurimmat ongelmat koskivat virtuaalivirtahevon käyttöä ja sen hengissä pitämistä, mitä muutettiin vielä kertaalleen julkistuksen jälkeen. Alussa palveluun lähetettyihin sähköpostikysymyksiin vastattiin käsin, mutta palautteen määrä kasvoi niin suureksi, että henkilökohtainen vastaaminen lopetettiin.

Palautteiden hallinta uupuu usein palvelun käytöstä. Pitkäikäisten palveluiden kohdalla palautteiden käsittely ja niihin reagoiminen (ei välttämättä vastaaminen) on kuitenkin palvelun hengissä pysymisen edellytys. Palautteen hyödyntämistä varten palvelussa pitäisi olla erikseen ilmoitettu palauteosoite ja mahdollisesti kaavake, jonka avulla voidaan saada strukturoidumpaa tietoa käyttäjien mielipiteistä. Saadun palautteen käsittely ja niihin reagoiminen tulee myös vastuuttaa organisaation sisällä. Järkevän työvuon rakentaminen ja mahdollisten aputyökalujen, kuten automatisoitujen vastausohjelmien, hankinta voi merkittävällä tavalle helpottaa palvelun ylläpidon käytettävyyttä.
Palautetta pääosin 11-14 v. lapsilta ja erityisesti tytöiltä. Alussa palaute oli enemmän avunpyyntöjä, mutta muuttui myöhemmin käsittelemään sisältöä ja antamaan mielipiteitä (parannusehdoutuksia, kehuja).

Palvelun kohderyhmiksi on seuloutunut laaja skaala eri- ikäisiä käyttäjiä (6-50 vuotta., keski-ikä 16 vuotta). Suurin osa käyttäjistä varhaisteinityttöjä, etenkin virtuaalilemmikin osalta. Aikuisten ensimmäiset kommentit palvelusta olivat: "mikä tässä on ideana?", kun taas lapset ottivat palvelun heti omakseen.

Hankkeen tavoite on selvästi toteutunut, sillä myös käytettävyys-tutkimuksen raati ja heuristiset analyysit kiinnittivät huomiota seikkoihin, joilla ei välttämättä ole kohderyhmälle merkitystä.
Ylläpidossa on tuotantoryhmän mielestä päästy alkuperäisen tavoitteen mukaiseen, hyvään automaatioon. Virtuaalivirtahepo ja postikortit päivittyvät tosiaikaisesti, linkit ajetaan eräajona kerran vuorokaudessa. Kirjoituskilpailu ja muu toimituksellinen aineisto päivitetään päivän - viikon välein. Tiedonhaku ei näyttele pääosaa palvelussa vaan käyttö on 75% kaikkea muuta (kuten virtuaalihepo, chat ja posti).

Palvelun yleistymisen ja suosion johdosta etenkin virtuaalilemmikkien tiedot (tietokanta) varmuuskopioidaan usein, koska kyseessä on palvelun kannalta kriittinen tieto.

Eniten ongelmia ilmeni web-postikorttien URL-osoitteiden kanssa, jotka taittuivat sähköpostissa riviltä toiselle pituutensa takia ja lakkasivat näin toimimasta.

Jatkokehitys

Tuotantoryhmä pohti muun muassa seuraavaa jatkokehitystä: Virtahevon toimintojen laajentaminen enemmän vuorovaikutteiseen tekemiseen, eikä vain napin painallukseen; palvelun käyttö web- opetustyökaluna, jolloin sinne voitaisiin myydä mainostilaa; sähköpostipalvelu (toteutunut); tosiaikaisen keskustelukanavat; Virtahepo-kauppa sekä mainonnan, opetuksen ja kaupan ominaisuuksien toteuttaminen..

Tuotantoryhmän arvioita käytettävyydestä

Palvelu nykymuodossaan ei tyydytä tuotantoprosessin jäseniä, vaan he kokevat sen tarvitsevan vahvaa panostusta rakenteen ja käytettävyyden parantamiseksi. Useat ongelmakohdat on jo tiedostettu, niiden korjaaminen vain on jäänyt resurssien puutteen takia.

Tuotantoryhmä koki palvelun avoimen beeta-testauksen olevan erityisen hyvä tapa löytää esimerkiksi selainten välisiä yhteensopivuusongelmia ja sisältöön liittyviä tarpeita. Kaikille palveluille tämä ei kuitenkaan sovi, mutta kokeilumuotoisille palveluille se saattaa olla hyvä ratkaisu, edellyttäen tietenkin, että palautteeseen kyetään reagoimaan riittävän lyhyellä viiveellä ja korjaamaan löytyneet ongelmakohdat.

Sisällysluettelo

3. Palveluiden tuotantokuvaukset        3.2 Tilastokeskuksen tuotantokuvaus