SEPA Heuristinen arviointi

SEPA Heuristinen arviointi Versio Päivämäärä Muokkaaja Kuvaus 1.1 24.2.2006 Markus Kattilamäki Yhteenvedon lisäys, käyttöliittymäkuvat 1.01 11.1.2006 Kirsi Rönkkö Kirjoituksen korjailua, pieni lisäyksi sinne tänne. 1.00 3.12.2005 Markus Kattilamäki Dokumentti luotu 0.50 Kirsi Rönkkö Alustava dokumentti Wikiin

Sisällysluettelo 1 Johdanto... 2 2 Menetelmän käyttö... 2 3 Kokemukset ja muutokset... 4 3.1 Suunnitteluvaihe... 4 3.2 Implementaatio 1... 4 3.3 Implementaatio 2... 5 4 Yhteenveto... 7 5 Lähteet... 9 1

1 Johdanto Heuristisen arvioinnin tarkoitus on kehittää mahdollisimman käyttäjäystävällinen käyttöliittymä tuotteeseen. Heuristisella arvioinnilla voidaan arvioida tuotteen käytettävyyttä jo siinä vaiheessa, kun käyttöliittymä on vasta piirroksia paperilla. Lisäksi heuristisen arvioinnin säännöt antavat paremman pohjan tuotteen tutkimiselle, siten ettei tarvitse turvautua vain mutu-tuntumaan. Heuristisen arvioinnin tarkoituksena on käyttää hyväksi havaittuja ja olemassa olevia sääntöjä eli ns. heuristiikkoja käyttöliittymän arviointiin. Kun käyttöliittymää arvioidaan näitä sääntöjä käyttäen, on tarkoituksena löytää käyttöliittymästä käytettävyyttä laskevia ominaisuuksia ja tuoda käytettävyyttä mukaan ilman varsinaista käyttäjän osallistumista prosessiin. Arviointi tapahtuu yleensä 3-5 henkilön toimesta. Heuristisella arvioinnilla pyritään löytämään erityyppisiä ja yleisiä käytettävyysongelmia. Näitä voivat Riihiahon [3] mukaan olla esimerkiksi vieraiden termien käyttö, epäyhteneväisyydet tai virheet sommittelussa. Heuristisen arvioinnin etu on käyttöliittymän ongelmakohtien löytäminen yksinkertaisesti, nopeasti ja edullisesti. Heuristisen arvioinnin säännöt on kuvattu kattavasti kehittäjän Jakob Nielsenin kirjoittamassa kirjassa Usability Engineering [2]. Nielsenin kirjassa myös kuvataan heuristisen arvioinnin menetelmää. Suomeksi aiheeseen hyvän opastuksen on kirjoittanut Sirpa Riihiaho artikkelissaan Käytettävyyden arviointi ilman käyttäjiä [3]. Vaikka tässä projektissa keskitymmekin suunnitelmien arviointiin ja parannusehdotuksiin, voi heuristisia sääntöjä käyttää myös suunnittelun tukena. Tämä aihe valittiin muiden aiheiden joukosta, koska aihealue kiinnostaa tekijöitä ja lisäksi haluttiin saada mahdollisimman laadukas tuote aikaiseksi. Käytettävyys on yksi asia, jolla tuotteen laadukkuutta voidaan mitata. Lisäksi oikeiden käyttäjien hankinta voi olla projektissamme vaikeaa. Menetelmällä pyritään edesauttamaan lopputuotteen käytön sujuvuutta ja mielekkyyttä. 2 Menetelmän käyttö Mitä aikaisemmin heuristiikat otetaan mukaan tuotteen suunnitteluun, sitä paremmat tulokset käytettävyyden suhteen saavutetaan. Siksi ensimmäisen kerran heuristinen arvio tehdään tuotteelle pääarkkitehdin prototyypeille mahdollisimman aikaisessa vaiheessa. Pyrimme aloittamaan heuristisen arvioinnin heti suunnitteluvaiheessa tai ensimmäisen implementaation alussa. Tämän lisäksi käyttöliittymää arvioidaan heuristisesti ensimmäisen implementaation lopussa, jolloin käyttöliittymästä toivottavasti on jo jollakin tasolla toimiva versio. Toisessa implementaatiossa tarkistellaan uusia käyttöliittymiä. Tarkastelulla pyritään kattamaan kaikki asiakkaalle päätyvät käyttöliittymät: analysaattorin käyttöliittymä, Ilmo-simulaattorin käyttöliittymä ja WWW-sivusto, jolla Valppaan tietoja voi seurata ja muokata. Eri lähteissä suositellaan heuristista arviointia tehtävän 3-5 asiantuntijan voimin. Tässä tapauksessa varsinaisia asiantuntijoita ei ole joten käytetään parhaita saatavilla olevia henkilöitä arvioimaan tuotetta. Käytettävyyttä hieman enemmän kuin pelkän peruskurssin ovat lukeneet ainakin Kirsi ja Markus, joten heidät on valittu arvioijaryhmään. Koska käyttöliittymän tekijät eivät välttämättä ole parhaita mahdollisia arvioijia tuotoksilleen, jätetään pääarkkitehti ja käyttöliittymän toteuttavat 2

