Hvordan et e-læringskurs blir til: verktøy, SCORM og det som kommer inn i plattformen

Kurset er ferdig, det er betalt, og det kommer som én zip-fil med et versjonsnummer i navnet; noen laster det opp i plattformen, trykker lagre, og neste dag er fullføringsoppføringene til 120 personer borte, selv om ingen har slettet noe. Det er verken myte eller sjeldenhet, og plattformen advarte til og med, bare at advarselen vises et halvt sekund før knappen allerede er trykket, og teksten der sier noe ingen forsto der og da.

Denne artikkelen handler om veien fra materialet til pakken, og om det plattformen som tar imot pakken gjør med den, fordi det er nettopp i dette overleveringspunktet to parter møtes som vanligvis ikke ser hverandres arbeid. Hva en læringsplattform er, og når virksomheten i det hele tatt trenger en, har vi skrevet om separat, og det samme gjelder hvordan du velger læringsplattform. Her dreier det seg om steget etter valget: kurset lages utenfor plattformen, pakkes og kommer så inn, og det er nettopp i denne overgangen nesten alle problemene oppstår som senere ser ut som plattformfeil.

Først er det verdt å si én ting som skiller dette emnet fra de fleste andre: nesten alle problemene her er dokumentert, navngitt og offentlig beskrevet, så du trenger ikke å oppdage dem med egne penger. Plattformens dokumentasjon har både advarslene, årsakene og løsningene, og det som vanligvis mangler, er et menneske som leser dem før bestillingen, ikke etter det første uhellet.

Hva pakken inneholder, og hva plattformen gjør med den

En SCORM-pakke er et zip-arkiv med filen imsmanifest.xml i roten, og det er nettopp denne filen som gjør pakken til en pakke, og ikke til en mappe med filer. Manifestet beskriver kursstrukturen, lister læringsobjektene (SCO) og angir hvilke filer som hører til dem, så plattformen leser det først og får vite hva den skal vise, og i hvilken rekkefølge.

Videre er skillet enklere enn man vanligvis tror, og det er verdt å si med en gang, fordi det forklarer nesten alt det øvrige, nemlig at plattformen viser pakken og lagrer data om det personen gjorde i den, men at den verken lager innholdet eller griper inn i det. Moodles dokumentasjon sier det rett ut: systemet leverer pakken og lagrer data om læringsinteraksjonen, men genererer ikke SCORM-innholdet selv. Derfor er alt som skjer inne på skjermen innholdsprodusentens arbeid, og alt som skjer rundt det, plattformens arbeid.

Kommunikasjonen mellom de to går gjennom en smal kanal, der læringsobjektet kaller plattformens grensesnitt med kommandoer som initialisere, sette verdi, lagre og avslutte, og der noen verdier går den veien: status, poeng, tid, svar på spørsmål og et lite tekstfelt for å lagre tilstanden (suspend_data). Denne kanalen er det viktigste elementet i hele emnet, fordi alt du senere vil se i en rapport, må sendes ut nettopp gjennom den, og det som ikke får plass der, kommer aldri inn i rapporten.

Det plattformen lagrer, er en konkret og begrenset liste knyttet til ett forsøk i den konkrete aktiviteten: status, oppnådde poeng sammen med minimum og maksimum, tiden som er brukt, svar på enkeltspørsmål og det nevnte tilstandsfeltet. Der finnes verken personens navn inne i kurset, eller hvor mange ganger personen spolte videoen, eller hvilke sider som ble hoppet over, med mindre kurset selv har gjort disse faktaene om til en av de opplistede verdiene.

Feilene som oppstår i denne overgangen, er også kjente og dokumenterte, så de trenger ikke oppdages på nytt, og den vanligste er at manifestet mangler eller ligger på feil sted i arkivet, fordi det skal ligge nettopp i roten, ikke i en undermappe, mens den andre er identifikatorer som ikke er unike, som har en egen sak i feilsporingssystemet. For eldre kurs kommer visningsproblemer på mobile enheter i tillegg, når innholdet er lagt i en ramme med fast størrelse, og også de har sine saksnumre, så du kan spørre leverandøren om dem direkte.

