Avainsana: prototypointi

IxDA Helsinki: pikaprototypointi Webille ja mobiilille

Helsingin yliopiston tietojenkäsittelytieteen laitos järjesti Kumpulan tiedekampuksella IxDA Helsingin ”Pikaprototypointi Webille ja mobiilille” -tapahtuman, jossa muutama sovelluskehitysyritys oli kertomassa ajatuksiaan parin tunnin ajan. Sen verran aihepiiri kosketti sekä mielenkiintoa että työtehtäviä, oli osallistuminen lähes pakollista. Neljän ajatuksia herättävän esityksen myötä sai hieman uusia ideoita miten paremmin täyttää asiakkaan tarpeet, arvioida millaista sovellusta tehdään, miten tehdä parempia sovelluksia ja miten erilaiset prototypointimenetelmät liittyvät aiheeseen. Tapahtuma oli sopiva annos tuttuja ja uusia ajatuksia sovellussuunnittelun ja suunnitteluajattelun saralta.

Pikaprototypointi Webille ja mobiilille -tapahtuma tarjosi kätevän yleiskatsauksen prototypoinnin hyödyntämiseen ja miten Lean-ajattelu, eli löyhästi suomennettuna solakka-ajattelu, ja suunnittelulähtöinen suunnittelu näkyvät sovellusta kehitettäessä, ja miksi toiset sovellukset menestyvät ja toiset epäonnistuvat. Prototypoinnin eri muodot käytiin muutamassa esityksessä lyhyesti läpi ja eivätpä ne tai niiden hyödyntämisvaiheet olleet sitten diplomityöni ajasta juuri muuttuneet.

Deveolta Ilmari Kontulainen kertoi ”Design thinking ABC for developers and startups” -aiheessaan suunnittelulähtöisestä ajattelusta ja miten he lähestyvät sovelluksen kehittämistä. Suunnittelulähtöisen ajattelun neljä vaihetta ovat: mitä on (aiheen tutkinta), mitä jos (ideointi), mikä loistaa (prototyyppi), mikä toimii (palaute). Deveon ote aiheeseen oli ratkaisu neljän kysymysmerkin yhtälöön: asiakkaan ongelma – ongelman ratkaisu – tuotteen markkinat – skaalautuvuus = tuotto. Vaikutti ihan toimivalta lähestymistavalta. Deveo kehittää omana tuotteenaan koodinhallintajärjestelmää isoille yrityksille.

Enemmän sovelluskehittäjän näkökulmaa aiheeseen toi Ruby Brigade Helsingin, eli Rubyn kehittäjäyhteisön, puolesta Pirkka Esko, joka kertoi aiheesta ”Rapid development in the cloud”. Muutamia kohtia jäi mieleen, kuten että nykyaikana on upeaa olla sovelluskehittäjä, kun saatavilla on hyviä työvälineitä tekemisen tueksi ja sovellusten ajamiseksi ei tarvitse itse huolehtia esimerkiksi palvelinraudasta. Toisaalta kehityksen painopiste on siirtynyt palvelinpuolelta käyttöliittymäpuolen moninaisiin tekniikoihin, jolloin vaaditaan koodaajilta laajempaa osaamista teknologioiden lisäksi. Lisäksi sovellusta kehitettäessä prototypoimalla, on hyvä pitää mielessä päätöspiste, jossa sovellusta aletaan oikeasti kehittämään tai hylätään aiottu idea.

Kolmantena lavalle asteli Futuricen Anton Schubert aiheella ”Lean Service Creation – Building successful digital services, fast!”. Esitys käsitteli Futuricen uusia ajatuksia, miten uudistaa toimintaansa ja mielikuvaa pelkästä sovelluskehitysyrityksestä myös suunnitteluun. Ajatuksena uudessa suunnassa on, että maailma muuttuu digitalisoitumisen myötä, kun kilpailu ja markkinat ovat globaaleja ja myös työkulttuuri muuttuu ja yritysten pitää pystyä vastaamaan muutokseen nopeammalla tahdilla ja uusia tapoja työhön. Futuricen vastaus asiaan on Lean Service Creation eli löyhästi käännettynä solakka palvelun suunnittelu, jossa suunnittelija, kehittäjä ja liiketoiminta -tekijäryhmällä voidaan paremmin vastata asiakkaan ongelmiin. Menestyvän sovelluksen rakentaminen meni jotenkin suunnittelulähtöisen ajattelun vaiheiden mukaan, eli ensin bisnesideasta löydetään ratkaisemisen arvoinen ongelma palveluvisioon, jonka jälkeen testataan tuotteen markkinasopivuus ja lopuksi käsitellään skaalautuvuus ja hienosäätö. Schubertin esitys oli vakuuttavaa kuunneltavaa ja asiakin tuntui järkeenkäyvältä.

Viimeisenä esityksenä oli SC5:lta Lauri Svanin ”Why do we design software that is impossible to build; and how could rapid prototyping help that?”. Eli miten erilaisilla prototyypeillä voidaan vähentää riskiä ja päästä parempaan lopputulokseen. Esitys toi hyvin esiin, mitä erilaisia prototyyppejä kannattaa käyttää ratkaisemaan suunnitteluongelmat ja päätöksiä mitä ollaan toteuttamassa. Asiaan esitettiin viisi vaihetta ja mitä ne ongelmia selvittävät: paperiprototyypit (käytettävyys) – arkkitehtuuripiikki (monimutkaisuus, mahdollinen) – prototyyppi sovellus (toiminta oikeassa ympäristössä, kiinnostavuus) – tuotantoaikomus (skaalautuvuus, kustannustehokkuus) – yksinkertaisin mahdollinen tuote (myykö se?). Kun tiedät mitä riskejä on, voit pienentää niitä prototypoimalla.

Helsingin yliopiston tietojenkäsittelytieteenlaitoksen ja Hanna Mäenpään, Emilia Hjelmin ja Tomi Männistön organisoima IxDA Helsingin tapahtuma oli sopiva annos tuttua ja uusia ajatuksia sovellussuunnittelun saralta. Lyhyitä esityksiä, joissa oli kuitenkin hyvin asiaa ja sai esimerkkejä miten muut tekevät sovelluskehitystä ja -suunnittelua. Aika vähän lopulta käsiteltiin varsinaisesti pikaprototypointia teknisessä mielessä ja keskityttiin enemmän suunnitteluaspektiin ja -ajatteluun, joka oli toimiva lähestymistapa. Ja saihan siellä myös virvokkeita kuten pähkinöitä, keksejä, puolukkapiirakkaa, kahvia ja omenoita.

Pitää jatkossakin seurata aihepiirin tapahtumia ja IxDA Helsingin Facebook-ryhmää, johon älysin vasta äskettäin liittyä, ja jonka kautta on helppo bongata kiinnostavia tapahtumia aiheeseen liittyen. IxDA Helsingin tavoitteena on verkostaa paikallinen suunnittelu-yhteisö ja edistää moderneita vuorovaikutteisia suunnittelukäytäntöjä Suomessa kuukausittaisilla tapaamisilla ja muulla toiminnalla. Ryhmä on voittoa tavoittelematon ja löyhästi järjestäytynyt.

Ihmisen ja tietokoneen vuorovaikutus -kurssi: loppuosa

