Avainsana: sovelluskehitys

Agile Community -päivä 3.6.2015

Ketterien menetelmien hyödyntäminen sovelluskehityksessä on nykyään arkipäivää, mutta ketteryyttä voi harjoittaa monella eri tapaa. Erilaisia menetelmiä on useita ja harvoin ne aivan suoraan soveltuvat käytettäväksi ketterissä projekteissa, joten oli hyvä kuulla CGI:n Agile Community -päivässä, miten SAFe oli otettu käyttöön asiakkaalla, miten DSDM:ää hyödynnetään Iso-Britanniassa ja mikä on LeSS. Hyvää jatkumoa viime syksynä Agile Community -päivälle. Tässä lyhyt yhteenveto tilaisuudesta.

Käytännön kokemuksia SAFen käyttöönotosta

SAFe eli Scaled Agile Framework on yksi menetelmä ketterän kehityksen, tai tässä tapauksessa, Scrumin skaalaamiseen isompia projekteja ajatellen, josta Anna Ferguson kertoi käytännön kokemuksia. Vuoden aikana on vesiputous-mallia käyttävästä kehityksestä siirrytty SAFen soveltamiseen, joka ei ole ollut aivan yksinkertaista, sillä muutos ei tapahdu hetkessä, jos kehitystä on tehty vesiputous-mallilla 20 vuotta. Tärkeänä osana muutosta on ketterän kehityksen perusperiaatteiden ja ketterien julkaisujunien valmentaminen. Käytännönläheistä tekemistä. Ei ole yhtä oikeaa tapaa toteuttaa SAFea, vaan se vaatii soveltamista.

Tavoitteena oli saavuuttaa niitä etuja, joita ketterä kehitys mahdollistaa, eli aikaista arvontuottoa, nopeuttaa läpimenoaikaa pienentämällä eräkokoa, saada parempi palautesykli asiakkailta ja rajoittaa yhtä aikaa käynnissä olevan työn määrää. Lean-periaatteita. Asiaa lähdettiin edistämään kahdella pilotilla ja SAFen julkaisujunien valmennuksella. Tavoitetilassa ylläpitotiimeissä käytettäisiin Kanbania ja kehityksessä SAFea palveluiden tuottamiseen ketterien julkaisujunien kautta. Tärkeänä osana muutosta oli myös koulutus SAFeen ja henkilökohtaisten kehityssuunnitelmien tekeminen.

Tehtävien osa-alueet
Tavoitteet

Työvälineinä käytössä olivat muun muassa JIRA ja siihen saatava Structure-lisäosa, joskin Portfolio-lisäosa olisi parempi. Testiautomaatiossa oli hyödynnetty CA Service Virtualisointia ja Silk Testiä.

Poimintoina kokemuksista mainittakoon, että muutos ketteryyteen vaatii valmennusta. Aikaa menee keskusteluun käyttäjätarinoiden ja määrittelyiden suhteesta ja edelleen tehdään helposti liian tarkkoja määrittelyitä jo alkuvaiheessa. Pienien eräkokojen, ketteryyden minimikriteerien määrittely ja testiautomaation tärkeyttä ei voi myöskään sivuuttaa. Ongelmana voi olla myös henkilöiden allokaatio. Testauksen kannalta oleellista on, miten ominaisuudet ovat jaettu, että ne ovat järkevästi testattavissa.

Uuden työtavan käyttöönotto ei koskaan suju ilman muutosvastarintaa, mutta asioihin tottuu. Omissa huoneissa -tekemisestä on vaikea siirtyä yhdessä tekemiseen, sopiiko menetelmä juuri meidän liiketoimintaan, jos ei tehdä määrityksiä ennalta, miten tiedetään mitä tehdään ja koska tarinat ovat pieniä, miten nähdään kokonaiskuva. Tekemistä ei kannatakaan verrata suoraan SAFe-malliin, vaan siihen, missä vuosi sitten oltiin ja kuinka pitkälle ollaan päästy. Vaikka tekemissä ei ollut erikoisia metriikoita, on vuoden julkaisuaikataulusta päästy kolmeen kuukauteen.

Dynamic Systems Development Method, eli DSDM

Päivän toinen aihe käsitteli DSDM:ää, eli Dynamic Systems Development Methodia. Tämä oli itselle uusi tuttavuus ketterien menetelmien osalta ja hieman avoimeksi se kyllä esityksenkin jälkeen jäi. DSDM:stä kuultiin videon välityksellä, joka nopeaan puhumiseen yhdistettynä ei ollut se tehokkain media esittää asia.

Ketteryys on jo vakiinnuttanut asemansa ja erilaisia metodeita on kehitetty erilaisiin lähestymistapoihin ja konteksteihin. Valinnanvaraa oikean työkalun valinnassa tehtävään riittää: Scrum, Kanban, SAFe, Xp ja DSDM. DSDM:n voi kiteyttää olevan iteratiivinen ja inkrementaalinen ketterämalli, joka on saanut alkunsa sovellusten kehityksestä, mutta kattaa nykyään näkymän tietojärjestelmään (bisnes, projekti, teknologia). Vuonna 1994 julkaistiin ensimmäinen versio mallista, 2007 toinen Atern -nimellä ja 2014 APF.

DSDM:n Atern -versiota voi kuvata lyhyesti seuraavien kuvien avulla, jotka esittävät projektin muuttujia ja elinkaarta.

DSDM ja projektin elinkaari (dsdm.org)
DSDM ja projektin muuttujat (dsdm.org)

DSDM:stä ei oikein selkeää kuvaa tullut, mitä se käytännössä tarkoittaa ketterän kehityksen kannalta, mutta jos asia kiinnostaa, niin siitä voi lukea lisää vaikka Wikipediasta.

LeSS is more

