Page History

Web Anatomy - Interaction design frameworks that work

Robert Hoekman jr., Jared Spool, New Riders

SISÄLLYSLUETTELO

PART ONE

1. The case for frameworks
2. The reuse trinity

PART TWO

1. Catalog
2. Search
3. Sign-up
4. About us
5. Movie sites

PART THREE

1. Building the framewotk toolkit
2. Putting frameworks to work
3. Improving the future

Tämä oli huono kirja. Tai se ei tarjonnut mitään uutta. Vain vanhaa ja samaa asiaa web-kehyksistä/rungoista (frameworks), interaktiomalleista/suunnittelumalli (patterns) ja niistä pikku komponenteista (components) mistä kaikki maailman verkkopalvelut rakennetaan. Tämä kirja oli pienoinen pettymys. 

Mutta yhden hyvän argumentin kirja kyllä tarjoaa. Nettisivuprojektit ovat joka kerta aina hieman sofistukoituneempia kuin ne aikaisemmat. Ja samalla tietenkin resursseja vähennetään. Mitä siis tehdä? Kirjoittajien mielestä tarvitaan uusiokäyttöstrategiaa, joka liitettynä innovointiin tekee maailmasta paremman paikan. Interaktiomallit (patterns) on yksi osa tätä strategiaa, kuin myös komponentit. Mutta koko komeuden korjaa ”interaction design frameworks” (interaktiosuunnittelukaava) joka on kolmas ja viimeinen osa tätä mahtaa ”Uusiokäyttökolminaisuutta” (Kirjoittajan suomennus sanalle ”The Reuse Trinity”). 

Kirja alkaa mainiolla avauksella käytettävyystestausta vastaan. Vuonna 1998 käytettävyysekspertti Rolf Molich aloitti tutkimuksen käytettävyystestien toimivuudesta. Tutkimuksen nimi oli Comparative usability evaluation (CUE), minkä tarkoituksena oli identifioida standardeja ja parhaita ratkaisuja käytettävyystestaamiseen. Kohteena oli hotmail.com -verkkopalvelu ja testaajaryhmiä oli 9. Yhdeksän tiimiä raportoi yhteensä 310 käytettävyysongelmaa. Yleisin ongelma raportoitiin 7 kertaa (siis 7 eri tiimiä löysi saman ongelman). 6 samaa ongelmaa raportoi vain puolet testiryhmistä. 232 ongelmaa (75% ongelmista) raportoitiin vain kerran. Eli 9 tiimiä raportoi 310 eri käytettävyysongelmaa, mistä 232 oli uniikkeja ongelmia. 

Vuonna 2003 17 testiryhmää testasi hotelpenn.com nimistä palvelua. 9 testiryhmää teki käytettävyystestejä ja 8 suoritti ns. asiantuntija-analyysin. Kollektiivisesti raportoitiin 340 käytettävyysongelmaa. Vain 9 samaa ongelmaa löydettiin ja sekin oli vain puolella tiimeistä. 205 ongelmaa raportoitiin vain kerran. 61 ongelmaa luokiteltiin kriittisiksi.

Jotta hotmail olisi löytänyt ne kaikki vakavat ja kriittiset käytettävyysongelmat, olisi hotmailin pitänyt kirjan kirjoittajien mielestä palkata kaikki yhdeksän käytettävyystestausta. Ja puolestaan Hotelpenn.com olisi joutunut palkkaamaan kaikki 17 käytettävyystestitiimiä saadakseen kaikki löydetyt käytettävyysongelmat korjattua. 

Ollaan vasta sivulla 3 ja jo tässä kohtaa kirjoittajat menevät pahasti metsään. Ei noin voi ajatella. Mitä jos testausryhmiä olisi ollut hotmailin tapauksessa 10? Olisiko silloin pitänyt palkata kaikki 10? Tai mitä jos testiryhmiä olisi ollut vaikka 20? Paljonkohan virheitä olisi silloin löytynyt? Eikä Rolf Molichin teettämän tutkimuksen tarkoitus ollut löytää virheitä, vaan tutkia niitä testimenetelmiä. 

Eihän nettisivut ole koskaan valmiit. Teknologia kehittyy ja käyttäjät oppivat kokoajan uutta, niin on ihan turha alkaa selittämään, että hotmail.com ja hotelpenn.com olisivat olleet täydelliset ja vapaat käytettävyysongelmista, jos kaikki käytettävyystestiryhmät olisi palkattu. Joskus vaan tulee ne resurssit ja aikataulut vastaan, niin on vaan pakko jossain kohtaa pistää peli poikki ja tuote on vaan pakko lanseerata. Eikä käytettävyystestaukset ole sitä varten. Käytettävyystestaukset antavat varmuutta siihen omaan suunnitelmaan ja suunnitteluun, että nyt ollaan tekemässä hyvää palvelua ja menossa oikeaan suuntaan. Toki aina löydetään ongelmia, joita voidaan korjata. Mutta pääasia mielestäni on sen oman suunnittelun tukeminen. Jotta käytettävyystestauksilla yritettäisiin saada kaikki mahdolliset ongelmat korjattua, tuli testaajien testata aina kaikki mahdolliset internetin käyttäjät. Eikö? Tai ainakin ne kaikki mitkä edes jollain tavalla liittyvät kohderyhmään. Tällä hetkellä taitaa olla niin, että noin 3 miljardia ihmisellä on pääsy internettiin. Se on paljon se. He kaikki voisivat käyttää hotmailia.