Stanfordin “ihmisen ja tietokoneen vuorovaikutus” -verkkokurssi Courserassa, eli englanniksi Human-Computer Interaction (HCI), päättyi muutama kuukausi sitten ja sen viimeiset pari viikkoa käsittelivät visuaalista suunnittelua, informaatiosuunnittelua, kokeiluiden suunnittelua ja suorittamista laboratoriossa ja webissä ja tulosten analysointia. Kurssin alkuosa oli prototypointipainotteinen. Kokonaisuuteena HCI-kurssin tarkoituksena on opettaa kehittämään käyttäjäkeskeisiä suunnittelutaitoja ja saamaan periaatteet ja keinot erinomaisten käyttöliittymien kehittämiseen millä tahansa teknologialla. Viiden viikon mittaisen kurssin luennot olivat hyviä ja vaikka suoritin kurssista vain ”luennot ja kyselyt” -osuuden, tarjosi se pohdittavaa ja uusia ideoita. Jos kurssista suorittaa myös harjoitustyöt sisältäen muun muassa prototypointia ja arviointia, on se erinomainen kurssi vähääkään käyttöliittymien kanssa tekemisissä olevalla suunnittelijalle tai sovelluskehittäjälle.

”Ihmisen ja tietokoneen vuorovaikutus”, osa 2

Stanfordin “ihmisen ja tietokoneen vuorovaikutus” -verkkokurssi kävi nopealla tahdilla läpi sovelluksen suunnitteluun liittyvät vaiheet idean saamisesta mallintamiseen ja asioiden prototypoimiseen, testaamiseen ja arviointiin. Tarkoituksena on, että kurssin jälkeen opiskelijalla on paremmat taidot käyttäjäkeskeisestä suunnittelusta ja tietää periaatteet ja keinot erinomaisten käyttöliittymien kehittämiseen käytettävästä teknologiasta riippumatta. Viisi viikkoisen kurssin aikana asiat käytiin läpi videoluentojen ja esimerkkien kautta, joiden tukena on vielä käytännön harjoitustyöt ja kokeet. Sekä harjoitustöiden että testien tekijät saivat kurssista “Studio” -todistuksen ja pelkkien pistokokeiden vastaajat “Apprentice” -todistuksen.

HCI-kurssin alkuosa käsitteli tarpeiden ja ideoiden löytämistä, prototypointia, mitä hyvät käyttöliittymät ovat, heuristiikkaa ja informaation esitysmuotoja. Kahden viimeisen viikon aikana käsiteltiin visuaalisen suunnittelun periaatteita tiedon jäsentämiseksi ja esittämiseksi käyttöliittymässä, havaintojen ja kognition periaatteita tehokkaan vuorovaikutuksen saamiseksi ja viimeisenä aiheena oli kontrolloitujen testien suorittaminen ja analysointi.

Viikko 4

Neljännen viikon luennot keskittyivät visuaaliseen ja informaatiosuunnitteluun.

Visuaalinen suunnittelu ja typografia

Visuaalisen suunnittelun osalta käsiteltiin tyhjän tilan merkitystä muun muassa ryhmittelyssä ja koon osoittamaa hierarkiaa. Eli käytä tyhjää tilaa ja lisää (tekstin) koon vaihtelua ja painoa.

Visuaalisen suunnittelun kolme tavoitetta ovat:

  • Ohjata: ilmaista rakennetta, suhteellista tärkeyttä, suhdetta
  • Tahdittaa: houkutella, ohjata suuntaa, tarjota kohtia syventymiseen
  • Viestittää: ilmaista tarkoitusta ja tyyliä, herättää sisältö elämään

Kolme perus välinettä tavoitteiden saavuttamiseksi ovat:

  • Typografia
  • Asettelu
  • Värit

Typografian osuus oli kohtalaisen tylsää, mutta osaltaan kuitenkin tärkeää. Luentoja seuraaville kerrottiin teoriana eri kirjasintyyppien ominaisuuksia ja käyttökohteita. Mitään yleisohjetta kirjasimen valintaan ei ole, sillä se riippuu ihan tarkoituksesta.

”Legibility, in practice, amount simply to what one is accustomed to” – Eric Gill, 1931

Informaatiosuunnittelu

Informaatiosuunnittelun osalta syvennyttiin ruudukoihin ja kohdistamiseen. Useat Web-sivut ovat ryhmitelty ruudukoihin, joka helpottaa tiedon organisointia. Tekstin osalta todettiin, että vasemmalle tasattu teksti on nopeampaa selata (jos luetaan vasemmalta oikealle). Tästä voidaan kuitenkin poiketa, jos se on tarkoituksellista. Esimerkkinä käsiteltiin Amazonin sivujen eri tekstintasaukset eri kohdissa sivustoa.

Värien merkitystä käsiteltiin lyhyesti, antaen esimerkkinä Amazonin sivut harmaasävyissä ja Javan ”ilme ja tuntuma” -ohjeen värimääritelmät. Javan (Swing-aikakauden) ohjeet määrittelivät kuusi väriä kahteen ryhmään: violetti = klikkaa, harmaa = ei klikattavissa. Näin se tarjosi puhtaan, yhdenmukaisen ilmeen, joka oli helppo silmille (lähinnä harmaa).

Lähinnä mitä värien käsittelystä voi lyhyesti sanoa, on kolme vinkkiä:

  • Kiinnitä huomiota väreihin
  • Suunnittele ensin harmaasävyissä
  • Säilytä luminanssi samana kuin harmaasävyissä, siirtyessäsi väreihin

Lukeminen ja navigointi

Viikon viimeinen luento keskittyi (Web-sivujen) lukemiseen ja navigointiin, miten helposti kävijät saavat ”hajun” sisällöstä (eng. Information Scent) ja löytävät sivuilta mitä haluavat ja tajuavatko he mitä vaihtoehtoja on tarjolla. Asian helpottamiseksi on muutamia keinoja. Ikonit auttavat, jos ne eivät ole liian yleisiä, avustavat toistuvaa tunnistamista ja jos käyttäjä tietää miltä asia näyttää, mutta ei sen nimeä. Toinen avustava tekijä on käyttää usean sanan linkkejä, joissa on tunnistettavia termejä ja avainsanoja.

Informaation löydettävyyden arvioimiseen voidaan käyttää silmäseurantaa, jolla saadan selvitettyä mihin käyttäjät sivuilla kiinnittävät huomion. Tutkimukset osoittavat, että sisältö pitäisi suunnitella silmäilyä ajatellen, jossa tärkein asia on vasemmassa yläkulmassa ja vähemmän tärkeät oikeassa alakulmassa.

On sanomattakin selvää, että sivujen tärkein alue on niin sanotun taitteen yläpuolelle (mikä mahtuu kerralla näkyviin selaimen ikkunaan), mutta käyttäjät kyllä selaavat alaspäin, jos he ajattelevat sen palkitsevan heitä. Myös tässä asiassa käyttäjät olettavat löytävänsä tärkeät asiat sieltä, jossa ne ovat muillakin sivuilla. On totuttu, että tietyt elementit ovat tietyissä kohdissa. Tämä pitäen mielessä, voi vain miettiä mikä on useiden sanomalehtien Web-sivujen tärkein sisältö, kun yli puolet sivusta on pelkkää mainosta.

Viikko 5

Viimeisellä viikolla keskityttiin kokeiden suunnitteluun, osallistujien olosuhteiden valintaan, kokeiden suorittamiseen ja niiden analysointiin ja vertaamiseen. Testaaminen on paljon muutakin, kuin ”pidätkö käyttöliittymästä” -tasoisten kysymysten kysymistä, ja on tärkeää tietää mitä vasten tuloksia arvioi ja mitä ne merkitsevät. Kokeiden osalta käytiin lyhyesti sanottuna läpi asioita, mitä luotettavilta, toistettavilta ja vertailukelpoisilta mittauksilta vaaditaan. Ei nyt ihan tieteellisellä tarkkuudella, mutta lähes. Tarkoituksena kokeilla on selvittää ”Onko käyttöliittymä X parempi kuin Y?” (ja mitä parempi tarkoittaa), ja usein vastaus on ”se riippuu”, joten kysymys onkin ”mistä?”.

Koejärjestelyt

