1.2. Web- palvelun suunnittelun erikoispiirteitä

• Vasteaikojen venyminen. Käyttäjä voi joutua odottamaan vastausta antamaansa syötteeseen, kuten hiiren klikkaukseen, joskus jopa useita kymmeniä sekunteja. Yleisesti vasteajat ovat verkkopalveluissa sekä pidempiä että satunnaisesti vaihtelevia perinteisiin ohjelmiin verrattuna. Jälkimmäisissä pyritään yleensä alle puolen sekunnin vasteaikoihin.
• web-palveluissa ei ole muotoutunut standardeja tai edes logiikkaa yleiseksi vuorovaikutusmalliksi. Sama käyttäjän antama syöte voi laukaista aivan erilaisia toimintoja kahdessa eri sovelluksessa.
• web-palvelun suunnittelija ei voi määrätä täysin tarkasti sivun ulkoasua ja näkymistä käyttäjän ikkunassa. Verkkopalveluiden skaalautuminen selaimesta toiseen edellyttää erityistä huomiota suunnittelussa.
• web-palveluiden käyttäjät voivat olla satunnaiskäyttäjiä tai muuten tietokoneohjelmien logiikkaan tottumattomia, minkä vuoksi palveluiden pitäisi olla erityisen helppoja käyttää myös ensikertalaisille.
• web-palvelut ja niiden hyperlinkit muodostavat laajan verkoston, jossa siirtyminen palvelusta toiseen tapahtuu usein huomaamatta. Tämä asettaa erityisvaatimuksia navigointi- ja etsintätyökaluille.

Yllä mainittujen erojen lisäksi web-palveluiden suunnittelussa on huomioitava yhä useammin myös seuraavia seikkoja:

• web-palvelu on usein rakenteellinen järjestelmä, joka sisältää useita sisäkkäisiä osioita, pienpalveluita ja toimintoja, ja joka sulautuu verkossa toisiin palveluihin. Siksi suunnittelussa pitäisi huomioida myös palvelukokonaisuuden käyttökokemus, eikä vain yksittäisten osien käyttöä toisistaan erillään.
• web-palvelun rakentamisen lähtökynnys on erittäin matala ja rakentaminen nopeaa. Siksi useita palveluita on rakennettu nopeasti, ilman testausta ja ilman erityistä huomiota käytettävyyteen. Suunnitteluvaiheessa palvelua ei pitäisikään verrata yleiseen (suomalaiseen) tasoon vaan parhaisiin toteutuksiin, jotta käytettävyyden merkityksestä ei tule vähäteltyä kuvaa.
• web-palvelun käyttöliittymiin on vakiintumassa piirteitä ja vertauskuvia muun muassa joukkoviestimistä (lehdet, televisio, kirjat), tietokoneohjelmista sekä automaateista. Näiden olemassaolevat hallinnointi- ja navigointikäytännöt voivat olla hyvinkin ristiriitaisia keskenään. Suunniteltavan palvelun tai kunkin osapalvelun luonne määrää toiminnan tavoitteet, jotka voivat vaihdella muun muassa informaation omaksunnasta uuden luomiseen tai tietyn asian suorittamiseen.
• Palvelun rakentaja ei voi tehdä juuri mitään oletuksia käyttäjän laitteistosta tai ohjelmistosta, mikä vaikeuttaa suunnittelua merkittävästi. Hyvä web-palvelu skaalautuu käyttäjän käyttölaitteiston mukaisesti eli sen käyttökelpoisuus ei merkittävästi vähene, vaikka käyttöympäristö olisi vaatimattomampikin.

Edellä mainittujen erikoisominaisuuksien lisäksi verkkopalveluiden käytettävyydessä on merkittävä ero tavallisiin ohjelmiin jo pelkästään niiden käynnistämisen kohdalla. Siinä missä perinteiset ohjelmat asennetaan kerran käyttäjän kovalevylle ja käynnistetään sieltä, toimivat web- palvelut hajautetusti verkosta käsin: pelkästään verkkoyhteyden muodostaminen voi toisinaan olla hankalaa, eikä itse verkkopalveluun yhteyden ottaminen ole useimmiten sen paremmin opastettu kuin mitä yksi URL-osoite asiaa ilmaisee. Seuraavassa tarkastelemme web-palveluiden erityisrajoitteita ja mitä ne merkitsevät palvelun suunnittelulle.