Vähemmän on enemmän? Kysymys pitää paikkansa, mutta tällä kertaa ei ole kyse sananmukaisesti vähemmästä tai tarkoiteta CSS-tyylien kirjoittamiseen tarkoitettua kieltä, vaan ketterän teeman hengessä puhe on Large-scale Scrumista. Tiina Jääheimo kertoi suhteellisen uudesta menetelmästä skaalata Scrum isompaan kontekstiin, joka tekee asian kevyemmällä ja enemmän Scrum-tyylisellä otteella kuin SAFe. LeSS:n säännöt vakiinnutettiin 2013 ja SAFen tapaan se on lähtöisin Nokiasta. Suomessa on vain yksi sertifioitu LeSS-kouluttuja, Ran Nyman Goseilta.

LeSS on tuotekehitys-kehys, joka laajentaa Scrumia skaalautumiseen liittyvillä säännöillä ja ohjelinjoilla tarjoten Basic LeSS -mallin 2-8 tiimille ja Huge LeSS -mallin yli 8 tiimille. SAFeen verrattuna LeSS säilyttää monet Scrumin käytännöt ja ideat, kuten sen että tiimit työskentelevät samassa sprintissä.

LeSS yleiskuva (less.works)
LeSS ydin (less.works)

Scrumiin verrattuna eroina on muun muassa Sprint planningit, joita on kaksi kappaletta. Yksi suunnittelutilaisuus kaikille tiimeille ja yksi jokaiselle tiimille erikseen. Retroja on myös jokaiselle tiimille erikseen ja yksi yhteinen. Skaalautuvuus näkyy Open Space -keskusteluissa, Town hall -tilaisuuksissa ja Scrum of Scrumeissa, joita pidetään useamman kerran viikossa informaation jakamiseksi ja koordinointia varten. Scrumiin tapaan tiimeillä on omat Sprint backlogit ja päivittäiset Scrum-tilaisuudet. Samoin tuotteen backlogin tarkennus tehdään tiimikohtaisesti asioille, joita tiimi todennäköisesti aikoo toteuttaa. Sprint Review pidetään kaikille tiimeille yhteisenä.

LeSSin periaatteet ovat käytännöllisiä kaikkeen tekemiseen sovelluskehityksessä.

LeSSin periaatteet (less.works)

LeSSissä myös ScrumMasterin ja tuoteomistajan roolit muuttuvat. ScrumMaster ei ole osa tiimiä, eikä tee työtä tiimissä, vaan keskittyy asiaan kokonaisuutena ja palvelee yhdestä kolmeen tiimiä. Tuotteella on yksi tuoteomistaja ja tuotebacklogi, jota useat tiimit tukevat. Tiimit työskentelevät suoraan asiakkaan ja sidosryhmien kanssa. Definition of Done on yhteinen koko tuotteelle ja sen pitäisi olla laaja ja käyttäjäkeskeinen. Tähän tarvitaan organisaatiorakenteen, roolien ja käytäntöjen muutoksia, joka ei välttämättä ole helppoa.

Scrumin tapaan kaikki tekeminen on tiimien sisällä, sisältäen muun muassa jatkuvan palvelun, laadunhallinnan, testauksen ja arkkitehtuurin, vaikka helposti nämä jäävät niin sanotun Undone-osaston vastuulle, joka tekee viimeiset silaukset tuotteelle. Tiimit ovat 7+-2 hengen moniosaaja-tiimejä, jotka tekevät käyttäjälähtöisen ominaisuuden kokonaisuudessa. Projektipäälliköiden on hyvä pysyä poissa tiimien läheltä.

LeSS vaikutti esityksen perusteella käytännönläisemmältä ja selkesti yksinkertaisemmalta lähestymiseltä skaalatuvaan ketterään kehitykseen.

Käytännön Kanban -kurssi oli käytännöllinen

Sovelluskehitystä voi toteuttaa monella eri tapaa ja jo jonkin aikaa ketterät menetelmät ovat olleet esillä parempaan lopputulokseen pääsemiseksi. Ketterät menetelmätkään eivät ole mitään hopeisia luoteja, vaan vaativat menetelmään perehtymistä, sopivien toimintatapojen kehittämistä ja organisaation kouluttamista uutta ajattelutapaa ajatellen. Osallistuin viime viikolla Reaktorin vetämälle "Käytännön Kanban" -kurssille, jossa perehdyttiin yhteen menetelmään toteuttaa sovelluskehitystä ketterästi läpinäkyvämmin ja paremmin.

Kanban-menetelmä

Lyhyesti tiivistettynä Kanban-menetelmän ideana on toimintatavan ja työtehtävien visualisointi taulujen avulla ja rajoittaa käynnissä olevan päällekkäisen työn määrää ja pyrkiä saamaan työkokonaisuuksia valmiiksi nopealla tahdilla. Uutta työtä ei oteta sisään ennen kuin nykyiset on saatu valmiiksi. Tavoitetta kuvaa iskulause: "Lopeta aloittaminen, aloita lopettaminen!" eli "Stop Starting and Start Finishing!". Prosessin ja organisaation nykytilan ymmärtämisen kautta tavoitellaan kysynnän ja kyvykkyyden tasapainon ylläpitämistä sekä asteittaista parantamista. Kanban-menetelmä liittyy Lean- ja Just-In-Time -ajatteluun ja sana "kanban" tulee Japanista tarkoittaen visuaalista merkkiä.

"Kanban-menetelmällä tiimi pystyy hallinnoimaan, ennakoimaan ja rytmittämään tapahtumien kulkua tehokkaasti työssään. Menetelmä auttaa tiimiä ymmärtämään, kuinka työ toimii ja tekemään oikeita päätöksiä oikeaan aikaan. Kanban kertoo, milloin kannattaa aloittaa, hiljentää ja lopettaa aktiviteetit työn eri vaiheissa — nykytilanne ja ongelmat on helppo nähdä ja ymmärtää yhdellä silmäyksellä." - Reaktorin Käytännön Kanban -kurssi

Käytännön Kanban -kurssi

