Luento 8: Strategic Usability

Kurssin viimeisen luennon lyhyt teoriaosa käsitteli strategista käytettävyyttä, jota tämän kurssin järjestänyt Strategic Usability Group (Stratus) tutkii. Strateginen käytettävyys käsittää kaksi näkökulmaa: kuinka yrityksen strategiaa voidaan hyödyntää käytettävyydessä ja käytettävyyttä puolestaan strategiassa. Jälkimmäinen tarkoittaa käytännössä taloudellisen lisäarvon hakemista käyttävyyden kautta.

Luennolla muistutettiin että tuotteen menestykseen vaikuttavat monet asiat. Jos teknisesti edistynein ratkaisu aina voittaisi, näyttäisi maailma hyvin erilaista. Luennoitsijan esimerkki tästä oli IBM:n OS/2 käyttöjärjestelmän edistyneisyys aikoinaan. Siinä oli myös käyttäjäkeskeisen suunnittelun kannalta paljon hyvää. Mutta silti OS/2 hävisi kilpailun Windowsille.

Infolaisena olin mielissäni, kun luennoitsija toi esille infon kolmion: tekniikka, talous ja ihminen. Teknisen toteutuksen ja käyttäjäystävällisyyden lisäksi myös taloudelliset asiat pitää ottaa huomioon. Kaupallisesti kannattava yritysympäristö on luennoitsijan mukaan jätetty usein huomioimatta käytettävyyden alalla. Pitää arvioida että onko käyttäjälle hyvällä ratkaisulla myös taloudellisten realiteettien tuki.

Käyttäjäkeskeisessä suunnittelussa on jatkossa yhä enenevissä määrin otettava huomioon yrityksen strategia: miten toimija hyödyntää resurssejaan saadakseen mahdollisimman suuren hyödyn ja miten käyttäjäkeskisellä suunnittelulla tuodaan hyötyä päätöksentekoprosesseihin.

Luennon loppuosa käytettiin hauskaan kertausvisaan ja kurssitarjonnan sekä Käyttäjän ystävät-yhdistyksen esittelyyn.

Luento 7: Esteettömyys suunnittelussa

Seitsemäs luento käsitteli esteetöntä suunnittelua, joka pyrkii takaamaan kaikille tasapuoliset mahdollisuudet hyödyntää järjestelmiä ja muita tuotteita.

Käytännössä esteettömyys tarkoittaa määriteltyjen teknisten standardien ja ohjeiden noudattamista sekä rajapintojen tarjoamista. Näin järjestelmää pystyy käyttämään erilaisten apuvälineiden, kuten ruudunlukijan tai pistekirjoitusnäytön avulla. Standardeja määrittelee esimerkiksi W3C:n Web Accessibility Initiative (WAI), joka luo ohjeistuksia Internetin esteettömyyteen.

Vierailevan luennoitsijan mukaan esteettömyyden toteutumisessa ongelma on se, että kun tekniikka kehittyy ja tulee uusia järjestelmiä, niin esteettömyys laahaa perässä. Toinen ongelma ja hidaste on puhtaasti taloudellinen: esteettömyyden huomioiminen vie resursseja, mutta sen ei kuvitella tuovan juurikaan lisää taloudellista hyötyä.

Taloudelliseen puoleen voisi toimia kannusteena se, että myös “normaalit” käyttäjät hyötyisivät esteettömyydestä ja suosisivat esteettömiä palveluita. Itse ainakin nautin selkeistä järjestelmistä. Tulevaisuudessa myös ääniohjaus/luku ja muut vaihtoehtoiset interaktiotavat yleistynevät, jolloin esteettömyyden tarve lisääntyy myös “normaaleilla” käyttäjillä.

Luento 6: Käyttöliittymät

Kuudennella luennolla aiheena oli käyttöliittymän mallintaminen ja rakentaminen. Huonoista käyttöliitymistä on kokemusta varmasti jokaisella. Yllä oleva kaameus on bongattu Stack Overflown Worst UI You’ve Ever Used -ketjusta. Aivan noin huono ei keskiverto käyttöliittymä sentään ole – onneksi.

Mutta millainen on hyvä käyttöliittymä? Luennolla esiteltiin Myersin hyvän käyttöliittymän tunnusmerkit:

