Hur en e-learningkurs blir till: verktyg, SCORM och vad som når plattformen

Kursen är klar, den är betald, och den kommer som en enda zip-fil med ett versionsnummer i namnet; någon laddar upp den på plattformen, trycker på spara, och nästa dag visar det sig att hundratjugo personers slutförande har försvunnit, trots att ingen har raderat något. Det är ingen myt och det är inte ovanligt, och plattformen varnade till och med för det, bara att varningen syntes en halv sekund innan knappen redan var tryckt, och där stod något som ingen just då förstod.

Den här artikeln handlar om vägen från material till paket och om vad plattformen som tar emot paketet gör med det, för det är just i den här överlämningen som två sidor möts som vanligtvis inte ser varandras arbete. Vad ett learning management system är, och när ett företag över huvud taget behöver ett, har vi skrivit om separat, liksom om hur du väljer en lärplattform. Här handlar det om steget efter valet: kursen blir till utanför plattformen, paketeras och kommer sedan in, och det är just i den övergången som nästan alla de problem uppstår som senare ser ut som fel i plattformen.

En sak skiljer det här ämnet från de flesta andra: nästan alla problem här är dokumenterade, namngivna och beskrivna offentligt, så de behöver inte upptäckas med egna pengar. Plattformens dokumentation innehåller både varningarna, orsakerna och åtgärderna, och det enda som vanligtvis saknas är en människa som läser dem före beställningen, inte efter det första missödet.

Vad paketet innehåller och vad plattformen gör med det

Ett SCORM-paket är ett zip-arkiv med en fil som heter imsmanifest.xml i roten, och det är just den filen som gör paketet till ett paket och inte till en mapp med filer. Manifestet beskriver kursens struktur, räknar upp lärobjekten och anger vilka filer som hör till dem, därför läser plattformen det först och får därifrån veta vad den ska visa och i vilken ordning.

Därefter är uppdelningen enklare än man vanligtvis tror, och den är värd att säga direkt eftersom den förklarar nästan allt annat, nämligen att plattformen visar paketet och sparar data om vad personen gjorde i det, men själva innehållet skapar den inte och den griper inte in i det. Moodles dokumentation säger det rakt ut: systemet presenterar paketet och sparar interaktionsdata från lärandet, men genererar inte SCORM-innehåll självt. Därför är allt som händer inne i skärmen innehållsproducentens arbete, och allt som händer runt omkring är plattformens arbete.

Förbindelsen mellan de två går genom en smal kanal, där lärobjektet anropar plattformens gränssnitt med kommandon som initiera, sätta ett värde, spara och avsluta, och genom vilken ett fåtal värden går: status, poäng, tid, svar på frågor och ett litet textfält för att spara tillståndet. Den kanalen är det viktigaste elementet i hela ämnet, för allt du senare vill se i en rapport måste skickas ut just genom den, och det som inte ryms där kommer aldrig fram till rapporten.

Det plattformen sparar är en konkret och begränsad lista, knuten till ett försök i en viss aktivitet: status, den poäng som uppnåtts tillsammans med minimum och maximum, tid som har lagts ner, svar på enskilda frågor och tillståndsfältet som redan nämnts. Där finns varken personens namn inne i kursen, eller hur många gånger hen spolade tillbaka en video, eller vilka sidor hen hoppade över, såvida inte kursen själv har gjort om de fakta till något av de uppräknade värdena.

Felen som uppstår i den övergången är också kända och dokumenterade, så de behöver inte upptäckas på nytt, och det vanligaste av dem är att manifestet saknas eller ligger på fel ställe i arkivet, för det måste ligga just i roten, inte i en undermapp, medan det andra är identifierare som inte är unika, vilket i ärendesystemet är ett eget ärende. Till äldre kurser kommer visningsproblem på mobila enheter, när innehållet har lagts i en ram med fast storlek, och även de har egna ärendenummer, så leverantören kan frågas om dem direkt.

Därför är den första frågan till innehållsproducenten inte vilket författarverktyg kursen ska byggas med, utan i vilket format den ska lämnas ut och vad den exakt kommer att rapportera. Två kurser som ser likadana ut på skärmen kan rapportera helt olika, och skillnaden blir synlig först när någon behöver ett bevis för att personen verkligen gick kursen.

Fyra förkortningar som inte är samma sak