Verkkopalvelun pitäisi skaalautua eri nopeuksille

Tiedonsiirtoviive on aika joka kuluu otettaessa yhteys web- selaimesta web-palveluun. Se on yleensä riippuvainen käyttäjän ja palvelun välisestä välimatkasta. Välimatkaa tietoverkossa ei kuitenkaan voi mitata yksinomaan fyysisesti vaan välimatkan "pituuteen" vaikuttaa myös verkon rakenne: mitä useamman aliverkon kautta tieto kulkee käyttäjän web-selaimesta web-palveluun, sen pidempi on yleensä tiedonsiirron viive. Viiveeseen vaikuttavat myös tiedonsiirtotiessä käytettävät laitteet, ja koska tie voi vaihdella käyttäjältä toiselle, voi myös viive olla hyvin eri pituinen kahdelle käyttäjälle. Toinen joutuu odottamaan vastausta painalluksiinsa alle sekunnin, toinen pahimmillaan useita sekunteja.

Tiedonsiirtonopeus kertoo kuinka nopeasti tietoa voi siirtää suuremmissa erissä palvelusta käyttäjälle. Se on myös riippuvainen käytettävissä olevista laitteista ja verkon rakenteesta. Vaikka tiedonsiirtonopeus onkin usein kääntäen verrannollinen viiveeseen, suunnittelijan kannalta kyseessä on kaksi eri tuntematonta suuretta. Viive kertoo kuinka nopeasti järjestelmä reagoi käyttäjän toimintoihin, kun taas tiedonsiirtonopeus kertoo kuinka nopeasti tietoa saadaan siirrettyä palvelusta käyttäjän selaimeen tai päinvastoin. Nopea tiedonsiirtotie ei vielä takaa lyhyttä viivettä, koska palvelu voi olla sisäisesti hidas ja pitkittää viivettä verkosta riippumatta.

Suunnittelussa viive ja siirtonopeus voidaan huomioida monella eri tapaa. Yksi usein käytetty tapa on suunnitella palvelusta kaksi eri versiota eri nopeuksille: nopeammille yhteyksille tarkoitettu versio voi sisältää enemmän havainnollistavia kuvia tai muuta nopeaa siirtonopeutta hyödyntävää materiaalia, kun taas hitaille yhteyksille tehty versio pyrkii minimoimaan verkon yli siirrettävän materiaalin kokonais- ja kappalemäärän. Usein palvelun sivujen painon, eli niillä sijaitsevan tekstin, äänen, kuvien ja ohjelmien, vähentäminen pienentää myös palvelun sisäistä viivettä, koska palvelu ei joudu lähettämään käyttäjälle yhtä monta erillistä tiedostoa. On tärkeää huomata, että nykyisellä tiedonsiirtostandardilla (HTTP 1.0/1.1) sekä siirrettävän materiaalin kokonaismäärä (yhteenlaskettu koko kilotavuina) että kappalemäärä (siirrettävien tiedostojen lukumäärä koosta riippumatta) vaikuttavat palvelun käytön nopeuteen. Pienempi määrä tiedostoja ja vähemmän siirrettäviä kilotavuja nopeuttaa palvelun käyttöä.

Käyttöliittymästandard it vasta muotoutumassa

Web-palveluissa vastaavia standardeja ei ole olemassa, eikä toistaiseksi ole edes suunnitteilla. Siksi suunnittelijoilla on käyttöliittymän suunnittelun suhteen huomattavasti enemmän vapauksia, mutta samalla myös vastuuta, koska he eivät voi nojautua standardoituihin ratkaisuihin kovin hyvin. Suunnittelijat voivat kuitenkin käyttää joitain verkkopalveluiden yleisiä ja muotoutuvia käytäntöjä muun muassa ruutuelementtien sijoittelusta, tekstin ja mediaelementtien käytöstä ja navigaatioapujen logiikasta. Usein nämä käytännöt vaihtelevat palvelutyypin mukaan niin, että esim. uutispalveluilla saattaa olla keskenään yhtenevä logiikka, hakupalveluilla oma yhteinen logiikkansa, jne. Jopa hyvin yksinkertaiset asiat, kuten syötelomakkeiden Tyhjennä ja Lähetä-painikkeiden järjestys vaihtelee, vaikka näille onkin löydettävissä perusteltu järjestys.

