Käytettävyystestaus: Puhe digitaalikuvan metadatan lähteenä

Transkriptio

1 TEKNILLINEN KORKEAKOULU Viestintätekniikka Graafisen tekniikan syventävät harjoitustyöt AS Työ n:o 1 Käytettävyystestaus: Puhe digitaalikuvan metadatan lähteenä Espoossa Matias Vakkilainen P 42370A matias@iki.fi

2 SISÄLLYSLUETTELO 1 JOHDANTO KÄYTETTÄVYYSTUTKIMUKSEN TEORIAA YLEISTÄ HEURISTINEN ARVIOINTI Yleistä Arvioinnin vaiheet Heuristiset säännöt KOGNITIIVINEN LÄPIKÄYNTI Yleistä Läpikäynnin vaiheet KÄYTETTÄVYYSTESTI Yleistä Perusrakenne Paritestaus Ryhmäläpikäynti Vapaa läpikäynti Tilannesidonnainen läpikäynti JÄRJESTELMÄN KÄYTETTÄVYYSTUTKIMUS YLEISTÄ JÄRJESTELMÄN KUVAUS Sanakirjan rakennus Puheentunnistus Metadatan lisäys kuvaan TUTKIMUKSEN TOTEUTUS Heuristinen arviointi Käytettävyystestaus TUTKIMUSTULOKSET HEURISTINEN ARVIOINTI Heuristiset säännöt Loppuarvio KÄYTETTÄVYYSTESTAUS Yleistä Aineisto Ohjelman toiminta Loppuarvio LUOTETTAVUUSANALYYSI JOHTOPÄÄTÖKSET YHTEENVETO...20 LÄHDELUETTELO...22

3 1 JOHDANTO Digitaalikuvien laatua pystytään säätämään automaattisesti erilaisilla olemassa olevilla säätörutiineilla. Nämä säätörutiinit eivät kuitenkaan tiedä mitä kuva sisältää, joten säätötuloksista ei aina saada optimaalisia. Jos ohjelma näkisi mitä kuvassa on, pystyisi se valitsemaan oikean säätörutiinin kuvan muokkaukseen. Näin lopputulos saataisiin ainakin lähemmäs optimaalista tasoa./2/ Kuvankäsittelyohjelmia voidaan auttaa ymmärtämään kuvan sisältömetatiedon avulla. Metatieto määritellään yleensä tiedoksi tiedosta. Määritelmä ei kuitenkaan kerro mitään metatiedon muodosta tai sisällöstä. Tallenne- tai dokumenttilähtöisesti tarkasteltuna metatiedolla tarkoitetaan tallenteen kuvausta. Metatieto on siis tietoa dokumentin alkuperästä, muutoksista ja käytöstä. Digitaalikuvan tapauksessa se voi myös antaa tietoa kuvan sisällöstä ja kuvaushetken olosuhteista. Tietojen avulla kuvankäsittelyohjelma osaa tehdä kuvalle tarvittavat korjaukset./1/ Metatietoa voidaan lisätä kuvaan erilaisten ohjelmien avulla, joissa halutut asiat kirjoitetaan niille varattuihin kenttiin. Vaikka tietokoneet pienenevät koko ajan ja markkinoille tulee kameroiden ja tietokoneiden hybridejä, ei tositilanteessa ole välttämättä kuitenkaan mahdollisuutta metatiedon lisäämiseen kuvadataan. Tämä nostaa esiin mahdollisuuden lisätä metadata puhuen. Puhe lisää tällaisen sovelluksen luonnollisuutta, helppoutta ja sovellettavuutta. Kuvatoimittaja pystyy kuvatessaan puhumaan kuvaan tulevan metadatan kameralleen, joka äänittää puheen. Ääntä tallentavia digikameroita on jo markkinoilla. Kuvat puretaan kamerasta ohjelmalle, joka tunnistaan kuva-puhepareista puheen. Ohjelma analysoi puheen, lisää tulkitun metadatan tuloskuvaan tekee mahdolliset automaattiset säätötoimenpiteen kuvalle metadatatiedon pohjalta ja arkistoi tiedot luokitustaan vastaavaan kansioon./2/ Teknillisen korkeakoulun viestintätekniikan laboratoriossa tutkittiin kesällä 2001 mahdollisuutta toteuttaa edellä kuvattu visio käytännössä. Tekn. yo Jyri Kivinen keskittyi aiheessa puhemetadatan analysointi- ja kuvaanlisäysvaiheeseen ja kehitti javapohjaisen sovelluksen, joka muokkaa sanellun metadatan muokattavaksi tekstimetadataksi. Tämä lisätään otettuun digikuvaan. Tässä tutkimuksessa on tarkoitus tehdä käytettävyystestaus kehitetylle javasovellukselle. Aluksi tutustutaan käytettävyystestauksen teoriaan, jonka pohjalta laaditaan kevyt koesuunnitelma ja toteutetaan tutkimus. 1

4 2 2 KÄYTETTÄVYYSTUTKIMUKSEN TEORIAA 2.1 Yleistä Käytettävyydellä tarkoitetaan tuotteen sopivuutta aiottuihin tehtäviin aiotuilla käyttäjillä. Laitteen käyttäjäryhmän tulisi siis pystyä käyttämään tuotetta tehokkaasti, tuottavasti ja miellyttävästi tietyssä käyttöympäristössä ja tilanteessa. Jakob Nielsen määrittelee käytettävyyden viiden mitattavan ominaisuuden avulla: opittavuus, muistettavuus, tehokkuus, virhetilanteiden vähyys ja käyttäjän tyytyväisyys. Käytettävyyden arvioinneilla pyritään löytämään jonkinlainen arvio näille ominaisuuksille./5/ Käytettävyyden arviointimenetelmät voidaan jakaa kokeellisiin käyttäjätesteihin ja ilman käyttäjiä tehtäviin asiantuntija-arvioihin. Yleisin käyttäjätestausmenetelmä on käytettävyystesti, jossa käyttäjä suorittaa annettuja tehtäviä arvioitavalla järjestelmällä. Ilman käyttäjiä tehtävät arvioinnit tehdään heuristiikan ja kognitiotieteiden keinoin. Heuristisella arvioinnilla löydetään yleisiä käytettävyysongelmia, kuten vieraat termit, epäyhtenäisyydet järjestelmän sanastossa ja näyttöjen sommittelussa tai painikkeiden ja tekstikenttien epäjohdonmukainen ryhmittely ja järjestys. Järjestelmän opetteluun liittyviä ongelmia voidaan kartoittaa esimerkiksi kognitiivisella läpikäynnillä./4//5/ 2.2 Heuristinen arviointi Yleistä Heuristisessa arvioinnissa tarkastetaan käyttöliittymän osat erilaisten käytettävyysperiaatteiden eli heuristiikkojen avulla. Muistilistat voivat sisältää yleisiä suunnitteluohjeita tai tietyille tuoteperheille räätälöityjä käytettävyysohjeita. Arvioinnissa ei tarvitse käyttää tutkittavaa järjestelmää, vaan arviointiin riittävät järjestelmän ja käyttöliittymän suunnitelmat tai varhaisen vaiheen prototyypit. Näin arvioinnin tulokset voidaan ottaa huomioon jo tuotteen kehitystyössä./4/ Heuristinen arviointi on hyvä tapa etsiä käyttöliittymän ongelmakohtia yksinkertaisella, nopealla ja edullisella tavalla. Se on helppo oppia ja helppo opettaa. Heuristinen arviointi ei korvaa käyttäjien kanssa tehtyjä testejä, mutta tarjoaa hyvät välineet käytettävyyden tutkimiseen jo tuotekehitysvaiheessa. Käytettävyyttä onkin hyvä ryhtyä arvioimaan jo ensimmäisten tuoteideoiden syntyessä./3//4/ Heuristisen arvioinnin tehokkuus riippuu siitä, kuinka paljon arvioijalla on kokemusta käytettävyydestä ja tutkittavasta järjestelmästä sekä sen käyttötarkoituksesta. Paras vaihtoehto on tietysti henkilö, joka hallitsee sekä käytettävyyden että sovellusalueen hyvin. Tällaisia ihmisiä on kuitenkin harvassa ja käytettävyyden ollessa testattavana toiseksi paras vaihtoehto on käytettävyysasiantuntija. Toisaalta käytettävyyttä tuntematon sovellusalueen asiantuntijakin voi olla hyödyllinen sillä mitä aikaisemmin virheet havaitaan, sitä helpompi ne on korjata. Joka tapauksessa kannattaa käyttää useampia asiantuntijoita, sillä eri ihmiset kiinnittävät huomionsa eri asioihin ja löytävät