Derfor er det første spørsmålet til innholdsprodusenten ikke hvilket forfatterverktøy kurset skal bygges i, men i hvilket format det skal leveres, og hva det konkret vil rapportere. To kurs som ser like ut på skjermen, kan rapportere helt forskjellig, og forskjellen blir synlig først når noen trenger et bevis for at personen faktisk gikk gjennom kurset.

Fire grupper av forkortelser som ikke er det samme

Ordene SCORM, xAPI, cmi5 og AICC brukes i markedet som om de kunne erstatte hverandre, men de betegner forskjellige ting og har forskjellige forvaltere. SCORM er et pakkeformat sammen med et kjøretidsmiljø, og den siste versjonen er fjerde utgave av SCORM 2004, som kom i 2009; det finnes ingen nyere utgave, og det er heller ikke ventet noen.

Organisasjonen som skapte SCORM, har lagt ned virksomheten, og i arkivene deres ligger det nå en melding om arkivering, men av det må du ikke slutte at standarden er uten forvalter, for datamodellen i SCORM-kjøretidsmiljøet vedlikeholdes av Institute of Electrical and Electronics Engineers som standard 1484.11.1, med siste revisjon fra 2022, og ved siden av den 1484.11.2 om grensesnittet. Samtidig er det verdt å kjenne en detalj som villeder: på arkivsiden til organisasjonen som skapte SCORM, står navnet skrevet som «Advanced Digital Learning», selv om det historiske navnet er «Advanced Distributed Learning».

xAPI er noe annet, nemlig ikke et pakkeformat, men en meldingsmodell og et grensesnitt der systemet sender oppføringer om det personen gjorde, til et eget LRS (learning record store). Siden 2023 er det en publisert standard med nummer 9274.1.1, og den samme teksten finnes også som internasjonal standard, så det dreier seg om én ting med to numre, ikke om to versjoner.

Det fjerde navnet er cmi5, og det er en xAPI-bruksprofil nettopp for å starte fra læringsplattformen, ikke enda en egen standard; den gjeldende utgaven av cmi5-profilen er fra 2016, og det internasjonale standardiseringsarbeidet er i gang, men ikke ferdig, så det riktige er å si at arbeidet er godkjent som prosjekt, ikke at standarden allerede finnes. AICC er på sin side det eldste av dem alle, og komiteen som vedlikeholdt det, la ned virksomheten i desember 2014 og overlot cmi5 og arkivet sitt videre.

Grensen du må kjenne før du bestiller kurset

Her er et av de praktisk viktigste faktaene i hele artikkelen, og det overrasker nesten alle som hører det første gang: Moodle støtter SCORM 1.2 og AICC, men den støtter ikke SCORM 2004, og det er verken en misforståelse eller slurv, men et bevisst valg som står i plattformens egen dokumentasjon, og som ingen der skjuler. Der står det at 1.2 består samsvarstestene, mens det av 2004-versjonen bare er realisert enkelte grunnleggende deler av grensesnittet, så noen pakker kan se ut til å virke selv om det ikke finnes fullt samsvar.

Denne grensen er viktig fordi innholdsprodusenter ofte tilbyr nettopp 2004-versjonen som den nyeste og beste, og formelt er den også det, fordi den har to atskilte statusfelt og et skalert resultat. For kjøperen som skal jobbe med Moodle, viser den nyeste versjonen seg likevel å være det dårligste valget, og det er en av de få gangene en eldre standardversjon er det riktige svaret, og ikke en innrømmelse til omstendighetene.

Så følger en setning det er verdt å lese to ganger, fordi den avgjør hvordan du handler videre: arbeidet med støtte for SCORM 2004 er stanset, og feilrapporter om det lukkes som saker som ikke skal rettes. Det betyr at noen 2004-pakker kan se ut til å virke, men du kan ikke stole på det, og ingen vil rette dem hvis de slutter å virke, mens den sertifiserte veien, hvis 2004-versjonen er påkrevd, går via en kommersiell ekstern tjeneste med sin egen utvidelse.

