SEPA PÄIVÄKIRJA HEURISTINEN ARVIOINTI. Eero Kallio 54942R Ilkka Terho 57643U Kaarlo Lahtela 61439P

SEPA PÄIVÄKIRJA HEURISTINEN ARVIOINTI Eero Kallio 54942R Ilkka Terho 57643U Kaarlo Lahtela 61439P

SEPA päiväkirja Sivu 1

SEPA päiväkirja Sivu 2 SEPA PÄIVÄKIRJAN VERSION HALLINTA Versio Päivämäärä Kirjoittaja Kuvaus 0.9 9.10.2005 Terho Yleinen kuvaus aiheesta ja suunnitelma menetelmän käyttöönotosta 1.0 14.11.2005 Lahtela Dokumentin katselmointi. Pieniä päivityksiä. 1.1 16.11.2005 Kallio Vaihe 1 1.2 23.11.2005 Terho Prosessiin tehdyt muutokset ensimmäisen heuristisen arvion jälkeen 1.3 29.11.2005 Kallio Yleistä hiomista 1.4 30.11.2005 Lahtela Vaihe 2 2.0 Terho Yhteenveto

SEPA päiväkirja Sivu 3 SISÄLTÖ 1. JOHDANTO...4 1.1. Aihe...4 1.2. Aiheen valinta...4 2. KÄYTTÖÖNOTTO...5 2.1. Aikataulu...5 2.2. Toteuttajat...5 2.3. Toteutus...5 2.3.1. Heuristiikka...5 2.3.2. Heuristinen arviointi...6 2.3.3. Käytettävyysongelmien priorisointi...6 2.3.4. Hyödyntäminen...6 3. KOKEMUKSET JA MUUTOKSET...7 3.1. Vaihe 1...7 3.2. Vaihe 2...8 3.3. Yhteenveto...8 LIITTEET...1 1. Heuristiset löydökset ensimmäisessä vaiheessa...1 2. Heuristiset löydökset toisessa vaiheessa...5

SEPA päiväkirja Sivu 4 1. JOHDANTO 1.1. Aihe 1.2. Aiheen valinta Valitsimme SEPA aiheeksi heuristisen arvioinnin. Heuristisessa arvioinnissa asiantuntijat arvioivat käyttöliittymää tai sen prototyyppiä heuristiikkoja vastaan. Menetelmällä saadaan palautetta järjestelmän käytettävyydestä jo kehityksen alkuvaiheessa. Lähteet Riihiaho, Käytettävyyden arviointi ilman käyttäjiä Nielsen, J. (1993). Usability Engineering. Academic Press, Boston, MA. Projektiryhmämme oli suuri, joten pyrimme siihen, että SEPA-käytännöillä katettiin laajasti projektin käytäntöjä. SEPA-ryhmällemme sovittiin aiheeksi käytettävyys ja valitsimme heuristisen arvioinnin toteutettavaksi käytännöksi. Ohjelmistoprojektiimme kuului prototyyppi vaihe. Prototyypillä tutkittiin Klusterien visualisointikomponentin toteutusta. Komponentin käyttöliittymä oli oleellinen osa projektiamme, joten käytettävyyden varmistaminen oli tärkeää. Prototyypin tarkoituksena oli pääasiassa kartoittaa ominaisuudet, joita järjestelmään haluttiin. Käyttöliittymän käytettävyys jäi tämän tarkoituksen ulkopuolelle, joten pyrimme heuristisella arvioinnilla estämään yleisten hyvien käytäntöjen unohtumisen. Heuristinen arviointi tuki näin ollen prototyypin rakennusprosessia ja tarjosi siihen käytettävyyden näkökulman.