5 erilaisia ongelmakohtia. Jakob Nielsen on tutkimuksissaan todennut, että yksi käytettävyyteen perehtynyt arvioija löytää noin 35% käytettävyysongelmista, kolme arvioijaa noin 60% ja viisi arvioijaa noin 75% ongelmista. Tämän jälkeen käyrä loiventuu ja jos halutaan löytää yli 90% ongelmista, on arvioijia oltava jo 15. On siis suositeltavaa, että heuristisessa arvioinnissa käytetään kolmesta viiteen arvioijaa./4/ Arvioinnin vaiheet Heuristinen arviointi voidaan jakaa neljään eri vaiheeseen: 1. Järjestelmän läpikäynti yksittäin 2. Ongelmien keruu 3. Ongelmien vakavuuden arviointi 4. Keskustelu ja ideointi Arvioija käy ensin järjestelmän läpi yleisesti ja sen jälkeen toisen kerran keskittyen käyttöliittymän käytettävyysongelmiin. Läpikäynnissä käydään läpi koko järjestelmä kohta kohdalta, näyttö näytöltä. Jokaisesta kohdasta kootaan lista ongelmista ja lopuksi listat yhdistetään./4/ Yhdistetyssä listassa olevat ongelmat laitetaan tärkeysjärjestykseen niiden vakavuuden suhteen. Tässä voidaan käyttää esimerkiksi seuraavaa jaottelua:/4/ katastrofaalinen vakava häiritsevä vähäinen kosmeettinen Ongelman vakavuuteen vaikuttaa se, kuinka usein ongelma ilmenee, kuinka vaikeaa siitä on selvitä ja kuinka helposti ongelma opitaan välttämään. Ongelmien vakavuuden arviointi tulisi tehdä vasta listojen yhdistämisen jälkeen, jolloin ongelmia voidaan verrata toisiinsa ja niiden vakavuus määritellään yleiseen käytettävyyteen rinnastaen. Vakavuuden arviointi voidaan tehdä joko yksitellen tai ryhmässä./4/ Lopuksi koko ryhmä kokoontuu keskustelemaan tuloksista ja luomaan parannusehdotuksia. Ryhmässä on hyvä olla mukana arvioijat, mahdollinen tarkkailija ja pari henkeä suunnitteluryhmästä. Ongelmien lisäksi keskustelussa tulisi käydä läpi myös testatun järjestelmän hyviä puolia. Heuristinen arviointi keskittyy herkästi löytämään ongelmia ja hyvät puolet jäävät kokonaan huomioimatta./4/

6 Heuristiset säännöt Heuristisessa läpikäynnissä käytettävyyttä arvostellaan siis heurististen eli käytettävyyssääntöjen perusteella. Tutkimukset nojautuvat usein Nielsenin ja Molichin kymmenen säännön listaan/4/: 1. Käytä yksinkertaista ja luonnollista dialogia 2. Käytä käyttäjän omaa kieltä 3. Minimoi käyttäjien 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. 2.3 Kognitiivinen läpikäynti Yleistä Kognitiivisessä läpikäynnissä pyritään ottamaan huomioon ihmisen ajattelutapa ja tapa opetella uusia asioita. Menetelmällä arvioidaan järjestelmän opittavuutta eli sitä, kuinka helppoa järjestelmää on käyttää ensimmäisillä kerroilla. Koska monet käyttäjät opettelevat käyttämään järjestelmiä ilman käyttöohjeita, kognitiivinen läpikäynti keskittyy opetteluun kokeilemalla. Menetelmä keskittyy oppimisen arviointiin siinä määrin, että muut käytettävyystekijät, kuten tehokkuus ja miellyttävyys, jäävät huomiotta. Menetelmää ei olekaan tarkoitus käyttää ainoana arviointikeinona vaan täydentämään muita menetelmiä./4/ Esimerkkinä sopivista kohteista voidaan mainita yleisöpäätteet eli jonkinlaista yleistä tietoa sähköisessä muodossa jakavat järjestelmät.. Siinä tietoa haluava henkilö saattaa olla sellainen, joka ei ole koskaan käyttänyt kyseisen tyyppistä laitetta. Järjestelmän on siis opastettava henkilö halutulle polulle ilman ulkopuolista ohjausta. Toisaalta kognitiivinen läpikäynti sopii myös käytettävyyden tutkimiseen esimerkiksi kännyköissä ja lippuautomaateissa. Molempia tulisi voida käyttää ilman ulkopuolista opastusta eikä käyttöohjeita useinkaan lueta./3/ Kognitiivisessa läpikäynnissä tehtävät käydään läpi esimerkiksi paperiversioiden ja järjestelmäkuvausten avulla. Testin kohteena saattaa olla myös järjestelmän prototyyppi. Menetelmää voidaan siis soveltaa jo tuotekehityksen hyvin aikaisessa vaiheessa./4/