Osallistuin viime viikolla Reaktorin Käytännön Kanban -kurssin, jonka aikana käsiteltiin menetelmän teoreettinen perusta, tärkeimmät periaatteet ja tutkittiin käytännönläheisesti Kanbanin soveltamista. Kerrankin koulutuksen painopiste oli sanalla käytäntö ja se toteutui mielestäni hyvin luentojen, tarinankerronnan, ryhmäkeskustelujen ja harjoitusten avulla. Koulutus painotti aktiivista oppimista ja kaksipäiväisen koulutuksen aikana opimme käytännön harjoitusten avulla muun muassa:

  • Kanban-menetelmän ottaminen käyttöön päivittäisessä työssä olemassa olevia toimintatapoja, rooleja ja vastuita kunnioittaen
  • Nykyisen toimintatavan visualisointi selkeästi ja ymmärrettävästi
  • Tiimityöskentelyn, tuottavuuden ja laadun kehittäminen järjestelmällisesti
  • Esteiden tunnistaminen ja poistaminen tiimien työssä
  • Työn kehittäminen kurssin aikana opittujen mittareiden avulla

Ensimmäinen päivä

Koulutuksen ensimmäisenä päivänä käytiin lyhyesti läpi menetelmän teoreettinen perusta ja tärkeimmät periaatteet, mutta asioiden läpikäynti painottui esimerkkeihin ja tarinoihin, eikä kalvoilta asian läpikäymiseen, mikä toimi mainiosti asian sisäistämisessä. Päivän aika aihetta läpikäydessä ei tullut niinkään tunnetta, että käsiteltäisiin juuri Kanbania, vaan miten töitä pitäisi tehdä parempaan lopputulokseen pääsemiseksi ja miten Kanban-menetelmä liittyy siihen.

Kanban ydinperiaatteet
Kanban ydinperiaatteet

Kurssin pitäjät, Sami Lilja ja Sami Honkonen, ovat käsitelleeet kurssin asioita blogikirjoituksissaan kuten Importance of pull, WIP limits and Kanban system ja How to fix 90% of problems at work, jotka liittyvät ja käsittelevät Kanbanin kolmea ensimmäistä periaatetta.

Teorian läpikäynnistä muistiin kannattaa pistää ainakin Littlen laki (läpimenoaika = keskeneräinen työ / nopeus), eli mikä on keskimääräinen aika tehtävän läpisaattamiseksi. Ei kannata ahnehtia liikaa töitä, sillä eivät ne yhtään nopeammin valmistu. Usein organisaatio yrittää kasvattaa nopeutta, mutta merkittävämpi tulos on pienentää keskeneräisen työn määrää. En tässä käy tarkemmin läpi muita esitettyjä asioita, mutta mainittakoon "vaihteluväli, ei trendi" (regression to mean), "kyvykkyys vs. kysyntä" ja "työn kirjo". Myös Scrum-bania sivuuttiin nopeasti.

Get Kanban -lautapeli oli oiva
Get Kanban -lautapeli oli oiva

Käytännön ensikosketuksen Kanban-menetelmään sai tehokkaasti GetKanban-pelillä, joka osoitti loistavasti mistä menetelmästä on kyse ja miten sovelluskehityksessä eri vaiheiden merkitys ja läpimenoaika näkyvät lopputuloksessa. Pelin avulla näki, miten Kanban teki työn eri vaiheista läpinäkyvää ja työn tekemisen esteet olivat helpommin ennakoitavissa ja poistettavissa. Tosin peli heitti eteen muutamia poikkiteloja kuten Carloksen ja Peten, joihin oma tiimini kompastui. Ohjelmistokehitystiimin työssä Kanban helpottaa havaitsemaan, onko työn eteneminen estynyt, mikä estää työn etenemisen, mitä on työn alla tällä hetkellä tai kuinka paljon töitä on odottamassa. Toisella pelikerralla tiimini onnistui pelissä paremmin, kun analysoimme hieman tikettien mahdollista läpimenoa, toteutimme automaattiset testit ja muutimme WIP-rajoja. Eli kuten käytännössäkin pitäisi tehdä :)

Päivän päätteeksi esiteltiin Case-esimerkki "Oma Elisa"-palvelun kehittämisestä ja Ray.fi -sivuston kehityksestä ja millaisia Kanban-tauluja tiimeillä oli ollut käytössä. Muutamina poimintoina esimerkeissä luovuttiin sprinteistä, ei tehty planningia vaan työtä lisää kun tarve ja estimointi tehtiin T-paita koolla läpimenoajasta, ei työmäärästä. Scrumista säilytettiin demot ja retrot ja 2 viikon välein tuotantoon. Lisäksi väki organisoitui vapaammin, ei ollut kiinteitä tiimejä ja WIP-rajat pakottivat parikoodaukseen. Päivittäisissä tilannekatsauksissa käytiin läpi vain laput, jotka olivat olleet pitkään boardilla (täppä per päivä lappuun). Backlogia ei täytetty jatkuvasti, vaan lämmittelyboardilta tuotiin lisää tavaraa, kun noin 2 viikon työt jäljellä.

Esimerkeistä keskustelua herättivät muun muassa miten eri osa-alueet ja niiden hallinta menivät käytännössä ja miten "päivittäinen agenda" ja "miten löydän töitä" toimivat käytännössä. Yksinkertaisuudessaan ne voisivat olla seuraavat:

Päivittäinen agenda
Miten löydän töitä?

Toinen päivä

Koulutuksen jälkimmäisenä päivänä keskityttiin Kanbanin soveltamiseen ja osallistujien omien projektien tarkoitukseen ja Kanban-taulujen pohtimiseen. Päivän aikana toteutettiin viisi eri taulua, joka osoitti käytännössä, että Kanban-menetelmä on suhteellisen helppo ottaa käyttöön kaikenlaisissa tiimeissä, eikä liikkeelle pääseminen ei vaadi isoja muutoksia työtapoihin. Organisaation prosesseja lähdetään muokkaamaan asteittain ja askel kerrallaan, ja samalla seurataan jatkuvasti palautetta ja saatuja tuloksia.

Kanban-taulun kehittämisen pohjaksi on hyvä muistaa ja pohtia seuraavia asioita:

Kanban-taulun kehittämisen ohjenuorat
Kanban-taulu on kehittyvä, ei staattinen

Tässä pari esimerkkiä tuotoksista:

Kanban-taulun suunnittelussa kaikkia tehtäviä ei välttämättä kannata merkitä boardille. Esimerkiksi jos on paljon pieniä tehtäviä, eli kohinaa, hyväksytään se. Sitä ei kannata merkata boardille, mutta kannattaa jotenkin seurata sitä, esimerkiksi tukkimiehen kirjanpidolla. Eli nähdään paljon menee aikaa tiskin alta ja triviaaliin työhön.

Systeemiajattelu

Kanban-menetelmän ja mielestäni työelämään yleisestikin liittyvien asioiden lisäksi koulutuksessa käsiteltiin lyhyesti myös systeemiajattelua ja mistä kokonaisuus ja sen suorituskyky muodostuu. Asiaa avasi hyvin Russell Ackoffin ~8 minuutin puhe systeemiajattelusta (tai vitsien kera). "Systeemi ei ole osiensa summa, vaan yhteistoiminnan tulos". Asiaa selventää hyvin myös Honkosen "You are part of a system" -kirjoitus.

Arvo- ja häiriökysyntä

Aiheeseen liittyen käsiteltiin myös arvo- ja häiriökysyntää (Value Demand ja Failure Demand). Asiaa pitää katsoa asiakkaan näkökulmasta, jolloin arvokysyntä on sitä, jota asiakas haluaa ja häiriö kaikkea muuta, kuten bugeja, muutospyyntöjä ja huonoa käyttöliittymää. Lisäksi yrityksen sisäistä häiriökysyntää ovat muun muassa raportointi, palaverit, infrahäiriöt ja odottaminen. Arvioilta 80 prosenttia työstä on häiriökysyntää ja vain 20 prosenttia arvokysyntää, eli sitä mitä pitäisi oikeasti tehdä. Kanban auttaa tekemään häiriökysynnän näkyväksi. Jotkut organisaatiot keskittyvät tekemään häiriökysyntää, kun pitäisi keksittyä tekemään arvokysyntää. Kannattaa olla täten tarkkana, ettei Kanbanilla hallita häiriökysyntää.

Muita läpikäytyä asioita olivat "tarkoitus -> mittaus -> menetelmät", "oikeiden asioiden tekeminen oikein", "kysyntäanalyysi" ja "kysyntä -> arvo -> virtaus".

Yhteenveto

Reaktorin Käytännön Kanban -kurssin aikana käsiteltiin menetelmän teoreettinen perusta, tärkeimmät periaatteet ja tutkittiin käytännönläheisesti Kanban-menetelmän soveltamista. Kerrankin koulutuksen painopiste oli sanalla käytäntö ja se toteutui mielestäni hyvin luentojen, tarinankerronnan, ryhmäkeskustelujen ja harjoitusten avulla. Kurssilla käsiteltiin paljon asioita ja ongelmia, jotka ovat maalaisjärjellä ajateltuna selviä, mutta ikävän todellisia työpaikoilla. Keskustelu oli antoisaa ja herätti ajatuksia, miten asioita pitäisi kehittää.

Kurssin kuvaus lupaa paljon hyviä lopputuloksia ja ideana ja tavoitteena Kanban-menetelmä vaikuttaa lupaavalta kaaoksen hallintaan. En voi kuitenkaan sanoa, että kurssilla opituista asioista on ollut välittömästi hyötyä oman organisaationi työn kehittämisessä, mutta hitaasti eteenpäin kuitenkin. Tavoitteena on ottaa kurssilla opittuja asioita käyttöön, mutta uuden menetelmän ottaminen samantien osaksi päivittäistä työtä ei ole niin yksiselitteistä etenkään jäykässä organisaatiossa.

Kurssilta sai lisäksi mukaan David J. Andersonin Kanban -teoksen ja kätevän Kanban-lehdykkeen kiireisille johtajille. Lisäksi pitänee lukaista lisää kurssilla käsitellyistä aiheista muun muassa Henrik Knibergin Lean from the Trenches -kirjasta (PDF) ja pohtia Modig Åhlströmin Tätä on Lean -teoksen tai Daniel Kahnemanin Thinking, Fast and Slow -kirjan hankkimista.

Päivitys 28.11.2014: Osallistuin Käytännön Kanban -kurssille toistamiseen loppusyksystä ja tällä kertaa vain oman yksikköni väen kanssa, joka antoi paremman lähestymisen tiimin ongelmien ratkaisemiseen. Sami Lilja veti jälleen mainion kurssin ja sisältö oli suurin piirtein sama kuin keväällä. Nyt oman Kanban-taulun kehittämiseen oli hieman enemmän käytännön kokemusta, mutta osittain myös väen vaihtumisen takia ongelmat olivat samat. Mitä tehdä, kun henkilö on useassa eri asiakkaan projektissa ja ylläpidossa. Miten rajoittaa multitaskingia ja työn hajautumista. Tähän ei vielä löytynyt vastausta, mutta on tärkeää, että ei manageroida henkilöitä, vaan asiakkaalle tehtäviä tehtäviä.

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 2

Kesälomat ovat jo kaukana takana ja paluu arkeen on todellisuutta sekä töiden että osaamisen kehittämisen osalta. Hieman lomien jälkeen jatkui myös Tieturin "Tietojärjestelmäarkkitehdin valmennusohjelma" -kurssi, jonka ensimmäinen osa pidettiin alkukesästä. Keinoja ja ratkaisuja erinomaiseen arkkitehtuuriratkaisuun pääsemiseksi esittelevän kurssin ensimmäinen osio käsitteli tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja, laatuatribuutteja, arkkitehtuurikehyksiä ja 4+1 -mallia. Toinen osio jatkoi aihepiirin käsittelyä muun muassa suunnittelumalleilla, integraatioilla, SOA:lla, tietoturvalla ja arkkitehtuurin arvioinnilla ja dokumentoinnilla. Kuuden päivän kokonaisuus oli aikamoinen annos aiheeseen liittyviä otsikoita ja ajateltavaa ja tarjosikin lähinnä paljon lähtökohtia lisäopiskelulle, eikä niinkään käsitellyt miten asioita pitäisi tehdä. Eli hyvä yleiskatsaus aihepiiriin ja ajattelemisen aihetta tarjoava.