SEPA päiväkirja Sivu 5 2. KÄYTTÖÖNOTTO 2.1. Aikataulu 2.2. Toteuttajat 2.3. Toteutus Prototyyppi rakennettiin ensimmäisen iteraation aikana. Heuristinen arviointi sopi hyvin vaiheittain kehittyvän prototyypin eri versioiden arviointiin nopealla aikataululla. Ensimmäinen heuristinen arviointi tehtiin paperiprototyypille heti sen valmistuttua. Toinen arvio tehtiin Swing-prototyypille. Heuristisen arvioinnin tuloksia sovellettiin mahdollisuuksien mukaan ensin paperiprototyyppiin ja sitten kehitettäessä Swing-prototyyppiä. Prototyypin perusteella kirjoitettiin käyttöohje Klusterien visualisoinnille. Käyttöohje valmistui ensimmäisen iteraation lopussa, jonka jälkeen käyttöliittymään ei tehdä enää suuria muutoksia. Tästä johtuen heuristista arviointia tehtiin ja voidaan tehdä vain ensimmäisessä iteraatiossa. Heuristista arviointi toteutettiin SEPA-ryhmän sisällä eli arviointiin osallistuivat Ilkka Terho, Eero Kallio ja Kaarlo Lahtela. Kaikki arviointiin osallistuneet tuntevat aihealueen hyvin ja ovat opinnoissaan suorittaneet kursseja käytettävyydestä. Arvion tekijät olivat näin ollen parhaita saatavilla olevia asiantuntijoita. Eero kuului prototyypin toteutusryhmään ja myös esitteli prototyyppiä koko ryhmälle. Ilkka oli vastuussa projektin vaatimusten määrittelystä ja oli ollut alusta asti mukana järjestelmän suunnittelussa. Kaarlo vastasi testaamisesta ja oli tämän takia hyvin perillä sekä järjestelmälle asetetuista vaatimuksista, että laatuvaatimuksista. Järjestelmän yleinen rakenne ja toiminta oli kaikille arvioijille tuttu, joten arvioinnissa voitiin keskittyä pelkästään Klusterien visualisointikomponenttiin ja sen käytettävyysongelmiin. 2.3.1. Heuristiikka Arvioinnissa käytettiin heuristiikkana Nielsenin ja Molichin kymmenen säännön listaa: 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äjille 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

SEPA päiväkirja Sivu 6 2.3.2. Heuristinen arviointi 9. Vältä virhetilanteita 10. Anna riittävä ja selkeä apu ja dokumentaatio Ryhmä kokoontui ensimmäisessä arvioinnissa yhteen tilaan, jossa jokainen teki itsenäisen heuristisen arvioinnin käyttöliittymälle. Aikaa itsenäiseen arviointiin kului noin tunti, jonka jälkeen havaitut ongelmat listattiin yhdessä. Toisella kertaa ryhmä teki omatoimisesti arvioinnin Swing-prototyypille, koska ensimmäisellä kertaa arviointi vei hyvin eri ajan eri arvioijilla. Näin varmistettiin tehokas ajankäyttö ja yhdessä voitiin paneutua keskusteluun, jossa arvioitiin ja pohdittiin heuristiikkojen esiintuomista ongelmista. 2.3.3. Käytettävyysongelmien priorisointi 2.3.4. Hyödyntäminen Listatut ongelmat priorisoidaan Nielsenin asteikolla: 0 - Ei ole käytettävyys ongelma 1 - Kosmeettinen ongelma. Korjataan jos aika riittää. 2 - Pieni käytettävyysongelma. Korjaaminen on matalalla prioriteetilla. 3 - Suuri käytettävyysongelma. Korjaaminen on korkealla prioriteetilla. 4 - Käytettävyys katastrofi. on pakko korjata ennen julkaisua. Heuristisen arvioinnin jälkeen Eero Kallio sai listan löydetyistä käyttöliittymän käytettävyysongelmista. Lista oli näin heti prototyypin toteutusryhmän käytössä. Listatuista käytettävyysongelmista keskusteltiin prototyypin toteutusryhmässä ja tarpeelliset muutokset tehtiin prototyypin seuraavaan versioon. Aivan kaikkia ongelmia ei ratkaistu, koska ne olisivat olleet osittain uusia ominaisuuksia, joille ei ollut tarvetta.