1. Näkymätön, huomaamaton
2. Ei vaadi koulutusta, helppo oppia
3. Yhdessä tilanteessa opittua voidaan solveltaa toiseen
4. Ennustettavuus
5. Virheetön; vähän virheitä, toipuminen yksinkertaista
6. Oikeiden tehtävien suorittaminen onnistuu hyvin
7. On joustava – ja älykäs
8. Käyttäjät pitävät siitä

Lista itsestäänselvyyksiä, mutta jälleen (vrt Nielsenin 10 heuristiikkaa) käytännössä helposti rikottavia.

Käyttöliittymän mallintamisesta mieleeni jäi erityisesti navigaatiomalli, jossa käyttäjän vuorovaikutuksen eteneminen kuvataan navigaatiokarttana. Kartasta on helppo tunnistaa mahdollisia ongelmatilanteita, esimerkiksi ikuisia looppeja.

Luennolla käytiin läpi myös käyttöliittymäkehittimiä, joiden avulla käyttöliittymiä voi helpohkosti toteututtaa. Tcl/Tk ja Borland Delphi -esimerkit olisi voinut päivittää tuoreempiin. Vanhojen käyttöliittymäesimerkkien suhteellisen tarkka läpikäynti oli mielestäni hieman vaivaannuttavaa.

Mielenkiintoisempi oli nopea Qt-demo. Itselläni on jo jonkin aikaa ollut tavoitteena ehtiä tutustumaan kyseiseen ympäristöön. Toivottavasti pian ehtisi. Luennoitsijan heitosta ymmärsin että harkkakurssilla saatamme käyttää Qt:ta.

Viimeiseksi käsiteltiin suunnitteluohjeistoja, jotka pyrkivät helpottamaan niin kehittäjän kuin käyttäjänkin elämää. Ohjeistot jakautuvat suunnitteluperiaatteisiin ja tyylioppaisiin, joista jälkimmäiset ovat tarkempia tiettyyn käyttöliittymäympäristöön sopivia ohjeistoja.

Tyylioppaat määrittelevät käyttöliittymäympäristölle ohjeistot, joiden avulla pyritään saavuttamaan yhtenäisyys eri ohjelmien kesken. Yhtenäisyys on tärkeää niin Myersin tunnusmerkkien (Yhdessä tilanteessa opittua voidaan solveltaa toiseen) kuin edellisellä luennolla käsiteltyjen Nielsenin heurestiikkojen (Ole yhdenmukainen) mukaan.

Luennolla käytiin esimerkkinä tyylioppaista KDE:n UI Guidelinejä, mutta paljon mielenkiintoisempi esimerkki on mielestäni Apple Human Interface Guidelines. Uppouduin lukemaan niitä varsin pitkäksi aikaa.

Luento 5: Käytettävyyden arviointi

Viidennen luennon aiheena oli käytettävyyden arviointi. Arvioinnin prosessi on yksinkertainen muodostuen (1) menetelmien valitsemisesta, (2) testien suunnittelemisesta ja (3) toteuttamisesta sekä lopulta (4) tuloksien analysoinnista ja raportoinnista. Käytettävyyden arvioinnin menetelmiä on kaksi: käyttäjätestaus ja asiantuntija-arviot, jotka jakautuvat edelleen erilaisiin tarkempiin menetelmiin.

Käyttäjätestauksen menetelmiin kuuluu perinteisen käytettävyystestin lisäksi esimerkiksi paritesti sekä vapaa ja tilannesidonnainen läpikäynti. Arvioinnin prosessi käytiin läpi käytettävyystestin näkökulmasta. Kävi selväksi että testi pitää suunnitella hyvin ja myös pilotoida ennen varsinaisten käyttäjien testaamista.

Käyttäjätestauksessa on tärkeää muistaa että nimestään huolimatta testauksen kohteena on tuote eikä käyttäjä. On helppo kuvitella että käyttäjä tuntee testitilanteessa itseään testattavan ja virheiden johtuvan hänestä, vaikka oikeasti on kyse tuotteen virheistä.

Asiantuntija-arvioinnin tunnetuin menetelmä on heuristinen arviointi. Menetelmässä läpikäydään tuottetta tehtäväpohjaisesti tai yleisesti ja lopputuloksena saadaan saadaan ongelmat ja vahvuudet priorisoituna. Priorisointi on tärkeää, jotta vakavimmat asiat saadaan korjattua ensin. Heuristinen arviointi vaikutti mielenkiintoiselta ja sitä pääseekin kokeilemaan harkkakurssilla.