4+1 -mallin kaavioita tilanvarausjärjestelmästä

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 2

Tietojärjestelmäarkkitehdin valmennusohjelman ensimmäisen osion jälkeen tunnelmat kurssista olivat aika teoriapainotteiset, mutta laajan aihepiirin käsittely konkreettisemmin olisi vaatinut vähintään pari päivää per aihepiiri, joten sinällään kurssin yleiskatsauksen omainen lähestyminen aiheeseen oli toimiva. Mutta silti odotukset kurssin jälkimmäiseltä osiolta olivat hieman enemmän. Lupasihan kurssikuvaus, että "valmennusohjelman suoritettuaan osallistuja osaa tietojärjestelmäarkkitehdin työn kannalta systemaattiset toimintatavat ja merkittävät välineet.".

Erinomaisen arkkitehtuuriratkaisun saavuttamiseksi keinoja ja ratkaisuja esittelevän kurssin toinen osio jatkoi aihepiirin käsittelyä muun muassa suunnittelumalleilla, integraatioilla, SOA:lla, tietoturvalla ja arkkitehtuurin arvioinnilla, valvonnalla ja dokumentoinnilla. Suurilta osin aihepiirit olivat tuttuja, mutta uusia keinoja parhaiden käytäntöjen metodeihin, arkkitehtuurin arviointiin ja sen testaukseen kyllä ilmeni.

Osa 2, päivä 1:

  • Parhaita käytäntöjä arkkitehtuurisuunnitteluun
    • Attribute Driven Development method (ADD), ketterän arkkitehtuurin suunnittelu, ketterän tiimin suunnittelukäytännöt

Kurssin neljäs päivä alkoi ryhmien saamien kotitehtävien läpikäynnillä, jonka harmillisesti oli tehnyt vain kaksi viidestä ryhmästä. Tehtävänä oli hyödyntää 4+1 -mallia jonkin järjestelmän, keksityn tai olemassa olevan, kuvaamiseen. Ryhmäni suunnitteli kuvitteellisen "neuvottelutilojen tilanvarauksen ja käytönseurannan integraatio" -sovelluksen, jonka idea oli tehostaa neuvotteluhuoneiden käyttöä. Olimme kuvanneet konteksti-, prosessi-, komponentti- ja sijoittelukaaviot, joista keskustelimme lyhyesti. Olisi ollut kiva nähdä useampienkin ryhmien ratkaisuja, mutta muuten harjoitus oli mielenkiintoinen ideointihetki.

Loppuaika neljännestä päivästä käytiin läpi arkkitehtuurisuunnittelun parhaita käytäntöjä muun muassa toiminnallisten vaatimusten hyödyntämisessä, arkkitehtuurin oikeellisuuden ja suorituskyvyn aikaisessa testauksessa ja käsiteltiin anti-patterneja. Monta maalaisjärjellä perusteltavaa asiaa, mutta todellisuudessa kuitenkin yllättävän hankalia käytännössä viedä läpi, kuten arkkitehtuurin muuttaminen sen osoittautuessa huonoksi, prototyyppien tekeminen tai aloittaminen liian isosti. Harjoituksena käytiin läpi ADD:tä elokuvateatterin lipunvarausjärjestelmän laatuattribuuttien osalta, joista esille nostettiin monikanavaisuus, skaalautuvuus, tietoturva, laajennettavuus, avoimuus, saatavuus, muunneltavuus ja jäljitettävyys. Nykytrendien mukaisesti keskusteltiin myös ketterästä kehityksestä ja sen suhteesta arkkitehtuurisuunnittelun. Vaikka Scrum-projektissa arkkitehtuuri tehdään "just in time", on sprint 0 ja ennakkosuunnittelu tärkeää ja projektin alkuvaiheessa painottuu arkkitehtuurin osuus väheten loppua kohden.

Osa 2, päivä 2:

  • Arkkitehtuurin testaaminen
    • Testaamisen ajoittaminen, testaamisessa huomioitavia seikkoja, suorituskyvyn testaaminen
  • Järjestelmien yhteensovittaminen
    • Tietojärjestelmäintegraation haasteet, löyhä kytkeytyvyys, tyypilliset integraatioratkaisut, integraatioarkkitehtuuri, palveluväylät (ESB)
  • Palveluarkkitehtuurin luominen (SOA)
    • Mitä SOA tarkoittaa?, avoin arkkitehtuuri, SOA arkkitehtuurin luominen, arkkitehtuurin toteuttaminen ja haasteet

Viidennen koulutuspäivän aluksi keskustelimme teknisestä velasta, jota tulee sekä tietoisesti että suunnittelun myötä. Jos velkaa on paljon, on sovellusta myöhemmin hankala tai mahdoton refaktoroida kuntoon. Päivän pääteemat olivat kuitenkin arkkitehtuurin testaaminen, järjestelmien integrointi ja palveluarkkitehtuuri.

Sovelluskehitysprojekteissa testauksen rooli usein aliarvioidaan. Testauksenkin osalta pätee 80/20 sääntö, eli 80 prosenttia ongelmista korjataan testaamalla avainvaatimuksia säännöllisesti ja 20 prosenttia ongelmista on haastavia ja hankalia löytää. Ongelmana usein on myös laadukas testiaineisto ja sen määrä. Testaukseen liittyy myös suorituskyvyn arviointi ja nyrkkisääntönä voidaan pitää, että kannattaa varata 3,14 kertaa enemmän kapasiteettia kuin vaadittu. Toiminnallisen testauksen lisäksi pitää huolehtia suorituskyvyn testauksesta, jota käsiteltiin komponenttien ja koodin osalta. Tarjolla on useita avoimen lähdekoodin testausvälineitä, joista mainittiin muun muassa jMechanic ja JProfiler . Lisäksi lyhyesti esiteltiin kaupallista Compuwaren Application Monitoring -tuotetta (entinen dynaTrace). Testauksessa on hyvä muistaa Heisenbergin epämääräisyysperiaate, joka soveltaen on: "Et voi suorittaa mittausta vaikuttamatta mitattavaan kohteeseen".