SEPA päiväkirja Sivu 7 3. KOKEMUKSET JA MUUTOKSET 3.1. Vaihe 1 Ensimmäinen heuristinen arvio toimi paremmin kuin oli odotettu ja kokonaisuutena hyvin. Pieniä käytettävyysongelmia löytyi heuristiikkojen avulla paljon. Suurin osa niistä oli hyvin teknisiä ja asiantuntijamaisia, koska käyttäjiltä saatua tietoa ei ollut käytössä. Tämä toi paljon uusia ideoita ja näkemyksiä prototyypin toteutusryhmälle, joka oli keskittynyt lähinnä käyttäjiltä saadun palautteen mukaiseen toteutukseen. Paperiprototyypin arviointi oli haasteellista, koska interaktiivisuutta ei ollut, tämä aiheutti jonkin verran arvailua toiminnallisuudesta. Etuna ryhmällä oli se, että Eero Kallio oli suunnittelemassa paperiprototyyppiä. Tämä mahdollisti hedelmällisen keskustelun löydytyistä ongelmista, kun ryhmän havaintoja koottiin yhteen. Haittapuolena oli vastaavasti se, ettei Kallio pystynyt tekemään heuristista arviointia täysin objektiivisesti, ja havaintoja syntyi muuta ryhmää vähemmän. Oletimme ensimmäisen vaiheen jälkeen Swing-prototyypin tarjoavan todenmukaisemman esityksen käytettävyydestä. Oletimme myös, että paperiprototyyppiin verrattuna käytettävyysongelmia löytyy vähemmän, koska oikeasti interaktiivinen käyttöliittymä vähentää epävarmuutta ominaisuuksien toiminnasta ja näin ollen olemattomien ongelmien raportointia. Toisaalta näimme riskinä sen, että odotettavissa olisi voinut olla myös epäloogista toiminnallisuutta, jota paperiprototyypissä ei ole. Emme muuttaneet hyväksi havaittua prosessia paljoa, mutta kaksi muutosta näimme tarpeelliseksi. Päätimme tehdä arvion omilla työasemillaan sovittuun päivään mennessä sen sijaan, että olisimme tehneet arvion yhtä aikaa samassa paikassa. Syitä tähän muutokseen oli kaksi: Ensimmäisessä heuristisessa arviossa arvioon kulunut aika vaihteli paljon ryhmän jäsenten välillä. Nopein ryhmän jäsen joutui odottamaan hitainta, joka taas joutui kiirehtimään, jotta saisi kaikki heuristiikat läpikäydyiksi. Kun arvio suoritetaan omalla ajalla, voi jokainen käyttää tarvitsemansa ajan. Toinen syy on paperiprototyypin vaihtuminen Java Swing prototyyppiin. Prototyypin ajaminen omalla koneella on helpompaa kuin sopivien vapaiden työasemien löytäminen koululta. Toinen muutos koski havaittujen käytettävyysongelmien kirjaamista. Ensimmäisessä arviossa havaitut ongelmat kirjattiin paperille ja ne kirjoitettiin puhtaaksi vasta yhteisessä läpikäynnissä. Kirjoittaminen vei huomiota ongelmien vakavuuden arvioinnilta. Toisessa toteutuksessa jokaisen ryhmän jäsenen piti kirjoittaa havaitsemansa ongelmat selkokielellä puhtaaksi ja tulostaa tuotoksen yhteistä läpikäyntiä varten. Läpikäynnin jälkeen ongelmat oli tarkoitus lähettää vielä sähköisessä muodossa yhdelle ryhmän jäsenistä, joka kokoaa ongelmat yhteen listaan. Tällä muutoksella on tarkoitus nopeuttaa yhteistä läpikäyntiä poistamalla siitä turha puhtaaksikirjoitusvaihe.