Palvelun suunnittelijat voivatkin miettiä mihin kategoriaan heidän suunnittelemansa web-palvelu parhaiten rinnastuu ja tutustua tämän palvelutyypin yleislogiikkaan ja muodostuneisiin käytäntöihin. Tätä suunnittelutapaa käyttivät myös kaikki tutkittujen web-palveluiden tuotantoryhmät. Puhtaasti kokeilemalla löydetyt, yleistyneet käytännöt eivät välttämättä yllä aina lähellekään parhaita ratkaisuja ja logiikan lainaaminen toisesta palvelusta voi olla myös vahingollista.

Ulkoasun tarkka määrittely lähes mahdotonta

Rakennekuvauskielen rinnalle on web-sivujen suunnittelua varten tehty myös tyylimäärityskieliä, joiden tarkoituksena on määrittää sivun ulkoasua rakenteen sijaan. Toistaiseksi käytössä on kuitenkin vähän selaimia, jotka tukevat tyylitiedosto-ominaisuuksia hyvin, eivätkä nämäkään toteuta tyylitiedostoja keskenään yhtenäisesti.

Sivun ulkoasun lopulliseen määrittelyyn vaikuttaa siis edelleenkin suunnittelijasta riippumattomat tekijät. Web-sivujen kohdalla puhutaankin, että perinteisen WYSIWYG-sivuntaittoperiaatteen ("se mitä näet ruudulla on myös lopullinen ulkoasu") sijasta verkossa noudatetaankin WYSIWYR-periaatetta ("se mitä näet ruudulla on yksi mahdollinen esitys kaikista lopullisista ulkoasuista").

Suunnittelijoiden pitäisi voida huomioida palvelun ulkoasua ja käyttöliittymää suunniteltaessa ulkoasun tarkan määrittelyn puuttuminen. Ulkoasumääritysten heikkouden takia osa suunnittelijoista lähtee rakentamaan kiertoteitä, joilla pyritään pakottamaan ulkoasu väkisin tiettyyn muottiin. Tämä lähestymistapa on kuitenkin useammin haitallinen kuin hyödyllinen: sivut eivät näy hyvin kaikilla selaimilla tai kaikille käyttäjille ja erilaisten kiertoratkaisuidensa takia ne saattavat lakata toimimasta standardien ja selainten päivitysten myötä.

Usein jonkinlainen keskitien kulkeminen ulkoasun tarkan määrittelyn ja pelkän rakenteen määrittelyn välillä onkin paras ratkaisu. Ulkoasu kannattaa määritellä niin, että se skaalautuu käytettäväksi eri selaimilla ja eri tilanteissa, säilyttäen kuitenkin ulkoasun perusajatuksen riippumatta esitysympäristöstä.

Verkkokäyttäjien osaaminen vaihtelee suuresti

Aloitteleva käyttäjä voi puolestaan käyttää tietokonetta ensimmäisiä kertoja samalla, kun tutustuu myös verkkopalveluihin ensimmäisiä kertoja. Näillä kahdella käyttäjäryhmällä on hyvin erilaiset odotukset ja oletukset verkkopalveluiden toiminnasta ja omista mahdollisuuksistaan verkon sisällä. Suunnittelijan tehtävä on pystyä luomaan palvelu, joka tukee näiden kahden ääripään sekä muiden ryhmien toisistaan poikkeavia tarpeita ja kykyjä.

Yleisesti on helppo todeta, että aloittelevat käyttäjät kaipaavat enemmän opastusta ja asioiden esittelyä heille, koska he käyttävät niitä mahdollisesti ensimmäistä kertaa. Aloittelijan käyttöliittymä voi siis olla vahvasti yksinkertaistettu silläkin uhalla, että se on hitaampi käyttää.