Den praktiske følgen av det er enkel: før du bestiller kurset, må du si til innholdsprodusenten hvilket format pakken skal leveres i, og i de fleste tilfeller blir svaret SCORM 1.2. Hvis produsenten bare tilbyr 2004-versjonen, er det ikke automatisk dårlig, men det endrer valg av plattform eller krever en ekstra komponent, og den samtalen må tas før arbeidet, ikke på overleveringsdagen. For cmi5 må du vite at Moodle ikke har det som standard, og at det trengs en egen utvidelse, samt et eget LRS.

Ett felt der alt skal få plass

SCORM 1.2 kjenner ett statusfelt, og der kan det stå én av seks verdier, som i Moodles norske grensesnitt vises som «Bestått», «Fullført», «Feilet», «Ufullstendig», «Lest» og «Ikke forsøkt». Det betyr at du ikke samtidig kan rapportere at personen gikk kurset ut, og samtidig at testen ikke ble bestått, fordi de to tingene kjemper om det samme feltet, og for virksomheten som trenger nettopp dette skillet, er det en reell begrensning, ikke en teknisk detalj.

SCORM 2004 løser dette ved å splitte statusen i to uavhengige felt, der det ene forteller om gjennomføringen og det andre om resultatet, og ved å legge til et skalert resultat; det er nettopp derfor noen innholdsprodusenter tilbyr den. Men fordi Moodle ikke støtter 2004-versjonen, er denne løsningen utilgjengelig for de fleste leserne, og du må planlegge at det kan trengs to aktiviteter i stedet for ett kurs: én for gjennomgang av materialet, og én for prøven.

Den andre begrensningen er enda mer konkret: feltet der læringsobjektet lagrer sin interne tilstand, slik at personen kan fortsette fra samme sted, tar i SCORM 1.2 4 096 tegn, og denne grensen står også i Moodles datamodellfil. For et langt kurs med mange spørsmål er det lite, og når grensen er nådd, lagres tilstanden rett og slett ikke lenger, så personen kommer tilbake til starten av kurset, og det ser ut som en plattformfeil, men er en standardgrense.

Den tredje begrensningen er en som kan gjøre et gjennomført kurs om til et ikke bestått uten at noe menneske er med, nemlig at hvis manifestet angir en godkjentgrense (masteryscore), så pålegger samsvarskravene plattformen å regne statusen om mot de oppnådde poengene, og Moodle tilbyr til og med denne atferden som en egen innstilling. Et kurs som rapporterer gjennomføring, men viser poeng under grensen, kan derfor dukke opp i rapporten med status Feilet, og det er dokumentert, ikke oppdiktet.

Det som forsvinner når du bytter ut pakken

Nå til det denne artikkelen begynte med. Hvis en ny pakke lastes opp oppå den gamle i den samme aktiviteten, og identifikatoren til manifestelementet skiller seg fra den forrige, så slettes sporingsdataene for denne pakken i Moodle, og det står i dokumentasjonen i akkurat den formen, og der står det til og med hva du skal gjøre: forsikre deg om at identifikatoren er den samme.

Plattformen advarer om det, og på norsk lyder advarselen nesten ordrett slik: pakken ser ut til å være endret eller modifisert, og hvis pakkestrukturen er endret, kan noen brukerspor ha blitt borte under oppdateringsprosessen. Den andre advarselen er enda mer direkte og sier at sporingsdata for denne pakken vil bli slettet. Problemet er at begge vises i det øyeblikket opplastingen allerede pågår, og den som ser dem, vanligvis ikke vet om identifikatoren er endret, fordi det avgjøres av innholdsprodusentens forfatterverktøy, ikke av personen selv.