kehittäjät arvioijaryhmän ulkopuolelle. Jäljelle pitäisi jäädä ainakin testaaja ja muutama kehittäjä, jotka valitaan arvioijaryhmään. Projektissa käytetään yleisesti hyväksi havaittua tapaa jossa annetaan jokaisen arvioijan tutustua käyttöliittymään ja arvioida se heuristisesti itsekseen. Jokainen arvioija kirjaa löytämänsä tulokset liitteestä 1 löytyvään lomakkeeseen, johon myös lopulliset, yhdistetyt tulokset kirjataan. Arvioijan on myös hyvä miettiä kuinka vakava löydetty ongelma on. Riihiahon artikkelista löytyy kuusiportainen arviointiasteikko, mutta näin moniosainen asteikko on hieman turha, joten tyydymme lyhennettyyn asteikkoon: katastrofaalinen, vakava, vähäinen, kosmeettinen ja ei ongelma. Itsekseen tehtyjen arvioiden jälkeen tulokset ja mahdolliset parannusehdotukset kootaan yhdessä kaikkien arvioijien kesken lopulliseksi arvioksi. Tässä projektissa parannusehdotukset esitetään pääarkkitehdille, joka voi määrittää tarvittavat muutokset kehitettävään tuotteeseen. Mikäli menetelmä ei ole tuttu jollekin arvioijaryhmään valitulle opastukseksi käytetään Riihiahon artikkelia [3], joka on havainnollinen ja selostaa tarvittavat tiedot suomeksi. Tämän uskotaan riittävän, sillä monet ovat varmasti käyneet kurssin T-121.100 Johdatus käyttäjäkeskeiseen tuotekehitykseen, jossa asiaa valotetaan. Menetelmän hallitsemisen varmistamiseksi aiheesta pidetään pieni keskustelutuokio vielä ennen varsinaiseen työhön ryhtymistä. Seuraavissa taulukoissa on esitetty käytetyt heuristiikat [3] sekä arvioinnissa käytetyt ongelmien vakavuusluokat. Taulukko 1: Arvioinnissa käytetyt vakavuudet Vakavuudet 1 Katastrofaalinen 2 Vakava 3 Vähäinen 4 Kosmeettinen Taulukko 2Arvioinnissa käytetyt heuristiikat Heuristiikat 1 Käytä yksinkertaista ja luonnollista dialogia 2 Käytä käyttäjien omaa kieltä 3 Minimoi käyttäjän muistikuorma 4 Tee käyttöliittymästä kauttaaltaan yhdenmukainen 5 Anna käyttäjälle palautetta toiminnoista 6 Anna selkeä poistumistapa eri tiloista ja toiminnoista 7 Anna käyttäjälle mahdollisuus käyttää oikopolkuja 8 Anna virhetilanteista selkeät virheilmoitukset 9 Vältä virhetilanteita 10 Anna riittävä ja selkeä apu ja dokumentaatio 3