Asiantuntija kaipaa puolestaan usein juuri nopeutta, tehokkuutta ja joustavuutta, eikä niinkään yleistä opastamista. Asiantuntijalle annettava opastus pitäisi aina olla tilannekohtaista ja yleensä tarjolla vain tämän omasta pyynnöstä. Näiden kahden ääripään ryhmien tarpeiden poikkeavuuksien takia, suunnittelija joutuu usein tekemään palvelun käytöstä helpomman joko aloittelijoille tai edistyneille käyttäjille. Toinen vaihtoehto on tarjota palveluun kaksi erilaista käyttöliittymää, jotka ovat suunniteltu eri käyttäjäryhmille.

Käytön helpottamiseksi eri käyttäjäryhmille on keksitty mitä erilaisempia ratkaisuja eri verkkopalveluissa, alkaen esiin ponnahtavista ikkunoista ja päätyen massiivisiin opastussivuihin. Useimmat näistä ratkaisuista on tavallaan jälkikäteen tehtyjä korjauksia, kun käytössä on huomattu vaikeuksia, eivätkä ne siis poista olemassa olevaa ongelmaa.

Arkipäiväisten esineiden käyttöä tutkinut Donald Norman onkin havainnut, että ensimmäinen signaali käytettävyysongelmista on jälkikäteen asennettu ohjelappu, kieltotaulu tai muu väliaikaisratkaisu (Norman, 1988). Järkevämpi tapa suhtautua käyttötaitojen erilaisuuteen, on määritellä ensisijaiset kohderyhmät ja suunnitella heille, tarkoitti tämä sitten kahden eri liittymän rakentamista, toisten ryhmien käyttötavan suosimista tai kahden käyttöliittymän sulauttamista toisiinsa.

Navigaation merkitys korostuu palveluiden käytössä

Verkkopalveluista ja koko internetin webistä onkin usein todettu, että käyttäjä voi eksyä niihin, mikä puolestaan vähentää palvelun käyttöarvoa. Eksymisen estämiseksi palvelun pitäisi tarjota käyttäjälle ymmärrettävä tietorakenne, jonka avulla käyttäjä voi hahmottaa palvelun kokoa, sen eri osia ja omaa sijaintiaan palvelussa. Tietorakenne on usein tyypiltään hierarkkinen malli, joka jakaa palvelun osiot keskenään alisteisiin ja rinnasteisiin osiin, ja helpottaa näin palvelun sisällön muistamista.

On tärkeää huomata, että käyttäjän kannalta mielekäs palvelun tietorakenne on usein erilainen kun palvelun ylläpidon tai asiakasyrityksen suosima tietorakenne. Peruskäyttäjälle hyvä tietorakenne ei siis ole sama kuin asiakasyrityksen yritysrakenne tai ylläpitäjien suunnittelema tiedostohierarkia.

Palvelun käytön kannalta tärkein tietorakenne on käyttäjän mentaalinen malli palvelun osista ja toiminnasta. Tämän mallin muotoutumista tiettyyn suuntaan voidaan ohjata esimerkiksi metaforan avulla, joka auttaa käyttäjää rinnastamaan palvelun toiminnan ja rakenteen johonkin jo tuntemaansa asiaan. Web- palvelun rakenne, käyttöliittymä ja navigointi voidaan siis rakentaa muistuttamaan vaikka auton tai supermarketin toimintaa, mikäli se vain sopii esitettävään aiheeseen.

Navigaation kannalta suunnittelijan on tärkeää kysyä itseltään muutama peruskysymys, aina kun hän suunnittelee palvelussa liikkumista. Käyttäjän kannalta on oleellista tietää palelun joka osiossa seuraavat asiat: missä olen, minne kaikkialle voin täältä liikkua, missä päin on tietty haluamani palvelu ja jos olen matkalla sinne, niin olenko menossa oikeaan suuntaan.