Päivän muut aiheet olivat palvelusuuntautuneisuutta tukeva arkkitehtuurityyli eli SOA ja sovellusten integraatio. Tässä palvelu on looginen esitystapa toistuville liiketoiminnan aktiviteeteille, joilla on määritelty lopputulos, eli se on itsenäinen (itseriittoinen), voi koostua muista palveluista ja on musta laatikko kuluttajilleen. SOA:n rakentaminen pitäisi lähteä liiketoiminnan prosessien tietojärjestelmien tarpeista ja tuottaa aina liiketoiminta-arvoa. Ei kannata myöskään unohtaa, että SOA on kuin koiranpentu, joka vaatii jatkuvaa valvontaa, hoitoa, selkeitä rajoja ja vastuuhenkilöä, eli johtamista. Lisäksi sivuttiin REST-palvelun versiointia ja kuvaamista, kun käytössä ei ole WSDL:ää kuten SOAP-palveluissa. Sovellusten integraatioista käsiteltiin muun muassa erilaisia suunnittelumalleja kuten julkaise-tilaa (Twitter, RSS), sanomaväylät (SETI), vastaavuustunniste (laskun viitenumero), prosessimanageri, sanomakeskus (SMS) ja sääntöjen mukainen tietomalli.

Osa 2, päivä 3:

  • Teknologia-arkkitehtuuri
    • Teknologia-arkkitehtuuri mahdollistajana, liiketoimintalähtöinen teknologia-arkkitehtuuri, teknologioiden hallinta sekä valinta, teknologia-arkkitehtuurin suunnittelu
  • Lisensointimallit
    • Arkkitehtuuri ja lisenssit, Open Source -tuotteet sekä sovelluskehykset, näkökulmia lakiasioihin
  • Tietoturva-arkkitehtuuri
    • Tietoturvan näkökulmat ja tasot, vyöhykkeinen tietoturva, tietoturvan perustekniikat, tietoturvasuunnittelun peruspilarit
  • Arkkitehtuurin käytön valvonta
    • arkkitehtuurin käytön ohjeistus, arkkitehtuurin käytön katselmointi
  • Arkkitehtuurin arvioiminen
    • Arkkitehtuurin laatukriteerit, arkkitehtuurin arvioiminen, Architecture Tradeoff Analysis Method (ATAM) -metodi, Cost Benefit Analysis Method (CBAM)
  • Arkkitehtuurin dokumentoiminen
    • Arkkitehdin rooli dokumentoijana, arkkitehtuurin dokumentoiminen UML-kielellä, muita dokumentoinnin välineitä
  • Arkkitehtuurin hallinnointi
    • Arkkitehtuurin toteutus, arkkitehtuurin muutoshallinta, arkkitehtuuriorganisaatio, vaaditut prosessit

Kurssin viimeinen eli kuudes päivä sisälsi paljon eri aihepiirejä ja alkoi harjoituksella, jossa käytiin läpi sovellus- ja teknologia-arkkitehtuurin yhteyttä ja miten teknologia-arkkitehtuuri täyttää järjestelmän laatuvaatimukset. Teknologia-arkkitehtuurin rooli on mennä syvemmälle ja tarkemmalle tasolle, sekä se voi olla jo olemassa ja sanella asioita sovellusarkkitehtuurille. Tarkoituksena on taata järjestelmän rakennuspalikoiden yhteensopivuus ja dokumentoida valitut teknologiastandardit. Teknologia-arkkitehtuurin suunnittelusta käsiteltiin siihen liittyvät eri vaiheet: lähtötason kuvaaminen, näkökulmien ja työvälineiden valinta, tavoitearkkitehtuurin luominen, liiketoiminnan tarpeiden täyttymisen varmistaminen ja nyky- ja tavoitetilan kuilun analyysi. Teknologiasta olikin hyvä siirtyä lisensseihin ja avoimen lähdekoodin sovelluksiin, joista lähinnä mainittiin, että niitä on moneen lähtöön. Parempi olla tarkkana.

Tietoturva-arkkitehtuuria käsiteltiin sentään hieman laajemmin ja siitä on hyvä muistaa seuraavat kirjaimet: C = Confidentiality, I = Integrity, A = Availability. Arkkitehti valitsee miten tietoturvateknologioita ja työvälineitä käytetään tietoturvan toteuttamiseksi ja tietoturva-arkkitehtuurin rakennuspalikoita ovat: henkilöstön tietoturva tietoisuus ja koulutus, käyttäjähallinta, autorisointi ja autentikointi, toimien vahvistaminen, kriittisten osien eristäminen, tunkeutumisen havaitseminen ja estäminen, salaustekniikoiden käyttäminen ja virustorjunta. Lisäksi kerrottiin OWASP Top 10 -ongelmakohtien listauksesta (pdf) ja ettei kannata jäädä kymmeneen, sillä maailma muuttuu jatkuvasti. Aiheeseen liittyen tehtiin harjoitus elokuvateatterin lippujärjestelmän potentiaalisista tietoturvariskeistä ja niiden hallinnasta.

Tietojärjestelmän arkkitehtuurin voi suunnitella monella eri tavalla, eikä yhtä oikeaa ratkaisua ole, joten arkkitehtuuriratkaisun arviointi on tärkeää. Parasta se olisi suorittaa jo etukäteen, eikä vasta jälkeenpäin, vaikka se tällöin onkin helpompaa. Arvioida voi muun muassa ylläpidettävyyttä ja uusien ominaisuuksien ja bugien korjaamisen helppoutta ja nopeutta. Yksi keino tähän on käyttää ATAM:ia (Architecture Tradeoff Analysis Method) ja CBAM:ia (Cost Benefit Analysis Method), joita voidaan soveltaa arkkitehtuuria luodessa, kun projekti on ongelmissa ja jo olemassa olevaan arkkitehtuuriin.

Yhteenveto

Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturin tietojärjestelmäarkkitehdin valmennusohjelma antaa hyvän yleiskuvan laajasta aihealueesta ja on kokonaisuutena aikamoinen annos aiheeseen liittyviä otsikoita ja ajateltavaa. Kurssi tarjosikin lähinnä paljon lähtökohtia lisäopiskelulle, eikä tarkemmin käsitellyt miten asioita pitäisi tehdä, joka olisikin ollut kurssin aikataulun ja aihepiirin laajuuden osalta mahdotonta.