3 Kokemukset ja muutokset Kappaleessa on käsitelty menetelmän käyttöä projektin aikana ja esitetty kokemuksia sen käytöstä. Arvioinnin tulokset joihin tässä on viitattu, löytyvät dokumentin lopusta. Menetelmää käytettiin kummankin implementaatiovaiheen aikana. 3.1 Suunnitteluvaihe Menetelmän käyttöä suunniteltiin ja valmisteltiin projektin ensimmäisessä vaiheessa. Tarkoitus oli tehdä heuristinen arviointi jo tässä vaiheessa, mutta sopivaa arvioitavaa käyttöliittymää ei ollut saatavilla. Heuristista arviointia ei varsinaisesti käytetty vielä projektin suunnitteluvaiheessa. 3.2 Implementaatio 1 Valpas-projektin analysaattorin käyttöliittymäprototyyppi arvioitiin heuristisesto viikolla 46. Käyttöliittymää arvioi Kirsi Rönkkö, Antti Poikela, Markku Huttunen sekä Markus Kattilamäki. Yhteenvetotilaisuus pidettiin 21.11.2005, jolloin arvioijien tulokset käytiin läpi ja niistä tehtiin yhteenveto. Arvioitavana oli Javalla toteutettu käyttöliittymän prototyyppi joka ei kuitenkaan sisältänyt vielä toiminnallisuutta. Arvioijat täyttivät löytämänsä virheet valmiille lomakkeelle (liite 1) joka lähetettiin ohjeiden ja aihetta käsittelevän materiaalin kanssa heille ennen arviointia. Heuristiikkojen käyttö arviointimenetelmänä osoittautui varsin tehokkaaksi menetelmäksi käytettävyysongelmien löytämisessä ja käyttöliittymän parantamisessa. Arvioijat löysivät varsin erilaisia ongelmia, joka lisäsi merkittävästi menetelmän tehokkuutta. Tiettyjä heuristiikkoja käytettiin huomattavasi enemmän osan jäädessä kokonaan pois. Tämä johtui osaltaan prototyypin rajoituksista. Esimerkiksi yksinkertaisen ja luonnollisen dialogin käyttäminen esiintyi varsin useassa parannusehdotuksessa, kun taas heuristiikka joka koskee palautteen antamista käyttäjälle, ei esiintynyt arvioinnissa kertaakaan. Tämä johtui prototyypin toiminnallisuuden puutteesta. Kuten yleisesti heuristista arviointia käsittelevässä kirjallisuudessa todetaan, kokeneemmat arvioijat löysivät enemmän virheitä kuin kokemattomammat. Kokemuksen myötä taito käyttää heuristiikkoja ja löytää niiden avulla virheitä kasvaa. Toisaalta kokemattomammat arvioijat toivat hyvän lisän menetelmän käyttöön erilaisella näkökulmallaan, joten heidän mukana olonsa todettiin myös tarpeelliseksi. Oli myös hyvä että prototyypin osallistuja ei osallistunut itse arviointiin. Kun keskeneräistä käyttöliittymää eli sen prototyyppiä käydään lopuksi yhdessä läpi, tulevat parannusehdotukset paremmin esille ja siitä on helpompi esittää kritiikkiä kun toteuttaja ei ole puolustelemassa kantaansa. Arvioinnissa löydettiin yhteensä 35 virhettä. Näistä 3 oli katastrofaalista virhettä, 12 vakavaa virhettä, 11 vähäistä sekä 9 kosmeettista virhettä. Löydetyt virheet ovat listattu kokonaisuudessaan liitteessä 2. Käyttöliittymää korjattiin käyttäjäystävällisemmäksi löydettyjen virheiden perusteella arvioinnin jälkeen. Havaitut virheet olivat luonteeltaan sellaisia että niiden vaatimat korjaukset oli mahdollista toteuttaa. 4