7 Läpikäynnin vaiheet Kognitiivinen läpikäynti jakautuu viiteen vaiheeseen:/4/ 1. Esiselvitys 2. Ryhmän kokoaminen 3. Kognitiivinen läpikäynti istunnossa 4. Havaintojen tallentaminen 5. Havaittujen virheiden ja puutteiden korjaaminen Ennen varsinaista läpikäyntiä tulisi tehdä esiselvitys siitä ketkä ovat järjestelmän tyypillisimpiä käyttäjiä. Kun tämä on selvitetty, tulisi pohtia minkälainen kokemus heillä on järjestelmien käytöstä ja minkälainen on heidän tekninen osaamisensa. Esiselvityksessä tulisi myös miettiä minkälaisia tehtäviä ryhmälle annetaan. Tehtävät tulisi valita markkinatutkimusten, vaatimusmäärittelyjen ja aiemmin havaittujen ongelmakohtien perusteella. Tehtävien tulisi käsitellä järjestelmän keskeisimpiä ominaisuuksia, mutta sekaan kannattaisi liittää myös joku hieman monimutkaisempi tehtävä, joka vaatii keskeisimpien ominaisuuksien yhdistelyä./4/ Arviointi voidaan tehdä ryhmässä tai yksinään. Ryhmäläpikäynnissä on kuitenkin koettu saavutettavan parhaat tulokset. Näin varsinkin jos vähintään yksi ryhmän jäsen hallitsee kognitiotieteen perustiedot. Kognitiotieteiden hallinta ei kuitenkaan ole edellytys sillä jokainen hallitsee tietämättään kognitiotieteitä sen verran, että yhdenkin henkilön läpikäynnillä on saatu merkittäviäkin tuloksia. Ryhmään on joka tapauksessa hyvä kerätä eri alojen ihmisiä sillä jokainen näkee asiat omalta kantiltaan. Näin markkinoinnista vastaava henkilö löytää järjestelmästä erilaisia asioita kuin dokumentoinnin ammattilainen ja vastaavasti koulutuspuolen ihminen katsoo asiaa eri silmin kuin ohjelmistosuunnittelija./4/ Itse läpikäynnissä tutkitaan tehtävät vaihe vaiheelta. Kunkin tehtävän kohdalla pohditaan seuraavia kysymyksiä:/4/ Onko käyttäjällä järjestelmän kannalta oikea tavoite? Löytääkö hän järjestelmästä oikean toiminnon? Yhdistäkö hän kyseisen toiminnon tavoitteeseensa? Mikäli oikea toiminto on suoritettu, saako käyttäjä riittävästi palautetta tehtävän etenemisestä? Kysymyksillä halutaan varmistua siitä, että käyttäjä käyttää järjestelmää oikein saavuttaakseen tavoitteensa. Tavoitteen saavuttaminen halutaan saada mahdollisimman yksinkertaiseksi ja yksiselitteiseksi. Monimutkaisissa järjestelmissä tämä voi olla joskus vaikeaa, mutta läpikäynnit tuovat usein myös parannusehdotuksia. Läpikäynnin aikana syntyneiden havaintojen tallentaminen tulisi tehdä läpikäynnin aikana taululle, lehtiöön, kalvoille tai muulle pinnalle, josta koko ryhmä pystyy ne näkemään. Jälkitarkastelua varten istunto on myös hyvä videoida./4/

8 6 Läpikäynnistä tulisi tallentaa ainakin seuraavat tiedot:/4/ Oletukset käyttäjistä ja heidän taidoistaan Uskottava tarina, joka kertoo, miten käyttäjä suoriutuu tehtävästä vaihe vaiheelta Käyttäjän tarvitsemat tiedot: mitä tulee tietää ennen tehtävää ja mitä opittava sen aikana Läpikäynnissä esiin tulleet ideat ja parannusehdotukset. Jälkitarkastelussa havaittuja puutteita voidaan korjata poistamalla esimerkiksi käyttäjän kannalta turhat vaiheet tai parantamalla ohjeistusta. Huonosti löydettävät toiminnot voidaan tuoda paremmin esiin ja sanasto korjata paremmin ymmärrettävään muotoon./4/ 2.4 Käytettävyystesti Yleistä Käytettävyystestillä pyritään keräämään informaatiota tuotteiden tai niiden prototyyppien käytettävyydestä sellaisilta käyttäjiltä, jotka eivät ole olleet osallisina tuotteen suunnittelussa. Käytettävyystestien ensisijainen tarkoitus on parantaa tuotteiden käytettävyyttä. Yksittäisillä testeillä saattaa olla myös muita tarkoituksia kuten vertailu kilpailijoihin tai opittavuuden ja tehokkuuden testaus./3/ Käytettävyystestejä voidaan tehdä oikeastaan missä vain. Omalla työpaikalla tai kotona suoritettavissa testeissä hyvänä puolena on tuttu ympäristö. Tuttu paikka voi auttaa testin tekijää yhdistämään annetut tehtävät arkielämän tehtäviin mikä on tietysti pyrkimys kaikissa testeissä. Testauslaboratorioiksi erityisesti rakennetut huoneet sisältävät taas täysin eri tyyppiset mahdollisuudet testin seuraamiseen kuten kaksisuuntaiset peilit, huomaamattomat kattokamerat ja muut testin tekijälle näkymättömät tallennusvälineet. Lisäksi testilaboratorioissa pystytään poistamaan tutkimusta häiritsevät tekijät. Testilaboratoriot on yleensä rakennettu mahdollisimman mukaviksi sohvineen, kasveineen ja televisioineen, jotta testaaja pystyisi pääsemään samaan mielenrauhaan kuin kotonaan./3/ Käytettävyystestit tehdään tietyn perusrakenteen mukaisesti, mutta sen rinnalle on syntynyt myös siitä muokattuja menetelmiä, joiden avulla voidaan testata käyttöliittymäratkaisujen toimivuutta käyttäjien kanssa. Paritestaus ja eri tyyppiset läpikäynnit tuovat järjestelmästä esiin erilaisia puolia, joiden tiedostaminen on tärkeää järjestelmää suunniteltaessa./5/ Perusrakenne Tyypillisessä käytettävyystestissä käyttäjä suorittaa ennalta valmisteltuja tehtäviä arvioitavalla järjestelmällä. Testi-istunnossa on yleensä mukana yksi käyttäjä kerrallaan. Yhteensä testikäyttäjiä on 3-8 tuotteen käyttäjäryhmän hajanaisuudesta riippuen./5/ Testiryhmän koostumus valitaan vastaamaan mahdollisimman hyvin loppukäyttäjäryhmää. Ystävien, sukulaisten tai työkavereiden käyttämistä tulisi välttää,

9 sillä liian läheiset suhteen testaajan ja kokeen järjestäjän välillä voivat vähentää testin luotettavuutta./3/ 7 Testikäyttäjän lisäksi testihuoneessa on mukana testin ohjaaja. Ohjaaja antaa käyttäjälle yhden tehtävän kerrallaan ja pyytää käyttäjää ajattelemaan ääneen tehtäviä suorittaessaan. Ääneenajattelu auttaa selvittämään, miksi käyttäjä esimerkiksi tekee tiettyjä valintoja tai ei löydä tarvittavaa toimintoa./5/ Käytettävyystestiin tarvitaan valmis tuote tai edes osittain toimiva prototyyppi, jotta käyttäjä voi mahdollisimman luonnollisesti suorittaa annettuja tehtäviä. Testitilanne on hyvin kontrolloitu ja häiriötekijät pyritään minimoimaan. Testi-istunnot videoidaan analysointia varten. Analysoinnin tueksi pyritään lisäksi tekemään mahdollisimman paljon muistiinpanoja jo testin aikana. Ohjaajan on hyvä keskittyä testikäyttäjän ohjaamiseen, joten muistiinpanojen teko jää muille tarkkailijoille./5/ Ääneenajattelu hidastaa käyttäjän toimintaa, joten tällainen käytettävyystesti ei sovellu tehokkuuden mittaamiseen. Sen sijaan käytettävyystesti on hyvä tapa arvioida opittavuutta, muistettavuutta ja virhetilanteiden määrää. Arvioitaessa käyttäjätyytyväisyyttä käytettävyystesti puolustaa myös paikkaansa hyvin./5/ Paritestaus Edellä kuvatun peruskäytettävyystestin rinnalle on syntynyt erilaisia variaatioita. Joskus testaus tehdään pareittain. Tämä tekee ääneen ajattelusta varsin luonnollista sillä tehtävät on tarkoitus selvittää yhdessä. Jotta tämä toimisi hyvin, on parien oltava tasaarvoisia keskenään. Jos toisella on kyseisestä alasta enemmän tietoa tai kokemusta, dominoi hän helposti testiä ja tuloksesta saadaan hieman vääristynyt. On myös hyvä, jos molemmat osapuolet ovat entuudestaan tuttuja ja tottuneet työskentelemään keskenään. Näin päästään luonnolliseen vuorovaikutukseen heti alusta lähtien. Tasavertaisuus aiheuttaa myös sen, että testaajat joutuvat perustelemaan toisilleen valintansa hyvin, joka helpottaa tulosten arvioimista myöhemmin./5/ Paritestaus sopii hyvin opittavuuden mittaamiseen, sillä parin keskustelusta käy hyvin ilmi, ovatko he ymmärtäneet tuotteen toimintatavan oikein vai saavatko he vain sattumalta suoritettua tehtävät oikein. Paritestaus sopii perinteisen käytettävyystestin tapaan myös muistettavuuden ja virhetilanteiden määrän arviointiin./5/ Ryhmäläpikäynti Ryhmäläpikäynti yhdistää käyttäjien kanssa tehtävien käytettävyystestien ja ilman käyttäjiä tehtävien asiantuntija-arvioiden ominaisuuksia. Ryhmäläpikäyntiä voidaan kuvailla viidellä ominaispiirteellä:/5/ 1. Testi-istuntoon osallistuu yhtäaikaa kolmen eri ryhmän edustajia: käyttäjiä, suunnittelijoita ja käytettävyyden asiantuntijoita. 2. Järjestelmä esitellään paperikuvien avulla. Kuvat esitellään samassa järjestyksessä kuin ne näkyisivät toimivassa järjestelmässä.