Suunnittelija voi auttaa käyttäjää navigoinnissa ja näihin kysymyksiin vastaamisessa käyttämällä selkeitä osiotunnisteita järjestelmällisesti palvelun eri osiossa, pitämällä tärkeimpien toimintojen pikavalinnat aina esillä, lyhentämällä matkaa osiosta toiseen mahdollisimman lyhyeksi ja tarjoamalla useita erilaisia apuja navigaation tueksi (kuten sivukartta, sanahaku, navigointipalkki ja "olet täällä"- ilmoitus). On oleellista huomata, ettei yksikään navigointitapa ole automaattisesti ylivertainen, vaan ihmisillä on erilaisia tapoja etsiä asioita verkossa ja näitä kaikkia kannattaa tukea mahdollisuuksien mukaan.

Käytettävyysratkaisuja syntyy web-tuotannon joka vaiheessa

Suuremmissa verkkopalvelutuotannoissa on yleensä mukana useita ihmisiä, joilla on eriytyneet toimenkuvat. Tällöin erikoisen tärkeäksi muuttuu prosessien välinen kommunikointi, jolla varmistetaan että edellisessä prosessissa tehdyt huomiot ja ratkaisut niin käytettävyydestä kuin muustakin päätyvät seuraavaan prosessiin. Muuten palvelun tuotannossa tehdään helposti useita keskenään ristiriitaisia ja yhteen sopimattomia päätöksiä, jotka vain heikentävät palvelun yleiskäytettävyyttä.

Paras tapa kommunikoinnin varmistamiseen onkin kirjallinen dokumentointi vaikka suunnittelukirjan muodossa. Kirja pitää sisällään suunnittelussa ja toteutuksessa tehdyt päätökset, jotka ovat nousseet alun jälkeen esiin. Tärkeimmistä päätöksistä pitäisi ainakin kirjata miksi asia nousi esiin, mitä päätettiin ja etenkin mikä oli päätökseen johtava logiikka. Ilman päätösperusteluja on vaikea puuttua järkevästi aikaisemmin tehtyihin päätöksiin ja miettiä niiden järkevyyttä prosessin myöhemmissä vaiheissa nousevien asioiden kannalta.

Käyttölaitteisto ja -ympäristö vaihtelevat suuresti

Perinteisten tietokoneohjelmien valmistajat ovat jo pitkään laittaneet ohjelmistojensa paketteihin minimilaitteistovaatimuksia ja yhä useammin säätävät ohjelmiensa toimintoja käytettävän laitteiston mukaan. Käyttäjät suhtautuvat web-palveluiden minimilaitevaatimuksiin historiallisen kehityksen takia usein penseästi, minkä takia niiden käyttö ei ole suositeltavaa. Käyttäjän laitteistosta ei voi saada ohjelmallisesti selville juuri mitään, parhaimmillaankin vain selainvalmistajan ja selainversion, joskaan nämäkään tiedot eivät aina pidä paikkaansa.

Lisäksi web-palveluihin käytettävien selainten kirjo laajenee jatkuvasti: syksyllä -98 julkaistun tutkimusyritys IDC:n raportin mukaan nopeimmin kasvava selainten joukko on muut kuin Internet Explorer tai Netscape Communicator. Käytettävyysasiantuntija Jakob Nielsen ennustaa puolestaan, että seuraava suuri läpimurto web-palveluissa on langaton käyttö, joka ei todellakaan koostu 19-tuumaisesta monitorista tai Java- selaimesta. Näiden muutoksien takia suunnittelijoiden on yhä vaikeampaa tehdä oletuksia käytettävissä olevista laitteistoista ja erilaisten minimivaatimusten asettaminen rajaakin palvelun käyttöä turhaan.

Ideaalitilanteessa web-palvelu suunnitellaan niin, että se skaalautuu eri yhteysnopeuksiin, käyttötarpeisiin ja laitteistoihin. Jos samaa palvelua on mahdollista käyttää eri tarkoituksiin eri selaimilla ja koneilla riippumatta verkon yhteysnopeudesta, palvelu on todennäköisesti käyttökelpoinen myös laitteiden ja standardien muuttuessa. Jos palvelua on vaikea tai mahdotonta tehdä eri laitteille skaalautuvaksi, täytyisi ainakin sen perustoiminnot olla käytettävissä muunlaisella laitteistoilla, kuin mitä minimilaitteistoksi on määritelty.