Heuristinen arviointi hyödytti projektia myös siinä mielessä, että Analysaattoriin liittyvät vaatimukset eivät olleet kovinkaan selkeitä. Kun käyttöliittymää arvioitiin heuristisesti, esiin nousi myös asioita, jotka eivät välttämättä ole käyttöliittymään tai käytettävyyteen liittyviä, joiden miettiminen yhdessä auttoi Analysaattorin toteutuksessa. Näistä pohdinnoista johtuen monet ongelmat tuloksissa ovat kysymysmuotoisia. Ryhmä halusi jättää tällaiset kohdat tuloksiin helpottamaan käyttöliittymän ja Analysaattorin suunnittelijaa kiinnittämään huomiota ehkä unohtuneisiin asioihin. 3.3 Implementaatio 2 WWW-käyttöliittymän arviointi suoritettiin viikolla 4 edellisestä iteraatiosta tutulla arvioijaryhmällä ja yhteenvetotilaisuus pidettiin 24.1.2006. Edellisestä iteraatiosta muutosta oli tapahtunut lähinnä siinä, että liitteessä 1 löytyvään arviointilomakkeeseen lisättiin omat sarakkeet sivuja ja huomautuksia varten. Tämä johtuu siitä, että tässä iteraatiossa arvioitu käyttöliittymä sisälsi useita sivuja ja sama ongelma saattoi esiintyä monella sivulla. Toisen arviointikerran yhteydessä kerättiin myös tilastollista tietoa siitä, miten arvioijien kokemus vaikutti arviointiin. Tulokset on esitetty alla olevassa taulukossa arvioijan kokeneisuus järjestyksessä. Kokemus vaihteli kahdesta reiluun kymmeneen arviointi kertaan. Taulukko 3: Tilastoa arvioinnista Arvioija Aika Ongelmia Aika / ongelma A 45 min 21 2,1 min B 60 min 15 4,0 min C 60 min 9 6,7 min D 75 min 8 9,8 min Tuloksista voidaan havaita, että kokemus parantaa ongelmien löytämisnopeutta. Tämä johtuu siitä, että kokeneempi arvioija löytää enemmän virheitä ja lisäksi kuluttaa vähemmän aikaa itsenäisen arvioinnin vaiheessa. Tulokset ovat yhdenmukaisia aihetta käsittelevän kirjallisuuden [2, 3] kanssa. Kokemattomampia arvioijia ei silti tarvitse vierastaa, sillä heidän löytämissä ongelmissa oli asioita, joita kokeneemmat arvioijat eivät olleet joko huomanneet tai merkinneet ylös. Lisäksi useamman henkilön kesken tehty keskustelu ongelmista tuotti tulosta: yhteisistunnossa löydettiin ainakin kaksi sellaista ongelmaa, joita kukaan yksin ei ollut havainnut. Yhteisen keskustelun kautta hyvien ratkaisujen kirjo myös laajeni ja keskustelu sai aikaan ratkaisujen vertailua. Lopullinen ongelmien määrä nousi 34 kappaleeseen. Näistä vain yksi oli katastrofaalinen. Vakavia virheitä löytyi 9, vähäisiä 18 ja kosmeettisia 6. Eniten ongelmia löytyi laitteita yleisesti kuvaavalta sivulta. Tulos ei ole yllättävä, sillä kyseiseen sivuun liittyy eniten toiminnallisuutta ja se on samalla järjestelmän tärkein sivu. Heuristisen arvioinnin aiheuttamia muutoksia voidaan havaita seuraavalla sivulla olevista kuvista (ongelma kohdat on numeroitu vastaavan ongelman numeroin). 5

Kuva 1: "Laitteen lisäys" ennen heuristista arviointia Kuva 2: "Laitteen lisäys" valmiissa käyttöliittymässä 6

Heuristisen arvioinnin hyötynä voidaan nähdä ainakin se, ettei kaikkea sivustoon tarvittavaa toiminnallisuutta oltu muistettu suunnittelussa huomioida. Lisäksi uskomme, että heuristisella arvioinnilla saatiin käyttäjän kannalta tärkeitä näkökulmia esille, jotka loppukädessä helpottavat sovelluksen käyttöä. Tällaisia asioita ovat esimerkiksi sarakkeiden seurattavuus, kun lista laitteista on pitkä. Tehdystä heuristisesta arviosta huolimatta on käyttöliittymälle hyvä tehdä vielä heuristinen arviointi ennen jatkokehitystä tai lopulliseksi tuotteeksi saattamista. Toteutuksessa asioita ei välttämättä tehty aivan samalla tavalla, kuin heuristisen arvioinnin yhteydessä oli ajateltu ja käyttöliittymään on kohdistunut muitakin muutostarpeita. Kaikki muutokset olisi hyvä arvioida uudestaan sen jälkeen, kun järjestelmässä on myös toiminnallisuutta sivuston takana. 4 Yhteenveto Kuten tuloksista voidaan huomata, käyttämämme Nielsenin heuristiikat soveltuivat arviointiin melko hyvin. Toisaalta arvioitavan prototyypin toiminnallisuuden puute johti siihen että jotkin heuristiikat jäivät käyttämättä. Menetelmän avulla saimme karsittua hyvin käyttöliittymän käytettävyyteen vaikuttavia ongelmia. Neljän arvioijan löytämät virheet olivat samoista säännöistä huolimatta varsin erilaisia. Yhteinen virheiden läpikäynti auttoi virheen korjauksen suunnittelussa ja ideoinnissa. Kokonaisuudessaan käyttämämme arviointimenetelmä oli ennakko-odotusten mukaisesti tehokas ja nopea keino poistaa käytettävyysvirheitä prototyypin tasolla olevasta käyttöliittymästä. Arvioinnin hyödyllisyyden kannalta löydettyjen virheiden kommunikointi ja korjaus on oleellista. Kuten edellä mainittiin, tuotoksen tekijä ei osallistunut arviointeihin. Projektissamme vastuu tarpeellisten korjausten suorittamisesta oli pääarkkitehdillä. Johtuen erilaisista syistä, mm. muistiinpanojen ja dokumentaation kielestä sekä lievästä välinpitämättömyydestä, kaikki korjaukset eivät päätyneet lopullisiin käyttöliittymiin. Emme myöskään käsitelleet emmekä kirjanneet virheiden korjaukseen arvioitua aikaa. Arvioiden avulla kuitenkin oleelliset virheet tulivat löydetyksi ja katetuksi. Arviointiprosessi kehittyi projektin edetessä. Toisen iteraation arviointi sujui jouhevasti koska prosessi oli jo kerran viety läpi. Haasteita toisen kerran arviointiin toi huomattavasti valmiimpi käyttöliittymä kuin edellisessä vaiheessa. Täten arviointiin mahdollisesti vaikuttivat valmiit ratkaisut. Toisaalta heuristista arviointia ei pitäisikään nähdä täysin suunnittelumetodina vaan käytettävyyttä estävien ongelmien löytämiseen tekeillä olevasta käyttöliittymästä. Molemmissa arvioinneissa toiset heuristiikat esiintyivät tiuhemmin kuin toiset. Osittain asiaan vaikuttivat käyttöliittymien rajoittunut toiminnallisuus. Vaikuttaako sitten toisten heuristiikkojen puuttuminen arvioinnin tehokkuuteen? Tähän kysymykseen emme löytäneet vastausta kirjallisuudesta. Kuten Riihiaho [3] toteaa, heuristinen arvio ei korvaa loppukäyttäjällä tehtävää arviointia. Tästä seuraava askel olisikin testien tekeminen loppukäyttäjällä. Prosessia voisi lähteä kehittämään arvioinnin yhteydessä hyväksi havaitsemillaan omilla heuristiikoilla ja säännöillä jotka olisivat kyseiselle sovellusalueelle ominaisia. Kykenimme kuitenkin mielestämme hyvin soveltamaan Riihiahon [3] tarjoamaa arviointiprosessia projektissamme. Toinen hyvä apuväline 7