10 3. Kaikki osallistujat samaistuvat käyttäjän rooliin. 4. Kaikki osallistujat kirjoittavat saamiinsa paperikuviin ne toiminnot, joita he tekisivät suorittaakseen annetun tehtävän. 5. Ryhmä keskustelee tekemistään ratkaisuista. Käyttäjät puhuvat ensin ja vasta heidän jälkeensä suunnittelijat ja käytettävyyden asiantuntijat voivat esittää omat mielipiteensä. 8 Arvioiva ryhmä koostuu siis sekä käyttäjistä että suunnittelijoista. Ryhmäläpikäynnin suurimpana antina onkin usein näiden kahden ryhmän välille syntyvä keskustelu. Molemmat voivat tehdä ehdotuksia ja saada ajatuksilleen välitöntä palautetta. /5/ Kaikki osallistujat samaistuvat käyttäjän rooliin. Tämä antaa myös suunnittelijoille, jotka saattavat tuntea systeemin läpikotaisin, mahdollisuuden astua askel taaksepäin suunnitelmista ja tehdä niin kuin he kuvittelisivat käyttäjien tekevän. Ratkaisujen purkukeskustelussa jokaisen kerrottua omat ratkaisunsa, kertoo testin vetäjä tai joku suunnittelijoista mikä olisi ollut oikea eli järjestelmän tukema ratkaisu. Kaikille jää siis lopulta tieto siitä miten järjestelmä olisi toiminut oikeassa tilanteessa. Tämä on hyvä lähtökohta hedelmälliselle keskustelulle./5/ Ryhmäläpikäynti soveltuu hyvin jo tuotekehitysprojektin alkuvaiheeseen kun suunnitelmista on vasta paperiversioita. Toisaalta hieman pidemmällä olevat kehitysprojektit ovat usein vielä ilman käyttöohjeita, jolloin paikalla olevat suunnittelijat voivat toimia elävinä käyttöohjeina. Tältä pohjalta käyttöohjeiden tekokin helpottuu./5/ Vapaa läpikäynti Vapaassa läpikäynnissä käyttäjälle ei anneta valmiita tehtäviä. Läpikäynti tehdään kontrolloidussa ympäristössä ja käyttäjää pyydetään ajattelemaan ääneen. Käyttäjää pyydetään käyttämään järjestelmää samaan tapaan kuin hän käyttäisi sitä kotonaan. Tällä tavoin saadaan selville kuinka paljon järjestelmä viestii ominaisuuksistaan ja käyttötavastaan eli kuinka helposti järjestelmän toiminnot on opittavissa./5/ Vapaaseen läpikäyntiin tarvitaan luonnollisesti toimiva prototyyppi. Testin ohjaajan on myös tunnettava järjestelmä niin hyvin, että hän pystyy neuvomaan käyttäjää tilanteessa kuin tilanteessa ongelmien ilmaantuessa. Testin tekijöiden on myös hyvä listata etukäteen tuotteen ominaisuudet ja merkitä erikseen ne ominaisuudet, joiden toimivuudesta ja löydettävyydestä halutaan kommentit jokaiselta käyttäjältä. Jos käyttäjä ei oma-aloitteisesti löydä näitä toimintoja, voi testin ohjaaja vihjeillä tai suorilla neuvoilla ohjata käyttäjän toimintojen luo tai antaa tarvittaessa myös ennalta valmistettuja tehtäviä. Tämä ei kuitenkaan ole vapaan läpikäynnin tarkoitus ja kertoo virheistä, joko järjestelmässä tai käytettävyystestissä./5/

11 2.4.6 Tilannesidonnainen läpikäynti Tilannesidonnaista läpikäyntiä sovelletaan todellisessa käyttöympäristössä ja tilanteessa. Testin järjestäjät toimivat siis pelkkinä havainnoitsijoina. Tehtäviä ei laadita etukäteen eikä tilannetta kontrolloida mitenkään. Tilannesidonnainen läpikäynti soveltuukin esimerkiksi puhelinpalvelujärjestelmien testaukseen. Tehtävät tulevat oikeilta palveluun soittavilta asiakkailta eikä tilannetta voida keskeyttää tai häiritä esim. ääneenajattelulla. Menetelmä sopiikin erityisesti tehokkuuden mittaamiseen./5/ Tilannesidonnaisessa läpikäynnissä tapahtuma videoidaan minkä lisäksi yksi tai kaksi henkilöä tarkkailee tilannetta ja tekee muistiinpanoja. Jos töissä tulee luonnollinen tauko, voi käyttäjä kertoa, mitä juuri päättynyt tehtävä piti sisällään. Tarkkailijat voivat esittää kysymyksiä muistiinpanojensa pohjalta. Jos taukoa ei tule, voidaan tehtävät käydä läpi myöhemmin videotallenteen avulla./5/ 9