Heuristisessa arvioinnissa voidaan soveltaa Nielsenin 10 heurestiikan muistilistaa (suomennokset luentokalvoista):

1. Käytä yksinkertaista ja luonnollista vuoropuhelua
2. Puhu käyttäjien omaa kieltä
3. Älä rasita käyttäjän muistikuormaa
4. Ole yhdenmukainen
5. Anna käyttäjälle palautetta toiminnoista
6. Osoita selkeä poistumistapa
7. Anna mahdollisuus oikopolkuihin
8. Anna selkeät virheilmoitukset
9. Vältä virhetilanteita
10. Anna riittävä ja selkeä apu

Heuristiikat käytiin luennolla läpi hyvien esimerkkien kera. Ne ovat yksinkertaisia ja loogisia, mutta käytännössä helposti unohdettavia ja rikottavia. Nielsenin heuristiikat ovat melko yleispäteviä ja niitä voikin soveltaa esimerkiksi naisen käytettävyyden arviointiin.

ISO 13407-prosessimallin mukaisesti arviointia tulee suorittaa koko tuotekehitysprosessin ajan ja hyödyntää aina sopivinta arviointimenetelmää. Käyttäjätestauksen etuna on että löydetään oikeasti käyttäjälle vakavat ongelmat. Asiantuntija-arvioiden etuna on puolestaan nopeus, edullisuus ja mahdollisuus toteuttaa aikaisessa vaiheessa.

Luento 4: Käyttätutkimus ja prototypointi

Luennon ensimmäinen osa käsitteli käyttäjätutkimusta. Aluksi käytettiin monta kalvoa käyttätutkimuksen tarpeellisuuden perustelemiseen. Päällimmäisenä jäi mieleen luennoitsijan heitto: Käyttäjät tekevät asioita hyvin eri tavalla kuin TE kuvittelette heidän tekevän.

Tärkeimmiksi käyttäjätutkimusmenetelmiksi esiteltiin havainnointi ja haastattelu. Kumpikin jakaantuu erilaisiin tarkempiin menetelmiin. Menetelmistä havainnointi vaikutti mielenkiintoisimmalta.

Havainnointia voi tehdä paitsi ihmissilmin, myös teknisesti. Törmäsin aikaisemmin Nielsenin sivuilla mielenkiintoisiin artikkeleihin eyetracking-tekniikasta webbisivujen käytettävyyden kehittämisessä. Hyviä esimerkkejä tekniikan avulla saaduista tuloksista ovat Nielsenin artikkelit Banner Blindness sekä F-Shaped Pattern For Reading Web Content.

Olisi mielenkiintoista päästä itse toteuttamaan eyetracking-tutkimus joskus. Onkohan TKK:lla Aalto-yliopistolla tällaista laitteistoa?

Luennon toinen osa käsitteli mallinnusta ja prototypointia. Osan mielenkiintoisin aihe oli paperiprototypointi, jossa käyttöliittymiä hahmotellaan paperille piirtämällä. Paperiprotot mahdollistavat halvan tavan tehdä käyttäjätutkimusta jo projektin alkuvaiheessa.

Luennoitsijan mukaan paperiprototypoinnin etu lopullista käyttöliittymää muistuttaviin prototyyppeihin verrattuna on matalampi kommentointikynnys. Löysin paperiprototypoinnista mielenkiintoisen artikkelin Snyder Consultingin sivuilta, jossa mainitaan paperien kannustavan luovuuteen, kun käyttäjä ei keskity epäolennaisiin seikkoihin kuten asetteluvirheisiin.

Jäin pohtimaan ajavatko koneella tehdyt wireframe-prototyypit saman asian kuin piirretyt. Niitä on ainakin helpompi iteroida. Kysyin luennon jälkeen asiasta luennoitsijalta, jonka mielipide oli että piirrettyjen paperiprototyyppien etuna on wireframeihinkin verrattuna niiden karkeus: käyttäjä näkee selkeästi että kyseessä on vasta luonnos, ja uskaltaa ehdottaa radikaalimpia korjauksia.

Linkki: Forum Nokia – User Experience Programme

Tentin lähestyessä hyvä linkkivinkki:  Forum Nokian User Experience Programme. Johdatus UX:n pariin.