olisi ollut videotykki, josta läpikäyty järjestelmä olisi heijastettu kaikkien nähtäville. Tästä arvioinnin johtaja olisi voinut nostaa läpikäytävän asian konkreettisesti kaikkien nähtäville. Mielestämme toteutettavien käyttöliittymien heuristinen arviointi oli oleellinen osa niiden toteuttamista. Oleellista oli löytää prototyypeistä käyttöä haittaavia ominaisuuksia pienillä resursseilla. Heuristisen arvioinnin avulla tuotiin käyttöliittymien kehittämiseen mukaan käytettävyyden näkökulma, joka muuten kiireisessä projektissa olisi helposti jäänyt sivuasiaksi. Heuristinen arviointi vaikutti käyttöliittymän käytettävyyden huomioimiseen myös suunnitteluvaiheessa, koska suunnittelija tiesi sitä arvioitavan. Menetelmällä saatiin haluttu käytettävyyttä edistävä vaikutus projektin tuotoksiin. 8

5 Lähteet [1] Faulkner, X. 2000, Usability Engineering. Basingstoke, Palgrave. [2] Nielsen, J. 1993, Usability Engineering. Boston, Academic Press. [3] Riihiaho, S. 1998, Käytettävyyden arvioiminen ilman käyttäjää. Saatavilla (1.2.2006) http://www.soberit.hut.fi/t-121/t-121.5600/asiantuntija-arviot.pdf 9

Liite 1: Arviointi lomake Heuristiikat Vakavuudet 1 Käytä yksinkertaista ja luonnollista dialogia 1 Katastrofaalinen 2 Käytä käyttäjien omaa kieltä 2 Vakava 3 Minimoi käyttäjän muistikuorma 3 Vähäinen 4 Tee käyttöliittymästä kauttaaltaan yhdenmukainen 4 Kosmeettinen 5 Anna käyttäjälle palautetta toiminnoista 6 Anna selkeä poistumistapa eri tiloista ja toiminnoista 7 Anna käyttäjälle mahdollisuus käyttää oikopolkuja 8 Anna virhetilanteista selkeät virheilmoitukset 9 Vältä virhetilanteita 10 Anna riittävä ja selkeä apu ja dokumentaatio ID Sivu Vakavuus Ongelma Heuristiikat Parannusehdotus Huom. 10

