Kategoria: opiskelu

Tieturin TOGAF 9 Foundation -kurssi luo perustan

Sovelluskehitys on pohjimmiltaan määrittelyjä, suunnitelmia, koodia ja testausta, mutta sen täytyy usein toimia jonkin ennalta annetun arkkitehtuurin mukaisesti ja on usein yksi rakennuspalikka isommassa kokonaisuudessa, kokonaisarkkitehtuurissa. Vaikka työtehtäväni eivät suoranaisesti liity yritysarkkitehtuurin kehittämiseen, on myös teknisen arkkitehdin roolissa hyvä tietää perusteet maailman yleisimmin käytetystä yritysarkkitehtuuriviitekehyksestä, eli Open Groupin TOGAFista, johon myös Julkisen hallinnon JHS-179 -suositus pohjaa. TOGAF materiaali löytyy ilmaiseksi verkosta, mutta osallistuin kuitenkin Tieturin järjestämälle TOGAF 9 Foundation -kurssille, joka tarjoaa (level 1) -sertifikaatin suorittamiseen tarvittavat tiedot ja valmiudet.

TOGAF 9

”Arkkitehtuuri on tarpeettoman luovuuden rajoittamista” – antiikin kreikka

Open Groupin TOGAF, eli The Open Group Architecture Framework, on maailman yleisimmin käytetty kokonaisarkkitehtuuriviitekehystä ja sekä ilmainen että vapaasti saatavilla oleva viitekehys yrityksen sisäiseen kehittämiseen. Viitekehyksen ideana on pienentää kokonaisarkkitehtuurin suunnittelemisen riskejä, kustannuksia sekä lyhentää sen suunnitteluun kuluvaa aikaa ja se tarjoaa sen saavuttamiseksi kehittämismetodin (ADM) ja työkaluja. TOGAF on myös perustana Suomen julkishallinnon käyttämässä kokonaisarkkitehtuurin suunnittelumenetelmässä (JHS-179). En ala tässä käymään tarkemmin viitekehystä läpi, vaan kiinnostuneet voivat lukea siitä TOGAF-dokumentaatiosta.

Suomessa TOGAFia kouluttavat ainakin Tieturi ja Wakaru.

Tieturin TOGAF 9 Foundation -kurssi

Tieturin TOGAF 9 Foundation -kurssi on kolmipäiväinen kokonaisuus, jossa on kahden ja puolen päivän tiukka annos teoriaa yritysarkkitehtuuriviitekehyksestä ja sertifiointikokeeseen valmistautumisesta. Kurssi tarjoaa TOGAF 9 Foundation (level 1) -sertifikaatin suorittamiseen tarvittavat tiedot ja valmiudet. Täten kurssilla on kaksi päätavoitetta: TOGAFiin perehdyttäminen ja sertifiointitestiin valmentaminen.

Kokonaisuutena Jari Kasslinin vetämä kurssi toimi oivallisesti TOGAF 9 -viitekehyksen sisällön läpikäymiseen ja asioiden hahmottamisessa, vaikka Foundation-osuus on teoriapainotteista ja sisältää paljon omaksuttavaa. Asioita käsiteltiin sertifiointitestiä ajatellen ja Kasslin esitti muun muassa TOGAFin osat, Enterprise Continuumin ja Architecture repositoryn paremmin visuaalisesti kuvattuna, kuin mitä Open Groupin materiaalissa. Lisäksi muutamat harjoitukset toimivat hyvin asian käsittelyn tukena. Ensimmäisenä päivänä sai kohtalaisen kokonaiskuvan viitekehyksen eri osa-alueista ja rooleista ja toisena päivänä käytiin tarkemmin läpi muun muassa eri vaiheiden tekniikoita ja tuotoksia. Kolmannen päivän aamupäivällä käytiin läpi muutama osio tarkemmin ja kerrattiin sertifiointitestiä varten. Kurssimateriaali tarjoaa kaksi testiin valmentavaa koetta, joista toinen tehtiin kurssin aikana ja toinen toisen päivän iltana kotona.

1. päivän tuotoksia
2. päivän ADM:n tuotokset -piirros

Tieturin kurssimateriaali ja aiheen läpikäynti tähtäsi mielestäni hyvin testiä varten, sillä vaikka TOGAFin Foundation osa sisältää paljon uutta asiaa sisäistettäväksi, kerrattiin aiheita sopivasti, jolloin se jäi paremmin mieleen. Tietenkään ei kurssi ilmainen ollut (1650e+alv), mutta en sitä itse maksanutkaan. Toki saman tiedon voi poimia lukemalla TOGAF 9:n dokumentaation, jonka pureskelu itsenäisesti lukemalla on työlästä, ja käyttämällä Open Group tarjoamaa opiskeluopasta (29,95 dollaria) ja harjoitustestiä (0,99 dollaria).

Omalta osaltani kurssi onnistui hyvin, pääsin tavoitteeseeni, eli nyt taskusta löytyy TOGAF 9 Foundation -sertifikaatti ja perustietämys TOGAF 9:n sisällöstä ja vaiheista. Sertifiointitestistä mainittakoon, että se onnistui jekuttamaan 30 prosentissa kysymyksissä. Testin läpipääsyraja on suhteellisen matala, 55 prosenttia, joten kysymyksistä on tehty hankalia ja jossain määrin termeillä ja sanamuodoilla leikkimistä. Hieman jäi sellainen fiilis, että niitä asioita, joita kertasin toisen päivän iltana ja kahdessa esimerkkitestissä, ei juurikaan kysytty siinä muodossa varsinaisessa testissä. Selkeästi aktiivinen seuraaminen ja kuunteleminen kurssilla oli tuottanut tulosta ja tieto oli sisäistetty :)

Seuraavaksi edessä on kolmen viikon päästä Foundation-vaiheessa opitun teorian yhdistäminen käytäntöön ja aihepiiriin syventyminen TOGAF 9 Certified -kurssilla ja Certified-sertifiointitesti.

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.

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.