Orden SCORM, xAPI, cmi5 och AICC används på marknaden som om de vore utbytbara, men de betecknar olika saker och har olika förvaltare. SCORM är ett paketformat tillsammans med en körningsmiljö, och den sista versionen är 2004 års fjärde utgåva, som kom 2009; någon nyare utgåva finns inte och väntas inte heller.

Organisationen som skapade SCORM har upphört med sin verksamhet, och i dess kodförråd står nu ett meddelande om arkivering, men av det får man inte dra slutsatsen att standarden har lämnats utan förvaltare, för datamodellen för SCORM:s körningsmiljö förvaltas av Institute of Electrical and Electronics Engineers, IEEE, som standard 1484.11.1, vars senaste utgåva är från 2022, och bredvid den står 1484.11.2 om gränssnittet. Samtidigt är en vilseledande detalj värd att känna till: på organisationens förrådssida är namnet skrivet som Advanced Digital Learning, fast det historiska namnet är Advanced Distributed Learning.

xAPI (Experience API) är något annat, nämligen inte ett paketformat utan en utsagnsmodell och ett gränssnitt genom vilket ett system skickar poster om vad personen gjorde till ett separat LRS (learning record store). Sedan 2023 är det en publicerad standard med nummer 9274.1.1, och samma text finns också som internationell standard, så det handlar om en sak med två nummer, inte om två versioner.

Det fjärde namnet är cmi5, och det är en cmi5-profil för xAPI just för start från en lärplattform, inte ytterligare en fristående standard; den gällande utgåvan av den profilen är från 2016, och den internationella standardiseringen pågår men är inte avslutad, så det rätta är att säga att arbetet är godkänt som projekt, inte att standarden redan finns. AICC, Aviation Industry Computer-Based Training Committee, är den äldsta av dem, och kommittén som förvaltade den upplöstes i december 2014 och lämnade vidare cmi5 och sitt arkiv.

Gränsen du behöver känna till innan du beställer kursen

Här är ett av de praktiskt viktigaste fakta i hela artikeln, och det överraskar nästan var och en som hör det första gången: Moodle stöder SCORM 1.2 och AICC, men inte SCORM 2004, och det är varken ett missförstånd eller slarv utan ett medvetet val, inskrivet i plattformens egen dokumentation och inte dolt där. Där anges att 1.2 klarar alla tester i överensstämmelsepaketet, medan av 2004-versionen bara vissa grundläggande delar av gränssnittet är genomförda, så en del paket kan se ut att fungera även om full överensstämmelse saknas.

Den gränsen är viktig därför att innehållsproducenter ofta erbjuder just 2004-versionen som den nyaste och bästa, och formellt är den det också, för den har två skilda statusfält och en skalad poäng. För en köpare som ska arbeta med Moodle visar sig den nyaste versionen likväl vara det sämre valet, och det är ett av de få tillfällen då en äldre utgåva av en standard är det rätta svaret, inte en eftergift åt omständigheterna.

Sedan följer en mening som är värd att läsa två gånger, för den avgör hur man ska agera vidare: arbetet med stöd för SCORM 2004 är stoppat, och felrapporter om det stängs som sådana som inte kommer att åtgärdas. Det betyder att en del 2004-paket kan se ut att fungera, men det går inte att lita på, och ingen kommer att åtgärda dem om de slutar fungera, medan den certifierade vägen, om 2004-versionen är obligatorisk, går via en kommersiell extern tjänst med en egen tilläggsmodul.

Den praktiska ordningen av det är enkel: innan kursen beställs ska innehållsproducenten få veta i vilket format paketet behövs, och i de flesta fall blir svaret SCORM 1.2. Om producenten bara erbjuder 2004-versionen är det inte automatiskt dåligt, men det ändrar valet av plattform eller kräver en extra komponent, och den här dialogen ska tas före arbetet, inte på överlämningsdagen. För cmi5 behöver du veta att Moodle inte har det som standard och att det krävs en separat tilläggsmodul, plus ett separat LRS.

Ett fält som ska rymma allting

SCORM 1.2 känner ett enda statusfält, och där kan det stå ett av sex värden, som i Moodles svenska gränssnitt syns som Godkänd, Slutfört, Misslyckades, Ofullständig, Visat och Ej försökt. Det betyder att man inte samtidigt kan rapportera att personen gick kursen till slutet och att hen inte klarade testet, för de två sakerna slåss om samma fält, och för ett företag som just behöver den skillnaden är det en verklig begränsning, inte en teknisk detalj.

