Hirviö SEPA-dokumentti Käyttöliittymän heuristinen arvoiointi

Transkriptio

1 Hirviö Käyttöliittymän heuristinen arvoiointi 30. marraskuuta

2 Sisältö 1 Johdanto 3 2 Nielsenin kymmenen kohdan heuristiikka 3 3 Heuristisen arvioinnin hyödyntäminen projektissa 4 4 Kokemukset ja muutokset suunnitelmaan 4 5 Projektin suunnittelu (Project planning) 4 6 Implementointi Heuristiikat kohta kohdalta Sisäänkirjautumisruutu Muistiinpanon lisäys Löydetyt virheet Implementointi Viimeistely ja toimitus (Finalization and delivery) 6 9 Yhteenveto 6 2

3 1 Johdanto n ja Timo Toivasen SEPA-harjoituksen aihe on käyttöliittymän heuristinen arviointi. Arviointia käyttämällä pyritään ehkäisemään käytettävyysongelmien syntymistä jo suunnitteluvaiheessa. Se on myös hyödyllinen työkalu silloin, jos varsinaisten käytettävyystestien tekeminen on syystä tai toisesta epäkäytännöllistä. Heuristisen analyysin ideana on käydä käyttöliittymä systemaattisesti läpi, raportoida löydetyt virheet ja luonnollisesti pyrkiä korjaamaan ne. Lähteenä asiaan tutustuessamme olemme käyttäneet pääasiassa Sirpa Riihiahon artikkelia Käytettävyyden arviointi ilman käyttäjiä[2]. Lisäksi olemme heuristisen arvioinnin osalta tutustuneet Xristine Faulknerin kirjaan Usability Engineerin[3]. Arvioinnin teemme Nielsenin kymmenen perusperiaatteen (heuristiikan) mukaan[1]. Valitsimme aiheen, koska heuristinen arviointi sopii hyvin projektin luonteeseen. Arvioinnin avulla voidaan varmistaa käyttöliittymän yhdenmukaisuus ja karsia suurin osa virheistä pois jo ennen kuin asiakas pääsee järjestelmää näkemään. Lisäksi käytettävyydellä ja tietoturvalla on usein vastakkaiset tavoitteet ja on hyvä että nämä ristiriidat huomataan mahdollisimman aikaisin. Heuristiaen arvioinnin yhteydessä nämä tietoturvanäkökohdista aiheutuneet käytettävyysongelmat tulee perusteltua ja perustelut voidaan tarjota myös asiakkaalle. Varsinainen käyttäjätestaus asiakkaan kanssa olisi aikataulullisesti vaikea järjestää. Lisäksi käyttäjäryhmän pienuuden ja erikoislaatuisuuden vuoksi henkilökohtaiset tottumukset saattaisivat vaikuttaa suhteettoman paljon saataviin tuloksiin. 2 Nielsenin kymmenen kohdan heuristiikka Heuristinen arvointi tehdään käyttäen Nielsenin kymmenen kohdan arviointia.[1] Kaikkia näitä periaatteita ei voida soveltaa sellaisinaan tähän järjestelmään sen luonteesta sekä arvoioinnin ajankohdasta johtuen. 1. Järjestelmän tilan näkyminen - Kertooko järjestelmä järkevän viiveen kuluessa missä tilassa se on ja mitä se on tekemässä? 2. Järjestelmän ja reaalimaailman yhteensopivuus. Käyttääkö järjestelmä tavalliselle ihmiselle ymmärrettävää terminologiaa? Esitetäänkö asiat loogisesti? 3. Hallinta ja valinnan vapaus - Onko käyttäjällä vapaus valita mitä hän tekee ja mahdollisuus myös valintojen perumiseen? (undo-toiminto) 4. Johdonmukaisuus ja standardit - Käytetäänkö järjestelmässä samaa terminologiaa ja käytäntöjä muiden järjestelmien kanssa? 5. Virheiden ennaltaehkäisy - Pyrkiikö järjestelmä ohjaamaan käyttäjän toimia niin, ettei virhetilanteita pääsisi syntymään? 6. Asioiden tunnistaminen muistamisen sijaan - Onko kaikki tarpeellinen näkyvillä? Pitääkö käyttäjän muistaa asioita järjestelmää käytettäessä? 7. Oikotiet - Onko järjestelmässä kokeneita käyttäjiä varten näppäimistöoikoteitä ja muita vastaavia apuja, jotka eivät kuitenkaan sotke aloittelijoita? 8. Minimalistinen suunnittelu - Kertovatko dialogit vain oleellisen ilman suurempia selittelyjä? Onko varsinainen tieto hukutettu koristeiden alle? 9. Virhetilanteiden esittäminen käyttäjälle - Esitetäänkö virhetilanteet selkokielellä mystisten koodien sijaan? Kerrotaanko käyttäjälle virheen yhteydessä sen syy ja korjausehdotus? 10. Avusteet ja dokumentaatio - Onko dokumentaatio helposti helposti saatavilla ja onko avun etsiminen siitä helppoa? Onko dokumentaatio tehty käyttäjän näkökulmasta? 3