Forum Nokian Desing and User Experience -osiosta löytyy myös muuta mielenkiintoista, esim:

• Mobiiliohjelmista kiinnostuneille Design Gallery.
• Paperiprotoiluun Design and Paper Prototyping Templates.

Luento 3: Käyttäjäkeskeinen tuotekehitys

Kurssin kolmannen luennon aiheena oli Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit. Luennon aluksi keskusteltiin käytännön haasteista käyttäjäkeskeisessä suunnittelussa. Esille tuli monta hyvää pointtia, kuten käyttäjien erilaisuus, resurssien puute ja suoran rahallisen lisäarvon puuttumisesta aiheutuva hyötyjen perustelun vaikeus. Aloin itse pohtimaan kuinka hyötyjen perusteluun olisi hyvä saada kylmää dataa käyttäjämäärien kasvamisesta ja asiakastyytyväisyyden noususta. Ongelmana on että näitä on mahdoton mitata ennen muutoksien toteuttamista.

Luenolla esitettiin käyttäjäkeskeisen suunnittelun perusperiaatteet viitenä kohtana, joista ensimmäiset kolme on määritellyt Gould & Lewis vuonna 1985:

1: Aikainen ja jatkuva huomion kiinnittäminen käyttäjiin
2: Aikainen ja jatkuva käyttäjien suorittama testaus
3: Iteratiivinen suunnittelu

ISO-standardi 13407 vuodelta 1999 ilmaisee samantyyppiset asiat, mutta lisää näihin vielä:

4: Tarkoituksenmukainen tehtäväjako käyttäjän ja järjestelmän välille
5: Monialainen suunnitelutiimi

Perusperiaatteet ovat mielestäni loogisia ja hyvin perusteltuja. Törmäsin myös käytettävyyssuunnittelija Jesse James Garretin hienoon tiivistykseen käyttäjäkeskeisestä suunnittelusta esityksessään (s. 7): tuote ei ole itsetarkoitus, vaan tarkoitus on lopulta tarjota hyva kokemus kayttajalle.

Luenon toinen osa käsitteli käyttäjäkeskeisen suunnittelun prosessikuvauksia, joista esiteltiin ISO 13407-standardin Human-centered design processes for interactive systems, Nielsenin Usability Engineering Life Cycle sekä LUCID-malli. Yhteistä näissä kaikissa kuvauksissa on iteratiivisuus ja käyttäjien huomioiminen mahdollisimman aikaisin.

Luennon lopuksi käsiteltiin vielä asiakas- ja käyttäjälähtöisyyttä. Erityisesti asiakaslähtöisyys on noussut trendiksi ja esiintyy jokaisen itseään kunnioittavan yritysjohtajan puheissa. Tuli mieleen että uskaltaako joku muka väittää että EI ole asiakaslähtöinen? Mielestäni termi on menettänyt merkityksensä.

Ongelmana asiakaslähtöisyydessä on usein se, että asiakas ei ole palvelun käyttäjä, eikä oikeasti tiedä mitä loppukäyttäjä tarvitsee. Myöskään toimittajapuolen myyjät ja suunnittelijat eivät ymmärrä asiakkaan loppukäyttäjää. Luennolla esitetty keinukuva kuvaa mielestäni hyvin tilannetta. Alla toinen versio samasta kuvasta.

Luento 2: Määritelmien sekamelskaa

Toisen luennon aiheena oli käytettävyys ja käyttäjäkokemus. Luento oli melkoisen teoriapainotteinen keskittyen lähinnä aihealueen terminologian määrittelyyn.  Toisistaan hieman eroavia termejä ja kilpailevia määritelmiä tuntuu riittävän. Alla oleva luentokalvoista napsaistu piirros kuvaa hyvin luennon jälkeistä sekavuutta.

Kyseessä on suomennettu versio Paul A. Boothin hahmotuksesta käyttöliittymäsuunnittelun aihealueista kirjassaan An introduction to human-computer interaction (1989). Hämmentävän sekava piirros ollakseen käytettävyyden materiaalia. Onnistuu kuitenkin pääviestinsä kertomisessa: käyttöliittymäsuunnittelun osa-alueet linkittyvät useisiin muihin tieteenaloihin.