Kokeiden yksi tärkeä osa-alue on osanottajien valinta eri koejärjestelyihin, miten he testaavat eri vaihtoehtoja vai kaikkia ja miten suoriutumista mitataan? Kokeen suorittamisen osalta pitää pohtia, testaavatko puolet käyttäjistä toista vaihtoehtoa ja loput toista, vai kummatkin ryhmät molempia ja missä järjestyksessä, että testattavat kohteet tai käyttäjien ominaisuudet eivät vaikuta lopputulokseen.

Koejärjestelyitä käsiteltiin teoriapainotteisesti ja niiden osalta päädyttiin kolmeen päästrategiaan:

  • Osallistujien sisällä: Kaikki kokeilevat kaikkia vaihtoehtoja. Toimiva vaihtoehto, jos eri versioiden testaus ei sotke toisten tuloksia.
  • Osallistujien välillä: Jokainen kokeilee yhtä. Vaatii enemmän henkilöitä ja tarkkaavaisuutta tasapuoliseen testien jakoon. Etuna on, että osallistujat eivät ole alttiita vaikutuksille toisesta testistä.
  • Tasoittamalla olosuhteita ja osallistujien järjestystä (esitestillä, raja-arvoilla), voidaan pienentää osallistujien välistä vaihtelua.

Koehenkilöiden kanssa tehtäviä kokeita käsiteltiin yhden luennon verran ja aiheessa keskityttiin muun muassa käytännön asioihin, sekä miten koe pitäisi suorittaa, tallentaa, käytiin läpi ”ajattele ääneen” -metodiin liittyviä asioita ja miten kokeen tuloksia pitäisi prosessoida, analysoida ja mitata. Hieman turhan pikkutarkkoja asioita tässä käytäväksi läpi. Erilaiset mitattavat asiat, kuten suoritusaika tai virheiden määrä ovat selkeitä tuloksia.

Kokeiden suorittaminen Internetissä

Pääpaino kokeiden suorittamisessa oli niiden tekemisessä Webin kautta, jota käsiteltiin kolmen luentokappaleen verran. Webissä suoritettavien kokeiden osalta käsiteltiin pääasiassa A/B -vaihtoehto -tyylisiä testejä, eli joissa osa kävijöistä saa erilaisen käyttöliittymän eteensä ja kokeilla selvitetään miten se vaikuttaa kävijän toimiin.

Esimerkkinä käsiteltiin Barack Obaman edellisen presidentinkampanjan Web-sivua, jossa oli neljä eri tekstivaihtoehtoa napissa (sign up, learn more, join us now, sign up now) ja kuusi erilaista visuaalista toteutusta (get involved, family, change, video obama greeting, video of campaign, sam’s video). Erot tekstivaihtoehtojen osalla olivat prosentuaalisesti pieniä ”learn more” -vaihtoehdon ollessa tehokkain, mutta kävijämäärään suhteutettuna suuria ja videovaihtoehdot toimivat kuvaa heikommin. Loppupäätelmänä esitettiin, että pienet muutokset aiheuttavat isoja eroja ja oletuksemme (mikä toimii parhaiten) ovat usein vääriä.

Toisena esimerkkinä esitettiin käyttäjien houkuttelemista seuraamaan henkilöä Twitterissä, muuttaen napin tekstiä. Kokeen lopputuloksena saatiin: ”I’m on Twitter” 4,7%; ”Follow me on twitter” 7,31%; ”You should follow me on Twitter” 10,09%; ”You should follow me on Twitter here” 12,81%. Eli mitä selkeämmäksi teet sen, mitä haluat käyttäjän tekevän, sitä useammin he tekevät sen.


Small distractions
like extra fields
can yield big changes

Periaatteina tehokkaiden online-kokeiden suorittamiseen esitettiin seuraavat asiat:

  • Kokeiden ajaminen 50/50%: vaikutuksen havaitsemiksi tarvitaan riittävä määrä osallistujia
  • Suorita nousevasti: rajaa koe alkuun 0.1% käyttäjistä ja varmistu, että se ei tuota ongelmia
  • Peruuta koe automaattisesti: määritä mittarit, joiden perusteella koe peruutetaan sen ollessa selkeästi heikompi esim. sivujen luontiajan suhteen
  • Aja koetta riittävän pitkään: ensimmäinen käyttö ei ole sama kuin mihin käyttäjät ovat tottuneet
  • Satunnaisen koejaon säännöt: johdonmukainen, eli sama käyttäjä saa saman kokeen, kestävä, riippumaton

Lopuksi luennolla esitettiin, että Internet-ajalla suunnittelussa on huomioitava, että ihmiset ovat usein liian varmoja itsestään, suunnittelijan rooli siirtyy olemisesta useiden vaihtoehtoisten ratkaisujen tekemiseen ja nopean kokeilemisen mahdollisuus tarkoittaa, että ensimmäinen versio (joskus) on vähemmän tärkeä.

Tulosten arviointi

Viimeisellä luennolla päästiin arvioimaan ja vertailemaan kokeiden tuloksia ja niiden dataa. Datan analysointiin esitettiin kolme kysymystä: 1. Miltä datani näyttää? 2. Mitkä ovat luvut kokonaisuudessaan? 3. Ovatko eroavaisuudet oikeita? Eli kannattaa tutkia dataa graafisesti eri yhteenvedoin ja menetelmin, sekä ryhmittää eli olosuhteiden tilastoja.

Erojen merkityksen arviointiin käytettiin eniten aikaa, esittelemällä Pearsonin Khii-toiseen -testi (Chi-squared), jolla vertailtiin odotettuja arvoja havaittuihin arvoihin esimerkiksi klikkausten määrän kehittymisessä. Tilastolliset menetelmät auttavat vahvistamaan, että ”olemme melkein varmoja” ja yleistämään tai olla yleistämästä pienestä testidatasta. Ja kannattaa huomioida, että data ei yleensä ole normaalia, vaan voi painottua eri tavoilla, joten testien ja niiden arvioinnin pitää ottaa se huomioon. Aika matemaattispainotteinen luento.

Yhteenveto

Viiden viikon mittainen Stanfordin “ihmisen ja tietokoneen vuorovaikutus” -kurssi oli aiheeltaan mielenkiintoinen ja tarjosi myös aihetta tuntevalla uusia ajatuksia ja ideoita. Kurssilla läpikäydyt aiheet olivat mielenkiintoisia ja tarjosivat sopivasti teoriaa ja esimerkkejä, vaikkakin muutamien ensimmäisten ja viimeisten luentojen aiheet olivat hieman tylsiä. Ainakin teoriassa osaan nyt selvittää ideoita ja tarpeita, suorittaa prototypointia eri tekniikoilla, arvioida eri vaihtoehtoja, ymmärrän miksi prototypointi ja vertaileva arviointi ovat oleellisia asioita erinomaisen vuorovaikutuksen suunnitteluun ja hahmotan miten tiedon eri esitysmuodot vaikuttavat käyttäjäkokemukseen.

Coursera-verkkokurssiympäristö toimi ihan asiallisesti, vaikka muutamia ongelmia sen kanssa kuulemma oli ainakin vertaisarviointiin liittyen, foorumien käytön mielekkyydestä voi olla montaa mieltä ja osallistumistodistusta sai odottaa pari kuukautta. Kuormittavuudeksi kurssisivuilla kerrotaan 8-10 tuntia/viikko, josta luentojen seuraamiseen ja pistokokeiden tekemiseen meni arviolta noin pari tuntia. Ei paha rasti, mutta kurssin parhainta antia olisi tehdä myös harjoitustehtävät, joiden avulla opittua asiaa saa harjoiteltua ideoinnista prototypointiin, testaamiseen ja arviointiin. Tämä jäi itseltäni harmillisesti väliin.