4 3 Heuristisen arvioinnin hyödyntäminen projektissa Teemme koko (siihen mennessä valmiina olevalle) käyttöliittymälle heuristisen arvioinnin molempien implementointivaiheiden lopussa. Löydetyt ongelmat käsitellään ja tarpeen vaatiessa korjataan seuraavan vaiheen alussa, ennen kuin käyttöliittymän kehitystä jatketaan. Mikäli käyttöliittymä vastoin suunniteltua muuttuu tai laajenee merkittävästi vielä viimeistelyvaiheessa, teemme vielä silloin arvioinnin muuttuneille osille. Arvioinnin tekevät ja. Kukin analysoija arvioi käyttöliittymää itsenäisesti, näyttö kerrallaan ja kokoaa ja perustelee löytämänsä ongelmat. Arvioinnin jälkeen kokoonnumme palaveriin, jossa löydetyt ongelmat kootaan yhteen, päätetään niiden vakavuus ja mitä niille tehdään. Ongelmien luokitteluun käytämme [2]:ssa ehdotettua luokittelua: katastrofaalinen, vakava, häiritsevä, vähäinen, kosmeettinen. Koko prosessi dokumentoidaan, jolloin myös niistä ongelmista, joita ei syystä tai toisesta voida korjata, jää merkintä ja selvitys, miksi korjaaminen ei onnistunut. 4 Kokemukset ja muutokset suunnitelmaan Tähän täydennetään myöhemmin kokemuksia ja muutoksia. 5 Projektin suunnittelu (Project planning) Suunnitteluvaiheessa käyttöliittymä ei ollut vielä niin pitkällä, että heuristista arviointia olisi ollut järkevää käyttää. 6 Implementointi 1 Koska käyttöliittymästä vasta pieni osa oli valmis tässä vaiheessa, kirjasimme pelkkien virheiden sijaan myös hyvät puolet. Kävimme lävitse molemmat näytöt tutkien vuorollaan kunkin Nielsenin kymmenen heuristiikan toteutumista. 6.1 Heuristiikat kohta kohdalta Sisäänkirjautumisruutu 1. Systeemin tila näkyy (odottaa kirjautumista). Ok. 2. Ei vaikeita termejä. Ok. 3. Jos käyttäjä kirjautuu vahingossa, hän saa virheilmoituksen. Virheilmoitus on selkeä, mutta voisi ehkä olla väriltään punainen tai muuten paremmin erottuva. 4. Näyttö on erittäin selkeä, pelkistetty ja tavanomainen. Ok. 5. Ei muuta mahdollisuutta virheisiin, kuin väärän käyttäjätunnuksen ja salasanan syöttäminen. Ok. 6. Ohjeet puuttuvat. Muuten kohta on huonosti sovellettavissa login-ruutuun. 7. Login-painiketta ei ole pakko klikata, vaan käyttäjä voi painaa enteriä. (Riippuen selaimen ominaisuuksista) käyttäjä voi halutessaan tallentaa käyttäjätunnuksensa ja salasanansa. Ok. 8. Näyttö on yksinkertainen. Ei sisällä mitään ylimääräistä. Ok. 4