Keskeisin aihealueen termeistä on käytettävyys. Käytettävyydelle ei ole olemassa yksiselitteistä määritelmää, mutta useita yleisesti hyväksyttyjä kyllä. Käytettävyyden määritelmä ISO 9241-11 standardin suomennoksen (Nelli – SFS standardit) mukaan:

Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi.

Käytettävyysguru Jakob Nielsenin määritelmän mukaan käytettävyys puolestaan tarkoittaa sitä, että järjestelmä on (suomennokset luentokalvosta):

• Helppo oppia
• Tehokas käyttää
• Helppo muistaa
• Sisältää vähän virheitä
• Subjektiivisesti miellyttävä

Nielsenin kotisivujen mainioita Alertbox-kirjoituksia on tullut lueskeltua enemmänkin. Näin webbikehittäjän näkökulmasta vastaan tuli monia mielenkiintoisia faktoja, kuten kuinka ihmiset jättävät huomioimatta mainoksilta näyttävän sisällön. Linkin esimerkki on tragikoomisuudessaan opettavainen, kannattaa lukaista. Lyhyesti: 86% käyttäjistä ei löytänyt sivuston etusivulla sijainnutta tietoa koska se näytti liikaa mainokselta.

Luennon lopuksi fiilisteltiin muodikkaan User Experiencen (UX) eli suomentajasta riippuen käyttäjäkokemuksen tai käyttökokemuksen parissa. Suomennosten merkityseroista lisää Köyttöliittymä.netin artikkelissa. Joka tapauksessa kyseessä on vieläkin epämääräisemmin määritelty termi kuin käytettävyys. Yleisesti termin nähdään keskittyvän käytettävyyttä enemmän ihmiseen ja hänen kokemuksiinsa järjestelmän käytöstä.

Luento 1: Sähköisen äänestämisen käytettävyysongelmista

Kurssin ensimmäisen luennon ensimmäinen puolikas käytettiin yleiskuvan muodostamiseen kurssin aiheista (kalvot). Nopea luentoaiheiden läpikäynti ei ollut kovin hedelmällistä, mutta mieleen jäi painotus käyttäjäkeskeisen suunnittelun kokonaisvaltaisuudesta – ei suunnitella yksittäistä käyttöliittymää vaan kokonaisvaltaista käyttötilannetta.

Palm Beach Countryn äänestyslomake v. 2000

Luennon kiinnostavin osuus liittyi esimerkkiin: USA:n vuonna 2000 presidentinvaaleissa Floridassa ilmenneisiin epäselvyyksiin, jotka johtuivat huonosti suunnitellusta äänestysjärjestelmästä. Järjestelmän takia jouduttiin mitätöimään ennätysmäärä ääniä ja suuri joukko ihmisiä äänesti oletettavasti eri ehdokasta kuin tarkoitti. Tämä vaikutti koko vaalien lopputulokseen. (Wikipedia: United_States_presidential_election_in_Florida,_2000: Palm Beach County’s butterfly ballots)

Epäselvyydet johtuivat huonosta äänestyslomakkeesta, jossa oli selkeä käytettävyysongelma. Jos lomaketta suunniteltaessa olisi huomioitu esimerkiksi luennolla esitetyt hahmolait, olisi ongelmia voitu välttää. Järjestelmän tarkasteleminen käyttäjäkeskeisen suunnittelun näkökulmasta olisi kannattanut.

Osataan sitä toki Suomessakin tunaroida. Luennollakin mainittiin sähköisen äänestyksen kokeilussa kunnallisvaaleissa vuonna 2008 esiintyneet käytettävyysongelmat, jotka johtivat lopulta vaalien uusimiseen kokeilukunnissa vuonna 2009.

Helsingin Sanomat kertoo äänestyksessä ilmenneistä ongelmista uutisessaan:

Sähköisen äänestyksen kokeilu ei sujunut kolmessa kunnassa aivan niin kuin piti. Kuntavaalien jälkeen on selvinnyt, että kaikkiaan 232 äänestäjältä ei äänen antaminen koneella onnistunut, vaan operaatio keskeytyi ja ääni jäi kokonaan antamatta.

Oikeusministeriön selvityksen mukaan äänestämisen epäonnistuminen johtui todennäköisimmin siitä, ettei äänestäjä painanut OK-painiketta ennen kuin poisti koneesta sähköisen äänestyskortin. Tällöin annettu ääni ei kirjautunut sähköiseen vaaliuurnaan.