En edes halua kääntää sivulle 4, mutta kai se on pakko.

Seuraavassa kappaleessa katsottiin sitten tarkemmin niitä runkoja, malleja ja komponentteja ja sitä miten ne tukevat toisiaan. Lyhyesti selitettynä se menee näin: 

• Komponentti - möhkäle nettisivua (tekstiä, linkkejä, nappeja, kuvia...) yhtyneenä rakennuspalikaksi, osa nettisivua. Komponentti on eri webbielementtien kombinaatio joka luo tarkoituksenmukaisen, uudelleenkäytettävän ja itsenäisen rakenteen. Komponentit ovat suunnittelumallin realisointia. Lähinnä koodaajille.
• Interaktiomalli/suunittelumalli - kirjottajien mukaan se on yleinen ratkaisu yleiseen ongelmaan annetussa kontekstissa. Yleensä suunnittelumallit ratkaisevat vain yhden ongelman. Kirjoittajien mukaan nämä suunnittelumallit eivät kerro miten ne yhdet ratkaisut vaikuttavat ja liittyvät toisiin ongelmiin. Kirjoittajien mukaan suunnittelumalleilta puuttuu jonkin sortin kommunikaatio muiden mallien kanssa. (Eikös se ole suunnittelijan tehtävä ratkoa ne ongelmat? Ja sitä paitsi, ei niitä suunnittelumalleja ole kiveen kirjoitettu.) Esimerkkimallina kirjassa esitellään kaikille tuttu pagination joka on tuttu malli jos googlettaa ja haluaa siirtyä hakutuloksissa seuraavalle sivulle.
• Interaktiosuunnittelukaava - on sitten se kirjottajien a-haa elämys. Ne on hieman samanlaisia kuin nämä suunnittelumallit (design patterns), mutta mukaan otetaan hieman ihmisten käyttäytymistä ja psykologiaa. Eli nämä mahtavat interaktiosuunnittelukaavat eivät ratko ongelmia vaan ne tukevat sitä käyttäjän toimintaa. Puhutaan siis jollakin tavalla UX:stä ja käyttökokemuksesta tai käyttäjäkokemuksesta. Kun näitä malleja sitten suunnitellaan, niin niitä on tietenkin hyvä kirjoittaa paperille. Sinne kannattaa kirjoittaa ainakin seuraavat asiat: kuvaus, käyttökonteksti, task flow, elementit (design patterns) ja suunnittelukriteerit. Eli saman asian mitä yleensä kirjoitetaan näihin suunnittelumalleihin, kun niitä suunnitellaan ja raportoidaan. Mieleeni herää kysymys; Miksi tehdä vielä yksi lisää?

Kirjottajien mielestä tämä tämmöinen interaktiosuunnittelukaava on hyvä tehdä kahdesta syystä. Ensiksi se auttaa tutkimaan hieman tarkemmin ihmisten (käyttäjien) käyttäytymistä. Toiseksi se mahdollistaa kehittämään uusia ratkaisuja, jotka tarjoavat saman tarkoituksen ja päämäärän. En valitettavasti ollut ihan vakuuttunut hyödyllisyydestä. 

Kirjan toisessa osassa katsottiin sitten hieman tarkemmin kirjoittajien tekemiä viittä eri web interface frameworkkiä. Se oli kyllä niin kuivaa ja huonoa tekstiä, etten lukenut sitä kovinkaan tarkasti. Ai niin, tulinko maininneeksi että kirjoittajat ovat perustaneet nettisivun, minne jokainen voi sitten alkaa kollektiivisesti kirjoittamaan näitä framewörkkejä. Kätevää eikö totta. 

Koko kirjassa on ehkä kaksi hyvää pointtia, jotka kannattaa laittaa korvan taakse. Ensiksi on oikeasti ihan hyvä alkaa kerätä itselleen tai ainakin bookmarkata netistä näitä design patternejä. Ne on oikeasti hyödyllisiä. Ilman muuta. Aina on hyvä vertailla eri malleja vaikkapa niinkin yksinkertaiseen tapahtumaan kuin kirjautumiseen tai rekisteröitymiseen. Saman asiat voi tehdä monella eri tavalla.

Jos oikeasti haluaa lukea kirjan interaction frameworkeistä patterneista ja muista jutuista, niin suosittelen Christian Crumblishin ja Erin Malonen kirjoittaman kirjan Designing social interfaces. Se on paljon parempi ja antaa rahalle enemmän vastinetta.

Rakas mikropäiväkirja!

Nyt on tullut valitettavasti taukoa kirjottamisesta.