8 Ihminen, hypermedia ja käytettävyys Hypermedia on ihmisen keksintö ja olemassa ihmisen tarpeita varten Hypermediasovellus voidaan tulkita tuotteeksi tai välineeksi Tuotteelle X asetetaan (voidaan yleisesti asettaa) seuraavia tavoitteita - tuotteella on käyttäjiä (kohderyhmä) - tuote täyttää käyttäjien jonkin todellisen tarpeen ("tarpeita" voidaan markkinoinnilla myös laskelmoidusti luoda) - tuotteella pitää yo. näkökulmasta olla jotain hyötyä - kaiken kaikkiaan tuotteesta on kohderyhmälle "todellista käyttöarvoa" (tarpeen näkökulmasta) Koska yleensä tuotteen pitäisi tietenkin toimia paitsi teoriassa, myös käytännössä, pitää tuotteen olla käytettävä (pelkkä periaatteellinen hyödyllisyys ei riitä) Tuotteen käytettävyys pyritään maksimoimaan käyttäjien, tarpeen ja tavoitellun hyödyn sanelemana (käytettävyys ilmenee siis vain jossakin kontekstissa) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 175
Välisoitto: Taide, käytettävyys, hypermedia ja muotoilu Taideteosten yhteydessä käytettävyydestä ei ole yleensä mieltä päällimmäisenä puhua. Jos hypermediasovelluksen X ensisijaisena tarkoituksena on taiteellinen ilmaisu, sen käytettävyyden arvioinnissa ei välttämättä juurikaan ole mieltä. 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 176
Useimpien käytännön sovellusten yhteydessä käytettävyydestä on kuitenkin mielekästä puhua (ja esim. arvioida sitä, miten helppoa taideteos-hypermedian katselu omalla kotitietokoneella käytännössä on). Toisaalta esim. hyvä veitsi voi myös olla todellinen taideteos. Yleisesti taiteellisuus, hyödyllisyys, käyttökelpoisuus, yms. eivät tietenkään ole toisensa poissulkevia käsitteitä. Käytettävyyden käsite liitetään yleensä kuitenkin ensisijaisesti yhteen hyödyllisyyden ja käyttöarvon käsitteiden kanssa (jotka esim. "nykyaikainen taide" [ahtaasti ymmärrettynä] pitkälti sivuuttaa). Tästä näkökulmasta katsottuna "taiteellisen hypermedian tekeminen" vastaa siis lähinnä muotoilua (design): Designin avulla luovuuden tuottamalle idealle annetaan toteuttamiskelpoinen muoto sekä hallittu, kaunis, käyttökelpoinen ja houkutteleva hahmo Hypermediaa ei siis kannata tehdä pöytälaatikkoon vaan täyttämään todellisen kohderyhmän eli loppukäyttäjien reaalisia tarpeita. Yleensä kohderyhmä ei ole - tietokone tai WWW-selain - tuotantotiimi tai tekijä itse - rahoittavaa tahoa edustava henkilö 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 177
Lähtökohta: HCI HCI = Human-Computer Interaction HCI on "paradigma" jonka tavoitteena ihmisen huomioonottaminen tietokonejärjestelmiä (erityisesti näiden käyttöohjeita, käyttöliittymiä ja opasteita) suunniteltaessa ja toteutettaessa Hyvä tietokone(sovellus) mukautuu käyttäjän tarpeisiin ei päinvastoin Onnistumisen edellytyksiä (käytännössä siis myös tuotantotyön organisoinnin tavoitteita): - loppukäyttäjät mukaan suunnitteluprosessiin(!) - tuotesuunnittelussa otettava huomioon muidenkin kuin "teknisten tieteiden" tuottama tieto (läh. "kognitiotieteet" ja havaintopsykologia) - tuotteiden jatkuva testaaminen ja asteittainen kehitys ( jatkuva protoilu) Filosofia pähkinänkuoressa: järjestelmää käyttävä ihminen on (tieto)teknisten sovellusten suunnittelun keskeisin tekijä (ei jotain joka liimataan mukaan "suunnittelun viime metreillä") 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 178
A model of HCI HCI:n "toimialueet" voidaan jäsentää esim. seuraavasti: Levels of analysis in HCI Level 3 Level 2 Social system Immediate environment Work Organizational goal Technical system Broader environment Level 1 People Technology (lähde Benyon et al: Human-Computer Interaction, s. 44) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 179
HCI-mäinen tapa tehdä asioita: iteratiivinen suunnittelu Lähtökohta: suunnittelija ei tunne asiakasta tai sovellusta paremmin kuin asiakas itse, toisaalta asiakas ei osaa jäsentää haluamaansa (teknisesti) Sama pätee järjestelmän loppukäyttäjään Seuraus: protoilu suunnittelu toteutus määrittely arviointi Protoilussa idea on se, että käyttäjä on "keskellä", ts. asiakas~loppukäyttäjä Käytännössä (noviisi)käyttäjät eivät kuitenkaan aina osaa määritellä tarpeitaan (esim. tekniset mahdollisuudet ja reunaehdot huomioiden); tällöin työtä tehdään yhteistyössä hyväntahtoisen suunnittelijan avustamana 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 180
HUOM: "Käytettävyys" on (vain) osa "hyväksyttävyyttä" Nielsen: The various parameters associated with system acceptability: Social acceptability Utility "TEKEE JOTAIN HYÖDYLLISTÄ" System acceptability Practical acceptability Usefulness Cost Usability Easy to learn Efficient to use Easy to remember Compatibility Reliability Etc. "TOIMII MYÖS KÄYTÄNNÖSSÄ" Few errors Subjectively pleasing Käytännössä järjestelmän X käytettävyyteen ei tietenkään pyritä "hinnalla millä hyvänsä" (ainakaan esim. hyödyllisyyden kustannuksella ei pitäisi pyrkiä) Käytettävyys voidaan määritellä eri tavoin (yleensä tavoite on sama) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 181
Esimerkki #1: On helppo suunnitella "piano" jota kuka tahansa osaa soittaa jos taas suunnitellaan Piano jolla pianotaiteilija voi soittaa myös rokkia, klassista ja humppaa, ei sitä kuka tahansa (millä taidoilla tahansa) osaakaan soittaa vs. Esimerkki #2: On helppo suunnitella "tekstinkäsittelyohjelma" jota kuka tahansa oppii käyttämään jos taas halutaan Tekstinkäsittelyohjelma jolla tekninen kirjoittaja voi dokumentoida myös paperikoneen huoltokirjan, sitä ei todennäköisesti kuka tahansa (millä tiedoilla tahansa) osaakaan käyttää Rakas Jane, Haluaisin alleviivata nimesi, mutta käyttämäni tekstinkäsittelyohjelma ei siihen pysty. Cowabanga tätä tekniikkaa #$&%!!!! vs. t: Tarzan 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 182
"HCI-mäisyydellä" saadaan käytettäviä sovelluksia Jos realistinen käyttäjän näkökulma otetaan (hypermedian) suunnittelussa huomioon, tuloksena on paitsi käytettäviä järjestelmiä, myös mm. turvallisia järjestelmiä (ts. ei vääriä olettamuksia käyttäjien tiedoista ja taidoista) Käyttöliittymä on osa käytettävyyttä (vrt. käytettävyys on osa hyväksyttävyyttä). Käytettävä järjestelmä on: - helppo oppia, - tehokas käyttää, - helposti muistettavissa, - aiheuttaa vähän virheitä ja - on mukava käyttää Pulma joka turhan usein sivuutetaan: ei-triviaalien sovellusten tapauksessa tavoitteet ovat osin ristiriitaisia (erityisesti helppokäyttöisyys ja tehokkuus) Ratkaisu: käytettävyydestä on tarkoituksenmukaista puhua suhteessa johonkin käyttäjäryhmään (joilla on tiettyjä tavoitteita, toiveita, tietoja ja taitoja) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 183
Noviisi-vakiokäyttäjä-ekspertti? Suoria ja konkreettisia vaikutuksia sovellusten kaikkeen suunnitteluun: 1. sovelluksen tavoite ja keskeiset käyttäjäryhmät pitää aina identifioida jo suunnittelutyön alussa (parhaimmillaan esitutkimuksen avulla) 2. olennaisesti erityyppisiä käyttäjiä varten on toteutettava erilaiset välineet (esim. "eksperteille" oma käyttöliittymänsä tai oikopolkunsa) 3. kannattaa muistaa, että käyttäjät muuttuvat & kehittyvät järjestelmän käytössä (tyypillinen jaottelu: noviisi, vakiokäyttäjä, eksperttikäyttäjä) Noviisi: "ei edes tiedä mitä ei tiedä (esim. ei tiedä järjestelmän toimintoja)" Vakiokäyttäjä: "tietää mitä järjestelmän avulla voi tehdä ja osaa yleensä tehdä sen mitä haluaa (jollakin tapaa)" Eksperttikäyttäjä: "tietää miten asiat hoituvat järjestelmän avulla parhaiten" Yksi ja sama käyttäjä voi eri asioiden suhteen olla noviisi, vakiokäyttäjä tai eksperttikäyttäjä -- HUOM: noviisi-ekspertti -jaottelu ei ole pelkästään "tiedollinen" jaottelu (eksperttiys edellyttää yleensä tietojen lisäksi myös taitoja!) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 184
HCI:n kulmakivi: selkeä vuorovaikutus Hyvä käyttöliittymä perustuu käyttäjän ymmärtämiin käsitteisiin eikä pakota ulkoa muistamiseen "Hyvässä" sovelluksessa toteutuvat HCI:n kaksi keskeistä ideaa: näkyvyys ja - toimintojen "näkyvyys ja saatavuus" (visibility) - toimintojen "itsestäänselvyys" (affordance) Minä olen nappula Minä olen linkki Minä olen kuva X Tämä on WWW-sivu jossa ei ole muita toimintoja Ensimmäiseen voidaan vaikuttaa selkeällä käyttöliittymäsuunnittelulla, toiseen hyvällä käsitesuunnittelulla ja esim. sopivan metaforan valinnalla (opitun siirtovaikutus) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 185
Mentaaliset mallit (lue: oikeat käsitteet ovat ¾ voittoa) Ihmiset ymmärtävät välineen käytön jonkin mentaalisen mallin avulla, eivät koskaan "suoraan" (tässä tulkinta: mentaalinen malli ~ käsitteellinen malli) muovista koostuu isoisällä oli pokasaha puuta metallista "saha" sillä voi sahata lasivillaa tylsyy ja ruostuu Mentaalinen malli on objektin tai prosessin tarkoituksenmukainen kuvailu sopivalla tarkkuudella joka "riittää käyttäjälle" - mallin tarkkuus ja "oikeellisuus" ovat riippuvaisia tavoitteista (ja aineistosta) - tarkoituksesta riippuen "sama objekti tai prosessi" voidaan siten ymmärtää useiden vaihtoehtoisten mentaalisten mallien avulla 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 186
Esimerkki: Sähköpostin käyttöön ja sähköpostipalvelimen ylläpitoon liittyvät mentaaliset mallit "sähköpostista" ovat erilaisia (mieti miten) Mentaalisia malleja käytetään: - päättelyn ja selittämisen tukena - ennustamisessa (todellisuuden "mielensisäinen simulointi") - ja siten toimintojen suunnittelussa ("mallien läpikävely") Mentaalisten mallien ominaisia piirteitä - yleensä tarkkaan ottaen tiedostamattomia ja ei-kielellisiä - rakennuspalasina suorat havainnot, muistikuvat, analogiat, propositiot ja objektien väliset suhteet (?) - taustalla olettamuksia ja tietoja objektin olennaisista piirteistä - pikemminkin suuntaa-antavia kuin pikkutarkkoja - käytetään tietoisesti esim. "ajamalla mentaalinen malli ongelmatilanteissa" - täydennetään ja täsmennetään tarvittaessa 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 187
Rakenteelliset ja toiminnalliset ja mentaaliset mallit Mentaalisia malleja ajatellaan olevan (kärjistetysti) kahdenlaisia: rakenteellisia ja toiminnallisia (funktionaalisia) RMM: miten se toimii tai millainen se on? TMM: mihin sitä voi käyttää ja miten sitä käytetään? muovista koostuu isoisällä oli pokasaha puuta metallista "saha" sillä voi sahata lasivillaa tylsyy ja ruostuu Rakenteelliset mallit - (teknisen) suunnittelun perusta - mentaalisia korvikkeita todellisille systeemeille ja tapahtumaketjuille 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 188
- tavoitteina systeemien ymmärtäminen ja niiden käyttäytymisen ennustaminen niiden rakenteen ja toiminnan kuvailun kautta - tyypillinen käyttö ongelmatilanteissa: miten se-ja-se korjataan/huolletaan? - rakenteelliset mallit ovat usein epätäydellisiä ja suorastaan virheellisiä - rakenteellisten mallien kehittyminen tapahtuu ääripäässä "teoreettisen opiskelun keinoin" (~selitysvoimaisten mallien kehitys & opiskelu) - usein luonteeltaan yleisiä ja kontekstiriippumattomia (seurauksena tiedon "kerääntyminen") - tuloksena eriytynyt asiantuntijuus (hyviä rakenteellisia mentaalisia malleja on "harvoilla") Toiminnalliset mallit - kuvailuja siitä mihin ja miten järjestelmiä käytetään - pyrkimyksenä tavoitteiden saavuttaminen ja tehtävien tekeminen ("kunhan työtapa toimii luotettavasti ~ tuottaa halutun lopputuloksen") - tyypillinen käyttö toistuvien tehtävien suorittaminen: miten se-ja-se käytännössä tehdään? 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 189
- toiminnallisten mallien kehittyminen tapahtuu usein käytännöllisen opiskelun kautta ("tekemällä oppii") Suurin osa tietämyksestämme perustuu toiminnallisten mallien käyttöön Seuraamuksia suunnittelutyöhön: järjestelmien toiminnan käsitteellistäminen toiminnallisesta näkökulmasta käsin on usein edullisempaa kuin rakenteelliseen tarkasteluun pohjautuva käsitteellistäminen, esim.: - noviiseille näytetään miten systeemi toimii ja miten sitä pitää käyttää - eksperteille tarjotaan mahdollisuus tietää myös miksi se toimii kuten toimii (jos tarpeen) Kysymys: Mitä mentaaliset mallit sitten "käytännössä" ovat? (päässäni) Vastaus: Kukaan ei (kai?) oikeastaan tiedä; psykologian näkökulma asiaan: - skeemat: yksilön kokemuksista ja tiedoista muodostunut käsitteitä ja niiden suhteista mallintava tietorakenne ("nappi: kohollaan olevaa osaa, jota painamalla tapahtuu jotain") - skriptit: skripti on sarjamuotoinen skeema, esimerkiksi tapahtumasekvenssi ("joku tulee avaamaan kun painan oven vieressä olevaa nappia") 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 190
Mentaalisten mallien huomiointi suunnittelussa Väärä mentaalinen malli johtaa virhearviointeihin ja erheisiin takaisinkytkentä todellisuuden kanssa Ihmisillä on mentaalisten mallien suhteen taloudellisuusperiaate ("ei haluta tietää enemmän kuin on välttämätöntä"; syy kognition rajoittuneisuus?) Tästä syystä järjestelmien käyttäjille (loppukäyttäjät) ja niiden suunnittelijoilla ja toteuttajilla on väistämättä "oletuksena" samasta järjestelmästä erilaiset mentaaliset mallit Erityisesti: loppukäyttäjiltä ei missään tapauksessa pidä vaatia teknisten suunnittelukäsitteiden tuntemusta elleivät ne ole osa sovelluksen keskeistä asiasisältöä Järjestelmien suunnittelutyössä on siten tarkoituksenmukaista pitää erillään - järjestelmän tekniseen suunnitteluun liittyvät käsitteet, - järjestelmän toteutukseen ja ylläpitoon liittyvät käsitteet ja - järjestelmän arkikäyttöön liittyvät käsitteet (loppukäyttäjät!) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 191
Huomaa: termillä "tekniikka" viitataan tässä paitsi tietotekniikkaan, myös esim. kognitiotieteen, psykologian & kasvatustieteen käsitteisiin ja malleihin Esimerkki: Television käyttö voidaan kuvata usein eritasoisin käsittein (mieti miten haluaisit itse käyttää / millaista käyttöopasta lukea?) - fysikaaliset käsitteet (empiiriset luonnonlait) - suunnittelukäsitteet (elektroniikan ja signaalinkäsittelyn käsitteistö) - loppukäyttäjän käsitteet (tv-kanavat, kuvan ja äänen säätäminen) On ilmeistä että "oikean" (käyttötarkoitukseen sopivan) mentaalisen mallin muodostuminen tehostaa välineen käytettävyyttä Loppukäyttäjien mentaalisten mallien muodostusprosessia pitää siis aktiivisesti tukea "oikeaan suuntaan" (käsitteellistäminen ja käyttöliittymäsuunnittelu) Lopullisena tavoitteena on suunnittelun käsitteellisen mallin (design model) ja käytön käsitteellisen mallin (user model) tarkoituksenmukainen yhdistäminen 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 192
Loppukäyttäjän kuudenteen aistiin ei pidä luottaa Tietotekninen järjestelmä välittyy suunnittelijalta loppukäyttäjälle ensisijaisesti kolmea "tietä" ( [loppukäyttäjän] järjestelmän käsitteellinen malli) 1. käyttökoulutuksen, -ohjeen ja järjestelmän dokumentaation kautta 2. järjestelmän "ajonaikaisen" käyttäytymisen ja toiminnan kautta 3. opasteiden kautta ETUSIJALLA: koulutus, dokumentaatio, käyttö, opasteet ja ohjeet todellisia tarpeita loppukäyttäjä tuote suunnittelija tietoa suunnittelusta ja toteutuksesta 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 193
Käyttöohjeen ja dokumentaation tehtävänä on kuvata tuotteen toiminta ja oikeaoppinen käyttö, sisältäen erityisesti - käyttötarkoituksen, - peruskäsitteet, - käyttöliittymän kuvailun, - yhtymäkohdat toimintaympäristön kanssa ja - järjestelmäarkkitehtuurin kuvauksen (kohderyhmittäin sopivalla tarkkuudella) Ohjelman ajonaikainen käyttäytyminen tehdään hallittavaksi järjestelmän näkyvän systemaattis-loogisen toiminnan ja hyvän käyttöliittymän avulla Käyttäjän turvaksi ja ulkoa muistamisen vähentämiseksi tarjotaan lisäksi opastetoiminto joka tyypillisesti sisältää myös - kuvauksen järjestelmästä ja sen käsitteistä, - tiivistetyn dokumentaation (josta mahd. pääsy täydelliseen dokumentaatioon), - kontekstisidonnaisia menetelmäohjeita ja vinkkejä sekä - ohjeita virhetilanteista toipumiseen 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 194
Heuristisen käyttöliittymäsuunnittelun 10 muistisääntöä Tyypillinen hyvän käyttöliittymäsuunnittelun muistilista sisältää esim. seuraavat kohdat (Nielsen): - järjestelmän tila (jos on pakko käyttää) pitää olla aina käyttäjän tiedossa - järjestelmän käsitteiden tulee vastata sovellusalueen käsitteitä - ei-toivotut komennot on voitava selkeästi peruuttaa (lipsahdukset!) - käsitteiden ja toimintojen tulee olla systemaattisia ja odotusten mukaisia - käyttövirheet tulee ennakoida ja ennaltaehkäistä virheiden tekeminen - käytön tulee olla havaitsemista ulkoa muistamisen sijaan - eksperteille on tarjottava tehokkaita menetelmiä (optiot ja adaptiivisuus) - pieni on kaunista - toteuta selkeät virheviestit jotka ehdottavan ongelman korjaamista - ohjeet ja dokumentaatio tulisivat aina olla tarvittaessa saatavilla 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 195
Opasteet Tyypillisiä opasteille asetettuja kysymyksiä ovat esim. - tavoite (mitä ohjelmalla voi ylipäänsä tehdä?) - määrittely ja kuvaus (mikä tämä on? mitä sillä tehdään?) - tehtävien suorittaminen (miten teen tämän-ja-tämän?) - toiminnan selittäminen (mitä tapahtui?) - tilan määrittäminen (missä minä nyt olen? mitä voin tehdä?) Opastuspyynnöt jatkuvaan käyttöön tarkoitetuista toiminnoista ovat tyypillinen merkki suunnitteluvirheestä (ohjeet, käsitesuunnittelu tai käyttöliittymä eivät ok) Mikäli käyttäjät eivät kykene käsitteellistämään ongelmiaan, opasteista ei juuri ole hyötyä (osittainen ratkaisu: kontekstisensitiiviset opasteet) Opasteet tulee suunnitella mentaaliset mallit huomioiden - käsitteelliset opasteet (rakenne) - konkreettiset opasteet (toiminta) 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 196
Hypermedian ominaispiirre: väline, jossa on sisältöä Yleisesti: (tietotekninen) järjestelmä on väline jota käytetään johonkin Esimerkki: toimistosovellukset - ensisijainen työtehtävä = työtehtävä X: (esim. tehokas tekstinkäsittely) - toissijainen työtehtävä = välineen v X käyttö (ja käytön opiskelu) työtehtävän X suorittamiseksi (esim. StarOffice -ohjelmiston opiskelu) vs. 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 197
Kärjistys: väline v X on käytettävä jos sen käyttäminen (käytön opiskelu) ei vie päähuomiota tehtävän X tekemisestä (eli käytännössä ensisijainen työtehtävä tavalla tai toisella tehostuu toissijaisen "lisä"työtehtävän tekemisen ansiosta) Pulma: Hypermediassa tilanne on sikäli erikoinen että esim. WWW-palveluilla on yleensä valmiiksi jotain tiettyä sisältöä Seuraus: hypermediasovellusten käyttöliittymäsuunnittelu kytkeytyy sisältöihin "yleisiä järjestelmiä" enemmän Keskeinen osa WWW-suunnittelua on siten asiasisällön ja sen rakenteen käsitteellinen ja kuvallinen koodaus sopivan vuorovaikutusmekanismin suunnittelun avulla Sisällön korostunut rooli 73270 HYPERMEDIAN PERUSTEET (syksy 2003) 198