Page History

2. 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.

Hyi s****** että osaa olla kylmä! Terve järkikin sen sanoo, että ulos ei tuossa säässä kannata mennä. Hyrr!!! Järjestä tulikin mieleen, että myös webbi/mobiilipalvelujen suunnittelussa voi käyttää tervettä järkeä. Ensimmäiseksi luen siis Robert Hoekmanin Designing the obvious - a common sense approach to web & mobile application design (second edition).

Kirja on jaettu 11 kappaleeseen. Tykkään lukea kappaleen kerrallaan, jonka jälkeen kirjottelen omia mietteitä sisältävän referaatin/yhteenvedon. Kappaleiden otsikot ovat seuraavat:

1. Defining 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

MIKROPÄIVÄKIRJA

Wau! Tämän luettuani voin jo kuvitella itseni Teräsmiespuku päällä, missä lukee "Super Web Designer". Joo, olen hieman skeptinen...

Rakas mikropäiväkirja!

Hehkutuskappale! You can do it! Kirjottajalla on jotenkin ärsyttävä tyyli kirjoittaa. Minä minä minä! Minä sitä, minä tätä! Mieleeni tulee vain vaasalaisen punk-yhtyeen yksi biisi. Mutta mitään ihmeellistä ja mullistavaa kirjan kappale ei lukijalle tarjoa. Mutta löytyy sieltä muutama hyvä pointti, mitkä kannattaa ottaa suunnittelussa huomioon.

Kirjoittajan mukaan webissä on kolme tasoa (layers): People, interface, data. People on ylin taso, data on alin ja interface on sitten siinä keskellä. People tasossa on vain ja ainoastaan ihmisiä. Heillä on tietoa, he käyttävät tietoa ja he haluavat tietoa. Data tasolla on sitten se kaikki tieto; asiakastiedot, kirjainmerkit, arvostelut, ruokaohjeet, elokuvien näytösajat, mikropäiväkirjat jne jne. Keskimmäinen kerros sitten yhdistää ne ihmiset ja sen kaiken tiedon. Ja se Interface taso voi olla sitten ihan millainen tahansa (kirja keskittyy pääasiassa webbisovelluksiin). Ainoa yhdistävä tekijä on se, että se keskimmäinen kerros yhdistää ne ihmiset ja sen datan.

Toinen hyvä pointti on se, että ei kaikki ihmiset ole yhtä kiinnostuneita netistä, sovelluksista ja teknologiasta, kuin esimerkiksi kirjan kirjoittaja tai vaikka minä. Suurin osa ihmisistä vain haluaa saada itselleen sen tarpeellisen tiedon ja lähtee menee! Ei ne jaksa tuijottaa näyttöjä ja kännyköitä koko päivää.

Rakas mikropäiväkirja!

Tämä oli hyvä kappale. Miksi näitä nettisivuja ja sovelluksia sitten tehdään? Mikä motivoi? Why why why??? Kirjoittajan mielestä se mitä teet, on todiste siitä kuka olet. Ei me ihmiset olla satunnaisia olentoja. Kaikki mitä teemme heijastaa omaa olemustamme. Me esimerkiksi emme osta tuotteita, vaan ostamme identiteettiä. Sama pätee myös yrityksiin. Kaikki mitä yritys suunnittelee, markkinoi, tuottaa ja sanoo kertoo yrityksestä itsestään. Ja se yhteys, joita asiakkaat tekevät sinun tuotteeseen, perustuu hyvin paljon siihen, miten hyvin se asettuu siihen keitä he ovat. On tärkeä luoda tällainen User experience strategy, joka yhdistää sen keitä he ovat siihen sinun tuotteeseen. Tai jotain sinnepäin tuo robert on ajatellut..

Kyllä on deeppiä settii. Mutta ei välttämättä täysin väärää.

Rakas mikropäiväkirja!

Nyt on tullut valitettavasti taukoa kirjottamisesta. Anteeksi! Otan siis loppukirin.

Tämä User experience strategy jäi kaivamaan mieltäni. Puhutaan siis jollain tasolla visiosta. "Can't know what to build until you know why to build it!" Koko kappaleen pointti on Simon Sinekin TED puhe. Ajattelin lisätä sen kurssin videoseinälle. Löytynee varmaan myös YouTubesta.