SEPA päiväkirja Sivu 8 3.2. Vaihe 2 3.3. Yhteenveto Toinen heuristinen arvio antoi paljon palautetta ensimmäisen tavoin. Odotimme löytävämme vähemmän ongelmia kuin ensimmäisellä arviointikerralla, mutta löydettyjen käytettävyysongelmien määrä pysyi suurin piirtein samana. Arviossa käytetty Swing prototyyppi oli todenmukaisempi ja pieniin ongelmakohtiin oli näin helpompi puuttua. Arviot tehtiin omilla koneilla ennen ryhmän tapaamista ja jokainen kirjoitti havaintonsa puhtaaksi. Tapaamisessa koottiin ryhmän löytämät ongelmat yhteen ja kirjoitettiin ne puhtaaksi suunnitelmista poiketen yhdessä ryhmän kanssa. Tarkoitus oli että listaus olisi tehty valmiiksi, mutta yhteistuumin ongelmien kirjaaminen tuntui kuitenkin luontevimmalta ja herätti eniten keskustelua. Näin saatiin myös karsittua päällekkäiset ongelmat ja voitiin arvioida parannusehdotusta. Keskustelun yhteydessä löydettiin myös lisää ongelmia, kun uusia näkökulmia oli auennut muiden löytämien ongelmien avulla. Lopuksi arvioimme ongelmien vakavuutta ja annoimme ongelmille korjausprioriteetin. Ryhmämme monimuotoisuus näkyi jälleen hyvin ongelmien löytämisessä. Ilkka Terho löysi paljon ongelmia heuristiikkojen pohjalta. Kaarlo Lahtela löysi taas enemmän teknisiin ongelmiin liittyviä ongelmia, syvän teknisen tuntemuksensa avulla. Muilla oli etulyöntiasema ongelmien löytämisessä Eero Kallioon nähden, koska hänellä oli pieni sokeus omaan työhönsä. Saimme kuitenkin erittäin kattavan listan ohjelmassa piilevistä käytettävyysongelmista. Heuristinen arviointi todettiin ryhmän kannalta hyväksi tavaksi jakaa tietoa käyttöliittymästä ja kartoittaa käyttöliittymän käytettävyyttä sekä sen ongelmakohtia. Menetelmä osoittautui myös suhteellisen kevyeksi toteuttaa ja sen tulokset yllättivät positiivisesti. Käytettävyysongelmien löytyminen lisää myös arvioijien tietämystä käyttöliittymästä. Lisäksi tarkat kuvaukset ongelmista ovat suunnittelijoille paljon hyödyllisempiä kuin pikaiset kommentit ihan hyvältä näyttää. Tekniikka on siis yksinkertainen mutta toimiva ja sen käyttöä voi luonnehtia kilpailukykyiseksi ja erinomaiseksi tavaksi iteroida käyttöliittymää. Seuraavassa on listattu heuristisen arvion eri vaiheisiin kuluneet ajat per henkilö - Aiheen valinta ja perustelu 1 h - perehtyminen aiheeseen 3h - ensimmäisen toteutuksen suunnittelu ja suunnitelman kirjaaminen 2h - toisen toteutuksen suunnittelu ja suunnitelman kirjaaminen 1h - ensimmäinen heuristinen arvio 2h - toisen heuristisen arvion itsenäinen osa 1h - toisen heuristisen arvion yhteinen osa 1h - SEPA päiväkirjan kirjoittaminen 2h

SEPA päiväkirja Sivu 9 - tulosten raportoiminen projektille vaiheessa 1 1h - tulosten raportoiminen projektille vaiheessa 2 1h SEPA:n kului noin 15 tuntia per henkilö. Tuntimäärä jäi siis reilusti alle budjetoidun 20 tunnin. Käytännön käyttöön ohjelmistoprojektissa kuluisi tämän laskelman mukaan reilu kymmenen tuntia per henkilö, kun kurssin vaatimat muodollisuuden jätetään laskuista. Mielestämme tämä on vähän suhteessa löydettyjen ongelmien määrään ja vakavuuteen.

