Una richiesta che mi è stata fatta recentemente è la possibilità di sbloccare elementi di uno SCORM sulla base di ciò che succede in altri moduli o in altri corsi.
Mi spiego meglio entrando nel merito della richiesta.
Si tratta di un modulo di Onboarding pensato in un’ottica di gamification, dove l’utente che supera tutti i passaggi ottiene un premio finale.
Alcuni di questi passaggi non sono però interni al modulo di Onboarding, si tratta infatti dei corsi obbligatori (nella fattispecie GDPR e 231) già presenti in piattaforma e gestiti da un dipartimento differente.
La piattaforma LMS, in questo caso proprietaria, non ha enormi potenzialità rispetto alla gestione di visibilità e condizioni per l’accesso dei singoli contenuti, di conseguenza l’unica possibilità era trovare un modo di far dialogare i contenuti fra loro, sfruttando le potenzialità di Storyline.
Abbiamo trovato 2 possibili soluzioni. In questo articolo vi propongo la più semplice, ma anche quella più facilmente manipolabile dall’utente (il secondo metodo lo trovi qui).
Il concetto chiave è che il link di accesso al modulo di Onboarding possa fornire allo SCORM l’informazione necessaria a sbloccare il passaggio, inserendo un parametro nell’url.
I corsi obbligatori, avranno quindi come ultimo passaggio, dopo il completamento del corso, un link verso il modulo di Onboarding, il cui url avrà un determinato parametro.
(consiglio il seguente articolo per: un approfondimento sui parametri dell’url)
Nel modulo di Onboarding dovrà quindi esserci un Trigger che andrà a leggere il parametro dell’url e, se quest’ultimo soddisfa una determinata condizione, sbloccherà il relativo passaggio.
Ecco qui un esempio:
- Accedendo allo SCORM dal seguente link si può notare come il bottone sia bloccato
https://www.nicolalombardelli.it/esempi/manipolare-variabili-scorm-tramite-parametri-url-con-storyline-e-javascrip/story.html - Accedendo da questo link, il bottone risulta invece attivo
https://www.nicolalombardelli.it/esempi/manipolare-variabili-scorm-tramite-parametri-url-con-storyline-e-javascrip/story.html?parametro=a
(Nota che è stato aggiunto in coda all’url: ?parametro=a) - Provando ora a riaccedere dal link al punto 1, si può notare che l’elemento risulta comunque attivo, in quanto è stato sbloccato grazie all’accesso dal link al punto 2. Ovviamente all’apertura dello SCORM bisogna scegliere “Resume” poiché scegliendo “Restart” anche le variabili tornano allo stato iniziale (in fase di pubblicazione è comunque possibile bypassare questo passaggio all’utente, impostando “Resume” di default).
Ma come può lo SCORM leggere l’url?
Con Storyline è possibile leggere l’url mediante poche righe di Javascript. Righe che sono assolutamente comprensibili anche per chi come me non è esperto di questo linguaggio.
(consiglio il seguente video per: un’introduzione all’uso di Javascript in Storyline)
L’esempio molto semplice che abbiamo appena visto è formato da 3 slide, ovvero la prima slide, la seconda slide e una slide invisibile di sblocco.
Il bottone inserito nella prima slide è impostato sullo stato iniziale di disabilitato.
Abbiamo quindi impostato 2 variabili di tipo testuale: la prima è parametro dove andremo ad inserire il valore letto dall’url e la seconda è sblocca che sarà la variabile che andrà effettivamente a determinare lo sblocco del bottone.
Nella seguente immagine vediamo i trigger della prima slide:
Andiamo prima di tutto ad eseguire Javascript. Lo script è il seguente:
var queryString = window.parent.location.search;
var urlParams = new URLSearchParams(queryString);
var parametroJs = urlParams.get('parametro')
let player = GetPlayer();
player.SetVar("parametro", parametroJs)
Le prime tre righe servono di fatto a e leggere il valore del parametro nell’url (che con grande fantasia ho chiamato… parametro) inserendolo nella variabile di Javascript denominata parametroJs.
Le ultime due righe servono ad inserire il valore della variabile parametroJs nella variabile di Storyline parametro. Nell’ultima riga infatti, la voce “parametro” tra virgolette è di fatto la variabile parametro che abbiamo precedentemente impostato in Storyline.
Poi vediamo il cambio ti stato del bottone, dallo stato di inattivo impostato di come stato iniziale allo stato normale. Ciò avviene all’avvio della slide se la variabile sblocca ha come valore a.
Poi vediamo che c’è un salto verso la slide sblocca, nel momento in cui la variabile parametro cambia di valore, a condizione che il valore sia a. Di fatto, la combiazione tra Javascript e questo Trigger, dice testualmente: se nell’url è presente la stringa parametro=a salta alla slide sblocca.
Questo passaggio è necessario, in quanto non è sufficiente controllare il valore della variabile parametro al fine di attivare il bottone, sebbene in un primo momento pensavo bastasse questo controllo. Questo perché il valore della variabile parametro non viene modificato nel contesto del player Storyline, ma in Javascript, che è come se fosse (passatemi il termine) un’entità esterna al player. Il valore della variabile parametro non viene quindi memorizzato, e al prossimo accesso la variabile avrà ancora valore nullo, mantenendo quindi il bottone ancora disattivato. E’ necessario quindi compiere un azione che valorizzi una variabile nel contesto del player, in modo che il suo valore rimanga memorizzato anche al prossimo accesso.
Io ho quindi optato per il salto alla slide sblocca, che al suo interno non ha alcun contenuto ma, come possiamo vedere nella seguente immagine, ha 2 Trigger. Il primo modifica il valore della variabile sblocca in a, valore che a questo punto rimarrà memorizzato, in quanto la modifica è avvenuta nel contesto del player. Il secondo Trigger riporta subito alla prima slide.
A questo punto, nella prima slide sarà soddisfatta la condizione che permette di sbloccare il bottone. Quest’ultimo sarà quindi cliccabile e io posso proseguire la navigazione.
Un ultima nota, il Trigger che esegue Javascript è condizionato al fatto che la variabile sblocca non sia valorizzata. In questo modo, una volta avvenuto lo sblocco, l’esecuzione di Javascript viene interrotta. Non so bene la causa, ma senza questa condizione diventava molto lento il passaggio tra una slide e l’altra quando rieffettuavo l’accesso tramite link senza parametro.
Ho trovato questo metodo molto più semplice da fare che da spiegare. Come dicevo però all’inizio, il rischio è che possa essere facilmente aggirabile dall’utente più smart.
Nel momento in cui capisce il gioco, può tranquillamente accedere al modulo utilizzando un link con il parametro giusto, o passarlo ai colleghi per sbloccare i contenuti senza realmente aver completato le azioni richieste.
Un suggerimento può essere quello di utilizzare parametri e valori non troppo “parlanti” magari utilizzando dei codici alfanumerici complessi, per non far comprendere il meccanismo. Si tratta comunque di un rischio limitato, in quanto (almeno per il mio caso) andrebbe a sbloccare semplicemente degli elementi di “gioco” nel modulo di Onboarding, ma non andrebbe ad influenzare minimamente lo stato di frequenza dei corsi obbligatori a monte.