SCORM 2004 löser problemet genom att dela statusen i två oberoende fält, där det ena talar om genomgången och det andra om resultatet, och genom att lägga till en skalad poäng; det är just därför en del innehållsproducenter erbjuder den. Men eftersom Moodle inte stöder 2004-versionen är den lösningen inte tillgänglig för de flesta läsare, och man får planera för att det i stället för en kurs kan behövas två aktiviteter: en för genomgången av materialet, en för examinationen.

Den andra begränsningen är ännu konkretare: fältet där lärobjektet sparar sitt inre tillstånd, så att personen kan fortsätta från samma ställe, rymmer i SCORM 1.2 fyra tusen nittiosex tecken, och den gränsen står också i Moodles datamodellfil. För en lång kurs med många frågor är det knappt, och när gränsen är nådd slutar tillståndet helt enkelt att sparas, så personen hamnar tillbaka i början av kursen, och det ser ut som ett fel i plattformen, men det är en gräns i standarden.

Den tredje begränsningen är en som kan vända en genomgången kurs till en misslyckad utan att någon människa är med: om det i manifestet anges en skicklighetspoäng är plattformen enligt överensstämmelsekraven skyldig att räkna om statusen mot den poäng som uppnåtts, och Moodle erbjuder till och med det beteendet som en egen inställning, Skicklighetspoäng åsidosätter status. En kurs som rapporterar genomgång men visar poäng under tröskeln kan därför dyka upp i rapporten med statusen Misslyckades, och det är dokumenterat, inte påhittat.

Vad som försvinner när paketet byts ut

Nu till det artikeln började med. Om ett nytt paket laddas upp ovanpå det gamla i samma aktivitet och identifieraren för elementet i manifestet skiljer sig från den föregående, raderas spårningsdata för det paketet i Moodle, och det står i dokumentationen i just den formen; där står till och med vad man ska göra: se till att identifieraren är densamma.

Plattformen varnar för det, och på svenska lyder varningen nästan ordagrant så här: ”Paketet verkar ha blivit ändrat eller modifierat. Om strukturen på paketet har ändrats så kan vissa användares spår komma att gå förlorade under uppdateringsprocessen.” Den andra varningen är ännu rakare och säger: ”VARNING: spårningsdata till detta SCORM-paket kommer att försvinna!” Problemet är att båda visas i det ögonblick då uppladdningen redan pågår, och den som ser dem vet vanligtvis inte om identifieraren har ändrats, för det avgörs av innehållsproducentens författarverktyg, inte av hen själv.

Av det följer två praktiska regler som är värda att sätta innan den första versionen lämnas över, och den första av dem är ett krav på innehållsproducenten att behålla samma identifierare i alla senare versioner och bekräfta det skriftligt. Den andra är ett enkelt kontrollsteg: före uppladdningen öppna zip-arkivet, hitta manifestfilen och jämför identifieraren med den föregående, vilket tar två minuter och skyddar mot en förlust som inte går att ångra.

Var de här uppgifterna över huvud taget bor förklarar resten och svarar på nästa fråga, som vanligtvis kommer direkt. Försök och resultat tillhör plattformens aktivitet, inte paketet, så om aktiviteten raderas raderas också resultaten, och att skapa en ny aktivitet för den nya versionen betyder att de gamla slutförandena stannar vid den gamla aktiviteten och inte syns i den nya. Det är en användbar lösning om den gamla aktiviteten döljs i stället för att raderas, men då måste kursens slutförandevillkor kopplas om till den nya aktiviteten, annars blir kursen plötsligt oavslutad för en del personer.

Det sista som är värt att veta om försök gäller när plattformen över huvud taget erbjuder att börja om, för det är inte användarens val utan ett beteende som standarden slår fast. I SCORM 1.2 erbjuds ett nytt försök bara om det föregående slutade med statusen Slutfört, Godkänd eller Misslyckades, medan ett Ofullständigt, Visat eller ännu inte påbörjat försök skickar personen tillbaka till samma försök, och ett paket utan egen inre logik skriver helt enkelt över de tidigare poängen och statusen.

Runt det beteendet har plattformen två inställningar som är värda att förstå innan kursen släpps, inte efter de första klagomålen. Den ena tvingar fram ett nytt försök och heter Tvinga nytt försök, och den andra låser aktiviteten efter det sista tillåtna försöket och heter Lås efter det sista försöket; själva begränsningen av antalet försök fungerar bara med SCORM 1.2 och AICC, för 2004-versionen har en egen separat definition. Det finns också en rapporteringsfinhet som ändrar siffrorna: värdet för det senast slutförda försöket räknar inte in dem som slutade med statusen Misslyckades, så två rapporter om samma kurs kan ärligt visa olika tal.