12 10 3 JÄRJESTELMÄN KÄYTETTÄVYYSTUTKIMUS 3.1 Yleistä Kesällä 2001 tehtiin Teknillisen korkeakoulun viestintätekniikan laboratoriossa sovellus, jonka avulla kuvatessa digikameraan puhuttu tieto saadaan tallennettua kuvan yhteyteen metatietona. Tämän tutkimuksen tarkoituksena oli tutkia järjestelmän käytettävyyttä. Koska harjoitustyön puitteissa ei ollut mahdollisuuksia käyttää järjestelmän potentiaalisia käyttäjiä eikä käytettävyysasiantuntijoita, toteutettiin käytettävyystestaus edellisestä luvusta saatujen oppien sovelluksena. Järjestelmää testattiin sekä heuristiselta pohjalta että perinteisellä käytettävyystestauksella. Resurssien puuteen vuoksi kummatkin tehtiin pienen mittakaavan testeinä. 3.2 Järjestelmän kuvaus Sanakirjan rakennus Sanakirjan rakennus on puheentunnistuksen tärkein vaihe sillä sanakirjat määräävät puheentunnistuskonetekstin. Tämä tarkoittaa, että jos jotain sanaa ei ole sanakirjassa valmiina, ei kone tunnista sanaa ja hylkää sen automaattisesti. Sanakirja määrittelee siis sen mitä sanoja ja lauseita puhujalta voidaan odottaa. Sanakirjan täytyy olla rakennettuna puheentunnistajan aktivoimiseksi. Sanakirjoja on kahdenlaisia: sääntösanakirjoja ja sanelusanakirjoja. Sääntösanakirjoilla ohjataan sisääntulevaa puhetta ja sanelusanakirjoja käytetään saneluun. Sääntösanakirjat ovat tyypillisesti paljon suppeampia kuin sanelusanakirjat ja ne soveltuvat etenkin ohjelman kontrollointia vaativiin ja hyödyntäviin sovelluksiin. Sääntösanakirjojen laatiminen on monimutkainen prosessi, mutta niitä on helppo käyttää. Tässä sovelluksessa käytetään kuitenkin sanelusanakirjaa, joka opetetaan lukemalla ohjelmaan sen tarjoamia näytetekstejä. Ohjelmalle voi myös opettaa erikseen tarvittavia erikoissanoja Puheentunnistus Kuvat ja niihin liittyvät äänitiedostot on tallennettu tietokoneen kovalevylle. Äänet ovat wav-formatissa ja kuvat metatiedon sallivassa png-formaatissa. Äänitiedosto ladataan puheentunnistajaan, joka kirjoittaa tunnistamansa puheen auki tekstiikkunaan. Ikkunassa tekstiä voi korjata ja muutella. Puheen voi myös syöttää suoraan ohjelmaan puhumalla tietokoneen mikrofoniin Metadatan lisäys kuvaan Kun teksti on saatu haluttuun asuun, se yhdistetään kuvaan. PNG-formaatissa on ennalta määriteltyjä avainsanoja, joita tulee pyrkiä käyttämään: Title Lyhyt(rivin) otsikko or tai kuvan selvennys Author Kuvanomistajan nimi Description Kuvan selvennys(voi olla pitkäkin)

13 Copyright Copyright - ilmoitus Disclaimer Lakivetoomus Warning Varoitus sisällöstä Creation Time Kuvanluontiaika Software Ohjelmisto, jolla kuva luotiin Source Laite, jolla kuva on tallennettu Comment Kommentti; kommentti formaattimuunnoksesta 11 Testattavana oleva ohjelma lisää puheesta tunnistetun tekstin ennalta määritellyn otsikon alle. Tekstin yhdistäminen kuvaan onnistuu napin painalluksella. 3.3 Tutkimuksen toteutus Heuristinen arviointi Järjestelmä tutkittiin heuristisesti ennen varsinaista käytettävyystestausta. Heuristisessa arvioinnissa tutkitaan järjestelmän käytettävyyttä heuristiikan sääntöjen perusteella. Tarkemmat tiedot menetelmästä löytyvät luvusta Käytettävyystestaus Käytettävyystestauksessa pyrittiin saamaan kattava kuva erilaisista tilanteista, joissa sovellusta voisi käyttää. Tämän saavuttamiseksi koekuvia otettiin äänimaailmaltaan hyvin erilaisissa ympäristöissä. Ympäristöiksi valittiin hiljainen huone äänekäs huone rauhallinen takapiha hiljaisen tien piennar vilkkaan tien piennar Erilaisten ympäristöjen ansiosta pyrittiin saamaan selville milloin taustameteli käy liian voimakkaaksi järjestelmän puheentunnistukselle. Ympäristön vaihtelun lisäksi puhuttu metadata puhuttiin eri äänenvoimakkuuksilla. Tämän jälkeen näytteet muunnettiin ohjelman ymmärtämiin formaatteihin. Kuvanottohetkellä puhutun metadatan testauksen lisäksi kokeiltiin myös ohjelman tarjoamien muiden metadatan syöttömahdollisuuksien, eli kirjoittaminen ja puhuminen metadatan liittovaiheessa, käytettävyyttä.

14 12 4 TUTKIMUSTULOKSET 4.1 Heuristinen arviointi Heuristiset säännöt Sovellusta tutkittiin luvussa esitettyjen heurististen sääntöjen perusteella: 1. Käytä yksinkertaista ja luonnollista dialogia Käyttöliittymä on yksinkertainen ja siksi siinä käytetty tekstikin on yksinkertaista. Keskeiset komennot on esitetty yksinkertaisesti ja yksiselitteisesti. Ainoastaan puheentunnistajan koulutukseen liittyvä Native Speech User Interfaces valikon otsikko herättää tottumattomassa käyttäjässä ihmetystä. Sen takana olevia toimintoja ei olisi arvannut ilman ohjeita. 2. Käytä käyttäjän omaa kieltä Tässä tapauksessa käyttäjän kieli on suomi, mutta ohjelman puheentunnistuksessa käytettyjen valmiiden puhetunnistajien kielen ollessa englanti kannattaa sitä käyttää myös testissä. Sovelluksen käynnistämiseen tarvitsee tietokoneiden ja erityisesti MS- DOSin olla tuttu, sillä jollei ohjelmaa ole asentanut hakemistojuureen, täytyy ensin osata mennä kansiosta toiseen eikä sellaisia taitoja ole välttämättä windowsiin tottuneilla nykykäyttäjillä. 3. Minimoi käyttäjien muistikuorma Koska sovelluksen rakenne on yksinkertainen, ei käyttäjän tarvitse muistaa paljoakaan. 4. Tee käyttöliittymästä kauttaaltaan yhdenmukainen Käyttöliittymä on yksinkertainen eikä eri näkymiä ole monta. Kaikki on toteutettu yksinkertaisena java-grafiikkana, joten yhdenmukaisuus näkymien välillä on kiitettävä. 5. Anna käyttäjälle palautetta toiminnoista Valittuna oleva äänitiedosto näkyy ruudulla aaltomuotona, josta ei pysty määrittelemään mitä äänitiedosto koskee, mutta näkee, että tiedostossa on ääntä. Sen sijaan virhetoiminnoista ei käyttäjä saa kovinkaan paljoa palautetta. Joku nappi saattaa vain yhtäkkiä olla pois käytöstä eikä missään sanota minkä takia sitä ei voi käyttää. Nappi on sentään näissä tapauksissa vaalennettu, jolloin se erottuu aktiivisesta napista. 6. Anna selkeä poistumistapa eri tiloista ja toiminnoista Eri toiminnoista poistumiselle on valittu pelkkä ikkunan sulkeva risti ikkunan oikeaan ylänurkkaan. Puheentunnistajaa koulutetaan Microsoftin puheentunnistusohjelmistoilla, jolloin käytössä on myös peruuta- ja muut windows:ssa yleisenä olevat napit. 7. Anna käyttäjälle mahdollisuus käyttää oikopolkuja Oikopolkuja ei oltu tehty. Sovelluksen toteutus on kuitenkin sen verran yksinkertainen, ettei oikopolkujen luominen ole tarpeellista.