Olisin itse kuitenkin kaivannut ehkä enemmän konkreettisempaa lähestymistä, jota kurssin neljäntenä ja viidentenä päivänä olikin hieman enemmän. Jos kurssista pitäisi mainita yksi mieleen jäänyt asia, on se 4+1 -malli, jonka käyttämistä arkkitehtuurin suunnittelussa käytiin läpi enemmän ja muita aihealueita sipaistaan siihen verrattuna suhteellisen pintapuolisesti.

Kurssi antaa pohjatiedot myös Open Groupin Certified Architect (Open CA) (aikaisemmin ITAC) sertifikaatin ykköstason suorittamiseen (edulliseen 1250 dollarin hintaan), jota pitää harkita.

Yksi sovellus, kolme Java EE -käyttöliittymäkehystä

Sovelluskehityksessä käyttöliittymän rakentaminen ja käyttäjille näkyvien toimintojen toteuttaminen on yksi tärkeimmistä osuuksista, sillä hyväkin sovellus voi kaatua heikkoon käyttöliittymään. Java EE -sovelluskehityksessä on tarjolla useita erilaisia käyttöliittymäkehyksiä, jotka tarjoavat työkalut toimivan käyttöliittymän rakentamiseen, mutta käyttötarkoitukseen sopivan välineen valinta ei ole aina yksiselitteistä. Oli siis aika päivittää hieman tietoja erilaisten Java EE -käyttöliittymäkehysten osalta ja tutustua Vaadin 7:aan, Java Server Faces (JSF) 2:een PrimeFacesin kanssa ja Apache Wicket 6:een toteuttamalla yksinkertainen imgur-kuvaselaussovellus. Aikaisemmin olen kehittänyt sovelluksia käyttäen muun muassa Strutsia, JSF 1.2:sta ja Wicket 1.5:sta.

Java EE 6 -sovelluksia voi toteutta monella eri tekniikoilla ja tällä kertaa toteutin käyttöliittymäkerroksen usealla eri tavalla (Vaadin 7, JSF2, Wicket 6) ja pitäen taustapalvelut vakiona. Imgurin REST-APIn käsittelyyn käytin jokaisessa sovelluksessa Apache CXF:ää rajapinnan lukemiseen ja GSONia JSON-sanoman muuntamiseen Java-olioiksi. Vaikka kaikki kolme kehystä tukevat Java EE 6:n JSR 299 CDI:tä, tein Java Beanien injektoinnin Spring 3:lla, joka toimi varmasti myös vanhemman WebLogic 11g -sovelluspalvelimen kanssa. Jettyllä tai TomEE:llä ajettaessa ei olisi ollut mitään ongelmaa.