5 9. Kirjautumisvirheilmoitus kertoo selkeästi, että joko käyttäjätunnus tai salasana oli väärä. Voisi kertoa, kummasta oli kysymys. 10. Dokumentaatiota ei vielä ole Muistiinpanon lisäys 1. Systeemin kirjautumistila on implisiittisesti näkyvissä (normaali työpöytä eikä pyydä sisäänkirjautumista) mutta mistään ei näe millä tunnuksella käyttäjä on kirjautuneena. Myöskään mahdollisesti vanhentunutta sessiota ei pysty havaitsemaan ennen kuin yrittää tehdä järjestelmällä jotain. Tämä on kuitenkin selainkäyttöliittymän rajoitus eikä sille voi järkevästi tehdä mitään. 2. Workgroup-termin merkitys ei selviä ellei sitä tiedä etukäteen. Myöskään archive-toiminnon tarkoitusta ei voi kovin helposti arvata. Due date olisi helpompi ymmärtää muodossa note is valid to tms. 3. Lisättyä muistiinpanoa ei voi poistaa. Sen voi kuitenkin korjata. Syntaktisesti väärää (= eräpäivä väärin) muistiinpanoa ei voi tallentaa. Ohjelma merkitsee virheen selvästi ja näyttää virheilmoituksen. Käyttäjä ei joudu selaamaan valikoita tai palaamaan taakse päin. Undo ja redo toimivat tekstikentissä, mikäli selain tai käyttöjärjestelmä niitä tukee. 4. Alasvetovalikot, napit ja linkit ovat normaalin näköisiä. Samaa asiaa ei (ainakaan vielä) voi tehdä monella tapaa. Show notes from -valikko voisi olla vähän selkeämpi. Active workgroup on hiukan epäselvä termi. 5. Käyttäjä voi syöttää väärän päiväyksen, mutta tästä ei onneksi aiheudu mitään vahinkoa. Väärää linkkiä tai painiketta on mahdollista painaa, mutta tämä on epätodennäköistä, koska oikea painike on selvästi nähtävillä ja varsin kaukana mistään muusta painikkeesta. 6. Käyttäjän muistia ei kuormiteta kovin pahasti. Käytössä olevat komennot ovat selkeitä ja yksikäsitteisiä. Linkeissä ja napeissa voisi kuitenkin olla työkaluvihjeissä hieman pidemmät selitykset. 7. Varsinaisia pikanäppäimiä ei voi olla käytössä, koska ohjelma on selainpohjainen. Sarkaimella voi navigoida eri kenttien välillä. Muistiinpanon kirjoituskentästä pääsee sarkaimella save-nappiin, joten hiirtä ei tarvita. 8. Dialogi on varsin hyvää. Vasemmalla oleva työkaluvalikko on ehkä hieman monimutkainen, mutta on parempi pitää se mahdollisimman konsistenttina, kuin muutella eri näytöissä. Näyttö on jaettu selkeästi leveyssuunnassa valikolle ja sisällölle. Sisältö edelleen koko sivun leveydeltä vaakaviivoilla. Yksittäiset muistiinpanot ovat kukin omassa laatikossaan. 9. Sivulla on toimimattomia linkkejä, koska kaikkea toiminnallisuutta ei ole vielä toteutettu. Väärän muotoisen eräpäivän syöttäminen antaa selkeän palautteen. Virheteksti voisi ehkä olla punainen tai jotenkin muuten paremmin erottuva. 10. Dokumentaatiota ei vielä ole. 6.2 Löydetyt virheet Edellä olevasta laajemmasta analyysistä poimittiin seuraavaksi luetellut virheet. Kunkin virheen perässä on suluissa ilmoitettu virheen vakavuus. Kirjautumisvirheilmoitus on selkeä, mutta voisi ehkä olla väriltään punainen tai muuten paremmin erottuva. (vähäinen) 5

6 Kirjautumisvirheilmoitus kertoo kyllä selkeästi, että joko käyttäjätunnus tai salasana oli väärä, mutta lisäksi se voisi kertoa, kummasta oli kysymys. (vähäinen) Järjestelmään kirjauduttuaan ei voi nähdä, millä käyttäjätunnuksella on kirjautunut. (häiritsevä) Vanhentunutta sessiota ei pysty havaitsemaan, ennen kuin yrittää tehdä jotain. (vähäinen) Workgroup-termin merkitys ei ole itsestäänselvä, ellei sitä tiedä etukäteen. (häiritsevä) Archive-toiminnon tarkoitusta ei voi kovin helposti arvata. (häiritsevä) Due date olisi helpompi ymmärtää muodossa note is valid to tms. (häiritsevä) Show notes from -valikko voisi olla vähän selkeämpi. Active workgroup on hiukan epäselvä termi. (häiritsevä) Väärän muotoisen eräpäivän syöttäminen antaa selkeän palautteen. Virheteksti voisi kuitenkin ehkä olla punainen tai jotenkin muuten paremmin erottuva. (vähäinen) Dokumentaatiota ei vielä ole. (katastrofaalinen) Havaitut virheet huomioidaan toisen implementaatiokierroksen aikana. Lopputulokset kirjataan kyseiseen kohtaan tähän SEPA-päiväkirjaan. Osa virheistä, esimerkiksi dokumentoinnin ja avusteiden puute, on selkeitä ja tullaan korjaamaan, mutta osaa joudutaan miettimään tarkemmin. 7 Implementointi 2 Tämä kappale täytetään myöhemmin. 8 Viimeistely ja toimitus (Finalization and delivery) Tämä kappale täytetään myöhemmin. 9 Yhteenveto Tämä kappale täytetään myöhemmin. Viitteet [1] J. Nielsen, Heuristics for User Interface Design, heuristic/heuristic_list.html, viitattu [2] S. Riihiaho, Käytettävyyden arviointi ilman käyttäjiä, T-121/T /asiantuntija-arviot.pdf, viitattu [3] X. Faulkner, 2000, Usability Engineering. 1st edition, Macmillian Press ltd. 244 s. ISBN