Ohjelmistoasennukset ovat myrkkyä!

Mikä tahansa asennusta (install) toimiakseen vaativa ohjelma on huono. Asennus on raskas ja arvaamaton prosessi edelleen, sekä mobiililaitteissa että PC:eissä.
Asennuksen onnistuminen voi vaatia etukäteistyötä eri tahoilta; levytilan vapautusta, käyttöoikeuksien säätämistä, lisenssien rekisteröintejä, sähköpostitilien luontia, yms. Vuonna 2020 pitäisi olla jo saatavilla materiaalia helposti digitaalisella valtuutuksella ja automaattisilla etäasennuksilla, jolloin oppilaan tai huoltajien vastuulle ei jää mikään osa teknisestä opetusalustan asennuksesta. Yksittäinen käyttäjätunnus per oppija,
tai jokaisella eri oppimisohjelmalla toimiva sama kertakirjautumiskäytäntö
ovat hyviä – sen sijaan huono on, mikäli käyttäjätunnus+salasala -pareja
kertyy tusinoittain per oppilas.

Päästäänkö alkuun? Kaiken A ja O

Oppimiskokemuksessa aivan keskeisenä kulmakivenä on materiaalin välitön saatavuus ja saavutettavuus. Kaikki muu on turhaa, mikäli sisältöön ei yksinkertaisesti pääse käsiksi; esimerkiksi odotetaan poikkeuksellisen monimutkaista ohjeistuksen seuraamista, useiden eri linkkien käyttöä; tai on merkittäviä rajoituksia web-selainten “oikeille versioille” eli oppimateriaali ei esimerkiksi toimi ilman tiettyjä web-selaimeen asennettavia lisäosia (plugins/extensions/addons).

Kultainen sääntö: tiedä tilannekuva, monitoroi

Jatkuvalla kuormitustestauksella ja ennenkaikkea mahdollisimman realistisesti käyttäjän oikeita kokemia vasteaikoja (latency) mittaamalla (robotti end-to-end testeillä) varmistetaan järjestelmän ylläpitopuolella, että todelliset käyttäjän kohtaamat vasteajat pysyvät järjellisissä rajoissa. Mm. Nielsen (NNGroup) ja kumppanit ovat luoneet varsin hyvät standardit vasteajoista, samoin Googlelta on paljon suosituksia ja tutkimuksia interaktiivisen järjestelmän vasteaikojen vaikutuksesta käyttökokemuksen miellyttävyyteen ja suoranaiseen tehtävän hylkäämiseen (task “abandon”); peukalosääntöinä sivusiirtymä eli uuden sisältösivun latautuminen siten, että sivu on asettunut (“settled”) aivan max. 10 sekuntia; vasteen saaminen sivulla tapahtuvaan toimintoon max. 0,1s. Response times: the 3 important limits. Varsinainen tekninen suorituskykyskaalaus pilvessä vasteaikojen noustessa, ei pitäisi olla rakettitiedettä enää.

Kehittäjä: Auta oppilasta auttamaan itseään

Itsetarkistus-mekanismit ovat erittäin hyödyllisiä: tehtävän yhteydessä on pieni kysely (polku) jolla voi tarkistaa, onko ymmärtänyt perusidean tehtävästä. Tai tehtävä sisältää vinkit, jotka reagoivat interaktiivisesti käyttäjän vastauksiin. Tällöin oppijalla on mahdollisuus paremmin itsenäisesti korjata pienet käsitysvirheet tai alkuunpäämisen ongelmat. Oppimisen sujuvuus ei riipu joka sekunti ohjaajan läsnäolosta. Digitaalisuuden haluttu skaalausvaikutus tulee aika suurelta osin siitä, että järjestelmä vapauttaa ajasta ja paikasta, ja vastapainoksi tukee käyttäjän itsenäistä työskentelyä. Usein heikoimman lenkin ilmiö voi olla showstopperina: pieni yksityiskohta, joka lisää epävarmuutta kokeilla ja tarttua toimeen; kun käyttäjä on autettu yli pienistä alkuvaikeuksista, usein jatko sujuu paljon paremmin. Käyttäjä saa luottamuksen sekä itseensä että oppimisalustaan.

Selkeä koontinäkymä koko opetusryhmän etenemisestä

Automaattiset koontitiedot (yleiskatsaukset) opettajalle, sirpaletiedon
sijaan. Opettaja saa tilanteesta riippuvan tarpeellisen tiedon, ei välttämättä jokaikistä turhaa väliaskelta mitä mahdollisesti kymmenet (tai jopa sadat) oppilaat ovat
päivän aikana tehneet. Vältä järjestelmän luojana siis tilannetta, jossa järjestelmä sokeasti tekee “digiroskaamista” (digiroskaaminen tarkoittaa automaattisten ilmoitusviestien määrää, jossa ne alkavat olla enemmänkin spammiä, kuin hyödyllisiä). Arkistointi lokiin (auditointivaatimus) on eri (ja hyvä) asia, kuin pienten sirpaleviestien ylimääräinen viljeleminen. Näiden mekanismien ohjelmointi vaatii suunnittelua ja syvällistä käyttötilanteen ymmärtämistä, mutta on sen väärti.

Esimerkki hyvästä koontitiedosta

Esimerkki: jos päivän maali on, että 30 oppilasta tekee 5 tehtävää jokainen, ja näin kävikin 96%:sti, on fiksumpaa ilmoittaa yksilöidysti 4% tekemättömät tehtävät listana (syntyy 6 kpl viestejä), kuin ilmoittaa jokaisen 96% tekemät suoritukset (144 kpl viestejä, lisäksi 6 kpl tekemättömistä). Erilaisia älykkäitä filttereitä voi suhteellisen pienellä vaivalla ohjelmoida:

• laske positiivisten ja negatiivisten tietojen määrä (eli eksplisiittisten tapahtumien ja niiden komplementtitapausten määrät)
• mieti, voiko järjestelmä koota (grouping) mielekkäästi selkeällä lauseella isoimman osan, ja lisäksi kertoa yksityiskohtaisesti oleelliset poikkeustapaukset
• jäikö joku yksittäinen henkilö selkeästi kokonaan väliin?
• onko jokin tehtävä selkeästi harvemmin suoritettu loppuun asti kuin muut?
• onko joku muu yhteinen selittävä tekijä nähtävissä suoritustrendissä?