15 13 8. Anna virhetilanteista selkeät virheilmoitukset Joskus virheilmoitukset ovat selkeitä, kuten silloin, jos joku toiminto ei ole käytössä. Tällöin pop-up-ikkuna kertoo asian selkeästi. Joskus tätä virheilmoitusta ei kuitenkaan tule ja ääniaalto ikkunaan tulee javan antama virheilmoitus. Tottumaton käyttäjä ei ymmärrä siitä mitään muuta kuin, että tapahtui virhe. Pahin on kuitenkin esim. väärässä vaiheessa painetun napin aiheuttama virhe. Jos recognize-nappia painaa väärään aikaan, se yksinkertaisesti kytkeytyy pois käytöstä ja napin aktiiviseksi saaminen jää hämärän peittoon. 9. Vältä virhetilanteita Ohjelmassa on toki pyritty välttämään virhetilanteita, mutta niitä syntyy aina. Sovelluksen on ilmeisesti ollut tarkoitus olla hieman monipuolisempi, koska nappeja tietyille toiminnoille löytyy, mutta niitä painaessa tulee vain ilmoitus, ettei kyseinen toiminta ole käytössä. Sovellus koodattiin hieman yli puoli vuotta sitten uusimmalla javan versiolla. Siitäkin versiosta on tullut tällä välin uusi painos, jolloin tarvittiin koodinmuokkausta, jotta ohjelma saatiin ylipäänsä toimimaan. Tämä on vaikeutena ohjelmilla, jotka tarvitsevat muita ohjelmia pyöriäkseen. 10. Anna riittävä ja selkeä apu ja dokumentaatio. Apuominaisuutta sovellukseen ei ole tehty lainkaan. Tämän takia virhetilanteissa voi käyttäjä joutua pattitilanteeseen ja sovelluksen tekijä on kutsuttava paikalle selvittämään ongelmaa. Dokumentaatio on kattava, mutta ohjelman käyttäjän kannalta siinä on paljon turhaa tietoa ja toisaalta siitä puuttuu tietoa esim. ongelmien ratkaisusta Loppuarvio Sovellus tehtiin harjoitustyönä Teknillisen korkeakoulun laboratoriossa. Sitä ei siis tehtykään markkinoille suunnattavaksi vaan enemmän kokeilemaan ajatuksen toimivuutta. Tämän takia ohjeistus ja aputoiminnot jätettiin varmasti tekemättä. Sovelluksen käynnistys oli myös tehty ajatellen, ettei ohjelmaa tule käyttämään henkilö, jolle tietokoneen käyttö MS-DOS tilassa ei ole tuttua. Ohjelma oli yksinkertainen ja siksi suht helppokäyttöinen. Ainoastaan muutama vieras termi ohjelman käyttöliittymässä sai käyttäjän ensin ymmälleen, mutta lyhyen tutkiskelun jälkeen nekin selvisivät. Selkeämpi käyttöohje olisi auttanut tässäkin vaiheessa. 4.2 Käytettävyystestaus Yleistä Ohjelman periaate on yksinkertainen: haluttu ääni- ja kuvatiedosto voidaan yhdistää pariksi. Ohjelma tunnistaa äänitiedostosta puheen ja muuntaa sen kuvan metadataksi. Metadatan voi myös puhua tai kirjoittaa ohjelmaa käytettäessä, jos kuvaa otettaessa ei puhetta ole voinut nauhoittaa tai taustamelun tai muun vuoksi ohjelma ei sitä pysty tunnistamaan.

16 4.2.2 Aineisto Aineisto käytiin kuvaamassa Sonyn digitaalivideokameralla, jossa pystyi ottamaan kuvia ja samanaikaisesti puhumaan noin seitsemän sekunnin verran nauhalle. Aineistoksi otettiin 20 kuvaa ennalta mietityissä ympäristöissä. Kuvatessa puhuttiin kuvan yhteyteen aina sama testilause. Ääni erotettiin kuvasta Adobe Premier videoeditointiohjelmalla. Tässä vaiheessa parista näytteestä oli jäänyt osa lauseesta pois. Kaikki näytteet päätettiin kuitenkin syöttää SRIM-järjestelmän tunnistettaviksi. Kuvatun aineiston kuvaus löytyy taulukosta 1. Taulukko 1. Aineiston kuvaus Nimi Kuva Ääni 1 Tekniikantie laboratorion edessä Kovalla äänellä, liikenteen taustamelua 2 Tekniikantien ja Miestentien risteys Tekniikantieltä päin Normaaliäänellä, äänitiedosto alkaa lauseen keskeltä, takana vähän liikenteen ääntä 3 Tekniikantien ja Miestentien risteys Normaaliäänellä, äänitiedosto alkaa lauseen keskeltä, takana vähän liikenteen ääntä 4 Tekniikantien ja Miestentien risteys Miestentieltä päin Normaaliäänellä, tuulee, liikenteen ääniä 5 Miestentie, huoltoaseman kyltti edessä oikealla Normaaliäänellä, hiljaisia liikenteen ääniä 6 Miestentie, säiliöauton vieressä Normaaliäänellä, hiljaisia ääniä, vähän tuulta, puheessa sanat menevät vähän sekaisin 7 Kivipöytä kivimuseon ulkopuolella Hiljainen puheääni, taustalla vähän liikennettä. 8 Metsä Normaaliäänellä, ei lähes lainkaan taustamelua 9 Koivu Hiljaisella puheäänellä, ei lähes lainkaan taustamelua 10 Puunjalostustekniikan laitos Hiljaisella puheäänellä, kävellessä, hiljaiset liikenteen äänet 11 Puunjalostustekniikan laitoksen nestekemikaalisäiliöitä Hiljaisella puheäänellä, juostessa, hiljaiset liikenteen äänet 12 Punaiset sormikkaat, puhelin ja Normaaliäänellä, huonekaiku niittari 13 Puhelin, keltainen lehtiö ja kaappi Hiljaisella puheäänellä, huonekaiku 14 Teippirullateline Hiljainen puheääni, lähellä mikrofonia, pieni huonekaiku 15 Rei'itin ja teroitin Hiljainen puheääni, todella lähellä mikrofonia 14

17 16 Ohjekirja, taustalla tietokone Normaaliäänellä, nopeasti, huonekaiku 17 Hyllykkö ja tietokone Normaaliäänellä, radio hiljaa, puhetta 18 Hyllykkö Hiljaisella puheäänellä, radio hiljaa, puhetta 19 SCENIC-tietokone Normaaliäänellä, radio kovempaa, puhetta 20 Pöydän pintaa Kovalla äänellä, radio kovalla, musiikkia Ohjelman toiminta Ohjelman toiminnassa oli suuria vaikeuksia. Alunperin Premieristä saadut ääninäytteet olivat 44 MHz stereonäytteitä, joita ohjelma ei suostunut soittamaan lainkaan. Kun näytteet muutettiin 16 MHz mononäytteiksi onnistui niiden soittaminen ohjelmassa, mutta puhetta ohjelma ei saanut tunnistettua. Ohjelma myös kaatui hyvin herkästi. Samaten ohjelma kaatui herkästi, jos ääninäytettä yritettiin yhdistää kuvaan. Ohjelma pystyy käsittelemään sekä jpg- että png-formaateissa olevia kuvia. Jos kuva on jpg-muodossa, ohjelma tallentaa sen automaattisesti png-muotoisena liittäessään siihen metatiedon. Näytteet tehtiin Adoben Photoshop-ohjelmalla sekä jpg- että pngmuotoisiksi. Jälkimmäisen formaatin kanssa tuli kuitenkin ongelmia metadataa liitettäessä. Photoshop liittää metadataan omia tietojaan niin paljon, että koko metadata-ikkuna täyttyi niistä. Lisäksi ohjelma ei pystynyt lisäämään haluttua metadataa kuvaan mukaan. Ainoa keino saada kuvaan metadataa oli siis tallentaa se jpg-muodossa ja antaa ohjelman muuttaa se png:ksi itse. Ohjelman muuttamiin kuviin metatietoa saatiin lisättyä helposti kirjoittamalla sitä valmiiseen tekstikenttään tai puhumalla tässä vaiheessa metatieto tietokoneen mikrofoniin. Jälkimmäisessä tapauksessa kuitenkin esiintyi jonkin verran virheitä. Ohjelma myöskin lopetti puheen tunnistamisen heti kun puheeseen tuli tauko. Joskus ohjelma kirjoittaa tunnistamansa puheen ruudulle useita kertoja peräkkäin. Tunnistettua tekstiä voi toki korjata ennen sen liittämistä kuvan metadataan, mutta kirjoittaen kaikki kävi nopeimmin. Puheen tunnistaminen kuvan oton yhteydessä tehdystä nauhoitteesta ei onnistunut lainkaan. Ohjelmassa on myös toinen versio, jossa metadatan liittäminen on helpompaa, nimeltään SRIMViewer. Ohjelmassa saa samalle ruudulle useita kuva-ääniyhdistelmiä, joten suurten määrien liittäminen on vieläkin yksinkertaisempaa. SRIMViewerissa ohjelma ei myöskään kaatunut joka kerta kun tiedostossa olevaa puhetta yritettiin tunnistaa. Jokaisen kuvan ottamisen yhteydessä äänitettiin lause This picture was taken as an exercise.tiedostoissa olevan puheen tunnistaminen ei kuitenkaan tuntunut luonnistuvan kuten Taulukosta 2 käy ilmi. Ohjelma ei yhdessäkään tunnistustehtävässä osannut tunnistaa tiedostossa olevaa puhetta.