Liite 2: Analysaattorin käyttöliittymästä löytyneet ongelmat ID Vakavuus Ongelma Heuristiikat Parannusehdotus H01 1 Miten kerrotaan mistä tiedot luetaan? Tai jos se on avaa, niin miten erotellaan simulaattorin ja valppaan tiedot? Tarvitseeko ohjelmalle edes kertoa, että kumpaa tieto edustaa? 1 Olisi hyvä, jos ohjelma osaisi päätellä asian. H02 1 Ei ole mitään käsitystä mitä eri väriviivat tarkoittavat H03 1 Liittyvätkö alanreunan tekstit valppaaseen vain simulaattoreihin? H04 2 Väriviivat ja eri laitteiden nimet sotkevat toisiaan H05 2 Kun ikkunaan ei mahdu kaikki näytettävä tieto ei viivojen tarkoitus ole selkeä. Kellon ajat jäävät piiloon vierityksen taakse. H06 2 Voiko tulokset tallentaa johonkin? Nyt käyttäjä voi joutua odottamaan kohtuuttoman pitkään, jos samat tiedot pitäisi analysoida joka kerta uudestaan 2, 10 Jos värillä, koolla tai suunnalla on väliä, tulisi se selittää pikaisesti 1, 3, 9, 10 Pitäisikö tiedot alhaalla ryhmitellä Valppaan ja simulaattorien mukaan ja sitten kaikki yhteensä. Lisätään otsikot. 1 1, 10 Skaalataan ikkunan koon mukaan ja lisätään aikatiedot myös taulukon päälle. 3, 10 Tiedot olisi hyvä voida tallentaa analysoidut tiedot. Mahdollisesti tiedon voisi myös tallentaa niin, että se olisi fiksu myös tekstitiedostona H07 2 Tietojen näkyminen vaatii suunnattoman suuren resoluution. Ei voida olettaa, että kaikilla käyttäjillä on suuri resoluutioinen näyttö 1 Skaalataan kuvaa H08 2 Ohjeet puuttuvat 10 Ohjeistusta lisää ainakin valikkoon. Lisäksi tooltipit voisivat toimia H09 2 Miten voi lisätä, poistaa tai vaihtaa tietoja, joita analysoidaan ilman, että vaihtaa kaikkia? Vai tuleeko kaikki luetella kerralla? 3, 6, 7, 9, 10 Lisätään lisää, poista ja vaihda painikkeet tai vastaavat toiminnot H10 2 Mistään ei tiedä minkä lokin on avannut 3 Lokitiedostoista voisi näyttää miltä aikaväliltä ne ovat. Aukiolevista lokeista voisi olla erillinen dialogi ja paneli näytöllä. H11 2 Käyttäjä haluaa nähdä virheellisten viestien suhteen onnistuneista, tämä ei ole tarpeeksi erottuva tieto, jos löytyy 1,3 Lisätään informaatiota esim. linjapollausviestien onnistumisprosentti 11

H12 2 Voiko valita pienemmän aikavälin analysoinnille, kuin lokien tiedot? H13 2 Osaako analysaattori valittaa siitä, ettei tiedot ole samoilta aikajanoilta H14 2 Selviääkö analysaattori tilanteesta, jossa valpas on käynyt alhaalla? Tällöin valppaalta on kaksi tiedostoa luettavana? H15 2 Käyttäjä voisi arvostaa myös tietoa keskimääräisestä linjavian korjaantumisajasta 1, 10 Annetaan mahdollisuus määrittää aikaväli, jolta analysointi määritetään 3, 9 Jos tiedostoissa ei ole valitulta aikaväliltä tietoa, niin tämä tulisi kertoa käyttäjälle 3 Analysaattori voisi hvyäksyä myös valppaalle useamman lokitiedoston, jos halutaan tehdä pidemmän aikavälin analysointia 1, 3 H16 3 Kellon ajat eivät ole viivan kohdalla 1, 4 H17 3 Voiko laitteiden nimiä vaihtaa jostain? Mistä 1, 10 Tietojen lukemisen yhteydessä voisi ne asetataan? määrittellä myös laitteen nimen? H18 3 Mitä tarkoittaa suorita? 2, 10 Vertaa / tee analysointi H19 3 Alareunan boxin tekstejä on vaikea huomata 1, 3 H20 3 Minkälaista palautetta käyttäjä saa, kun tietojen analysoidaan (ei ilmeisesti tapahdu hetkessä) 5 Progress bar mukaan H21 3 Oikopulut eivät vastaa konventioita 1, 7 Ctrl + o ja ctrl + q H22 3 Alareunan tiedot ovat klimpissä, eivät 1 Kolumnien väliin enemmän tilaa erotutoisistaan H23 3 Toimintojen löytäminen hankalaa, aluksi ei huomaa valikoiden olemassa oloa 1, 4, 10 Yleisimmät toiminnot voisi sijoittaa nappuloina näytölle H24 3 Aikaskaala ei ole yhdenmukainen 4 Aika pitäisi vaihtua tasaisin välein H25 3 Akselien aikavälit ovat kovin suuria, ei 1, 3 Lisätään mahdollisuus aikajana välttämättä saa selvää, koska viesti lähetetty. tihentämiseen ja skaalaamiseen. Tai viestin tiedot näytetään kun valitaan viestiä vastaava viiva. H26 3 Teksti oli kovin pientä 1 Tekstin voisi isontaa hieman H27 4 Alun aikatiedot eivät ole aseteltu samalla 4 tavalla kuin lopun aikatiedot. H28 4 Lokin alku/loppu on turhaa tietoa 1 Poistetaan turha teksti H29 4 Valikoissa vain yksi toiminne, sama kuin 1 Joku vain yksi menu tai sitten valikon otsikko painikkeiksi ohjelmaan. H30 4 Log tai logi ei ole suomea 2 Loki H31 4 Onnistumisprosentissa ei ole %-merkkiä 2, 10 Lisätään 5-merkki H32 4 Luvut eivät oikein erotu tesktin seasta alareunan tekstissä 1 Taulukkomainen esitys tai korostus numeroihin 12