Useat Courserassa olevat kurssin pyörivät useamman kerran ja niin myös HCI, jonka seuraava toteutus alkaa syyskuun 24. päivä. Suosittelen kurssia kaikille, jotka vähääkään sivuavat käyttöliittymiä suunnittelun tai sovelluskehityksen ohessa, vähintään luentojen ja pistokokeiden osalta. Itse suunnittelin käyväni samaan aikaan käynnistyvän Scalalla toteutettavan funktionaalisen ohjelmoinnin -kurssin, joten HCI:n kattavampi suoritus jää myöhemmäksi.

Ihmisen ja tietokoneen vuorovaikutus -kurssi: alkuosan poimintoja

Stanfordin järjestämä ”ihmisen ja tietokoneen vuorovaikutus” -verkkokurssi, eli englanniksi Human-Computer Interaction (HCI), alkoi viimeinkin muutama viikko sitten. Kurssin tarkoitus on auttaa kehittämään käyttäjäkeskeisiä suunnittelutaitoja ja saamaan periaatteet ja keinot erinomaisten käyttöliittymien kehittämiseen millä tahansa teknologialla. Siis aivan erinomainen kurssi sovelluskehittäjälle. Verkkokurssin alkuosan luennot käsittelivät tarpeiden löytämistä, prototypointia, mitä hyvät käyttöliittymät ovat, heuristiikkaa ja informaation esitysmuotoja.

”Ihmisen ja tietokoneen vuorovaikutus”

Käyttäjäkeskeinen suunnittelu ja ihmisen ja tietokoneen välinen vuorovaikutus ovat aiheiltaan kiinnostavia ja niitä osiltaan diplomityössäni käsittelin prototypoinnin osalta. Stanfordin ”ihmisen ja tietokoneen vuorovaikutus” -verkkokurssi menee aiheeseen syvemmälle ja käy läpi suunnittelun vaiheet idean saamisesta mallintamiseen ja asioiden esittämiseen. Tarkoituksena on, että kurssin jälkeen omaa paremmat taidot käyttäjäkeskeisestä suunnittelusta ja tietää periaatteet ja keinot erinomaisten käyttöliittymien kehittämiseen käytettävästä teknologiasta riippumatta. Kurssi kestää kaikkiaan viisi viikkoa ja asiat käydään läpi hyvien videoluentojen ja esimerkkien kautta, joiden tukena on vielä käytännön harjoitustyöt ja kokeet. Sekä harjoitustöiden että testien tekijät saavat kurssista ”Studio” -todistuksen ja pelkkien testien täyttäjät ”Apprentice” -todistuksen, johon myös itse tähtään.

HCI-kurssista on nyt edennyt neljännelle viikolla ja tässä muutamia poimintoja ensimmäisen kolmen viikon luentojen aiheista. Luennot käsittelivät tarpeiden ja ideoiden löytämistä, prototypointia, mitä hyvät käyttöliittymät ovat, heuristiikkaa ja informaation esitysmuotoja. Käytännössä siis selvittää ideoita ja tarpeita, suorittaa prototypointia eri tekniikoilla, arvioida eri vaihtoehtoja, ymmärtää miksi prototypointi ja vertaileva arviointi ovat oleellisia asioita erinomaisen vuorovaikutuksen suunnitteluun ja hahmottaa miten tiedon eri esitysmuodot vaikuttavat käyttäjäkokemukseen.

Kahden viimeisen viikon aikana käydään vielä läpi visuaalisen suunnittelun periaatteita tiedon jäsentämiseksi ja esittämiseksi käyttöliittymässä, käsitellään havaintojen ja kognition periaatteita tehokkaan vuorovaikutuksen saamiseksi ja viimeisenä aiheena on kontrolloitujen testien suorittaminen ja analysointi.

Viikko 1

Ensimmäinen viikko aloitettiin käsittelemällä prototyyppien voimaa. Lyhyesti sanottuna prototyypit prototypoivat tunnetta (miltä se voisi näyttää), toteutusta (miten se voisi toimia) ja ulkonäköä (mikä voisi käyttökokemus olla). Prototyypit ovat kysymyksiä ja niitä kannattaa kysyä useita.

”The best way to have a good idea is to have lots of ideas”
– Linus Pauling, Practice of trying multiple approaches.

Asian käsittelyä jatkettiin tarpeiden löytämisellä, eli miten saada ideoita asioiden kehittämiseen. Osallistujien havainnointi on yksi hyvä tapa ja siinä kannattaa keskittyä etenkin kiertoteiden ja kekseliäiden ratkaisujen käyttämiseen. Lisäksi virheet ovat kullanarvoisia.

Haastatteluiden avulla saadaan lisää tietoa ja niissä kannattaa miettiä haastateltavien valintaa ja millaisia kysymyksiä esittää. Avoimet, ei johdattelevat kysymykset ovat toimivia, kun vielä muistaa, että ihmiset sanovat toista, kuin mitä oikeasti tekevät. Muita menetelmiä ovat esimerkiksi päiväkirjatutkimukset, otanta kokemuksista ja erilaisten käyttäjäryhmien hyödyntäminen havainnoinnissa.

”You can observe a lot just by watching”
– Yogi Berra.

Viikko 2

Toisen viikon luennot aloitettiin prototypoinnilla ja mitä tekniikoita suunnittelun eri vaiheissa kannattaa hyödyntää. Alussa yksinkertaiset kuvakäsikirjoitukset ovat näppäriä ja niistä voidaan edetä paperimalleihin, digitaalisiin luonnoksiin ja yhä enemmän viimeisteltyihin malleihin.

Kuvakäsikirjat ja paperimallit

Lyhyesti tiivistettynä kuvakäsikirjoitus auttaa tähdentämään miten käyttöliittymä täyttää tehtävän, välttää sitoutumisen tiettyyn käyttöliittymään ja auttaa kaikkia sidosryhmiä saamaan saman kuvan asiasta, mihin ollaan pyrkimässä. Käytännössä kuvakäsikirjoituksen pitäisi välittää kolme asiaa:

  • Tapahtumapaikka: liittyvät henkilöt, ympäristö ja suoritettava tehtävä.
  • Jakso: liittyvät askeleet, miksi henkilö käyttää sovellusta, mitä tehtävää kuvataan.
  • Tyytyväisyys: mikä motivoi henkilö käyttämään järjestelmää, mitä se mahdollistaa henkilöiden saavuttaa ja mitä tarpeita se täyttää.

Paperiprototyyppien osalta parasta antia olivat esimerkit niiden tekemisestä ja käyttämisestä käyttäjien kanssa. Paperimallithan ovat hyviä keinoja testata sovelluksen vuorovaikutuksen kulkua erittäin nopeasti ja edullisesti. Niitä on myös helppo muuttaa useiden erilaisten asioiden testaamiseksi. Lisäksi käytiin läpi eri välineitä, joita paperiprototyyppien teossa voidaan käyttää. Hyvinä vinkkeinä mallien tekoon annettiin monikäyttöisten komponenttien piirtäminen ja suulliset kuvaukset hankalasti simuloitavista asioista (kuten etenemispalkki, hiiren menut) ja tuttujen käyttöjärjestelmä elementtien käyttäminen viitekontekstin luomiseksi (kuten selain). Lisäksi rautaa ja sovellusta voi sekoittaa esimerkiksi ottamalla kuva oikeasta laitteesta ja sijoittamalla paperimalli sen sisään. Ei mitään salatiedettä, vaan luovaa ajattelua.

”Test multiple prototypes simultaneously to get most value.”
”Parallel prototyping yields to more diverse designs.”

Toimintojen jäljittely