Av det følger to praktiske regler det er verdt å få på plass før første versjon leveres, og den første av dem er kravet til innholdsprodusenten om å beholde den samme identifikatoren i alle senere versjoner og bekrefte det skriftlig. Den andre er et enkelt kontrollsteg: før opplasting åpner du zip-arkivet, finner manifestfilen og sammenligner identifikatoren med den forrige, noe som tar to minutter og verner mot et tap du ikke kan reversere.

Det er også verdt å forstå hvor disse dataene i det hele tatt bor, fordi det forklarer resten og svarer på det neste spørsmålet, som vanligvis kommer med en gang. Forsøk og resultater tilhører plattformens aktivitet, ikke pakken, så sletting av aktiviteten sletter også resultatene, og å opprette en ny aktivitet for den nye versjonen betyr at de gamle fullføringsoppføringene blir værende på den gamle aktiviteten og ikke synes i den nye. Det er en brukbar løsning hvis den gamle aktiviteten skjules, og ikke slettes, men da må kursets fullføringskrav kobles om til den nye aktiviteten, ellers blir kurset plutselig ufullført for en del av folkene.

Det siste det er verdt å vite om forsøk, gjelder når plattformen i det hele tatt vil tilby å starte på nytt, fordi det ikke er brukerens valg, men atferd bestemt av standarden. I SCORM 1.2 tilbys et nytt forsøk bare hvis det forrige endte med status Fullført, Bestått eller Feilet, mens ved et ufullstendig, lest eller ennå ikke forsøkt forsøk kommer personen tilbake til det samme forsøket, og pakken uten egen intern logikk skriver rett og slett over de forrige poengene og statusen.

Rundt denne atferden har plattformen to innstillinger det er verdt å forstå før kurset settes i gang, ikke etter de første klagene. Den ene tvinger i gang et nytt forsøk, og den andre låser aktiviteten etter det siste tillatte forsøket, og selve begrensningen av antall forsøk virker bare med SCORM 1.2 og AICC, fordi 2004-versjonen har sin egen, atskilte definisjon. Det finnes også en rapportdetalj som endrer tallene: visningen av siste fullførte forsøk teller ikke med dem som endte med status Feilet, så to rapporter om det samme kurset kan ærlig vise ulike tall.

H5P er noe annet, ikke en lettere SCORM

H5P nevnes ofte i samme åndedrag som SCORM, og det gir inntrykk av at det dreier seg om to løsninger av samme type, der den ene rett og slett er lettere å bruke. Det er ikke sant, og sammenblandingen koster, fordi de to kjøpes i ulike tilfeller: H5P er en type interaktivt innhold som kjører i nettleseren og leveres som en egen fil, men det bruker verken manifest eller SCORM-grensesnittet, og derfor rapporterer det annerledes til plattformen.

Inn i Moodle kommer H5P ad tre ulike veier som ikke må blandes, fordi de oppfører seg forskjellig, og den første av dem er plattformens egen innebygde mulighet med innholdsbank og en egen aktivitet, som er vurderbar og holder styr på forsøk. Den andre er en eldre utvidelse som fortsatt er installert i mange installasjoner og for noen innholdstyper behandler vurderingen annerledes, mens den tredje er en betalt skytjeneste som kobler seg til plattformen som et eksternt verktøy, og i produsentens forum er det sagt rett ut at du kan klare deg uten den, fordi den betalte delen er egne innholdstyper og importmuligheter.

Vurderingsatferden er stedet der de ubehagelige overraskelsene oppstår, fordi i forsøksrapporten for den innebygde aktiviteten betyr kolonnen for bestått at personen fikk 100 %, mens kolonnen for fullføring bare betyr at personen gikk innholdet ut, og i dokumentasjonen står det klart at denne listen ikke er knyttet verken til aktivitetens godkjentgrense eller til aktivitetens fullføringskrav. Virksomheten som venter at H5P-resultatet selv fyller ut kursfullføringen, kan derfor oppdage at kurset formelt ikke er fullført for noen.