H5P är något annat, inte ett enklare SCORM

H5P, kort för HTML5-paket, nämns ofta i samma andetag som SCORM, och det ger intrycket att det handlar om två lösningar av samma slag, där den ena bara är enklare att använda. Så är det inte, och sammanblandningen kostar, för de två köps i olika fall: H5P är en typ av interaktivt innehåll som körs i webbläsaren och lämnas över som en separat fil, men det använder varken manifest eller SCORM-gränssnittet, och därför rapporterar det till plattformen på ett annat sätt.

Till Moodle kommer H5P längs tre olika vägar, som inte får blandas ihop för de beter sig olika, och den första av dem är plattformens egen inbyggda möjlighet med innehållsbank och en separat aktivitet som är bedömningsbar och håller försök. Den andra är en äldre tilläggsmodul, som fortfarande är installerad i många installationer och för vissa innehållstyper hanterar betyget annorlunda, medan den tredje är en betald molntjänst som kopplas till plattformen som ett externt verktyg, och på tillverkarens forum sägs rakt ut att man klarar sig utan den, för den betalda delen är extra innehållstyper och importmöjligheter.

Betygsbeteendet är stället där obehagliga överraskningar uppstår, för i den inbyggda aktivitetens försöksrapport betyder kolumnen för godkänt att personen fick 100 %, medan kolumnen för slutförande bara betyder att hen gick igenom innehållet till slutet, och dokumentationen anger tydligt att den rapporten inte är kopplad vare sig till aktivitetens betygsgräns för godkänt eller till aktivitetens slutförandevillkor. Ett företag som väntar sig att H5P-resultatet självt ska fylla i kursens slutförande kan därför upptäcka att kursen formellt inte är slutförd för någon.

Det finns också en detalj om själva innehållstyperna som är värd att kontrollera före valet, för inte varje H5P-typ rapporterar betyg och slutförande på samma sätt, och det finns dokumenterade fall där enskilda typer inte satte slutförande- och godkännandeposter alls, så just de typer som ska användas i kursen måste kontrolleras. Licensmässigt ligger programvaran under en permissiv licens med undantag för en del av koden, men viktigare är att själva innehållet du skapar inte licensieras automatiskt med den, och dess licens väljs av upphovsmannen.

Kursinnehållet har egna tillgänglighetskrav

Frågan om tillgänglighet ställs vanligtvis om plattformen, men merparten av svaret ligger i innehållet, för det är där videor utan undertext, bilder utan beskrivning och interaktiva uppgifter som inte går att genomföra med tangentbordet bor. Plattformen kan vara oklanderlig, och kursen på den kan ändå vara oanvändbar för en person som inte ser skärmen eller inte använder mus.

Vem som har en skyldighet, och inte bara ett val, måste besvaras precist, för här är det lätt och dyrt att ta fel: för digital service som tillhandahålls av en offentlig aktör sätter lagen (2018:1937) om tillgänglighet till digital offentlig service kraven, och den genomför Europaparlamentets och rådets direktiv (EU) 2016/2102. För vissa privata tjänster, däribland e-handelstjänster, gäller från den 28 juni 2025 lagen (2023:254) om vissa produkters och tjänsters tillgänglighet. Det betyder inte att varje företags webbplats från det datumet måste uppfylla ett tillgänglighetskrav, för lagens tillämpningsområde är avgränsat till angivna produkt- och tjänstetyper, och 10 § undantar tjänster som tillhandahålls av mikroföretag.

För företagets interna utbildning följer av det en praktisk slutsats som inte kräver en jurist: om utbildningen är avsedd för de egna medarbetarna finns det vanligtvis ingen direkt skyldighet enligt de två lagarna, men det finns en skyldighet att göra skäliga anpassningar för en enskild medarbetare som behöver det, och det är en helt annan, personlig fråga som hör hemma i diskrimineringsrätten. Om utbildningen säljs som tjänst till konsumenter på nätet, eller om beställaren är en offentlig aktör, ska kraven kontrolleras på allvar och före upphandlingen, inte efter den.