Prototyyppien avulla voidaan myös helposti kuvata asioita, joita ei ole vielä olemassa, kuvittelemalla ja simuloimalla mahdollista toimintaa. Yksi tekniikka tähän on käyttää ”Wizard of Oz”, eli ”Ozin velho” -menetelmää, jossa suunnittelija toimii tietokoneena ja simuloi käyttäjälle näkyvää toimintaa. Sen avulla voidaan helposti täyttää sovelluksen aukot, joita ei ole vielä toteutettu ja suunnittelija oppii samalla ymmärtämään sovelluksensa logiikan. ”Ozin velho” -tekniikan avulla saadaan kerättyä paljon kommentteja käyttäjältä jo alkuvaiheessa ja sillä voidaan näppärällä, halvalla ja nopealla tavalla imitoida jotain tekoälyä vaativaa toiminnallisuutta. Toisaalta helposti voidaan simuloida asioita, jotka eivät ole teknisesti mahdollisia.

Jos halutaan visualisoida asiaa enemmän, voidaan hyödyntää videoprototypointia, jossa kuvakäsikirjoituksen tavoin kuvataan sovelluksen käyttämistä hyödyntäen esimerkiksi fyysiseen laitteeseen yhdistettyjä paperimalleja käyttöliittymän osalta. Videot ovat edullisia ja nopeita tehdä ja toimivat erinomaisina kommunikointivälineinä. Video voi toimia myös määritelmänä kehittäjille ja se sitoo käyttöliittymän ja tehtävän toisiinsa.

Prototypoidessa on hyödyllistä tehdä enemmän malleja, kuin keskittyä laatuun. Lisäksi, kun eri malleja tekee rinnakkain päästään osittain eroon yhteen ideaan ja toimintatapaan juuttumisesta. Rinnakkaisuus erottaa egon luomuksesta ja kannustaa vertailuun, joka vastaavasti auttaa oppimista.

Suora vaikuttaminen ja ajatusmallit

Toisen viikon jälkimmäisillä luennoilla käsiteltiin asioita, mitkä tekevät käyttöliittymistä helppoja, vaikeita tai luonnollisia. Yksi huomioitava asia on suorituskuilu, eli miten käyttäjä tietää mitä tehdä ja mitä pitäisi tapahtua. Luennoilla annettiin muutamia esimerkkejä, miten asioiden ei pitäisi toimia.

Käyttäjän tehtävän suorittamisen tueksi järjestelmän pitäisi tarjota:

  • Näkyvyyttä (käyttömahdollisuudet, tarkoitus)
  • Palautetta toiminnasta
  • Yhdenmukaisuutta (toisin sanoen standardit)
  • Toiminnot eivät ole peruuttamattomia (Peruuta-toiminnon tärkeys)
  • Löydettävyys: kaikki toiminnot ovat löydettävissä järjestelmällisessä valikoiden tutkimisella
  • Luotettavuus: toimintojen pitäisi toimia. Tapahtumien ei pitäisi tapahtua satunnaisesti

Suorituskuilujen lisäksi ongelmia aiheuttavat myös käyttäjän mielikuvat, miten asioiden pitäisi hänen mielestään toimia. Tämä johtaa helposti virheisiin, jos käsitteellinen malli asiasta eroaa järjestelmän toiminnasta. Käyttäjän mielikuvat ja uskomukset siitä, miten asian pitäisi toimia, juontavat kokemuksiin, vertauskuviin ja verrannolliseen päättelyyn kuten ”tekstinkäsittelyohjelma on kirjoituskone”. Mielikuvat ovat usein epätäydellisiä, epäjohdonmukaisia, muuttuvat ajan mukaan ja täynnä taikauskoa. Tavoitteena suunnittelussa pitäisi olla, että suunnittelu viitoittaa oikeaan ajatusmalliin toiminnasta, jolloin ei tarvitse luottaa käyttäjän ajatusmaailmaan asiasta. Eli nykyisen käytännön ja uuden teknologian välistä välimatkaa pitäisi minimoida.

”The goal: design beacons the right model”

Käyttöliittymässä mielikuvien vaikutus, eli ero kuvitellun toiminnallisuuden ja miten järjestelmä oikeasti toimii välillä, näkyy hitaana suorituksena, virheinä ja turhautumisena. Sitä voidaan pienentää hyödyntämällä oikean maailman vertauskuvia ja tekemällä käyttöliittymästä sellainen, että se tuo esille miten sitä pitää käyttää.

”If technology is to provide an advantage, the correspondence to the real world must break at some point”
– Jonathan Grudin

Viikko 3

Kolmannella viikolla luennot syventyivät enemmän teoriaan, alkaen heuristisella arvioinnilla ja jatkuen tiedon esitysmuotojen vaikutuksilla ja ajattelun hajauttamisella.

Heuristiikka

Heuristinen arviointi on Jakob Nielsenin kehittämä ja auttaa löytämään käytettävyysongelmia. Siinä pieni ryhmä (3-5 henkeä) tutkii käyttöliittymää ja tarkistaa sen yhdenmukaisuuden käytettävyysperiaatteita vasten. Heuristista arviointia voidaan suorittaa toimivalle käyttöliittymälle tai luonnoksille ja se on erittäin kustannustehokasta. Käyttäjätestaukseen verrattuna se on muun muassa nopeampaa, tulokset ovat ennalta tulkittuja ja se löytää eri ongelmia.

Luennoilla esitettiin kymmenen heuristiikkaa arviointia varten (sovellettu Nielsenin arvoista):

  • Näytä järjestelmän tila
  • Tutut vertauskuvat ja kieli
  • Hallinta & vapaus
  • Yhdenmukaisuus
  • Virheiden estäminen
  • Tunnistaminen ennen muistamista
  • Joustavuus & tehokkuus
  • Estetiikka & minimalistinen design
  • Tunnista, määritä & palaudu virheistä
  • Ohjeet ja avustaminen

Tiedon esitysmuodot

Informaation esittämistä ja sen merkitystä käsiteltiin esimerkkien avulla, puhuen hieman myös miten työmuisti vaikuttaa asioiden käsittelyyn. Kokeellista ajattelua, ongelmanratkaisua, avustaa, jos esitysmuodon ominaisuudet vastaavat asian ominaisuuksia, jota ollaan esittämässä.

”Solving a problem simply means representing it so as to make the solution transparent”
– Herbert Simon, The Science of the Artificial

Ajattelun hajauttaminen

”Distributing cognition”, eli jotakuinkin ajattelun hajauttaminen, tähtää asioiden helpompaan käsittelyyn muuntamalla asioiden esitystapaa. Hyvän esitysmuodon pitäisi näyttää vain oleellinen informaatio ja mahdollistaa vertailu, tutkiminen ja ongelmien ratkonta. Esitysmuoto on myös sidottu siihen tehtävään, jonka käyttäjä haluaa suorittaa.

Kun käyttöliittymät auttavat käyttäjiä hajauttamaan ajattelua, se:

  • Kannustaa kokeiluun (esim. Tetris)
  • Tukee oppimista ja vähentää virheitä ylimääräisyydellä (Montessori palikat)
  • Näyttää vain erot, jotka merkitsevät (Lontoon metron kartta)
  • Muuntaa hitaat laskennat nopeiksi havainnoiksi (kartan väritys)
  • Tukee asioiden ryhmittelyä, etenkin ammattilaisten toimesta (Shakki & eleet)
  • Lisää tehokkuutta (kaaviot)
  • Helpottaa yhteistyötä (Lentokoneen ohjaamo)

Informational equivalence != computational equivalence

Esitysmuotoja käytiin läpi useiden esimerkkien kanssa, jotka havainnollistivat miten vaihtoehtoinen esitysmalli vaikuttaa asian ymmärtämiseen. Etenkin esimerkit huonoista esitystavoista olivat käteviä. Esimerkkejä oli muun muassa miten virheilmoituksia ja kysymyksiä esitetään käyttäjälle tilanteissa, joissa lomakkeella on puutteellisia tietoja, kysyttäessä mitä tiedoston merkistöongelmassa pitäisi valita, mitä maksutapaa käyttäjä haluaa käyttää ja miten jo olemassa oleva tiedosto pitäisi korvata.

