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.

Designing the obvious

Robert Hoekman Jr.

SISÄLLYSLUETTELO

1. Designing the obvious
2. Lead with why, follow with what
3. Ignore the user, know the situation
4. Build only what is absolutely necessary
5. Support the user’s mental model
6. Turn beginners into intermediates immediately
7. Be persuasive
8. Handle errors wisely
9. Design for uniformity, consistency and meaning
10. Reduce and refine
11. Don’t innovate when you can elevate

Robert Hoekmanin Designing the obvious on ihan hyvä kirja. Voisin jopa sanoa sen kuuluvan jokaisen web-suunnittelijan kirjahyllyyn. Hoakmanin filosofia on käytännöllinen/toiminnallinen minimalismi, tarkoittaen että suunnittelija käyttää suurimman osan ajastaan poistaen ominaisuuksia ja toiminnallisuuksia kuin lisäämään niitä. Mikä varmaankin on hyvä idea.

Kirjan perusidea on hyvin yksinkertainen ja se menee jotakuinkin näin: Tutki ensin mitä webbisovelluksesi tekee. Tämä voi olla vain yksi asia. Sitten, poistat kaiken muun mikä ei tee sitä yhtä asiaa. Jos tämän jälkeen voit vielä tehdä sen yhden asian, olet voittanut ja suunnitelmasi on loistava. Jey!

Kirjan monet kappaleet lähestyvät monia asioita mitä suunnittelija voi tehdä saadakseen webbisovelluksestaan parhaan mahdollisen. Kirja myös auttaa hyvien esimerkkien kautta välttämään tyypilliset sudenkuopat.

Kirjan parasta antia on UCD:n, ACD:n ja persoonien (Personas) täydellinen dissaaminen. Hoekmanin mielestä Käyttäjäkeskeinen suunnittelu (UCD) toimii kyllä käytännössä, mutta ei teoriassa. Hoekmanin mielestä UCD voi olla todella hyvä ja tehokas tapa suunnitella, mutta se toimii vain hyvin pienelle käyttäjäkunnalle. Persoonien tekeminen on hyvä tapa markkinoida ja luoda empatiaa. Hoekmanin mielestä persoonien kehittäminen ei suoraan kerro tai auta suunnittelijaa luomaan toiminnallisuuksia. Jotkut asiat, kuten työtehtävä ja henkilön vaatimukset auttavat suunittelussa. Mutta käyttäjän ikä, sukupuoli, sijainti, elämäntyyli ja urasuunnitelmat kuuluvat suoraan markkinointitiimille, ei suunnittelijalle. Ei meitä suunnittelijoita kiinnosta kuka käyttäjä on, meitä kiinnostaa mitä hän tekee.

ACD on puolestaan liian kapeakatseista. Siinä missä UCD luottaa liian paljon persooniin, ACD luottaa niihin liian vähän. Ihmisten käyttäytymistä motivoi enemmän tilanne, kuin ihminen itse. Tai siis millainen tuo ihminen on yleensä. Kun tarkastelemme käyttäjää ymmärtääksemme hänen tarpeita,

Sovelluksen suunnittelu alkaa kun tilannetta voidaan tukea sovelluksella. Se ei ole käyttäjäkeskeistä suunnittelua, eikä toimintakeskeistä suunnittelua, vaan tilannekohtaista suunittelua. Ja jos tilanne muodostuu asioista: kuka, mitä, missä, koska ja miksi, niin sitten se sovellus on miten.

Hyvä esimerkki on viisi kirjastonhoitajaa. Viisi täysin erilaista ihmistä voivat olla kaikki samassa tilanteessa. Ja he voivat olla siinä vieläpä yhdessä. Kuvitellaan viisi kirjastotyöntekijää. Yksi on 62-vuotias ja toinen on 32-vuotias. Yksi on naimisissa oleva kahden lapsen äiti ja toinen on 20-vuotias opiskelija. Yksi pelaa pokeria ja polkupyöräilee töihin ja toinen käyttää iltansa pienoismallien rakenteluun ja World of warcraftin pelaamiseen. Nämä kaikki ihmiset voivat olla täysin erilaisia verrattuna toisiinsa, mutta heillä kaikilla on aivan samat tavoitteet ja toiveet webbisovelluksesta, koska he ovat kaikki samassa jaetussa tilanteessa. Se tilanne on olla kirjastonhoitaja; auttaa asiakkaita, uusia lainoja, ladata e-kirjoja jne. Mutta vain siinä kirjastonhoitajakontekstissa kuka, mitä, missä, koska ja miksi on kaikille kirjastonhoitajille sama. Joten sama sovellus voi toimia kaikille kirjastonhoitajille.

Kirjan mukaan webbipalvelut ja webbisivut, mitä suunnitellaan, ovat ratkaisuja ongelmiin. Ongelmat ovat tilannekohtaisia. Ihmiset eivät ole. Suurin osa mitä tiedämme käyttäjistä on irrelevanttia suunnittelussa. Ei meidän tarvitse olla heidän parhaita ystäviä. Kirjan mukaan meidän (eli suunnittelijoiden) pitää auttaa heitä tekemään asiat paremmin. Emme tarvitse holistista näkökulmaa heidän elämästään, vaan tarvitsemme tilannekohtaisen kuvan ongelmista, joita he kokevat.

Kirjassa on monta hyvää esimerkkiä tilannekohtaisesta suunnittelusta. Paras esimerkki on Applen iPod. Kirjoittaja argumentoi, että iPod ei ole suosittu sen takia, koska se on parempi musiikkisoitin tukemaan sitä musiikinkuuntelun aktiviteettiä. Se on parempi musiikkisoitin koska se tukee sitä tilannetta missä ihmiset kuuntelevat musiikkin. iPod toimi paremmin niissä tilanteissa mihin se oli suunniteltu; juoksemiseen, duunimatkaan, koiran ulkoiluttamiseen ja tietenkin musiikin kuuntelun keskeyttämiseen. Se iso valkoinen scrollipyörä ja iso nappi siinä keskellä on taikaa verrattuna muihin mp3-soittimiin.

Kirjassa annetaan paljon hyviä esimerkkejä ja malleja miten erilaisia tekniikoita käyttämällä voidaan suunnitella todella jouhevaksi ja estämään tyypilliset sudenkuopat.
Esimerkiksi kaizen, poke-yoke, 5S(sort, straighten, shine, standardize, sustain), 60-second deadline (törkeen hyvä) ja 5-second screen test ovat hyviä tekniikoita kaiken ylimääräisen karsimiseen ja käyttäjien lojaalisuuden kasvattamiseen sekä paremman task-flown suorittamiseen. Kirjassa puhutaan paljon myös 80-20 suhdeluvusta.

Kun alkaa kuvitella, miten fiktionaaliset hahmot reagoivat hypoteettiseen tilanteeseen käyttäen kuvitteellista käyttöliittymää, taitaa olla aika laittaa ne pikku muovisotilaat takaisin laatikkoon ja lopettaa leikkiminen.