POLKU-PROJEKTIN HEURISTINEN ARVIOINTI Uteam, koostanut Joonas Jokiniemi 1.3.2010 Tampereen yliopisto 1
TIIVISTELMÄ Menetelmä Kohde Työryhmä Huomioitavaa Päätulokset Heuristinen arviointi Polku-projekti, http://polku.cs.uta.fi/html/ (testi-versio) Uteam On huomioitava, että järjestelmä ei ollut valmis sitä arvioitaessa. Lomake käyttää kame-kurssin raporttipohjaa. Heuristisessa arvioinnissa löydettiin yhteensä 14 käytettävyysongelmaa. Kriittisiä ongelmia löytyi yksi. Lopultakin polun käytettävyys oli hyvällä tasolla, ja projekti selvästi kärsi siitä, että heuristinen arviointi suoritettiin keskeneräiselle projektille. Erityisesti kiitosta sai minimalistinen suunnittelu ja ammattimainen graafinen suunnittelu. Suurimmiksi yksittäisiksi käytettävyysongelmakokonaisuuksiksi arvioitiin: 1. yleinen navigoinnin epäjohdonmukaisuus sekä 2. muutamat vakavan virheen mahdollistavat käyttöliittymän epäloogisuudet. Yleistä ohjeistusta tulisi lisätä roimasti ja käyttäjälle tulisi tarjota enemmän palautetta ohjelmassa tekemistään asioista. 2
1 JOHDANTO Tässä arvioinnissa sivusto on arvioitu heuristisen arvioinnin avulla. Käytettävyyden heuristisessa arvioinnissa käytetään yleisesti ohjeistoja ja säännöstöjä, joita käyttöliittymien kehittämisestä on laadittu. Tässä arvioinnissa on käytetty Jakob Nielsenin kehittämää tarkistuslistaa. 1 1.1 Heuristisen arvioinnin tarkistuslista Ohjelman arviointi tarkistuslistan avulla tarkoittaa sitä, että ohjelma käydään läpi vaihe vaiheelta ja joka kohdassa tarkastetaan, noudattaako käyttöliittymä seuraavia käytettävyysperiaatteita. Hakasuluissa on merkintätapa, jolla viitataan periaatteisiin kunkin havaitun käytettävyysongelman kohdalla. 1. Järjestelmän tilan näkyvyys [näkyvyys] Järjestelmän tulee koko ajan pitää käyttäjä tietoisena siitä, mitä on tapahtumassa. Siksi järjestelmän tulee antaa kohtuullisessa ajassa asianmukaista palautetta. 2. Järjestelmän ja reaalimaailman yhdenmukaisuus [tuttuus] Järjestelmän tulisi puhua käyttäjän kieltä, eli käyttää toteutukseen liittyvien ilmaisujen sijasta sanoja, lauseita ja käsitteitä, jotka ovat käyttäjälle tuttuja. Noudata reaalimaailman käytäntöjä ja esitä informaatio luonnollisessa ja loogisessa järjestyksessä. 3. Käyttäjällä toiminnan ohjaus ja valinnan vapaus [valinnan vapaus] Käyttäjät valitsevat toimintoja usein vahingossa ja tarvitsevat selvästi merkityn hätäuloskäynnin, jonka avulla ei-toivotusta tilasta pääsee pois ilman pitkällistä dialogia. Tue undo- ja redotoimintoja. 4. Johdonmukaisuus ja standardit [johdonmukaisuus] Käyttäjien ei tulisi joutua ihmettelemään sitä, viitataanko järjestelmän eri termeillä samaan asiaan tai toimintoon. Noudata toteutusympäristön vakiintuneita käytäntöjä. 5. Virheiden torjunta [virheiden torjunta] Hyviä virheilmoituksiakin tärkeämpää on huolellinen suunnittelu, jonka avulla jo ongelman syntyminen voidaan estää. 6. Tunnistaminen, ei muistaminen [tunnistaminen] Tee kohteista, toiminnoista ja vaihtoehdoista näkyviä. Käyttäjän ei pitäisi joutua muistamaan informaatiota käyttöliittymän osasta toiseen siirryttäessä. Järjestelmän käyttöohjeiden tulisi olla näkyviä tai tarvittaessa helposti saatavilla. 1 http://www.useit.com/papers/heuristic/heuristic_list.html 3
7. Käytön joustavuus ja tehokkuus [joustavuus] Oikopolkuvalinnat joita aloitteleva käyttäjä ei edes huomaa voivat usein tehostaa kokeneiden käyttäjien työtä niin, että järjestelmä sopii sekä kokemattomille että kokeneille käyttäjille. Anna käyttäjien räätälöidä usein toistuvia toimenpiteitä. 8. Esteettinen ja minimalistinen suunnittelu [esteettisyys] Käyttöliittymän ei pitäisi sisältää informaatiota, joka on asiaankuulumatonta tai jota tarvitaan harvoin. Jokainen ylimääräinen informaatiopalanen kilpailee huomiosta oleellisen informaation kanssa ja heikentää eri osien suhteellista erottuvuutta. 9. Käyttäjän avustaminen virheiden tunnistuksessa, niiden syyn selvityksessä, ja niistä toipumisessa [virheilmoitukset] Virheilmoitukset tulisi esittää luonnollisella kielellä (ilman koodeja), niiden tulisi kuvata ongelma täsmällisesti ja tehdä rakentava ehdotus tilanteen korjaamiseksi. 10. Opasteet ja dokumentit [opastus] Vaikkakin on parempi, jos järjestelmää voi käyttää ilman ohjekirjoja, saattaa olla välttämätöntä tarjota käyttäjille opastusta ja oppaita. Tiedon etsinnän opasteista ja oppaista tulisi käydä helposti. Sisällön tulisi keskittyä käyttäjän tehtäviin, luetella konkreettisia toimintaketjuja, ja olla laajuudeltaan kohtuullinen. Jokainen arvioinnissa löydetty ongelma on luokiteltu vakavuusasteikolla, joka kertoo asiantuntijoiden mielipiteen käytettävyysongelman vakavuudesta. Ongelman vakavuusluokka ilmaistaan numeroilla yhdestä neljään seuraavasti: 1 Kriittinen ongelma, joka estää palvelun käytön halutulla tavalla. 2 Suuri käytettävyysongelma, joka vaikeuttaa käyttöä merkittävästi. 3 Pieni käytettävyysongelma, joka vaikeuttaa palvelun käyttöä jossakin määrin. 4 Kosmeettinen ongelma, joka estää viimeistellyn vaikutelman syntymisen. Lisäksi havaintojen kuvaamiseen käytetään seuraavia merkintöjä silloin, kun kyseessä ei ole varsinainen käytettävyysongelma: K Kommentti, joka ei ota kantaa raportoitavan asian vakavuuteen. Kommentilla halutaan ehdottaa toimenpidettä tai korostaa jonkin ominaisuuden onnistunutta toteutusta. T Tekninen ongelma, joka johtuu palvelun teknisessä toteutuksessa olevasta virheestä. 2 ASIANTUNTIJA-ARVIOINTI Arviointi suoritettiin 1.3.2010 Uteamin heuristiikkaworkshopissa, jossa viiden käytettävyysasiantuntijan avulla suoritettiin tuotteen käytettävyyden heuristinen arviointi. Workshopin kesto oli noin neljä tuntia. (Selain Firefox ja käyttöjärjestelmä Linux.) 4
Ongelmat on jaoteltu kolmeen kategoriaan. Kategoriat luokittelevat ongelmat yleisiin, navigointia koskeviin, sekä toimintoja koskeviin ongelmiin. Lopussa on listattuna muutamia kommentteja ja teknisiä ongelmia, joihin törmättiin heuristista arviointia tehdessä. 2.1 Yleiset ongelmat Ongelma 1. Poista-valinnan ei tulisi olla dialogien oletusvalintana. Painike poista on kaikkien dialogien oletusvalinta, ja tämä voi johtaa vahingossa poistamiseen, mikäli käyttäjä epähuomiossa painaa enteriä kesken valinnan. Oletusvalinta tulisi siirtää peruuta -painikkeeseen. [tuttuus, johdonmukaisuus, virheiden torjunta, virheilmoitukset] [1] Ongelma 2. Painikkeiden tekstit eivät ole johdonmukaisia. Painikkeiden tekstit tulisi tarkastaa kauttaaltaan, ja ne tulisi korjata kontekstista riippuen. Esim. Juttujen muokkaamisessa tallennetaan muokkaus, ei muokata muokkausta sekä henkilöiden kohdalla luo lisääksi ja niin edelleen. Lisäksi dialogien peruta-painiketta tulisi tukea nyt peruuta-painiketta näkee käyttöliittymässä harvakseltaan. [tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen] [3] Ongelma 3. Pop-up-ikkunoiden tulisi olla suurempia. Osa ikkunoista ei näytä kaikkia tietoa, jota niissä on mahdollista muokata. Käyttäjän kannalta onkin tärkeää, että tarvittavat tiedot näytetään luonnollisesti siten, ettei tietoa tarvitse ikkunasta liiaksi scrollata. [tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen, esteettisyys, opastus] [3] Ongelma 4. Syötteiden oikeellisuus tulisi tarkastaa. Esim. henkilöille voi antaa samoja lyhenteitä ja ylipäätään lomakkeiden syötteiden oikeellisuutta ei juuri tarkasteta. Tarkastus on kuitenkin tärkeä osa nykysovelluksia, ja käyttäjät osaavat jo odottaa sitä. [virheiden torjunta, tunnistaminen, virheilmoitukset, opastus] [3] Ongelma 5. Pop-up-ikkunoissa käytetyt sanamuodot tulisi tehdä yhteneväiseksi. Pop-upikkunoiden tekstit tulisi tarkastaa kauttaaltaan, ja ne tulisi korjata yhteneväiseksi. Kysymykset mitä tässä dialogissa tehdään, mikä verbi kuvaa tekemistä parhaiten auttaa oikeiden termien ja sanamuotojen löytämiseen. [näkyvyys, tuttuus, virheiden torjunta, tunnistaminen, opastus] [3] Ongelma 6. Aktiiviset huomiot ja tavalliset huomiot tulisi erottaa muutoin kuin numerokoodauksella. Tällä hetkellä aktiivisten ja tavallisten huomioiden ero näkyy numeroinnista, kuitenkin näin ei pitäisi olla. Sanallinen selitys olisi parempi. [näkyvyys, tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen, opastus] [4] Ongelma 7. Ohjelma ei tue palauta-painikkeita. Lomakkeissa palauta-painike palauttaa edelliset valinnat, tällöin käyttäjän ei tarvitse muistaa edellisiä tekemiään edellisiä valintoja, vaan hän voi kätevästi palauttaa lomakkeen entiselleen. [näkyvyys, tuttuus, johdonmukaisuus, virheiden torjunta, opastus] [4] 2.2 Navigointiin liittyvät ongelmat Ongelma 8. Navigoinnin epäjohdonmukaisuus. Käyttäjän on mahdollista navigoida kahdella eri tavalla: 1. selauksessa monipolun avulla sekä 2. Muistikirjassa selaimen back-toimintoa hy- 5
väksi käyttämällä. Navigointi tulisi toteuttaa siten, ettei molempiin osioihin tarvitsisi omaa logiikkaa, vaan navigointi olisi yhtenäinen. Esim. muistikirjaan voitaisiin tehdä oma muropolku, jonka tausta väri erottaisi sen selausnäkymästä. Toinen vaihtoehto on tukea takaisin-nappia sivussa itsessään. [näkyvyys, tuttuus, valinnan vapaus, johdonmukaisuus, tunnistaminen, joustavuus, opastus] [2] Ongelma 9. Monipolkua(=semanttisten suhteiden polkua) tulisi jatkaa henkilöiden, tahojen ja kokonaisuuksiin saakka. Monipolku on selauksen päänavigointi tapa ja siksi sen toimintalogiikka on erittäin tärkeä arvioidessa koko sivuston käytettävyyttä. Monipolku on eräällä tavalla yhden askeleen liian lyhyt ja se ei ylety hierarkian viimeiselle tasolle. Olisikin luonnollista, että myös viimeinen taso otettaisiin mukaan. [näkyvyys, tuttuus, valinnan vapaus, johdonmukaisuus, virheiden torjunta, tunnistaminen, joustavuus, opastus] [3] Ongelma 10. Projektia luodessa, käyttäjälle tulee tarjota varmistus tehtävän onnistumisesta tai epäonnistumisesta. Mikäli käyttäjä ei anna projektille nimeä, projekti ei tallennu, mutta käyttäjälle ei kerrota, miksei tallennus onnistunut. Ohjeistusta voisi lisätä esim. lauseella projektia luodessa, sille täytyy antaa nimi tai pakollinen kenttä. [näkyvyys, tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen, virheilmoitukset, opastus] [2] 2.3 Toimintoihin liittyvät ongelmat Ongelma 11. Ohjelma ei anna palautetta riittävästi. Vaikka asia onkin mainittu erillisinä kohtina, on silti hyvä korostaa, että ohjelman tulisi antaa palautetta onnistuneista tai epäonnistuneista toiminnoista. Mikäli palautetta ei anneta, käyttäjä saattaa erehtyä lisäämään jotkut asiat ohjelmaan useaan eri kertaan. [näkyvyys, tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen, virheilmoitukset, opastus] [2] Ongelma 12. Käyttäjälle tulisi ilmoittaa, onnistuiko projektin/tapahtuman/henkilön/kokonaisuuden luominen tai liittäminen. Eräs huomio, joka toistuu läpi ohjelman on se, ettei käyttäjälle anneta palautetta hänen tekemistä toiminnoista riittävästi. Olisikin tarpeellista lisätä sanallisia selityksiä sinne tänne ohjelmaa, erityisesti sen jälkeen kun joku toiminto on tehty, käyttäjä odottaa varmennusta siitä, että jotain aidosti tapahtui. [näkyvyys, tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen, virheilmoitukset, opastus] [2] Ongelma 13. Syötteiden merkkimäärä tulisi ilmoittaa (lomakkeissa). Käyttäjälle tulisi ilmoittaa lomakkeiden maksimi merkkimäärä ja jos ko. merkkimäärä ylittyy kenttään ei pitäisi pystyä enää kirjoittaa.[näkyvyys, tuttuus, johdonmukaisuus, virheiden torjunta, virheilmoitukset, tunnistaminen, opastus] [3] Ongelma 14. Henkilön luominen kontekstisidonnaiseksi. Henkilöä ei tällä hetkellä liitetä suoraa tapahtumaan, vaikka luominen on aloitettu kontekstissa, jossa käyttäjä olettaa luovansa henkilöä ko. tapahtumaan. Henkilön luomisen jälkeen käyttäjä löytää itsensä muistikirjasta, ei selauksesta. Lisäksi käyttäjälle ei anneta selvää palautetta onnistuko uuden henkilön luominen. [tuttuus, johdonmukaisuus, virheiden torjunta, tunnistaminen, joustavuus] [3] 6
2.4 Kommentit ja tekniset huomiot Ongelma 15. Käyttäjätunnus ja uloskirjautuminen olisi hyvä näkyä kaikissa näkymissä. Selvästi suurin osa nykysisitä järjestelmistä näyttää käyttäjätunnuksen ja antaa uloskirjautumismahdollisuuden kaikissa näkymissä. Tätä ominaisuutta olisi hyvä tukea myös polussa. [Kommentti] [Huom. Uteam ei ollut yhtenäinen tämän kommentin suhteen] Ongelma 16. Kalenterin tulisi tulla näkyviin erillisestä ikonista. Kalenteri toimii tällä hetkellä siten, että kursorin koskettaessa tekstikenttää, kalenteri aukeaa. Mieluummin ikoni, jota painamalla päivämäärä on mahdollista valita eritavalla. [Kommentti] [Huom. Uteam ei ollut yhtenäinen tämän kommentin suhteen] Ongelma 17. Kriittisiin toimintoihin tulisi lisätä kriittisen toiminnan ikoni. Yleinen standardi on se, että kriittisten toiminnallisuuksien yhteydessä tarjotaan myös ikoni, joka ilmoittaa tapahtuman olevan kriittinen. Kuvan 1. ikoni lienee riittävä. [Kommentti] Kuva 1. Ongelma 18. Taulukon tietojen listaamisen eri vaihtoehdot. Taulukon tietojen listaaminen olisi hyvä lisä, joka voisi osoittautua tarpeelliseksi lisäksi. [Kommentti] Ongelma 19. WWW-sivujen osoitteet tulisi olla linkkejä, ei tekstiä. Web-sivut olisi hyvä koodata linkeiksi, jotka avautuvat omaan ikkunaan. Näin sovelluksen ulkopuolisten www-sivujen selauksesta tehdään helpompaa ja käytetään hypertekstin ominaisuuksia hyödyksi. [Kommentti] Ongelma 20. Vasemman palkin otsikko ja linkit ovat samanvärisiä. Yleisen tavan mukaan linkit ja otsikot erotellaan toisistaan selkeästi. Saattaisi olla parempi jos otsikko olisi vielä enemmän erillään valinnoista tai jos se olisi värikoodattu eritavalla. (Ks. Kuva 2.) [Kommentti] Kuva 2. Ongelma 21. Vasemman palkin tulisi säilyä koko työn ajan. Web-sivut olisi hyvä koodata linkeiksi, jotka avautuvat omaan ikkunaan. Näin sovelluksen ulkopuolisten www-sivujen selauksesta tehdään helpompaa ja käytetään hypertekstin ominaisuuksia hyödyksi. [Kommentti] 7
Ongelma 22. Uusia instansseja luodessa, vasemman palkin tulisi säilyä. Käyttäjä jää odottamaan, että vasen palkki olisi omalla paikallaan kaikissa näkymissä, mutta nyt se katoaa mm. luodessa uutta projektia. Edes otsikko olisi hyvä jättää jäljelle. [Kommentti] Ongelma 23. Pop-up:ista olisi hyödyllistä siirtyä suoraa henkilön luomiseen. Käyttäjä jää odottamaan, että vasen palkki olisi omalla paikallaan kaikissa näkymissä, mutta nyt se katoaa mm. luodessa uutta projektia. Edes otsikko olisi hyvä jättää jäljelle. [Kommentti] Ongelma 24. Jutun poisto-dialogissa merkitsevät tiedot tulisi olla sisältö ja päivämäärä. Nykyisellään jutun poistossa näytetään päivämäärää sekä julkaisupaikkaa. Mikäli kaksi juttua on julkaistu saman päivänä ja samassa lähteessä, käyttäjä ei tiedä kumpi juttu on kumpi. [Kommentti] Ongelma 25. Henkilön listauksessa olisi hyvä näyttään ne tahot ja projektit, joihin ko. henkilö kuuluu. Semanttisten suhteiden kannalta lienee tärkeää, että tahot ja projektit listataan myös henkilöiden kohdalla. [Kommentti] Ongelma 26. Aika tulisi ilmoittaa eurooppalaisella tavalla. Testiversiossa aika on ilmoitettu, amerikkalaisittain. [Kommentti] Ongelma 27. Kalenterin päivämäärät eivät täsmää. Maanantaina 1.3.2010, kalenteri näytti tiistaita 1.32010. [Tekninen huomio] Ongelma 28. Järjestelmän versio ei näyttänyt omia aktiivisia huomioita etusivulla. Kyseessä on kuitenkin vain tekninen huomio, ja asia korjattaneen lopputuotteeseen. [Tekninen huomio] Ongelma 29. Vanhoja juttuja ei voi liittää, vaan liittääkseen jutun käyttäjä joutuu luomaan aina uuden jutun. Kyseessä on kuitenkin vain tekninen huomio, ja myös tämä asia korjattaneen lopputuotteeseen. [Tekninen huomio] Ongelma 30. Henkilöiden poistaminen tulisi olla mahdollista. Kyseessä on kuitenkin vain tekninen huomio, ja asia korjattaneen lopputuotteeseen. [Tekninen huomio] Ongelma 31. Ne asiat, jota järjestelmään ei toteuteta, tulisi ottaa pois. Yksinkertaisesti käyttöliittymää tulisi karsia siten, että ainoastaan toimivat osiot jäävät jäljelle. Tämä lienee itsetäänselvää lopputuotetta silmälläpitäen. [Tekninen huomio] 8