18 Taulukko 2. SRIMViewerin puheesta tunnistama metadata Kuva Tunnistettu puhe Kuva Tunnistettu puhe 1 If 11 And 2 The 12 If If if 3 And 13 If 4 If 14 if 5 If 15 If the 6 If If If If her 16 The 7 If 17 If 8 If 18 If 9 If 19 If 10 If 20 If 16 SRIMViewerilla oli sen sijaan helppo lisätä tekstiä kuvan metadataksi kirjoittamalla haluttu viesti sille tarkoitettuun laatikkoon. Ohjelma tunnisti myös sille saneltua puhetta lähes virheettömästi. Näillä tavoilla metadatan lisääminen siis onnistui hyvin. Tiedostoissa puheentunnistusta häiritsi luultavasti taustalta kuuluvat äänet vaikka ne joissain näytteissä olivatkin hyvin hiljaisia. Kuvassa 1. on näyte SRIMViewerohjelmasta, jossa kuvan metadataan on lisätty kirjoittaen kommentti A Birch ja suoraan ohjelmaan puhuen teksti This text was spoken. Kuva 1. SRIMViewer

19 4.2.4 Loppuarvio Ohjelman puheentunnistuksessa on vielä työtä. Tunnistustulokset huononivat radikaalisti, jos puhetta häiritsemässä oli yhtään taustamelua. Tulokset paranivat huomattavasti, kun teksti luettiin hiljaisessa huoneessa käyttäen samaa mikrofonia, jonka kanssa puheentunnistajaa oli koulutettu. Kirjoittamalla metatieto saatiin liitettyä kuvaan helposti. 17

20 5 LUOTETTAVUUSANALYYSI Tutkimuksessa oli monta elementtiä, jotka pudottavat sen luotettavuutta. Koska käytössä ei ollut tavalliseen digikuvaukseen tarkoitettua kameraa, jolla olisi saanut äänitettyä myös puhetta, jouduttiin turvautumaan digitaalisen videokameran käyttöön. Siinä nauhalle kuvattiin noin seitsemän sekunnin ajan pysäytettyä kuvaa. Samaan aikaan nauhalle tallentui myös noiden seitsemän sekunnin aikana kuuluvat äänet. Koska kamera oli vääränlainen, ei käytettävissä ollut myöskään ohjelmistoa, joka olisi saanut kuvat ja äänet yksinkertaisesti tietokoneelle kuva- ja äänitiedostoiksi. Materiaali jouduttiin siirtämään koneelle video-clippinä, josta sitten Adoben Premiere-ohjelmalla tallennettiin yksittäiset framet bittikarttakuviksi ja äänet omiksi tiedostoikseen. Tässä yhteydessä parista ääninäytteestä hävisi katkelma alusta. Kuvat jouduttiin vielä muuttamaan jpg-muotoisiksi erillisessä kuvankäsittelyohjelmassa. Kuvat muutettiin myös png-formaattiin, mutta se toi mukanaan liikaa metatietoa eikä SRIM-ohjelma osannut enää lisätä omia tekstejään metatietoon. Lopulta kuvat muutettiin png-muotoisiksi SRIM:llä, jolloin halutut metatietolisäykset pystyttiin tekemään. Äänet olivat Premierin jälkeen niin hyvälaatuisia, ettei SRIM osannut niitä soittaa. Ilmeisesti sen muistikapasitetti loppui kesken. Niinpä ne oli vielä muutettava stereosta mono-muotoisiksi ja näytetaajuudeltaan 48 MHz:stä 16 MHz:ksi. Näin monen muutoksen jälkeen tiedostojen laatu oli tietysti jo huonontunut niin paljon, että jo se voi aiheuttaa ongelmat puheentunnistamisessa. Lisäksi SRIM-ohjelma on vielä niin epästabiili, että sen kaatumiset ja toiminnan hidastuminen muutaman kuvan käsittelyn jälkeen saattaa myös vaikuttaa tunnistustuloksiin. Lisäksi javan versio, jolla ohjelma tehtiin oli jo ehtinyt päivittyä, joten ohjelma ei senkään takia toiminut niin hyvin kuin sen olisi pitänyt. Tämä entisestään lisäsi virhetilanteiden määrää. 18

21 6 JOHTOPÄÄTÖKSET Tulevaisuudessa kuvan yhteyteen liitettävän metadatan merkitys korostuu kuvatulvan kasvaessa jatkuvasti suuremmaksi. Yhdeksi vaihtoehdoksi kuvaajille tarjotaan mahdollisuutta puhua haluttu metadata kuvan yhteyteen kuvaamisen yhteydessä. Tässä tutkimuksessa tutkittiin ajatuksen toteuttamismahdollisuutta ja erään ajatuksen ympärille rakennetun demon käytettävyyttä. Täysin todellista kuvaa tilanteesta ei kuitenkaan pystynyt saamaan oikean tyyppisten laitteiden puuttuessa. Tästä aiheutuneet virhemahdollisuudet on selvitetty edellisessä luvussa. Näytteiksi saattiin kuitenkin 20 kuvaa ja niiden yhteydessä otettua ääninäytettä. Ohjelma ei kuitenkaan pystynyt tunnistamaan näytteistä yhtään oikeaa lausetta. Tunnistetut tekstit menivät kaikki täysin väärin. Puheentunnistuksessa käytettiin Microsoftin verkkosivuilta saatavaa puheentunnistajaa, jota ohjailtiin java-apletilla. Tunnistajan ongelmana tuntui olevan taustaäänien negatiivinen vaikutus näytteen tunnistamisessa. Kameralla nauhoitetuista näytteistä ohjelma ei tunnistanut yhtäkään, mutta suoraan tietokoneelle sanellut lauseet se tunnisti täysin oikein. Kyse on siis pienestä viilauksesta. Kun puheentunnistuksen pystyy saamaan puhetta yleisemmin tunnistavaksi, voi SRIM-ohjelmakin olla käyttökelpoisempi sen tarkoittamaan tehtävään. Periaate tutkitussa ohjelmassa oli yksinkertainen ja hyvin käytettävä. Tiedostosta tunnistettu puhe siirtyi suoraan kuvan metatietoihin. Tässä yhteydessä olisi ehkä toivonut vielä mahdollisuutta muokata tekstiä ennen liittämistä, mutta toisaalta toimenpide teki ohjelman entistä helppokäyttöisemmäksi. Suoraan koneelle saneltua tekstiä pystyi vielä halutessaan muuttamaan ennen liittämistä. Kun kuvat saadaan helpommin kamerasta koneelle tiedostoiksi, on niiden liittäminen kuvaan ohjelman avulla helppoa. Metadatan syöttö puhumalla ei sovi kaikkiin tilanteisiin. Nopeasti vaihtuvassa tilanteessa kuvaaja saattaa ottaa kuvia puolen sekunnin välein. Muutaman sekunnin lausekin saattaa kestää liian pitkään. Uutis- ja urheilukuvaajilla sovelluksesta on siis harvoin hyötyä. Toisaalta lehdistötilaisuudessa voi olla mahdollisuus ottaa kuva ja sanella samalla haluamansa informaation nauhalle, kun kuvattavat istuvat joka tapauksessa paikallaan pöydän tai puhujanpöntön takana. Mahdollinen kohderyhmä voisi myös olla luontokuvaajat, jotka voisivat hiljaa sanella kuvaamansa lajin nimen tai muuta tietoa ottamastaan kuvasta. Myös valvontakameroihin liitetyt mikrofonit voisivat tuoda lisäinfoa mahdollisten vaarallisten tilanteiden aiheuttajien aikeista. Tässä tietenkin saatetaan mennä jo yksilösuojan puolelle. Tällä hetkellä puheentunnistajat pitää kouluttaa jokaiselle henkilölle erikseen, joten viimeksi mainittu sovellus on mahdollinen vasta jonkin ajan päästä. 19