SEPA liite 2 Sivu 1 LIITTEET 1. Heuristiset löydökset ensimmäisessä vaiheessa ID 1 Prioriteetti 0 Minimapin sijainti Voisi olla keskellä ID 2 Mitä liput ovat minimapissa (merkitys epäselvä) Merkityksestä voisi kertoa esim. kun kursori on päällä ID 3 Ruutu 2 Mikä on "save dataset" Poistetaan ja käytetään copyä sen sijaan ID 4 Ruutu 3 Mitä ovat editin alta löytyvät optiot Poistetaan cut ja paste ID 5 Värien käyttö Kontrasti priotiteetin mukaan ID 6 Ruutu 4 Miten zoom toimii Esim. nuoli-ikkuna jolla voi liikkua zoomin sisällä (+ zoomit bonuksena) ID 7 Ruutu 6 Ei välttämättä geenejä Pitää olla dynaamisia

SEPA liite 2 Sivu 2 ID 8 0 Geenien määrä epäselvä voisi olla esim. kpl ID 9 Ruutu 6 Heatmap - parallel epäselvä Esim. tabimaisesti ID 10 Ruutu 6 Dataset Cluster epäselvä Esim. dataset -> cluster html tyylisesti ID 11 Heuristiikka 7 Mistä pääsee clusterinäkymään Esim. hiiren oikea näppäin ja boldattu Open tai Open nappi clusterilistan alla ID 12 Prioriteetti 0 Mitä ovat optionsin jutut Voisi lukea kuvassa, että missä niitä on käytetty ID 13 Prioriteetti 0 Minimap nimi on vaikea Voisi olla esim. zoomlevel ja lisäksi näkyä zoomauksen taso ID 14 Ruutu 2 Mitä eroa send to clipboard ja copy Poistetaan send to clipboard

SEPA liite 2 Sivu 3 ID 15 Heuristiikka 4 Ruutu 4 Miksi zoomaukset on isoilla kirjaimilla Voisi olla pienillä kirjaimilla ID 16 Ruutu 6 Statusbar puuttuu Voisi olla statusbar ID 17 Ruutu 7 Miksi lyhennetty coord. Voisi olla kokonaan ID 18 Heuristiikka 4 Ruutu 2 Prioriteetti 0 Puuttuu Pitää olla jos aukaisee uuden ikkunan ID 19 0 Ruutu 7 Viivojen selitykset Voisi olla nimet reunassa ID 20 Heuristiikka 6 Ruutu 7 Joku ero dataset cluster ja heatmap parallel coord. Esim. eri tyyleillä ID 21 Heuristiikka 7 Ruutu 4 Prioriteetti 0 Minimapissa voisi olla zoombar Esim. rullahiirellä ID 22 Mikä clusteri valittuna Aktivoida clusteri ja

Sivu 4 SEPA liite 2 Heuristiikka 3 värittää se kuviin ID 23 Heuristiikka 3 Mitkä clusterit jo katsottu Esim. joku merkintä tai värin muutos ID 24 Heuristiikka 3 Miten voi laittaa omia merkintöjä Pitää voida laittaa esim. omia lippuja ID 25 Heuristiikka 3 Mistään ei näy mikä datasetti avattuna Pitää näkyä mikä datasetti on avattuna ID 26 Heuristiikka 3 Mistä tietää missä koordinaateissa on Pitää näkyä koordinaatit myös kuvassa ID 27 Heuristiikka 5 Kun sorkkii optioneja, niin mistä tietää meneekö päivitys jakoon Pitää näyttää päivitystila esim. statusbaarissa ID 28 Heuristiikka 7 Ruutu 2 Miksi ei ole shortcuttia send to clipboard Pitää olla shortcut ID 29 Heuristiikka 8 Jos ei ole klustereita niin mitä sitten Pitää kertoa jos ei ole klusteria