Sovellusten koodit löytyvät GitHubista (https://github.com/walokra/fotorest.git), vaikkakaan ne eivät ole mitenkään viimeisteltyjä. Ehkä niistä kuitenkin on jollekin hyötyä.

Sovellus 1: Vaadin 7

Vaadin on avoimen lähdekoodin Java-sovelluskehys Web-sovellusten rakentamiseen ja muistuttaa enemmän työpöytäsovellusten tekemistä esimerkiksi Java Swing -kehyksellä kuin perinteistä Web-sovelluskehitystä HTML:n ja JavaScriptin kanssa. Vaadin rakentuu Google Web Toolkitin päälle ja käyttää GWT:tä sivujen renderöintiin. Vaadin on suomalaisen Turussa pääkonttoriaan pitävän Vaadin Oy:n kehittämä. Vaadin 7 julkaistiin pari kuukautta sitten.

Vaadin tarjoaa perinteiselle Java-kehittäjälle helpomman lähestymisen Web-sovellusten kehittämiseen, kun käyttöliittymän rakentaminen onnistuu ilman HTML:n ja JavaScriptin kanssa askartelua. Vastaavasti HTML:ää osaavalle kehittäjälle Swing-tyylinen käyttöliittymän rakentaminen voi olla tuskastuttavaa. Vaadin tarjoaa itsessään kattavan valikoiman erilaisia käyttöliittymäkomponentteja ja erilaiset demot antavat hyvän kuvan mitä Vaatimella saa aikaan.

Yksinkertaisen imgur-selaajan toteutus Vaadin 7:lla luonnistui nopeasti, kun olin ensin sisäistänyt Swing-tyylisen käyttöliittymän idean. Toimivan ulkoasun ja muutamat toiminnot sai rakennettua suhteellisen helposti ja lopputuloksesta tuli siisti. Koska Vaadin-sovellus on käytännössä kasa Javascriptiä, on sen debuggaaminen hieman hankalampaa, mutta kehys tarjoaa avuksi kohtalaiset työvälineet (?debug-parametri). Käytin Vaatimen oletusteemaa, koska muut teemat eivät vielä uusinta versiota tukeneet. Uuteen kehykseen tutustumisessa auttoi myös Vaatimen laadukas dokumentaatio ja keskustelufoorumi, vaikkakin moni keskustelu ja netistä löytyvä esimerkki käsitteli aikaisempaa 6 versiota.

Fotorest-sovellus toteutettuna Vaadin 7:lla:
Fotorest Vaadin 7

Sovellus 2: JavaServer Faces 2 + PrimeFaces

JSF 2 eli Java Server Faces on Javan spesifikaatio Web-sovellusten komponenttipohjaisten käyttöliittymien rakentamiseen ja osa Java Enterprise Editionia. Sovellus koostuu HTML:ää ja Facelet-tageja sisältävistä -XML-tiedostoista, jotka kehys prosessoi ja tarjoilee käyttäjälle. JSF:n 2 -versio julkaistiin 2009 ja tuorein 2.2. versio huhtikuussa 2013.

Sovelluksen ulkoasun rakentaminen ei juurikaan eroa normaalista Web-kehityksestä, joten HTML ja CSS -osaaminen ovat tarpeen siistin käyttöliittymän aikaansaamiseksi. JSF:n tarjoamia ominaisuuksia ja komponentteja voi laajentaa muun muassa PrimeFaces tai RichFaces -komponenttikirjastoilla, joilla käyttöliittymään saa enemmän kilkettä ja parempaa käytettävyyttä.

JSF 2:n oli sovelluskehitysalustana suhteellisen tuttu, sillä olin käyttänyt sitä pienen prototyypin tekemiseen pari vuotta sitten, eikä vuosien aikana mikään ollut juuri muuttunut. Täten uutena asiana oli enemmänkin PrimeFaces -käyttöliittymäkomponenttien käyttäminen. Yksinkertainen kuvaselaaja syntyi lähes yhtä helposti kuin Vaadinta käytettäessä, vaikka osa toiminnoista piti koodata sivupohjiin ja osa Javan puolelle ja käyttöliittymän dynaamisessa päivittämisessä oli alkuun pieniä ongelmia. PrimeFaces tarjosi kattavan listan erilaisia käyttöliittymäkomponentteja ja niiden ulkoasua oli helppo muokata jQuery UIn ThemeRollerin avulla.

Fotorest-sovellus toteutettuna JSF 2 + PrimeFacesilla:
Fotorest JSF 2 + PrimeFaces

Sovellus 3: Apache Wicket 6

Apache Wicket on avoimen lähdekoodin komponenttipohjainen Web-sovelluskehys Javalle. Lyhyesti kuvattuna Wicket on kuin yhdistelmä Vaadin ja JSF -kehyksiä, sillä käyttöliittymä rakentuu HTML-sivupohjista ja tapahtumiin reakoivista komponenteista. Sovelluksen ulkoasun voi täten rakentaa HTML:llä ja lisätä toiminnot Javan puolelta juurikaan koskematta sivupohjiin. Wicket 6 julkaistiin syksyllä 2009.

Wicket ei JSF:n tavoin tarjoa peruskomponentteja enempää, mutta käyttöliittymän toiminnallisuuksien laajentamiseen voi käyttää useita jQuery-pohjaisia komponenttikirjastoja kuten Wicket - jQuery UI, jqwicket ja wiquery. Vaikka komponenttikirjastoja on useita, ovat niiden heikkous ajantasaisuus (esim. jqwicket vain 1.5 versiolle), eivätkä ne eivät ole aivan yhtä kattavia kuin mitä Vaadin tai JSF:n kirjastot tarjoavat.

Ideana HTML-sivupohjat ja työpöytäsovellusmaisen tapahtumapohjaisuuden yhdistelmä on hyvä, mutta jotenkin kokonaisuus ei ole yhtä miellyttävä kuin JSF 2 tai Vaadin. Kehittäjän kannalta Wicketissä on monia hyviä puolia, kuten toimintojen liittäminen komponentteihin ja niiden uudelleenkäyttö on kätevämpää kuin JSF 2:ssa ja sovelluksen kehittäminen on kohtalaisen selkeää, kun toiminnot ovat yhdessä paikassa eikä sekä sivupohjassa että Java-luokassa kuten JSF 2:ssa. Itseäni eniten Wicketin osalta harmittaa kuitenkin kattavien komponenttikirjastojen puute, joka tekee käyttöliittymän toiminnallisuuksien rakentamisesta hieman työlästä, kun asiat joutuu toteuttamaan itse. Yksinkertaista kuvaselaajaakin varten piti tehdä muutamia lisäluokkia, eikä valmista loputtomasti skrollaavaa taulukkokomponenttia ollut saatavilla.

Fotorest-sovellus toteutettuna Wicket 6:lla:
Fotorest Wicket 6

Yhteenveto

Kolme Java EE -käyttöliittymäkehystä ja kolme erilaista tapaa lähestyä käyttöliittymän rakentamista. Vaadin 7 tarjosi nopeasti siistiä Swing-tyylisesti komponenttien kera, JSF 2 + PrimeFaces luotti perinteisempään komponenttipohjaiseen HTML:ään ja tageihin ja Wicket 6 oli joukosta hieman työläämpi komponenttipohjainen ratkaisu. Kokonaisuutena Vaadin on selkeästi yhtenäisin paketti ja sekä JSF:n että Wicketin kanssa on hieman enemmän askarreltavaa, joka toki myös tarjoaa vapauksia.

Jokaisella kehyksellä sai aikaan suhteellisen pienellä vaivalla yksinkertaisen imgur-kuvaselaajan haun kera. Jos pitäisi saada nopeasti valmista, niin kenties toteuttaisin sen Vaatimella, jolloin aikaa ei mene niin paljoa käyttöliittymän kanssa taisteluun. Valmiiden sivupohjien kanssa JSF 2:llakin syntyy koodia nopeasti. Kaikissa kolmessa on kyllä omat jekkunsa ja "ongelmansa" muun muassa sessioiden koon ja selaimen kuormittavuuden osalta.

Seuraavaksi tutustumislistalla JVM:ssä toimivien kehysten osalta on ehkä Spring MVC, Play Framework, Grails ja puhdas GWT. Lisäksi Node.js:llä toteutettu kuvaselain on jo osittain tehty.

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1

Tietojärjestelmät eivät rakennu itsestään, vaan niiden kehitys vaatii monia askelia vaatimusmäärittelystä, suunnitteluun, toteutukseen, testaukseen ja toimittamiseen. Yksi tärkeä askel on järjestelmän arkkitehtuurin suunnittelu, joka luo perustan onnistuneelle ratkaisulle. Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturi on useamman vuoden ajan järjestänyt 3+3 -päiväistä "Tietojärjestelmäarkkitehdin valmennusohjelma" -kurssia, jossa käsitellään tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja ja keinoja erinomaiseen ratkaisuun pääsemiseksi. Osallistuin kurssin ensimmäiselle kolmipäiväiselle teoria- ja alustuspainotteiselle osiolle alkuviikosta ja tietämystä kertyi suurilta osin avainteemoista ja 4+1 -mallin hyödyntämisestä. Kurssin toinen osa on edessä syksyllä.

Jatka lukemista "Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1"

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.