10 Hypermedia, ihminen ja käytettävyys Tekeminen jäsentyy symbolien ja metaforan kautta Ennen syvällisempää paneutumista käytettävyyteen luonnehditaan lyhyesti metaforakäsitettä. Yhteys aiheeseen löytyy ajatuksesta, jonka mukaan ei-triviaalin WWW-sivujen tekemistä voi verrata käyttöliittymän suunnitteluun ja toteuttamiseen (hyperdokumentin lukemisen vuorovaikutteisen perusluonteen ansiosta). Tällöin pelkän asiasisällön esittämisen ohella merkittävää on ilmeisesti myös se tapa, jolla asiat jäsennetään & esitetään. Metaforan rooli kaikessa tässä on tarjota käyttäjälle käsitteelliset välineet uuden oppimiseen. Tietojenkäsittely ja ohjelmistotyökalujen käyttö ja (miksei myös muiden asioiden ymmärtäminen) perustuvat käsitteellisesti metaforien käyttöön Metaforalla tarkoitetaan kuulijalle entuudestaan tuttua tai ymmärrettävää vertauskuvaa, esimerkkiä tai analogista mallia jonka kautta uuden käsitteen tai prosessin ymmärtäminen helpottuu Usein ohjelmistojen käyttöliittymät, työkalut (miksei myös teoriat) muotoillaan siten, että ne on mahdollista helposti ymmärtää joidenkin entuudestaan tuttujen käsitteiden avulla > << > >> 12:45.00 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 217 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 218 Esimerkkejä - hypertekstin intuitiivinen selittäminen onnistuu helpoimmin kartta&paikka-metaforan avulla (tai suoraan sanan verkko avulla) - puun (graafin erikoistapaus) metafora puolestaan on puu - WYSIWYG-tekstieditorin avulla tapahtuva kirjoitustyö perustuu pitkälle ajatukseen paperille tapahtuvasta kirjoitustyöstä (+uusia ominaisuuksia) - graafisen käyttöliittymän malli tulee toimiston pöydästä (mukana myös selviä ristiriitoja!) - verkossa välitetään tietoa ilmoitustaulujen, sähköpostin ja kotisivujen avulla - hyperdokumenteissa navigoidaan ja sähköisen kaupan sivuilta ostokset kerätään ostoskoriin - laskutoimituksia suoritetaan avaruudessa, funktion integroiminen tarkoittaa pintaalan laskemista, lukujono saattaa olla suppeneva, predikaattilogiikan lauseiden totuusarvo selviää mallien avulla, jne. Huomaa: - metaforan nimi näkyy usein sovelluksen nimessä (usein metaforan käyttöä ei edes huomaa ajatella) - metaforat lisääntyvät kulttuuris-teknillisten muutosten myötä; tänä päivänä CDsoittimen ohjauspaneli sopii jo metaforaksi länsimaissa - tietokoneet ja näihin liittyvät asiat myös muuttavat vanhoja metaforia; vrt. toimistometaforan muuttuminen (arkistokaapit? kortistot? ) - esim. hyperteksti alkaa toimia jo omana metaforanaan Metaforien käyttö perustuu ajatukseen, jonka mukaan ymmärtäminen on karkeasti sanottuna kyky mallintaa (uudelleenmuotoilla) jokin ilmiö entuudestaan tuttujen käsitteiden avulla (riittävän yhtäpitävässä muodossa) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 219 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 220
Metaforien käytön hyviä puolia: - uusia sanoja (termejä) tarvitaan vähemmän! - uusien käsitteiden omaksuminen on nopeampaa - jos metafora on soveltuva, työskenteleminen on alusta alkaen loogista ja intuitiivista - samantyyppisten metaforien käyttäminen eri sovelluksissa mahdollistaa tietojen ja taitojen monipuolisen käytön (ja tietämyksen siirtämisen) Metaforien käytön huonoja puolia: - sanat (termit) voivat mennä myös sekaisin! - metaforan kautta ilmiöön saatetaan liittää vääriä olettamuksia - ilmiö saatetaan olettaa liian suppeaksi tai monimutkaiseksi - jos metaforan ymmärtämiseen liittyy virheitä tai huonoja työtapoja, siirtyvät samat ongelmat myös uuteen sovellukseen Hypertekstijärjestelmän paras käyttömetafora EI aina ole hyperteksti (!) 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) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 221 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 222 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ä. 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ö MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 223 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 224
Lähtökohta: HCI HCI = Human-Computer Interaction HCI on toimintatapa, 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ä) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 225 A model of HCI HCI:n toimialueet voidaan jäsentää esim. seuraavasti: Levels of analysis in HCI Level 3 Level 2 Immediate environment Level 1 Social system People Work Organizational goal Technical system Technology Broader environment (lähde Benyon et al: Human-Computer Interaction, s. 44) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 226 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 määrittely toteutus 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 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 227 HUOM: Käytettävyys on (vain) osa hyväksyttävyyttä Nielsen: The various parameters associated with system acceptability: System acceptability Social acceptability Practical acceptability Usefulness Cost Compatibility Reliability Etc. Utility Usability "TOIMII MYÖS KÄYTÄNNÖSSÄ" "TEKEE JOTAIN HYÖDYLLISTÄ" Easy to learn Efficient to use Easy to remember 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ä) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 228
Käytettävyys voidaan määritellä eri tavoin (yleensä tavoite on sama) Esimerkki #1: On helppo suunnitella pianon kaltainen soitin, 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 #$&%!!!! t: Tarzan vs. MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 229 HCI-mäisellä toiminnalla 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) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 230 Noviisi-vakiokäyttäjä-ekspertti? Suoria ja konkreettisia vaikutuksia sovellusten kaikkeen suunnitteluun: Sovelluksen tavoite ja keskeiset käyttäjäryhmät pitää aina selvittää ja yksilöidä jo suunnittelutyön alussa (parhaimmillaan esitutkimuksen avulla) 1. olennaisesti erityyppisiä käyttäjiä varten on toteutettava erilaiset välineet (esim. eksperteille oma käyttöliittymänsä tai oikopolkunsa) 2. 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!) 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: - toimintojen näkyvyys ja saatavuus (visibility) - toimintojen itsestäänselvyys (affordance) Minä olen nappula Minä olen linkki Minä olen kuva 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) X MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 231 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 232
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 metallista tylsyy ja ruostuu koostuu "saha" isoisällä oli pokasaha sillä voi sahata MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 233 puuta lasivillaa 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 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 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 234 Rakenteelliset ja toiminnalliset mentaaliset mallit Mentaalisia malleja ajatellaan olevan (kärjistetysti) kahdenlaisia: rakenteellisia ja toiminnallisia (funktionaalisia) RMM: miten se toimii tai millainen se on? muovista metallista tylsyy ja ruostuu koostuu "saha" TMM: mihin sitä voi käyttää ja miten sitä käytetään? isoisällä oli pokasaha sillä voi sahata puuta lasivillaa Rakenteelliset mallit - (teknisen) suunnittelun perusta - mentaalisia korvikkeita todellisille systeemeille ja tapahtumaketjuille - 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? MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 235 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 236
- 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) 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!) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 237 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 238 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 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: todellisia tarpeita loppukäyttäjä koulutus, dokumentaatio, käyttö, opasteet ja ohjeet tuote suunnittelija tietoa suunnittelusta ja toteutuksesta MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 239 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 240
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 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 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 241 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 242 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) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 243 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) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 244 vs.
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 WWW-palvelujen erityispiirteitä (käytett. näkökulmasta) Hypertekstin sisäsyntyiset käytettävyysongelmat - hyperavaruuteen eksyminen (~rajattomuudesta aiheutuva monimutkainen navigointihistoria) - kognitiivinen ylikuormitus (~paljon informaatiota, vaihtoehtoja, nähtävää ja muistettavaa) Keskeinen pulma (toki myös WWW:n rikkaus) on se, että erityyppiset vuorovaikutusmekanismit limittyvät WWW:ssä, eikä tähän pystytä juuri vaikuttamaan - WWW-sovellusten rajat ovat yleensä käyttäjille epäselviä (vaikea hallita) - sama toiminto tuottaa eri tuloksen eri paikoissa (mahdoton hallita) WWW:n tekniset ongelmat - muutokset (kehitys) - ohjelmistojen yhteensopivuusongelmat - verkon kapasiteettiongelmat (pitkät vasteajat ja vaihteleva kapasiteetti) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 245 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 246 Verkkopalvelun käytettävyyden yleisiä tekijöitä (esim.) Esitiedot (mitä käyttäjältä vaaditaan miten helppoa palvelun oppiminen on) Luettavuus (miten helppoa/nopeaa/miellyttävää tekstin lukeminen on) Navigoitavuus (missä olen, mihin voin mennä, tuonneko, olenko perillä) Haettavuus (selaus, hakusanat, tulosten esitys, tarkennus) Skaalautuvuus (tekniikka, sisältö, käyttöliittymä) Nopeus (miten nopeasti näyttö vaihtuu tai hakukone toimii) Vuorovaikutus (dialogi, jatkuva, koodattu, tarkoituksenmukainen) Vakaus (voinko luottaa että käytössä/toimii/tallettaa tiedot/suojattu) Muunneltavuus (vaihtoehtoisia näkymiä, voiko sisällön jäsentää toisin, palveleeko sekä noviiseja että eksperttejä, kansainvälisyys, aistivammaiset ja muut erityisryhmät) Sisällön soveltuvuus (rakenteeseen/käyttötarkoitukseen) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 247 Tyypillisiä WWW-sovellusten ongelmia (huono suunnittelu) Todellista sanottavaa ei aina juurikaan ole (!) tai sitten asiasisällön tarkoituksenmukaista jäsennystä ei juuri mietitä etukäteen Käyttäjäkuntaa ei huomata profiloida järkevästi (tuhoisa kaikille kaikkea -pyrkimys; parempi olisi: useimmille jotakin kohderyhmälle kaikkea) Toteutukset ovat usein liian ns. teknologiavetoisia (syyttä suotta) Oletetaan perusteetta että kaikilla on 10Mb lähiverkko ja että asiakkaat haluavat ladata & asentaa selaimen X4.812b ja siihen selainlaajennukset x 1,x 2,,x n Työn ensisijaiset tavoitteet sekoittuvat matkan varrella - sekoitetaan sisältötuotanto ja teknologiademoilu - ylikorostetaan ulkoasua asiasisällön kustannuksella (ks. ajankäyttö!) - luontevasti peräkkäismuotoisen tekstin rakenne rikotaan suotta tai puuroutetaan teksti epäolennaisilla linkeillä (muka hypertekstiä) Unohdetaan WWW-sovelluksen konteksti ja yhtymäkohdat esim. painetun tekstin ja käyttäjän varusohjelmien (ja laitteiden) kanssa MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 248
Käytettävyyssuunnittelun perusta: kokemusperäinen tieto Työvälineen käytettävyyden arviointi ja sen parantaminen perustuu - käyttäjäryhmän (tavoitteiden, tietojen ja taitojen) tuntemukseen (kenelle) - työtehtävän tuntemukseen (tarpeet) - välineen, sen tekniikan ja mahdollisuuksien tuntemukseen (tekn. perusta) - ihmisen kognition tuntemiseen (inhim. perusta) - jatkuvaan testaamiseen ja testituloksiin reagoimiseen (nöyryys!) Jos yksikin yo. peruspilareista puuttuu, jää välineen käytettävyyden arviointi ja toteutuminen pakostakin vaillinaiseksi Käytännössä käytettävyyden toteutumiseen pyritään (itse testauksen ohella) - tavoitteiden, työn suunnittelun, työn toteutusvaiheiden ja testauksen systemaattisen suunnittelun ja kirjaamisen avulla sekä - sudenkuopat välttävien tarkistus- ja muistilistojen seuraamisen avulla Muiden hyväksyttävyys-kriteerien täyttymiseen pyritään vastaavasti (tärkeitä!) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 249 Käytettävyyden suunnittelu (esim.) Tie hyvän ja käytettävän tuotteen tekemiseen on systemaattinen ja realistinen suunnittelu jossa tavoitteet, menetelmät ja arviointi on kirjattu mustalla valkoiselle Työn yleiset tavoitteet - mikä on työn kokonaistavoite (hyväksyttävä tuote) ja käytettävyyden rooli tässä tavoitteenasettelussa - tilaajat, toteuttajat, käyttäjät (jokaisella on omia käytettävyystavoitteitaan) - ristiriitaisuus on vain hyväksyttävä ( tavoitteiden & organisoinnin monitavoiteoptimointi; hankalaa, mutta pakko tehdä) - muutokset tarvittaessa Keskeinen kohderyhmä (todellisuudessa) - taustatiedot: atk-taidot, sisältötuntemus, yms. - ikä, huomiokyky, näkökyky, käyttötyyli, nopeus, luku- ja navigointitottumukset - käytön nopeus, kärsivällisyys, kokemus MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 250 - laitteisto, käyttöjärjestelmä, ohjelmat, selain ja selainlaajennukset, verkkoyhteys, näyttölaite (koko, värit), syöttölaitteet (näppäimistö, hiirten nappien lkm) - käyttöympäristö, keskeiset ympäristötekijät (esim. käytetään työkonetta ajettaessa), käytön tiheys - erityisvaatimukset; ei-standardi laitteisto, erityisryhmät (henkiset kyvyt, motoriikka, nopeus, aistit) Käyttäjien tarpeet - tiedostetut/tiedostamattomat, pysyvät/väliaikaiset - ennen tuotetta, tuotteen käytön kautta ja sen jälkeen, mihin ei vastata - tarpeiden priorisointi Työn rajoitteet - suhteessa tavoitteisiin: ehdottomat, joustavat, välttävät - kohderyhmän rajoitteet: käyttäjien taitotaso, verkkoyhteys, laitteisto - tarvelähtöiset rajoitteet: ensisijaiset vs. toissijaiset tarpeet jne. - legacy-rajoitteet: käytössä olevat järjestelmät, politiikka, resurssit MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 251 - valheelliset tavoitteet Sisältötuotanto - tyyli, muoto, rakenne, mediaelementit - koko, pituus, paino, alue, rakenneosat - formaatti Rakenne - luontainen rakenne: hierarkiat ja polut - valittu tietorakenne: puu, polku, hila, verkko, relaatio, - käyttäjä/ylläpitäjä/suunnittelija ja näiden väliset kuvaukset Käyttöliittymä - käsitelty jo edellä (esim. 10 kohdan muistilista) Skaalautuvuus - tekniikka/sisältö/käyttöliittymä - ohjain- ja näyttölaiteriippumattomuus MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 252
- riisutut versiot, verkkokapasiteetin huomioivat versiot - eksperttien ja ylläpitäjän välineet Testaus (ja ylläpito & päivittäminen myöhemmin) - tavoitteiden, tarpeiden ja rajoitteiden toteutuminen & noudattaminen - heuristiset menetelmät, käytön nopeus, virhearvioinnit, käyttöaktiivisuus, koettu miellyttävyys - kokemuksista oppiminen ja tehtävät parannukset(!) Korjausten tekeminen - virheiden todellisten syy- ja seuraussuhteiden selvittäminen heti testien jälkeen - varovasti ja vähän kerrallaan, testaaja mukana - lisätestit uusien virheiden välttämiseksi (korjaus voi hyvinkin tuottaa uusia virheitä!!!) Vähemmällä pääsee kun asioita miettii & pistää paperille jo hyvissä ajoin MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 253 Käyttäjien tekemät virheet kertovat käytettävyydestä Erehtyminen on inhimillistä; niinpä järjestelmää/välinettä X käyttäessämme teemme aina silloin tällöin virheitä (tämä pitää hyväksyä suunnittelussa) systemaattinen (tietoinen) virhe: satunnainen lipsahdus: Hmmh Sileällä kantilla sahaaminen on selvästi kevyempää näin kai sitten pitää toimia! Oho terä osui kiveen ja hammas katkesi! Toistuvien virheiden luokittelu helpottaa niiden ennakoimista esim. käyttöliittymäsuunnittelussa (turhat virheet pois). Perusjaottelu: - satunnaisvirheet - systemaattiset virheet - karkeat virheet ja erehdykset MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 254 Virhe voi lisäksi olla erityisesti olla - lipsahdus tai tietoinen virhe Hyvässä järjestelmässä lipsahdukset ovat tietoisia virheitä huomattavasti yleisempiä (käytettävyyssuunnittelussa pitää varmistaa että lipsahduksista syntyvät virheet ovat helposti peruttavissa tai epäoleellisia) Usein toistuvat tietoiset virheet ovat merkki siitä että seuraavat eivät vastaa toisiaan: on löydetty suunnitteluvirhe ( korjaukset, täsmennykset, uudelleensuunnittelu, tarvittaessa käyttökoulutus) - konkreettinen käyttötilanne, työtehtävä ja tarve - käyttäjän mentaalinen malli, järjestelmän käsitteellinen malli - koulutus, käyttöohje, opasteet - käyttöliittymä ja sovelluksen reaalinen käyttäytyminen HUOM: Vain osa todellisuudessa syntyvistä virheistä on etukäteen odotettavissa/arvattavissa, osa selviää vain testaamalla (ne hankalimmat) Inhimillinen tietojenkäsittely on avainasemassa Sovellustuotannossa on yllättävän helppoa unohtaa käyttäjän keskeinen rooli: ihminen (tietoteknisen) välineen käyttäjänä ja tästä aiheutuvat rajoitukset Samaan tapaan kun emme kykene taivuttamaan kyynärniveltämme kuin kahteen suuntaan, emmekä hyppäämään pituutta muutamaa metriä enempää, ei ole realistista odottaa että ihmisen aistit tai mieli olisivat vuorovaikutustapahtumassa ideaalisia tai rajoitteettomia Osaa ominaisuuksistamme voimme kehittää, osaa emme voi 5 4 3 2 1 Hmmh Hyppään pituutta (ilman ponnahduslautaa) vain 4m kenties en sittenkään pysty hahmottamaan 25 muuttujan prosessia reaaliajassa ulkomuistista? Tämä kulminoituu käyttöliittymäsuunnittelussa: käyttöliittymäsuunnittelun tärkein tekijä on ihminen itse (loppukäyttäjä) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 255 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 256
Käytettävyyssuunnittelun & -testauksen tuloksia Tulosten kirjaaminen, niistä oppiminen sekä korjaus- & muutostyöt Koska valmiiden tuotteiden korjaaminen on yleensä työlästä ja kallista käytettävyyttä tulisi testata jo ennen tuotteen valmistumista. Työtapoja: 1. kuvitteleminen ja keskusteleminen 2. paperilla tapahtuva rajoitettu testaus (käyttöliittymäkuvat piirretty paperille, testihenkilö kertoo mitä haluaa tehdä ja sovelluksen kehittäjä kertoo vieressä [auttamatta liikaa] miten sovellus käyttäytyisi) 3. testaus nopeasti toteutetun (käyttöliittymä) leikkisovelluksen avulla (esim. ns. RAD-välineet, Rapid Application Development, tällöin esim. käyttöliittymään kuulumaton tuotteen muu suorituskyky ei ole riittävä ja iso osa ominaisuuksista jätetään toteuttamatta) 4. prototyypin tai keskeneräisen toimivan tuotteen avulla tapahtuva testaus Käytännössä kaikkia yo. työtapoja yhdistellään luovasti (+havainnoinnin menetelmät: tulosten kirjaaminen, näyttöjen/käyttäjien videointi, yms.) Käytettävyyden lisäksi yleensä testataan toki muutakin (esim. hyödyllisyys [yleensä työteho], suorituskyky, virheistä toipuminen, tietoturva yms.) Sovellusarkkitehtuurissa (käyt.)testauksen tuloksena tehtäviä parannuksia - suunnittelukäsitteiden ja loppukäyttäjäkäsitteiden erottaminen toisistaan(!) - välineen ja todellisen työtehtävän toimintojen ja niitä kuvaavien käsitteiden yhtenäistäminen - suorituskykyyn, skaalautuvuuteen, saatavuuteen, yms. liittyvät parannukset Käyttöliittymässä - selkeästi turhien tai virheellisten toimintojen korjaaminen - tarpeellisten informaationäyttöjen lisääminen, turhien poistaminen - näytettävän informaation tarkoituksenmukainen jäsentäminen - usein toistuvien töiden komentopolkujen optimointi (yleensä lyhentäminen) ja automatisointi (mahdollisuuksien rajoissa) - harvemmin tarvittavien toimintojen siirtäminen syrjemmälle käyttöliittymässä MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 257 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 258 - varmennuksen (tai peru-toiminnon) toteuttaminen virhealttiiden toimintojen yhteyteen - skaalautuvuuteen liittyvät parannukset (yleensä vaikeita toteuttaa, saattavat jopa vaatia vaihtoehtoisia käyttöliittymiä) Käyttöohjeissa ja opasteissa - loppukäyttäjän käsitteiden ja realististen työtapojen huomiointi (vrt. arkkitehtuuri) - tarvittaessa eri käyttöohjeet ja opasteet eri käyttäjille (yleensä noviisi, peruskäyttäjä, ylläpitäjä) - esityksen tarkkuuden täsmentäminen (informaatiota ei saa liian vähän muttei myöskään liikaa) - opasteissa oikeisiin ongelmiin vastaaminen (käyttöesimerkit ja virheistä toipumaan opastavat esimerkit pitää valita kohdeyleisön ja työtapojen mukaan) - sisällön ohella myös opasteiden käytettävyys välineenä on varmistettava (saatavilla & info löydettävissä, kohdennetut opasteet, opasteen käyttö ei ehkäisen itse sovelluksen käyttöä, yms.) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 259 Lopuksi Käytettävyys on keskeinen osa kaikissa välineissä, erityisesti hypermediassa (jonka näkyvin osa ovat nimenomaan käyttöliittymät ja niiden toiminta) Käytettävyyden edellytys on käyttäjäkeskeinen suunnittelu ja testaus Tyypillisiä syitä käytettävyysnäkökulmista lipsumiseen ovat - on kiire, rahaa tai tekijöitä ei ole" käytettävyyden määrittely tippuu pois kirjatuista reaalisista tavoitteista varsin helposti - asiaa ei huomata ajatella(!) - uudentyyppinen suunnittelu tai laajamittainen testaaminen on muka liian kallista - lopputuotteen mukauttaminen erilaisten käyttäjien tarpeita vastaavaksi käytettävyystutkimuksen perusteella on vaikeaa tai tulisi liian kalliiksi Pahimpien käytettävyysvirheiden karsiminen tuotteesta vaatii kuitenkin oikeastaan vain miettimistä (ja erittäin vaatimatonta testausta) Motto: 10% satsaus käytettävyyteen tuottaa helposti 90% lisäyksen käyttökelpoisuudessa (hyötysuhde tosin yleensä pienenee lisäsatsauksen myötä) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 260
11 Hypermediajärjestelmistä Pelkistetyn hypertekstijärjestelmän rakenne (selainpohj.) Lyhyt vilkaisu järjestelmätason hypermediaan sekä hypermediajärjestelmien erikoistapauksena nykyaikaiseen WWW-arkkitehtuuriin. Hypermediasovellukseen liittyy aina kaksi näkökulmaa: lukijan ja laatijan näkökulma Hypertekstijärjestelmä (hypermediajärjestelmä) tarjoaa lukijalle ja laatijalle erilaiset näkymät ja työkalut Tyypillinen hypermediasovellusten (tekninen) jako on seuraava - integroidut sovellukset - alustaratkaisut, ts. yleiskäyttöiset selain+dokumenttix -sovellukset Esimerkki: Integroitu sovellus voi olla esim. Toolbookilla, Macromedia Directorilla tai Visual Basicilla toteutettu infokioski Esimerkki: Tuttu alustaratkaisu: WWW-selain + hyperdokumentti (selain tarjoaa käyttäjälle peruspalveluja, joista tärkein on ajonaikainen "Takaisin"-toiminto) Kolme arkkitehtuurin perustasoa on helposti tunnistettavissa: esitys haut & navigointi aineiston välittäminen asiakkaalle varastointi tietokanta akdj kasdklj aslk askdl aslkdlk akdj kasdklj aslk askdl aslkdlk tai erityyppiset solmut dokumentit ja mediaelementit, ikkunointi, linkkien esittäminen, navigointi, hakupyynnöt, hyperdokumenttien looginen rakenne ja käsitteistö (=merkattujen graafien käsitteet) tiedostojärjestelmä MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 261 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 262 Hypertekstijärjestelmien analysoiminen & vertailu Pelkistetyn hypertekstijärjestelmän rakennetta voi kuvata esim. HAM-abstraktion ([Hypertext Abstract Machine]) avulla (v. 1988) - esitystapakerros ([presentation level]) - abstrakti hypertekstikerros ([HAM level]) (graph, context, nodes, links, attributes) - tietokantakerros ([database level]) User Interface Application Tools Hypertext Abstract Machine Host File System or Storage Mechanism Hypertekstijärjestelmän osat voidaan myös standardoida, ts. määritellä yleinen malli (referenssikuvaus), jonka kautta analysoida ja vertailla eri (todellisia) hypertekstijärjestelmiä Kenties merkittävin tällainen kuvaus on Dexter Reference Model (v. 1990) - esitystapataso ([run-time layer]) - rakennetaso ([storage layer]) - komponenttitaso ([within-component layer]) Dexterin pääpaino on rakennetason kuvailulla (hypertekstimäinen tieto) Dexter kuvaa myös - yhteydet eri tasojen välillä ([presentation specifications] & [anchoring]) - eri kerrosten peruskäsitteet (komponentit: atomit, linkit & koosteet, ) - eri tasojen funktiot ja operaatiot Dexterille ominaisia piirteitä: - hypertekstiä lukee yhtä aikaa monta käyttäjää (kullakin oma sessio) ja käyttäjät voivat tehdä hypertekstiin muutoksia MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 263 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 264
Dexterin painotus: rakennetaso (Storage Layer) - hypertekstin reaaliaikainen muokkaaminen & päivittäminen on mahdollista (transaktiot tietokantojen tapaan) - jokaisella solmulla ja linkillä on oma yksikäsitteinen tunnisteensa - linkit ovat aina valideja (linkit ovat omia konkreettisia objektejaan) ja linkit voivat olla aidosti monensuuntaisia - hypertekstin kaikki solmut ovat aina reaalisesti saatavilla saantifunktion avulla - koko hypertekstistä voidaan etsiä solmuja hakufunktion avulla " Storage layer models a database that is composed of a hierarchy of data-containing components which are interconnected by relational links. Components have unique identifiers and links can be identified by a set of two or more component identifiers. Components correspond to the general notion of nodes and can contain text, graphics, images, audio, video etc. The components are treated as generic containers of data and the model does not specify any structure within the containers. Thus, the storage layer does not differentiate between text components and graphics components. It focuses mainly on the mechanism by which components and links are tied together to form hypertext networks." (Balasubramanian) MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 265 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 266 Sisällöntuottajan näkökulmasta Dexter-malli ei nykyään ole kovinkaan ajankohtainen, standardien kehittäjät mallia kuitenkin käyttävät - multimedian huomioonottaminen: Dexter Amsterdam Hypermedia Model (AHM) - standardointi, tiedon abstrahointi & SGML Hypermedia / Time-based Structuring Language (HyTime) XLink(!) Dexter-malli on suunniteltu lähinnä hypertekstijärjestelmän suunnittelijan näkökulmasta. Referenssimallin idea on, että - erilaisten hypertekstijärjestelmien vertailu ja analysoiminen helpottuu (esim. etsimällä yleisestä mallista pienin yhteinen tekijä) - standardointi tiedonsiirto eri hypertekstijärjestelmien välillä helpottuu - samalla oikeastaan myös täsmällisesti määritellään mitä hypertekstillä tarkoitetaan MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 267 Soveltajan näkökulmasta referenssijärjestelmiä mielenkiintoisempia ovat yleensä kuitenkin konkreettiset hyperteksti- ja hypermediajärjestelmät esim. - multimedian tekeminen Multimedia ToolBook-ohjelmalla - multimediaohjelmointi Visual Basic -ohjelmointityökalulla - hypermedian tekeminen Macromedia Director-ohjelmistolla - HyTime SGML-standardin käyttäminen sisällöntuotannossa ja työhön liittyvät työkalut, - XML-standardiperhe ja ko. standardeihin liittyvät työkalut sekä - WWW:n HTML-standardi ja tähän liittyvät muut spesifikaatiot ja työkalut. MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 268
Käytännössä hypertekstiä ja -mediaa voidaan siis toteuttaa suunnilleen miten tahansa, Dexteristä yms. hypertekstimalleista piittaamatta - kuitenkin esim. WWW hypertekstijärjestelmänä voidaan aika luontevasti jäsentää HAM-mallin avulla Dexter-tyyppiseen standardointi- & kerrosajatteluun päätyy kuitenkin myös omassa työssä helposti, lähinnä taloudellisista ja tehokkuussyistä johtuen Standardoinnin tyypillinen tavoite on kuvattavan järjestelmän eri tasojen erottaminen käsitteellisesti toisistaan, tasojen yhdistäminen toisiinsa standardoitujen primitiivien avulla ja tasojen toteutuksen kapselointi, vrt. HAM: User Interface Application Tools Hypertext Abstract Machine Host File System or Storage Mechanism Hypertekstin käsitteelliset tasot Hypertekstin tarkasteleminen johtaa väistämättä tiedon ja kielen ominaisuuksien (omituisuuksien?) tarkasteluun Hypertekstin laatimisessa, käytössä ja opiskelussa voidaan erottaa kolme (kielenkäytön) käsitteellisesti erilaista osa-aluetta: syntaksi, semantiikka ja pragmatiikka Semantiikka vastaa sisältöjä, joita halutaan esittää ja käsitellä (tietosisältö), syntaksi tarjoaa keinon tehdä asiat käytännössä (rakenne) ja lopulta pragmatiikka osoittaa, miksi asioita tehdään (käyttö) Esimerkki: HTML-sivu noudattaa HTML-syntaksia, jolla on HTML:n & selainten toteuttama (sovittu) semantiikka. Se, miksi sivu on tehty ja mitä sillä ajetaan takaa, riippuu laatijan ja käyttäjän näkökulmista ja työlle asetetuista tavoitteista: pragmatiikka. Edellä esitetty formaali kolmijako nousee tärkeään rooliin yleensä vasta siinä vaiheessa, kun erottelu osataan (lähinnä teknisesti) tehdä MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 269 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 270 Nykyaikainen WWW-arkkitehtuuri WWW on ylivoimaisesti suosituin hypertekstijärjestelmä. Käydään seuraavaksi läpi nykyaikaisen WWW-arkkitehtuurin perusteet. Resurssi, yksilöinti ja representaatio Representaatio edustaa resurssia tietyllä ajanhetkellä (HTTP-pyyntö): Vuonna 2004 julkaistu Architecture of the World Wide Web -määritys jakaa WWWarkkitehtuurin kolmeen kokonaisuuteen: Yksilöinti ([Identification]): Resurssien yksilöinti URI-tunnisteiden avulla. Esimerkki: Levyharrastajilla on verkkopalvelu, jonka URI-tunniste on http://www.levylaari.fi. Vuorovaikutus ([Interaction]): Viestien välittäminen sovellusten välillä protokollien avulla. Esimerkki: Käyttäjä kirjoittaa URI:n selaimen osoitekenttään. Selain ottaa yhteyden palvelimeen www.levylaari.fi (portti 80) ja tekee tälle HTTP-pyynnön resurssista. Selain lähettää vastauksen HTTP-protokollan avulla. Representaatio ([Representation]): Resurssit esitetään tiedostomuotojen joukon avulla. Esimerkki: Levyjen tiedot esitetään XHTML-dokumentteina, kannet ja ikonit ovat PNG-muotoisia. Palvelun ulkoasu määritellään CSS-tyylitiedostossa. URI http://www.levylaari.fi/vuodenlevy Representaatio Metatieto Content-type: application/xhtml+xml Tietosisältö <html><head> <title>l e v ylaari: Vuoden levy</title> </html><body>...</body></html> Edustaa Yksilöi Resurssi Levylaarin vuoden levy MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 271 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 272
Yksilöinti: URI-tunnisteet Idea: maailmanlaajuisen verkon muodostaminen vaatii maailmaanlaajuisesti yksikäsitteiset tunnisteet Tim Berners-Leen alkuperäisen määritelmän mukaan URI tulee sanoista Universal Resource Identifier, joka muutettiin myöhemmin muotoon Uniform Resource Identifier. (Syy: Universal koettiin liian vahvaksi termiksi). URI on joko URL (Uniform Resource Locator) tai URN (Uniform Resource Name) Esimerkkejä URI-skeemoista: http, mailto, tel, ldap,... Esimerkkejä URI-tunnisteista: http://www.levylaari.fi, mailto:jukka.huhtamaki@tut.fi, tel:+358-3-555-1234 URI-skeemojen rekisteröinnistä vastaa IANA. URI-tunnisteita voidaan käyttää verkosta noudettavissa olevien resurssien lisäksi minkä tahansa yksilöintiin: ihmiset, valuutat, äänilevyt, aikavyöhykkeet, tietotyypit,... Tämä on keskeinen ajatus W3C:n Semanttisessa Webissä. URI-tunnisteet: hyviä käytäntöjä Resurssilla pitäisi (SHOULD) olla tasan yksi tunniste: rinnakkaisia URI-aliaksia on syytä välttää Minkä tahansa URI-tunnisteen perusteella pitäisi koska tahansa olla mahdollista noutaa resurssin representaatio: kokeile esimerkiksi ladata selaimeesi XHTMLnimiavaruuden yksilöivä URI http://www.w3.org/1999/xhtml Laiteriippumattomuus ([Device Independence]): resurssin representaation pitäisi olla noudettavissa saman URI:n perusteella päätelaitteesta riippumatta. - Voidaan toteuttaa esimerkiksi siten, että laite kuvaa ominaisuutensa pyynnön yhteydessä ja representaatio räätälöidään laitteen ominaisuuksien perusteella ([Content negotiaton]). - Saavutettavuus (Accessibility) voidaan toteuttaa samalla idealla: laitteen tuomien reunaehtojen lisäksi rajoitteita voi aiheutua esimerkiksi käyttäjästä tai käyttötilanteesta Viileät URI:t eivät muutu : älä siirtele resursseja paikasta toiseen. Parempi vaihtoehto on resurssien järkevä nimeäminen (versiointi). MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 273 MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 274 Esimerkki: levylaari.fi on valinnut Laika and the Cosmonautsin levyn Absurdistan vuoden 1997 levyksi: Vuorovaikutus: protokollat Vuoden levyn URI: http://www.levylaari.fi/vuodenlevy Vuoden 1997 levyn URI: http://www.levylaari.fi/1997/vuodenlevy Levyn Absurdistan URI: http://www.levylaari.fi/levy/absurdistan Esimerkin URI-tunnisteet eivät ole aliaksia, koska kaikki URI:t yksilöivät eri resurssin. Esimerkin URI:t voivat käytännössä ohjata samaan resurssiin HTTPuudelleenohjauksen avulla. Esimerkki uudelleenohjauksen toteuttamisesta PHPohjelmointikielen avulla: <?php header( Location: http://www.levylaari.fi/levy/absurdistan );?> Uudelleenohjauksen voi toteuttaa myös HTML-kielen META-elementin tai vaikka JavaScriptin avulla, mutta tämä ei ole suositeltavaa. Arvaatko miksi? URI-tunnisteiden tulevaisuus on IRI (Internationalized Resource Identifier), joka mahdollistaa esimerkiksi skandinaavisten kirjainten (ja riimukirjoituksen) käytön resurssien tunnisteissa. Esimerkiksi Seinäjoen kaupungin kotisivujen tunniste voi siis tulevaisuudessa olla reilusti http://www.seinäjoki.fi. MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 275 Protokolla on keino viestien ([message]) välittämiseen asiakasohjelman ja palvelimen välillä. Protokolla määrittelee viestien sisällön kieliopin (syntaksi), viesteissä käytettyjen termien merkityksen (semantiikka) ja kiinnittää viestien vaihdon järjestyksen. Esimerkkejä WWW-protokollista: HTTP, SOAP, FTP, SMTP,... Yksityiskohta: W3C määrittelemän nyrkkisäännön mukaan protokollat säilyvät keskimäärin pitempään kuin niitä käyttävät sovellukset (Lähde: Architecture of the World Wide Web) tai esimerkiksi ohjelmointirajapinnat (API). Vinkki hajautettujen sovellusten kehittäjille? WWW:n arkkitehtuuri -suosituksen mukaan käyttäjän (protokollan avulla tekemät) toimenpiteet voidaan jakaa turvallisiin ja turvattomiin: - Turvalliset toimenpiteet vastaavat luonteeltaan hakuja tai kyselyjä: käyttäjä ei esimerkiksi saa linkkiä seuratessaan tietämättään joutua sähköpostilistalle. - Turvattomat toimenpiteet vastaavat luonteeltaan tilauksia. Turvattomia toimintoja varten selaimeen voidaan toteuttaa oma käyttöliittymä. Toteutuuko WWW:ssä? MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 276
Representaatio: tiedostomuodot Representaatio: resurssin informaation tilaa esittävä tieto ja metatieto Tiedostomuodot voidaan jakaa binäärisiin ja tekstipohjaisiin: - Binäärisiä: PNG, MPEG, PDF,... - Tekstipohjaisia: HTML, SMIL, CSS, RDF/XML,... Binääristen ja tekstipohjaisten tiedostomuotojen vertailua (yleistyksiä): - Tekstipohjaiset ovat riippumattomampia yksittäisestä sovelluksesta, laitteesta tai käyttöjärjestelmästä - Binäärimuotoinen tieto vaatii vähemmän tilaa: pienempi tiedostokoko - Tekstimuotoisen tiedon esittäminen vaatii enemmän suorituskykyä - Tekstipohjainen tieto on helpommin hyödynnettävissä tulevaisuudessa: uudelleenkäyttö HTML: WWW:n keskeisin tiedostomuoto, mahdollistaa hypertekstiverkon rakentamisen (linkit) ja yksittäisten solmujen sisäisen rakenteen esittämisen MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 277 Lopuksi Osa Architecture of World Wide Web -suosituksen ohjeista on suunnattu erityisesti protokollien tai tiedostomuotojen suunnittelijoille. Suuri osa tiedosta on kuitenkin hyödyllistä kaikille WWW-sovellusten ja -sivustojen tekijöille. Tutustumisen arvoinen dokumentti! Suositus tarjoaa jälleen kerran mahdollisuuden oppia toisten tekemistä virheistä: ainakin periaatteet ([Principles]) ja hyvät käytännöt ([Good practices]) on hyvä käydä läpi yleisten sudenkuoppien välttämiseksi. Mielenkiintoista: WWW on hypertekstijärjestelmä, jota ei oikeastaan koskaan ole määritelty kokonaisuutena arkkitehtuurin tasolla. WWW:n pienin yhteinen tekijä on HTML-kielen, HTTP-protokollan URI-tunnisteiden yhdistelmä. Mikäli WWW-sovelluksen keskeinen toiminnallisuus on nojaa näiden lisäksi muihin tekniikoihin, käyttäjäryhmä selaimineen olisi syytä olla tiedossa. Järjestelmätason hypermediaan kannattaa perehtyä viimeistään siinä vaiheessa kun on suunnittelemassa uutta hypertekstiin perustuvaa järjestelmää, esimerkiksi monikanavaisuuteen kykenevää sisällön hallinta- ja julkaisujärjestelmää. Valmis jäsennys helpottaa taatusti suunnittelutyötä. MATHM-37000 HYPERMEDIAN PERUSTEET (syksy 2005) 278