Det finnes også en detalj ved selve innholdstypene det er verdt å sjekke før valget, fordi ikke hver H5P-type rapporterer vurdering og fullføring likt, og det er dokumentert tilfeller der enkelte typer ikke satte fullførings- og beståttmeldinger i det hele tatt, så du må sjekke nettopp de typene du planlegger å bruke i kurset. Når det gjelder lisens, ligger programvaren under en tillatende lisens med unntak for deler av koden, men viktigere er det at selve innholdet du lager, ikke lisensieres automatisk med den, og at lisensen for det velges av opphaveren.

Kursinnholdet har egne krav til universell utforming

Spørsmålet om universell utforming stilles vanligvis om plattformen, men det meste av svaret ligger i innholdet, fordi det er der video uten teksting, bilder uten beskrivelse og interaktive oppgaver som ikke kan løses med tastatur, bor. Plattformen kan være feilfri, og kurset i den likevel ubrukelig for den som ikke ser skjermen eller ikke bruker mus.

Hvem dette er en plikt for, og ikke et valg, må svares presist, fordi det er lett og dyrt å ta feil her: for nettløsninger i offentlige virksomheter stiller forskrift om universell utforming av IKT-løsninger (IKT-forskriften) § 4b krav om at de skal være mulig å oppfatte, mulig å betjene, forståelige og robuste, med samsvar gjennom EN 301 549 og plikt til tilgjengelighetserklæring etter § 4e, og det er Norges gjennomføring av direktiv (EU) 2016/2102, som ligger i EØS-avtalen. For private virksomheter gjelder allerede § 4: nettløsninger skal minst utformes i samsvar med WCAG 2.0 på nivå A og AA, uten unntak for mikrovirksomheter. EUs tilgjengelighetsdirektiv (2019/882) er ikke gjennomført i norsk rett og trer ikke i kraft 28. juni 2025; direktivets unntak for mikrovirksomheter på tjenestesiden finnes derfor ikke her.

For internopplæring i virksomheten følger det en praktisk konsekvens som ikke krever advokat: er opplæringen ment for egne ansatte i en privat virksomhet, er det vanligvis ingen direkte plikt etter IKT-forskriften, fordi § 2 unntar IKT-løsninger som brukes ved utøvelse av arbeid; legger en kommune eller et direktorat kurset på eget intranett eller ekstranett, gjelder ikke unntaket, fordi § 4b fjerde ledd allerede gir plikt til universell utforming av slikt innhold som er publisert etter 1. februar 2023, eller som har gjennomgått en vesentlig revisjon etter den datoen, med samsvar gjennom EN 301 549 V3.2.1. Det finnes likevel en plikt til individuell tilrettelegging for den konkrete arbeidstakeren som trenger det, etter likestillings- og diskrimineringsloven, og det er et helt annet, personlig spørsmål. Selges opplæringen som en tjeneste til forbrukere på nett, eller er oppdragsgiveren en offentlig virksomhet, må kravene sjekkes grundig og før anskaffelsen, ikke etter den.

På den tekniske siden uttrykkes kravet som regel som samsvar med WCAG-retningslinjene på AA-nivå, og for innholdsprodusenten betyr det konkrete ting: teksting på video, transkripsjon av lyd, tilstrekkelig kontrast, tekstalternativer for bilder og mulighet til å utføre alt interaktivt med tastatur. Disse kravene må skrives inn i bestillingen, fordi teksting i etterkant når kurset er ferdig, betyr omarbeiding av videoen, og det koster like mye som det ville ha kostet med en gang, bare senere.

Det pakken aldri inneholder

Import av pakken oppretter én aktivitet, ikke et kurs, og dette skillet forklarer mange senere misforståelser som dukker opp nettopp i overleveringsøyeblikket. Alt i kurset som ligger rundt selve innholdet, blir værende på plattformsiden og må opprettes separat, uavhengig av hvor godt pakken er forberedt og hvor dyrt den har kostet.