Loppuosa

HCI verkkokurssin alkuosa on ollut mielenkiintoinen, vaikkakaan ei asiasisällöltään ole mitään yllättävää tarjonnut. Moni asia on tullut eteen jo aikaisemmin, mutta kertaus on oppimisen kannalta hyvä. Ehkä kurssin loppuosa, eli seuraavat pari viikkoa, tarjoavat jotain uutta. Ne käsittelevät visuaalista suunnittelua, informaatiosuunnittelua, kokeiluiden suunnittelua ja suorittamista laboratoriossa ja webissä ja tulosten analysointia. Kuulostaa mielenkiintoiselta ja siitä lisää myöhemmin.

Toiminnallisia Web-sovellusten prototyyppejä Tiggr:llä

Sovelluskehitysprojektissa on toivottavaa, että sovellusta prototypoidaan hyvissä ajoin jo mielellään määrittelyvaiheessa, jolloin sen toiminnasta saadaan tekstiä parempi kuva ja täten nähdään vastaavatko suunnitelmat sitä, mitä ajateltiin. Prototyyppien tekemiseen on erilaisia menetelmiä ja apuvälineitä lähtien yksinkertaisesta ”kynä ja paperi”-menetelmästä, mutta usein on toivottavaa, että tehdyt mallit ovat sähköisiä. Yksi kätevä työväline Web-sovellusten prototyyppien tekemiseen on Exadelin kehittämä Tiggr.

Tiggr on Web-pohjainen nopeaan prototypointiin tarkoitettu sovellus, jonka avulla voidaan luoda, jakaa, tehdä yhdessä ja esitellä sekä Web- että mobiilikäyttöliittymien malleja. Ideana on tarjota työvälineet interaktiivisten mallien tekemiseen sovelluksesta, jotka näyttävät ja toimivat kuten lopullinen sovellus. Käytännössä tämä toteutuu siten, että Flex-pohjaisessa sovelluksessa vedetään käyttöliittymään eri komponentteja ja kokonaisuudesta tuotetaan HTML, JavaScript ja CSS -pohjainen klikkailtava malli. Tiggr on ilmainen ja suunnitteilla on lisäksi maksullinen versio.

Tiggr:n käyttöliittymä muistuttaa perinteistä sovellusta, jossa toisella laidalla on tarjolla olevat komponentit ja toisella niiden ominaisuudet. Komponenttien siirtely ja hienosäätö on helppoa, jota ei voi esimerkiksi kuvankäsittelyohjelmalla tai vastaavalla sovelluksella tehdyistä malleista sanoa. Käytettävissä olevat komponentit pohjaavat siihen, mitä JSF:ssä ja RichFacesissa, Exadelin työstämässä Java EE -komponenttikirjastossa, on tarjolla.

En ole vielä kovin kattavasti testannut Tiggr:n ominaisuuksia, mutta toiminta vaikuttaa erittäin kätevältä ja monipuoliselta, vaikka osiltaan tarjolla olevat ovat rajattuja. Tarvittaessa malliin voi ladata omia komponenttejaan kuvina, mutta tällöin menettää niiden osalta mallin toiminnallisuus-aspektin. Tiggr:n etuna on, jos lopullisessa sovelluksessa käytetään myös RichFaces-komponentteja, jotka löytyvät jo valmiiksi. Myös mahdollisuus jakaa prototyyppien tekoa ja tuotoksia helposti muiden kanssa on suuri etu, sillä se edesauttaa eri osapuolten kommunikointia ja täten suunnittelu- ja kehitysprosessia.

Tiggr:iä kehitetään aktiivisesti eteenpäin ja tulossa on muun muassa prototyyppien annotointi, eli mahdollisuus lisätä kuvaavia tekstejä, sivupohjat ja toiminnallisen HTML-prototyypin laajentaminen. Jo nyt sovellus on hyvin käyttökelpoinen vaihtoehto enemmän tai vähemmän toiminnallisten ja lopullista tuotosta mallintavien prototyyppien tekemiseen.

HTML-teknologian hyödyntäminen Web-sovelluksen prototypoinnissa

Alkutalvi ja kevät on ollut kiireistä aikaa, mutta viimeinkin pitkäjänteinen työ tuottaa tulosta ja sain viime viikolla valmiiksi diplomityöni. Jee. Kun diplomityön aihe on ”HTML-teknologian hyödyntäminen Web-sovelluksen prototypoinnissa” (työ Lutin julkaisujärjestelmässä), voi helposti aavistella mitä työ käsittelee, eikä varmasti kovin paljon harhaan mene. Tarkemmin ottaen työ sisältää asiaa prototypoinnista hieman laajemmin sovelluskehitysprojektin kokonaisuuden näkökulmasta.

Kokonaisuutena työ pohjaa viime syksynä tekemääni kandidaatin työhön, jossa käsittelin aihetta hieman laajemmin ja pintapuolisemmin. Tuolta perustalta oli helpohkoa jatkaa diplomityössä ja kohtalaisen nopeasti se työ lopulta valmistuikin, mutta vaati useita iltoja töiden jälkeen puurtamista ja useampia viikonloppuja aherrusta. Lisäksi viimeinen viikko, kun työ oli jo saanut painoluvan ja muutamia kommentteja ohjaajilta, meni aika lailla dippaa ajatellen ja viimeistellen. Tekstin hiomista, pilkkujen viilaamista ja kirjoitusvirheiden etsimistä. Tuntui, että viimeistely, byrokratian anomusten täyttäminen ja dipan sitomoon saattaminen oli paljon raskaampaa, kuin varsinaisen työn kirjoittaminen.

Tulostuksen, sidonnan ja yliopistolle toimittamisen osalta hoiti Lappeenrantalainen Saimaprint homman hyvin kokonaispakettina. Helpotti paljon aikataulutusta, kun työtä ei tarvinnut luottaa postin harteille tai lähteä itse sitä viemään. Hinnat olivat muistaakseni: mustavalkosivu 0,1e; värisivu 0,7e; sidonta 22,5e/kirja; toimitus yliopistolle 20e; käsittely- ja postikulut jotain. Eihän toi halpaa touhua ole, mutta enemmän sitä olisi palanut rahaa ja aikaa, jos olisi etsinyt halvimman vaihtoehdon ja ajellut yhtenä päivänä vajaat 600 km:iä.

Diplomityössäni käsittelin käyttöliittymän ja sen toiminnallisuuksien prototypointia projektin eri vaiheissa. Alkuosa oli teoriaa eri menetelmistä ja teknologioista, ja käytännön osuudessa käytin mallina viime vuonna ollutta projektia, jonka aikana sovelsin eri prototypointimenetelmiä sovelluksen määrittelyssä, suunnittelussa ja toteutuksessa. Eli alkuun piirtelin paperille hahmotelmia miltä sovellus voisi näyttää ja myöhemmin toteutin käyttöliittymästä mallin HTML:llä. Ihan opettavainen projekti kaikin puolin, jossa myös käytettiin itselleni uusia JSF-teknologioita.

Oikeastaan pitää kiittää tutkintorakenneuudistusta, joka tavallaan pakotti valmistumaan ”Wanha tutkinto valmiiksi” -aikataulussa, johon nähden sain kaiken valmiiksi hyvissä ajoin. Koska 31.7.2010 päivämäärän jälkeen voi valmistua vain uuden kaksiportaisen tutkintorakenteen mukaan ja mahdollisesti lisäkursseja suorittaen, on tänä keväänä ja kesänä erityisen paljon valmistuvia. Itsekin olen diplomityötä hautonut useamman vuoden, mutta se vain vaati kunnollisen määräajan, johon mennessä se oli saatava valmiiksi.