H33 4 Linjapollaus ei välttämättä suomea 2 linjakysely? H34 4 Lokin aloitus- ja lopetusajan tarkkuus erilainen kuin akseleissa 4 Kumpaankin sekunnit tai kummastakin sekunnit pois H35 4 Kello on turhaa tietoa päivämäärässä 1 Poistetaan kello sana 13

Liite 3: WWW-käyttöliittymästä löytyneet ongelmat Sisäänkirjautuminen ID Vakavuus Ongelma Heuristiikat Parannusehdotus Huom. H01 4 Login-painike ei ole yhtenäisessä 1, 4 Siirretään painike joko linjassa käyttäjän toimintojärjestyksen kanssa. kenttien alle tai niiden oikealle puolelle H02 3 Sivulla olevat elementit ovat niin kiinni toisissaan, että niitten erottaminen ja hahmottaminen on vaikeutunut H03 3 Sivu on englanninkielinen seuraavan sivun ollessa suomenkielinen H04 3 Kaikki tiedot on sijoitettu aivan reunaan ja yläkulmaan. H05 3 Ei mahdollisuutta palauttaa unohdettua salasanaa Laitteiden tarkistelu sivu 1 Lisätään tyhjää tilaa eri kenttien ymppärille. 2, 4 Vaihdetaan sivun tekstit suomeksi. 1 Sijoitetaan tiedot keskemmälle sivua paremman visuaalisuuden vuoksi. 3 "Unohditko salasanasi?" Koskee kaikkia sivuja ID Vakavuus Ongelma Heuristiikat Parannusehdotus Huom. H06 4 Taulukko ei ole yhtenäinen 4 H07 4 Tiedot laitteesta eivät välttämättä 1 Pitäisikö tiedot laitteen tilasta siirtää ole loogisia käyttäjän kannalta: ennen kellonaikaa? Myös laitteen Jos tulee hälytys, on ensisijaisen pohjavärin voisi värittää tärkeää tietää mistä laiteesta on hälytystilanteessa erilaisella värillä kyse ja vasta sitten milloin hälytys on alkanut. H08 4 Taulukon ulkoreunoja oon 1, 4 Paksumpi viiva taulukon ulkoreunalle vaikea hahmottaa H09 2 Yhteenveto laitteiden tilasta puuttuu, käyttäjä ei näe helposti monellako laitteella on ongelmia. H10 2 Sivulla ei ole minkäänlaista ohjeistusta H11 2 Laitteen manuaalisen testaukseen puuttuu välineet tältä sivulta H12 2 "Hälytykset" -> "Hälytys" saattaa hämmentää käyttäjää, on toisteista informaatiota, eikä anna lisätietoa. H13 2 Jos laitteella on hälytys, mistä tietää kuinka kauan laitteella on ollut hälytys? Käyttöliittymä näyttäisi näyttävän ainoastaan 3, 10 Lisätään sivun yläreunaan tieto vikojen kokonaismäärästä, lajitellaan vialliset laitteet ylös. 10 Lisätään linkki ohjeisiin. Koskee kaikkia sivuja 1, 3, 7 Lisätään mahdollisuus testata laitteen kunto painikkeesta. 1, 2, 10 Sarakkeet mieluummin "Hälytys" ja "Vikaa", joka jakautuu kahteen sarakkeeseen: "linjassa" ja "laitteessa". 1, 3, 9 Käyttöliittymään voisi lisätä tiedon hälytysten alkamisajasta. Paras varmaan hälytyksestä kertovaan sarakkeeseen kuvakkeen alle 14