Oikeusministeriön mukaan järjestelmän testauksessa ei etukäteen tullut esille mahdollisuus, että äänestäjä voisi keskeyttää koneella äänestämisen erehdyksessä.

Kattavalla käytettävyystestaamisella on tärkeä rooli käyttäjäkeskeisessä tuotekehityksessä – eikä suotta.

Oiva Eskola on kommentoinut äänestyslaitteen käytettävyysongelmia blogissaan ja tuo esille myös äänestystilanteen vaikutuksen:

Äänestystilanteessa voi kuvitella olevan paljonkin tekijöitä, jotka vaikeuttavat äänestyskoneen käyttämistä. Äänestyspaikalla on jonoa ja äänestäjä haluaa toimia ripeästi koska tuntee jonon paineen takanaan, [...] äänestäjä ei halua vaikuttaa tyhmältä, ja haluaa näyttää osaavansa sujuvasti käyttää laitetta, jonka näkee ensimmäistä kertaa, eikä varmasti pyydä apua, jne.

Luennolla esitetty kokonaisvaltainen käyttötilanteen suunnitteleminen olisi sähköisen äänestyksen tapauksessa ollut suotavaa.

Aapo Puskala on tehnyt sähköisestä äänestyspäätteestä laajahkon käytetettävysarvion (pdf), jonka tuloksia hän summaa seuraavasti:

Äänestyspäätteessä havaittiin 7 merkittävää ja 15 kohtalaista käytettävyysongelmaa. Näiden lisäksi todettiin 9 mahdollista ongelmaa, joiden arviointi edellyttää tarkempia tietoja äänestyspäätteen toiminnasta kuin mitä oli saatavilla.

Tulosta voi pitää surkeana, sillä laitteella on vain yksi varsinainen tehtävä ja sekin yksinkertainen: tallentaa yksi enintään kolminumeroinen käyttäjän näppäilemä luku.

Sähköisen äänestämisen hanke on vastikään pantu jäihin.

Käytettävyyden huomioiminen ei ole hankalaa, mutta huomioimatta jättäminen saattaa aiheuttaa suuria ongelmia ja kustannuksia.

Oppimispäiväkirja

Opintoihini Informaatioverkostojen koulutusohjelmassa kuuluu tänä keväänä kurssi T-121.2100 Johdatus käyttäjäkeskeiseen tuotekehitykseen.

Kurssilla tarjotaan lisäpisteitä oppimispäiväkirjan pitämisestä. Kurssin sivuilla ohjeistetaan:

Oppimispäiväkirjan tavoitteena on tukea kurssin aineiston opiskelua. Päiväkirja tulee rakentaa ja kirjoittaa siten, että kirjoittajan lisäksi myös muut (kurssin opetushenkilökunta) ymmärtävät sen sisällön. Päiväkirja voi sisältää esimerkiksi esseemäisiä kirjoitelmia, piirroksia, luonnoksia, mindmappeja, lehtiartikkeleja, tai erilaisia kuvauksia (esimerkiksi menetelmä- tai käyttäjäryhmäkuvaukset).

Oppimispäiväkirjan voi tehdä joko julkisena tai perinteisesti yksityisenä kerralla palautettavana tekstinä. Itselläni on kokemusta kummastakin metodista. Julkista päiväkirjaa pidettiin legendaarisella Informaatioverkostojen Studio 1 -kurssilla ja perinteinen oppimispäiväkirja tuli kirjoitettua viimeksi sosiologian kurssilla.

Kokemukseni perusteella julkinen oppimispäiväkirja on vaihtoehdoista parempi useastakin syystä. Julkista päiväkirjaa tulee kirjotettua säännöllisesti ja motivaatio kirjoittamiseen on suurempi. Blogimuodossa pidettävään oppimispäiväkirjaan on myös helppo lisätä pieniäkin julkaisuja esimerkiksi vastaan tulevista kiinnostavista sivuista.

Kurssin sivuille kootaan lista julkisista oppimispäiväkirjoista, jonka kautta voi seurata myös muiden oppimista. Parasta olisi jos kirjoittajien välille saadaan herätettyä keskustelua kommentoinnin myötä.

Hienoa että kurssi elää ajassa ja tarjoaa tällaista tapaa oppimisen tukemiseen!