Hieman kiireinen aikataulu tosin vaikutti myös työn tieteelliseen laatuun, sillä näin jälkeenpäin kun työtä lueskelee ja katselee, huomaa miten aihetta olisi voinut paremmin ja kattavammin käsitellä. Etenkin käytännön osuuteen olisi voinut lisätä tarinaa prototypointiprosessista ja toteutetuista malleista. No, työ on nyt kuitenkin tehty ja vaikka kaikki tietous ei kansien väliin päätynytkään, on se korvien välissä tallessa. Lisäksi työ ei nyt mitään järisyttävän uutta asiaa tuo prototypoinnista esille, vaan karkeasti sanottuna on katsaus miksi ja miten asioita voi projektissa mallintaa. Kyllähän kaikki tietää, että kynällä ja paperilla on helppo piirrellä kuvia sovelluksesta ja HTML:llä saa paljon aikaan nopeasti verrattuna Java-toteutukseen.

Kandidaatintyöni tapaan kirjoitin myös diplomityön LaTeXilla ja kirjoitusprosessiin soveltuu samat sanat kuin kesälläkin:

Vaikka aivan mutkatonta ei työskentely ollutkaan, oli kirjoittaminen helppoa ja muotoiluihin ei tarvinnut erikseen panostaa. Etenkin viitteiden ja viittausten hallinta oli erittäin kätevää BibTeX:llä: valmiit viitetiedot sai suoraan liitettyä muun muassa ACM:stä ja IEEE Xploresta. Vastaavasti oikoluvun puute teetti hieman lisätyötä ja taulukoiden, sekä kuvien joustava sijainti tekstin seassa hieman ärsytti.

Oikeastaan oli kohtalaisen turhaa kirjoittaa työ LaTeXilla, kun työssä ei kaavoja ollut, mutta kun kerran alkuun oli päästy, niin pitäähän se loppuun asti vängätä. LaTeX-mallipohjaa piti vielä hieman jalostaa muun muassa viiteluettelon, tiivistelmän ja nimiölehden osalta ja pitää siitä julkaistava versio jossain vaiheessa muistaa kasata. Kaikkien kuvien sijoittelu, oikoluku ja työvaiheessa kommentointi ja merkintä olisivat olleet paljon helpompia esimerkiksi Wordilla. Tosin nyt LaTex mahdollisti versionhallinnan ja kirjoittamisen riippumatta käytettävästä koneesta.

Diplomityön valmistuminen päättää myös yhden aikakauden elämässäni. Opiskeluaika on ihmisen elämään suuresti vaikuttava ajanjakso ja ainakin itsellä se tarjosi mukavia hetkiä, uusia ystäviä ja tietenkin paljon uuden oppimista. Hieman ikävä totuus kuitenkin on, että kaikki loppuu aikanaan ja on aika suunnata kohti uusia haasteita. Eiköhän se yhdeksän vuotta opiskelijana ole riittävästi, josta tosin vuosi aikalailla tyhjäkäynnillä ja pari vuotta töissä. Melkein varmaa kuitenkin on, että opiskelut eivät tähän jää, sillä elämä on jatkuvaa uuden oppimista.

Vielä tosin on edessä kypsyysnäytteen kirjoittaminen ja diplomityöesitelmän pitäminen, mutta kunhan työ arvostellaan 5.5.2010 ja saan paperit kouraan 28.5.2010, ovat opiskelut tältä erää paketissa. Paljon se vaati, mutta paljon se antoikin.

Lisäys: 18.7.2010:
Loppujen lopuksi työni sisälsi 65 sivua, 15 kuvaa, 3 taulukkoa, 43 viitettä ja 0 liitettä. Eli kohtalaisen tiivis katsaus aiheeseen, mutta ilmeisen onnistunut, ainakin työn tarkastajien mielestä, sillä arvosanaksi muodostui kiitettävä (5). Työn lausunnossa kehuttiin sujuvaa näkökulman vaihtoa prototypoinnista web-sovelluksiin ja itse toteutettuun sovelluksen prototypointiin, työn tasapuolisuutta, johdonmukaisesti etenevää kokonaisuutta ja mallikasta lähdekirjallisuutta ja sen käyttöä. Arvostelun osa-alueet muodostuivat seuraavasti:

  • Työn tulokset: 5
  • Tekijän itsenäisyys, omintakeisuus ja aikataulun hallinta: 5
  • Esityksen johdonmukaisuus ja huolellisuus: 4
  • Kieliasu: 5
  • Kirjallisuuden valinta ja käyttö: 4

Web-sovelluksen käyttöliittymän prototypointi

Olen kesän aikana työstänyt opiskeluitani kohti valmistumista ja välituloksena sain aikaan kandidaatintyön otsikolla ”Web-sovelluksen käyttöliittymän prototypointi”. Työssä käsittelin erilaisten prototypointimenetelmien soveltuvuutta Web-sovellusten käyttöliittymien mallintamiseen ja siihen liittyviä asioita ja työvälineitä. Näkökulma oli hieman katsauksen tyylinen, eikä työssä varsinaisesti toteutettu mitään ja se kyllä näkyy työn tuloksissa: enemmän pohdintaa kuin konkreettisia asioita.

Kandidaatintyöni alkoi alkukesästä alkuraportin kirjoittamisella, ja koska havahduin kesäkurssin alkamiseen hieman myöhään, keräsin lähteet, käsittelin ohjaajan kommentit, tein aiheanomuksen ja kirjailin raportin kasaan parin viikon aikana. Onneksi alkutalvesta oli tullut hieman pohdittua aihetta ja mietittyä työn suurpiirteinen rakenne jo kuntoon, sillä alkuraportista 10 minuutin seminaariesityksen pitäminen kesäkuun alussa tulikin eteen nopeasti. Kun muiden raportteja ja professorin kommentteja kuunteli, oli omani hyvällä pohjalla muun muassa rakenteen ja lähteiden suhteen. Ensimmäinen vaihe sujui siis hyvin, vaikka jos olisin ollut hieman aikaisemmin liikkeellä, olisin voinut esittää raportin 7 hengen ryhmässä, kun nyt piti tyytyä kolme kertaa isompaan porukkaan. Se päivä hieman venyi, sillä esitysten päälle piti vielä matkustaa Helsingistä Lappeenrantaan ja takaisin.

Alkuraportin esittämisen jälkeen iskikin sitten pienoinen jatkamisen vaikeus ja kesällä työ eteni suhteellisen hitaasti. Muutamaan viikkoon en tainnut saada mitään aikaan ja kelitkin olivat mitä mainioimpia. Lopulta löysin taas oikeanlaista motivaatiota työn edistämiseen ja heinäkuun puolenvälin jälkeen loppuraportti alkoi jo muodostumaan ihan käsiteltäväksi kokonaisuudeksi. Elokuun alkupuolella sitten painettiinkin näppäimiä oikein urakalla ja muutaman kommenttikierroksen ja hienosäätämisen jälkeen oli loppuraportti esittämiskunnossa. Onneksi töissä oli kesälomien aikana hieman hiljaisempaa, jolloin aikaa jäi muullekin kuin töille.

Elokuun loppupuolella oli taas aika matkustaa Lappeenrantaan esittämään loppuraportti ja tällä kertaa ehdin aikaisempaan ryhmään 10 muun henkilön kanssa. Paljon miellyttävämpää. Jos alkuraportti oli hyvällä mallilla, ei loppuraportti aivan samalle tasolle yltänyt. Hieman teoriapainotteisuudesta ja asioiden arvioivasta otteesta johtuen työn tulokset jäivät hieman vähäisiksi, mutta onneksi eivät kyllä muidenkaan töiden tulokset mitään kovin erikoisia olleet, ainakaan sen perusteella mitä esityksistä pystyi päättelemään. Vasta työn valmistumisen jälkeen oikeastaan näki, miten aihetta olisi voinut (paremmin) käsitellä, rajata käsittelyä hieman suppeammaksi ja tarkentaa tiettyihin osiin.