viimeisen testausajan. H14 2 Jos laitteita on monta, on alareunan linkit "Lisää uusi laite" ja "Kirjaudu ulos" vaikeasti saavutettavissa. H15 3 "Laite" ei välttämättä kerro minkälaisesta hälytyksestä on kyse. H16 3 Punainen X ei ole tarpeeksi erottuva. H17 3 Jos laitteita on monta, voi olla vaikea erottaa mihin sarakkeeseen rasti kuuluu. 1, 4, 6 Siirretään linkit laitetietojen yläpuolelle. Uloskirjautumis-linkki oikeaan yläkulmaan konvention mukaisesti. 1, 3 Vaihdetaan sanaan "Huolto". 1 Valitaan näkyvämpi symboli ja/tai tapa ilmoittaa viasta ja hälytyksestä. 1, 3 Valitaan erilaisille vioille ja hälytyksille kullekin omanlaisensa symboli tai väritys, josta vika on helppo assosioida (esim. katkennut johto, hälytyskello). Otsikkoa voidaan myös toistaa tai otsikko voidaan pitää kiinteänä H18 3 Muokkaa ja Poista ovat linkkejä. 1, 4 Muutetaan linkit nappuloiksi. H19 3 Sarakeotsikoita on vaikea 1, 4 Lihavointi ja/tai isompi teksti hahmottaa Lisää uusi laite ID Vakavuus Ongelma Heuristiikat Parannusehdotus Huom. H20 1 Uutta laitetta ei voi tallentaa 1, 5, 9 Lisätään sivulle Peruuta ja Myös järjestelmään Tallenna -painikkeet Muokkaussivulla H21 4 Numeroarvoille tarkoitetut kentät ovat hirvittävän leveitä niihin tulevaan dataan nähden. H22 2 Ohjeistus häiritsee käyttämistä ja tekee ulkoasusta sekavan. 1, 3 Kavennetaan numeroarvoihin liittyviä kenttiä. 1, 4 Siirretään ohjeet ja selvennyksen kentän oikealle puolelle vihjeiksi ja esimerkeiksi H23 2 Verkko-osoite on hämäävä termi 3, 9, 10 TETRA-osoite, ja esimerkki perään H24 3 Tiedot ovat turhan tiheässä sekä pysty- että vaakasuunnassa. 1, 4 Lisätään välejä ainakin sulkujen ja kaksoispisteiden viereen ja lisätään tyhjää tila tekstin ja kenttien väliin. Myös Muokkaussivulla Myös Muokkaussivulla Myös Muokkaussivulla Myös Muokkaussivulla H25 3 Tietoja on vaikea hahmottaa 1 Lisätään valiotsikoita. Myös Muokkaussivulla H26 3 Jos laitteen nimen on tarkoitus olla fyysinen katuosoite, on sille varattu kenttä kovin kapea. 1, 3 Levennetään nimi kenttää. Myös Muokkaussivulla 15

H27 3 Back-linkki 2, 4 Peruuta-painike Myös Muokkaussivulla H28 3 Kentät eivät ole minkäänlaisessa linjassa toisiinsa nähden H29 3 Käyttäjälle ei tarjota uloskirjautumismahdollisuutta 1, 4 Sijoitetaan kentät samaan kohtaan. Tasataan reunoista 4, 6 Jokaisella sivulla pitäisi näkyä kirjaudu ulos -painike. Myös Muokkaussivulla Myös Muokkaus- ja Poista-sivulla Poista laite ID Vakavuus Ongelma Heuristiikat Parannusehdotus Huom. H30 4 Kyllä ja Ei ovat linkkejä. 1, 4 Muutetaan linkit nappuloiksi. H31 2 Käyttäjä ei saa 5 Näytetään käyttäjälle jonkin aikaa tietoa Myös minkäänlaista palautetta siitä, että laite poistettiin onnistuneesti ja laitteiden siitä, että poistaminen siirrytään vasta sitten Laitteet-sivulle tai lisäys onnistui. näytetään viestiä pääsivun yläreunassa. H32 3 Poistettavasta laitteesta näytetään vain nimi, jonka käyttäjä ehkä muistaa väärin. H33 3 Poista voi olla liian radikaali termi yksinään H34 3 Kyllä ja Ei eivät ole yhdenmukaisia muiden sivujen kanssa 3, 9 Näytetään sivulla myös laitteen TETRAosoite tiedot ja mahdollisesti muita tietoja. 2, 5 Vaihdetaan "Poista laite valvonnasta" tai "Poista laite käytöstä". 4 Peruuta ja Poista 16