22 7 YHTEENVETO Tutkimuksessa tutustuttiin käytettävyystutkimukseen ja kirjallisuudesta saatujen tietojen pohjalta laadittiin koesuunnitelma ja tutkittiin puheesta tekstiä kuvan metadataan syöttävän ohjelman käytettävyyttä. Tämän lisäksi tutkimuksessa pohdittiin ohjelman takana olevan idean toimivuutta ja sen mahdollista kohderyhmää. Käytettävyystutkimus voidaan jakaa kahteen päätapaan: tulevien käyttäjien kanssa tai ilman heitä tehtävä käytettävyystutkimus. Ilman käyttäjiä tehtävässä tutkimuksessa yleensä käytettävyyteen tutustuneet henkilöt tutkivat tuotteen läpikotaisin. Joskus tutkimus saatetaan tehdä ryhmässä, jossa on mukana käytettävyysspesialistien lisäksi myös tuotteen suunnittelijoita. Ryhmään voidaan vielä lisätä tulevat käyttäjät, jolloin tutkimustuloksista saadaan hyvin kattavia. Ilman käyttäjiä tehtävissä tutkimuksissa voidaan nähdä kaksi päätyyppiä: heuristinen arviointi ja kognitiivinen läpikäynti. Heuristisessa arvioinnissa järjestelmää tai tuotetta arvioidaan yleisten käytettävyyssääntöjen eli heuristiikkojen mukaan. Sääntöjen kanssa ristiriitaiset asiat merkitään muistiin ja niiden vakavuus arvioidaan. Kognitiivisessa läpikäynnissä pyritään lähinnä mittaamaan järjestelmän opittavuutta. Järjestelmää tuntematon henkilö yrittää selvittää hänelle annettuja tehtäviä järjestelmän antamien ohjeiden perusteella. Käyttäjien kanssa tehtävässä käytettävyystutkimuksessa käyttäjälle annetaan tehtäviä ja ohjeet siitä miten toimia. Käyttäjä kommentoi jatkuvasti ajatuksiaan jotka kirjataan myöhemmin ylös testistä tallennetusta nauhoitteesta. Perustestistä on kehitetty myös variaatioita kuten paritestaus ja ryhmätestaus. Paritestauksen hyvänä puolena on mm. ääneen ajattelun luonnollisuus parin pyrkiessä yhdessä ratkaisemaan tehtävää. Ryhmäläpikäynnissä on mukana käyttäjien lisäksi järjestelmän suunnittelijoita ja käytettävyysspesialisteja, joista kaikki pyrkivät samaistumaan käyttäjän osaan. Erityisen hedelmällistä näissä tilaisuuksissa on suunnittelijoiden ja käyttäjien käymä vuoropuhelu. Testattavana oli Teknillisen korkeakoulun Viestintätekniikan laboratoriossa kesällä 2001 tehty ohjelma, joka liittää puhutun tekstin määrättyihin kuviin metadatana. Ohjelma tutkittiin sekä heuristisesti että perinteisellä käytettävyystestauksella. Heuristisessa tutkinnassa kiinnitettiin huomiota käyttöliittymän yksinkertaiseen rakenteeseen ja siitä johtuvaan ohjelman käytön helppouteen. Negatiiviseksi koettiin ohjelman aputoimintojen puuttuminen ja joissain tapauksissa puuttuvat tai epämääräiset virheilmoitukset. Ohjelma on myös varsin epästabiili, joten virhetilanteita syntyi usein. Käytettävyystestauksessa ongelmana oli oikeantyyppisen laitteiston puuttuminen. Jouduttiin käyttämään korvaavaa laitteistoa kuvia otettaessa, joka aiheutta paitsi 20

23 ylimääräistä vaivaa, mutta myös ylimääräisiä virhetilanteita kuvia ja ääntä siirrettäessä tietokoneelle. Lopputulos oli, ettei ohjelma osannut tulkita oikein yhtään 20:stä ääninäytteestä. Sen sijaan ohjelmassa oleva mahdollisuus metatiedon puhumiseen suoraan ohjelmaan toimi hyvin kuten myös metatiedon lisäys perinteisesti kirjoittamalla. Valokuvauksen alalla on tilanteita, joihin metadatan puhuminen sopii ja tilanteita, joihin se ei sovi. Kuvatulvan kasvaessa metadatan merkitys kuvien organisoinnissa kuitenkin kasvaa jatkuvasti. Vaihtoehtoja kirjoittamiselle kannattaa etsiä. Puheentunnistus on yksi varteenotettava tapa, vaikka se suuresta kehityksestään huolimatta on vielä sen verran lapsen kengissä, että tutkitun menetelmän saaminen ideasta täysin toimivaksi sovellukseksi vienee aikaa vielä useita vuosia. 21

24 22 LÄHDELUETTELO /1/ Anttonen, T. Metatieto: mitä se on? Jyväskylän yliopisto, Tietotekniikan tutkimusinstituutti, Jyväskylä 1999, päivitetty [viitattu ]. Saatavilla www-muodossa:<url: /2/ Kivinen, J. Tutkimusraportti: Puhe digitaalikuvan metadatan lähteenä. TKK, Viestintätekniikan laboratorio, Espoo s. /3/ Riihiaho, S. Experiences with usability evaluation methods. Helsinki University of Technology, Department of computer science and engineering, Espoo p. /4/ Riihiaho, S. Käytettävyyden arviointi ilman käyttäjiä. Teknillisen korkeakoulun käytettävyyslaboratorion julkaisuja, Espoo [viitattu ]. Saatavilla wwwmuodossa: <URL: /5/ Riihiaho, S. Käytettävyystestauksen muunnelmia. In: Pantzar, Eero (Ed) Informaatio, tieto ja yhteiskunta. Reports of information Research Programme of the Academy of Finland No. 4. University of Tampere, S