Konkret finnes det ikke innmelding i pakken, altså vet den ikke og kan ikke vite hvem som har lov til å ta kurset, og den har ingen fullføringskrav for kurset, altså avgjør den ikke hva plattformen skal telle som et fullført kurs. Der finnes det ikke innstillinger for roller og rettigheter, ikke karakterbokens beregning, ikke kursbevis og ikke resten av kursinnholdet. Hvis leverandøren lover å levere et kurs, er det verdt å presisere om det dreier seg om en pakke eller om et fullt kurs i plattformen, fordi forskjellen i arbeidsomfang er stor.

Video er et eget tilfelle som nesten alltid dukker opp i denne listen, og læringsplattformer er ikke systemer for videodistribusjon, så store filer lagres vanligvis utenfor den og kurset får bare en avspiller, noe som betyr at det faktum at videoen ble sett, ikke er automatisk kjent for plattformen og først blir kjent hvis kurset gjør det om til en av de verdiene som rapporteres. Virksomheten som venter en rapport om hvor lenge hvem så, oppdager vanligvis at en slik ikke finnes, fordi ingen hadde bestilt den.

Her er det også et eierspørsmål som i dette emnet ligger nærmere enn det ser ut til: hvis en fagekspert hos deg skriver kursinnholdet, mens leverandøren bygger kurset, er utgangspunktet i åndsverkloven det samme som i ethvert oppdragsverk, og det betyr ikke at betaling i seg selv overdrar opphavsretten til oppdragsgiveren. Etter § 67 innbefatter overdragelse av eksemplar ikke overdragelse av opphavsretten, og opphaveren skal ikke anses for å ha overdratt en mer omfattende rett enn det avtalen klart gir uttrykk for. Den praktiske konklusjonen her er kort: rettighetene til kurset, som til kildeprosjektet, må skrives inn i avtalen før arbeidet starter.

Her går det også en grense mot et nabotema som denne artikkelen bevisst ikke rører, nemlig spørsmålet om hvordan du tar et helt kurs ut av én plattform og inn i en annen: det er et portabilitetsspørsmål, og det har sine egne formater og sitt eget svar, som vi har beskrevet i artikkelen om hva en læringsplattform er. Pakken er enheten for ett kurs, ikke en eksportmekanisme, og å blande de to er dyrt.

Hva du bør spørre om før kurset bestilles

Alle de foregående avsnittene leder fram til et lite sett spørsmål det er verdt å stille innholdsprodusenten før avtalen, fordi svarene etter overleveringen ikke lenger endrer noe, og det første av disse spørsmålene gjelder formatet: i hvilken standard pakken skal leveres, og om det er SCORM 1.2, tatt i betraktning at Moodle ikke støtter 2004-versjonen. Det andre gjelder identifikatoren: om identifikatoren til manifestelementet blir den samme i senere versjoner, og om det kan skrives inn i avtalen.

Det tredje spørsmålet gjelder hva kurset vil rapportere, nemlig om det vil sette status, om det vil sende poeng, om manifestet vil ha en godkjentgrense, og hva du konkret vil se i rapporten om en person som gikk gjennom materialet, men ikke besto testen. Det fjerde gjelder omfanget: hvor mye tilstandsdata kurset vil lagre, og om det får plass i standardfeltet, fordi et langt kurs med mange spørsmål når denne grensen i stillhet.

Det femte spørsmålet gjelder kildematerialet og er det som glemmes oftest: om du også får kursets kildeprosjekt, og ikke bare den ferdige pakken, fordi uten kilden kan neste endring bare gjøres av den samme produsenten med det samme forfatterverktøyet. Det er det samme spørsmålet som i ethvert oppdragsverk, og det må stilles før arbeidet starter.

Disse spørsmålene tar ikke mye tid og fornærmer ingen, fordi en profesjonell innholdsprodusent svarer på dem med en gang, men de hindrer situasjonen der virksomheten har betalt for et kurs og etter et år verken kan oppdatere det eller bevise at noen gikk gjennom det. Hvis du vil at vi tar den samtalen, eller at vi sjekker en pakke du allerede har fått, før den lastes opp, skriv til oss, så gjør vi det sammen med innføring av læringsplattform.