På den tekniska sidan tar kravet vanligtvis formen av överensstämmelse med WCAG-riktlinjerna på AA-nivå, och för innehållsproducenten betyder det konkreta saker: undertext på video, transkription av ljud, tillräcklig kontrast, textalternativ till bilder och möjlighet att genomföra allt interaktivt med tangentbordet. De kraven ska skrivas in i beställningen, för att lägga till undertext efter att kursen är färdig betyder att videon måste göras om, och det kostar lika mycket som det hade kostat på en gång, bara senare.

Vad paketet aldrig innehåller

Importen av ett paket skapar en aktivitet, inte en kurs, och den skillnaden förklarar många senare missförstånd som dyker upp just vid överlämningen. Allt i kursen som sitter runt själva innehållet stannar på plattformens sida och måste skapas separat, oberoende av hur väl paketet är förberett och hur dyrt det har kostat.

Konkret finns det ingen inskrivning i paketet, så det vet inte och kan inte veta vem som får gå kursen, och där finns inga slutförandevillkor för kursen, så det avgör inte vad plattformen ska räkna som en slutförd kurs. Där finns inga inställningar för roller och rättigheter, ingen beräkning i betygsboken, inga intyg och inget av det övriga kursinnehållet. Om leverantören lovar att lämna över en kurs är det värt att precisera om det gäller ett paket eller en full kurs på plattformen, för skillnaden i arbetsmängd är stor.

Video är ett separat fall som nästan alltid dyker upp på den här listan, och lärplattformar är inte system för videodistribution, så stora filer ligger vanligtvis utanför dem och kursen innehåller bara en spelare, vilket betyder att det inte är automatiskt känt för plattformen att videon sågs och blir känt bara om kursen gör om det till något av de värden som rapporteras. Ett företag som väntar sig en rapport om hur länge var och en tittade upptäcker vanligtvis att någon sådan inte finns, för ingen hade beställt den.

Det finns också en ägarfråga som ligger närmare det här ämnet än det ser ut: om kursinnehållet skrivs av din ämnesexpert men kursen byggs av en leverantör, är upphovsrättens utgångspunkt densamma som vid varje beställt verk, och den innebär inte att betalningen i sig överlåter de ekonomiska rättigheterna till beställaren. 27 § lagen (1960:729) om upphovsrätt till litterära och konstnärliga verk säger att överlåtelse av exemplar inte omfattar överlåtelse av upphovsrätt, och den praktiska slutsatsen här är kort: rätten till kursen, liksom till källprojektet, ska skrivas in i avtalet innan arbetet börjar.

Här går också en gräns mot ett grannämne som den här artikeln medvetet inte rör, nämligen frågan om hur hela kursen tas ut ur en plattform och in i en annan, som är en portabilitetsfråga, och den har sina egna format och sitt eget svar, som vi har beskrivit i artikeln om vad ett learning management system är. Paketet är en enhet för en kurs, inte en exportmekanism, och att blanda de två är dyrt.

Vad du ska fråga innan kursen beställs

Alla föregående avsnitt leder fram till en liten uppsättning frågor som är värda att ställa till innehållsproducenten före avtalet, för efter överlämningen ändrar svaren inte längre något, och den första av de frågorna gäller formatet: i vilken standard paketet kommer att lämnas ut och om det är SCORM 1.2, med tanke på att Moodle inte stöder 2004-versionen. Den andra gäller identifieraren: om identifieraren för elementet i manifestet kommer att förbli densamma i senare versioner, och om det kan skrivas in i avtalet.

Den tredje frågan gäller vad kursen kommer att rapportera, nämligen om den sätter en status, om den lämnar poäng, om det kommer att finnas en skicklighetspoäng i manifestet och vad du exakt kommer att se i rapporten om en person som gick igenom materialet men inte klarade testet. Den fjärde gäller volymen: hur mycket tillståndsdata kursen lagrar och om det ryms i standardfältet, för en lång kurs med många frågor når den gränsen tyst.

Den femte frågan gäller källmaterialet och är den som glöms oftast: om du också får kursens källprojekt, inte bara det färdiga paketet, för utan källan kan nästa ändring bara göras av samma producent med samma författarverktyg. Det är samma fråga som i varje beställt arbete, och den ska ställas innan arbetet börjar.

De här frågorna tar inte mycket tid och sårar ingen, för en professionell innehållsproducent svarar på dem genast, men de hindrar en situation där företaget har betalat för en kurs och ett år senare varken kan uppdatera den eller bevisa att någon gick den. Vill du att vi tar den här dialogen, eller att vi granskar ett paket som redan har kommit in innan det laddas upp, skriv till oss, så gör vi det tillsammans med införandet av en lärplattform.