Työn arvosteltavaksi lähettämistä ja kandidaatintyöksi paketoimista varten jäi siis vielä hieman hiottavaa, vaikka suuria muutoksia tässä vaiheessa ei oikein ollut aikaa toteuttaa. Hieman tarkennusta käytännön osioon, kieliasun tarkistamista ja pilkun viilausta. Lopulta työni sisälsi 43 sivua, 1 kuvan, 2 taulukkoa, 27 viitettä ja 0 liitettä. Eli hieman turhan lavea, kun ohjeistus sanoo työn mitaksi 1/3 diplomityöstä, noin 25-35 sivua. Kaikkiaan ”Kandidaatintyö ja seminaari” -kurssi koostui seuraavista kokonaisuuksista:

Arvostelun osalta ohjaaja arvioi eri osa-alueita arvostelumatriisin perusteella. Kieliasun ja johdonmukaisuuden osalta olisi voinut päästä parempaan lopputulokseen ja lähteiden analysointia olisi voinut tehdä enemmän. Työn tulokset muodostuivat nyt sellaisiksi kuin ovat ja osaltaan palvelevat aiheen jatkokäsittelyä, mutta eivät oikein yksinään tarjoa kovin erikoisia havaintoja. Ainahan sitä olisi voinut panostaa enemmän aikaa kokonaisuuden hiomiseen, mutta näillä resursseilla osa-alueet muodostuivat seuraavasti:

  • Työn suunnittelu (15%): 4.5
  • Työn tulokset (30%) : 4
  • Tekijän itsenäisyys / omintakeisuus (15%) : 5
  • Esityksen johdonmukaisuus ja huolellisuus (15%) : 4
  • Tutkielman kieliasu (10%) : 4
  • Kirjallisuuden valinta ja käyttö (15%) : 4.5

Kirjoitin työn alusta alkaen käyttäen LaTeXia, ja vaikka aivan mutkatonta ei työskentely ollutkaan, oli kirjoittaminen helppoa ja muotoiluihin ei tarvinnut erikseen panostaa. Samalla tuli tutustuttua paremmin LaTeXin käyttöön. Etenkin viitteiden ja viittausten hallinta oli erittäin kätevää BibTeX:llä: valmiit viitetiedot sai suoraan liitettyä muun muassa ACM:stä ja IEEE Xploresta. Vastaavasti oikoluvun puute teetti hieman lisätyötä ja taulukoiden, sekä kuvien joustava sijainti tekstin seassa hieman ärsytti.

Onneksi kirjoittamista ei tarvinnut aloittaa aivan tyhjältä pohjalta, vaan sovelsin jonkun Lappeenrantalaisen tekemää LaTeX-mallipohjaa englanninkielistä diplomityötä varten. Laitan jatkokehittelemäni suomenkielisen mallipohjan saataville, kunhan saan sen muokattua julkaistavaan kuntoon. Suurimmat muutokset tein lähinnä PDFLaTeXin käytössä (PNG- ja JPG-kuvat) ja viitteiden esittämisen muodossa.

Periaatteessa nyt olisi jo kasassa tekniikan kandidaatti -tutkinto (alempi korkeakoulututkinto), mutta koska opiskelen diplomi-insinööriksi vanhan tutkintorakenteen mukaisesti, on kandidaatintyö vain ”Erikoistyö”-kurssin korvaava välietappi. No, tavoite on kuitenkin korkeammalla ja siihen liittyen diplomityön kirjoittaminen alkaa siitä, mitä kandintyössä aiheen jatkokäsittelyssä pohdittiin.

Käyttöliittymän hahmottelua luonnostelemalla

Käyttöliittymien suunnittelussa ideoiden hahmottelu ja visualisointi käsiteltävään muotoon on yksi ensimmäisiä vaiheita ennen koodiin sukeltamista. Visualisointia voi suorittaa monella tapaa ja yksi kätevä keino on luonnostelu, eli piirtämällä kynällä karkea malli halutusta lopputuloksesta paperille. Yksinkertaista, helppoa ja nopeaa prototypointia, vaikka paperimallit eivät ole kovin joustavia ja muutokset ovat työläitä.

Luonnostelu on yksi yleisimmistä tekniikoista matalan tarkkuuden prototyyppien luomiseen. Menetelmässä käytetty ”kynä ja paperi-menetelmä on luonnollinen ja vähän vaivaa vaativa tekniikka, joka mahdollistaa abstraktien ideoiden siirtämisen konseptista nopeasti kiinteämmälle pohjalle. Erityisen hyödyllisen menetelmän tekee sen luovuuteen ja ajatteluun rohkaiseva luonne. Lisäksi luonnostelu rohkaisee useamman eri tekijän osallistumisen mallin luontiin, kun visuaalinen malli ja tekniikka on kaikille tuttua. Asiat jäävät myös riittävän epätarkoiksi, joka sallii tarkennusten tekemisen myöhemmin, estämättä luovuutta mallin kehittämisen aikana.

Luonnostelua voi suorittaa myös tietokoneella, hyödyntämällä Washingtonin yliopistossa kehitettyä avoimen lähdekoodin BSD-lisenssillä julkaistua DENIM-ohjelmistoa. Ohjelma tarjoaa käytännössä paperintapaisen käyttöliittymän mallien luontiin. DENIM on tarkoitettu tukemaan Web-kehittäjien alkuvaiheen suunnittelua informatiivisen luonnostelun kautta, ja tarjoaa suunnittelun tueksi kynällä luonnostelua, eri tarkkuuksille kohdentamista (sivukartta, kuvakäsikirjoitus, sivu), sivujen linkittämistä kuvakäsikirjoitusta varten, mallin ajamista esittämistä ja vuorovaikutusta varten ja mahdollisuuden luoda uudelleenkäytettäviä komponentteja. Lopputuloksen voi myös viedä linkitetyiksi HTML-sivuiksi. Javalla toteutettu DENIM on saatavilla Windowsille, Unixille ja Mac OS X:lle.

Denim Denim

DENIMillä luodut prototyypit muistuttavat kynällä ja paperilla luonnosteltuja malleja sekä hyvässä että pahassa, ja koska nyt piirtovälineenä toimii hiiri, on piirtojälki kynääkin karkeampaa. Paperimalleihin verrattuna sähköinen media tarjoaa mahdollisuuden elementtien siirtelyyn ja muokkaamiseen ja lopputuloksen dokumentointi ja säilöminen myöhempää käyttöä varten on helpompaa. Tietenkin kuten kynällä ja paperilla luonnostellessa, jää käyttöliittymän vuorovaikutuksen esittäminen ja mallin myöhempi hyödyntäminen vähäiseksi. DENIMin käyttö on suhteellisen yksinkertaista ja opasteen avulla hieman erikoinen käyttöliittymä ja sen tarjoamat toiminnot selviävät nopeasti, mutta tämänkin jälkeen työskentely on hieman hidasta ja monimutkaisen tuntuista.

DENIM tarjoaa mahdollisuuden sähköiseen luonnosteluun, mutta käyttö on hieman kömpelöä, joka tosin johtunee suurilta osin piirtovälineenä käytettävästä hiirestä. Piirtopöydällä käytettynä DENIM voisi olla pätevä apuväline, mutta nyt osa sovelluksen kätevyydestä menee hiiren epätarkkuuden kanssa hukkaan, vaikka ohjelmisto suoristeleekin piirrettyjä viivoja. Myös isolla kosketusnäytöllä, jolloin useampi henkilö voisi yhtä aikaa ilmaista ideoitaan, voisi ohjelman käyttö olla kätevää. Toisaalta, kynällä ja paperilla saa edelleen luotua nopeammin ja helpommin luonnoksia ja piirrosjälki on tarkempaa ja mahdollistaa pienempien ja tarkempien elementtien hahmottelun.