SEPA liite 2 Sivu 5 2. Heuristiset löydökset toisessa vaiheessa ID 1 Ikkuna 5 Prioriteetti 0 Statistics on hassussa kohtaa Preferences ja statistics voisi vaihtaa paikkaa ID 2 Ikkuna 1 Copy to clipboard ei yksinkertainen Esim. copy tilalle ja ylävalikkoon myös aktivoituna ID 3 Ikkuna 4 Tabien nimet ei vastaa ikkunoiden nimiä List = Cluster List, Stat = Statistics, General ei vastaa ikkunaa, esim. ylävalikossa, mikä on snap window ID 4 Ikkuna 1 Kaikkialla mainittu geenit (g) Voisi olla dynaaminen nimeäminen ID 5 Ikkuna 2 Mikä on 70% neliö heatmapissa Voisi lukea treshhold 70% kanssa ID 6 Ikkuna 4 Mikä on cluster map Parannetaan Main Viewn, nimeämistä ID 7 Ikkuna 2 Main View epäselvä Voisi olla map (yhtenäisyys minimapin kanssa)

SEPA liite 2 Sivu 6 ID 8 Heuristiikka 3 Ikkuna 1 Ikkunoiden nimeäminen / niiden tila Voisi olla aktiivisen valinnan nimi ikkunan ylärivissä ID 9 Heuristiikka 3 Ikkuna 1 Data set ei erotu klustereista Data set voisi olla puu, jonka lehtiä klusterit ovat ID 10 Heuristiikka 3 Ikkuna 1 G= ja C= mitä tarkoittaa Jos on muuta dataa, niin apua. Voisi olla tippi kun hiiri menee päälle ID 11 Heuristiikka 4 Ikkuna 2 Main View, MainView, Main Window Voisi olla yhtenäistä ID 12 Heuristiikka 4 Ikkuna 3 Minimapissa ei ole kuvaa yläpalkissa Voisi olla minikuva ID 13 Heuristiikka 4 Ikkunat 1,2,3 Korostukset eri väreillä: sininen, valkoinen, musta Voisi olla yhtenäisen värisiä ID 14 Heuristiikka 4 Valikko 1 Save Dataset.. Voisi olla sama kuin copy

Sivu 7 SEPA liite 2 ID 15 Heuristiikka 4 Ikkunat 1-5 Javalla tehty, lookandfeellikewindows ei päällä Voisi olla päällä ID 16 Heuristiikka 4 Ikkuna 1 Hiiren oikea näppäin ei aktivoi alla olevaa klusteria Voisi aktivoida ID 17 Heuristiikka 4 Valikko 2 Windows hämää Pitää olla View ID 18 Heuristiikka 5 Ikkuna 2 Miten palautetta tulee jos joku kestää kauan Pitää olla loading statusbarissa ID 19 Heuristiikka 5 Ikkuna 4 Prioriteetti 0 Miten asetukset vahvistetaan Voisi olla perus apply ID 20 Heuristiikka 5 Ikkuna 2 Missä ollaan heat mapissa Voisi olla xy-koordinaatit ID 21 Heuristiikka 6 Ikkuna 4 Toiminnon kumoaminen ei mahdollista Pitää voida peruttaa esim. mapin generoiminen ID 22 Heuristiikka 6 Ikkuna menee alhaalla pahasti toisen ikkunan Voisi toimia kuten Windows-valikko

SEPA liite 2 Sivu 8 Ikkunat 1-5 taakse ID 23 Heuristiikka 7 Ikkunat 1-5 Ei oikopolkuja missään Pitää olla yleiset oikopolut ID 24 Heuristiikka 8 Ikkuna 5 Miksi minimap tulostaa kohtaan statistics Voisi tulostaa statusbariin/popup ID 25 Heuristiikka 9 Ikkunat 1-5 Voisi tulla virhetilanteita, jos muutoksesta ei tule tietoa Pitää tulla tilannetietoa matkanvarrella ID 26 Heuristiikka 9 Ikkunat 1-5 Ikkunoita käytössä Voisi olla Splitpaneja ID 27 Heuristiikka 9 Ikkuna 1 Clusterin tietoja voi muokata Ei saisi voida muokata ID 28 0 Valikko 3 Ei ohjeita Pitää olla jotain ohjeita / tippejä ID 29 0 Ikkuna 4 Prioriteetti 0 List ennen MainViewtä Samassa loogisessa järjestyksessä kuin ikkunat ovat

SEPA liite 2 Sivu 9