Captivate - LMS - Problemi di comunicazione SCORM

Question

Sto sviluppando un LMS compatibile con SCORM e ho alcuni problemi con i contenuti generati da Captivate.

Fondamentalmente, il comportamento è: Se si vede un SCO (contenuto generato accattivante) con 15 diapositive e 1 domanda in ogni diapositiva in modo rapido, il mio lm non sta monitorando tutte le 15 domande, solo i primi 3 o 4. Se si attende molto tempo alla fine, o se si prende il contenuto lentamente, funziona perfettamente.

Dopo un sacco di ricerche di Google, e il debug e la ricerca, infine, ho trovato due questioni principali:

1) Captivate - comunicazione SCORM API è asincrona (è lo stesso di flash - javascript comunicazione). Quindi, quando l'utente vede il contenuto velocemente, la funzione richiama sempre più dealay e alla fine, forse l'utente risponde alla domanda 15, e il contenuto invia le informazioni della domanda 4. Non riesco a cambiare l'interfaccia Flash o JS-Flash, perché questo è fornito da Captivate.

C'è un modo per fare questa sincronizzazione ?? Voglio dire, per forzare il flash ad aspettare in qualche modo?

2) Le funzioni impiegano più tempo ogni volta che vengono richiamate, ad esempio, setValue impiega 7 millisecondi per la prima volta e 200 viene chiamato l'ultima volta.

Per comprendere questo problema, ecco un piccolo background: Captivate i contenuti (tutti i contenuti in realtà ma più accattivanti) chiama una funzione specifica molte volte, la funzione SetValue, una delle funzioni API SCORM. Questa funzione richiede due parametri (nomeCampo, valore), il primo è il nome del campo da impostare e il secondo il nuovo valore. Nella mia implementazione, questa funzione prima convalida il valore utilizzando un'espressione regolare e quindi imposta il valore in un oggetto.

Ok, posso aggiungere molte più informazioni, ma non so cosa sia veramente importante, non spero che tu possa correggere il mio codice senza vederlo, ma sono fuori di idee e ho bisogno di nuove opinioni , le idee, le direzioni .... forse che chiedono la domanda giusta sombody ... aiuto :)

Grazie

Answer 1

Alcune Opzioni:

si potrebbe cambiare come si sta facendo le domande. Invece di 1 per frame metti tutte le domande su 1 frame.

In caso contrario, è necessario eseguire alcune magie JavaScript nel proprio JavaScript di SCORM Player. Vorrei iniziare riducendo al minimo il codice JS con uno strumento come JSMin.

Quindi provare a memorizzare nella cache i file JS in modo che vengano caricati solo una volta. Ho il sospetto che i file vengano chiamati più e più volte con ogni frame.

Answer 2

"C'è un modo per fare questa sincronizzazione, voglio dire, per forzare il flash ad aspettare in qualche modo?"

A quanto pare, il problema è questo: "Captivate è l'unico SCO che chiama le funzioni SCORM JavaScript in modo asincrono Firefox è l'unico browser che non forza comunicazioni sincrone tra la SCO e il codice JavaScript di supporto Quando un Captivate SCO,.. in esecuzione su Firefox, invia un aggiornamento di stato a una delle funzioni JS, Captivate non attende una risposta positiva o negativa prima di inviare il successivo aggiornamento di stato.Da Captivate è piuttosto prolisso nelle sue comunicazioni e JavaScript non è multithreaded impilare e sovrascrivere l'un l'altro. Ciò può causare una perdita di dati, specialmente per quiz più lunghi.]

Se desideri vedere il problema asincrono con qualsiasi altro LMS, fai un quiz Captivate lungo usando Firefox e rispondi rapidamente alle domande . Alcune delle domande vicino alla fine andranno sceso .. "(interzoic.com forum)

E forse un solution: " La questione lenta viene risolto quando forzo il g_intAPIType a 0 (nel file htm) , quindi forza Captivate a comunicare come se fosse in IE. "

Answer 3

Quando si esegue la pubblicazione per SCORM, Captivate non utilizza metodi di comunicazione sincrona. * A seconda del browser, Captivate utilizza FSCommand o il metodo old school getURL per comunicare con il file HTML, il file HTML utilizza quindi JavaScript per inoltrare i dati all'LMS tramite l'API SCORM.

La risposta (se presente) viene inoltrata da JavaScript a FSCommand oa un proxy SWF (per getURL), che viene quindi monitorata internamente in Captivate tramite una funzione di richiamata. Questa funzione di callback utilizza i timer, e probabilmente si tratta del tuo problema.

Se si imposta g_intAPIType su 0, si sta forzando il browser a utilizzare FSCommand, che non è supportato in tutti i browser e sistemi operativi. Impostare g_intAPIType su 1 significa che stai forzando il browser a utilizzare getURL, che è cross-browser ma presenta alcuni svantaggi (inclusi molti clic su suoni).

In entrambi i casi, i dati vengono inviati tramite uno script di coda interno, che utilizza la funzione di richiamata waitForResponse.

I problemi di prestazioni che si verificano sono probabilmente dovuti all'accodamento e la comunicazione asincrona aggrava il problema a causa dei timer collegati a waitForResponse. La modifica di g_intAPIType probabilmente avrà solo un piccolo effetto sui problemi di prestazioni, sebbene l'utilizzo di getURL (g_intAPIType=1) possa contribuire a migliorare la coerenza dal browser al browser.

A prescindere dalle impostazioni g_intAPIType, non è possibile impedire al meccanismo di localizzazione interno di utilizzare la funzione asincrona waitForResponse, quindi non è possibile arrestare Captivate dall'utilizzo dei timer durante l'acquisizione/impostazione dei dati; in un periodo di tempo probabilmente inizierai a notare ritardi sempre più lunghi come quelli che hai descritto, esp. se stai facendo molte chiamate al LMS.

(* piccola eccezione: Sono stato informato Captivate 4 e 5 l'uso ExternalInterface se il progetto è costruito in AS3 e viene pubblicato per SCORM 2004, ma sembra la coda e waitForResponse timer sono ancora utilizzati, in pratica trattando ExternalInterface come i metodi asincroni elencati sopra.)

Answer 4

In modo accattivante, durante la pubblicazione di uno scorm vedrete l'opzione "Invia dati di tracciamento alla fine", Utilizzare questa opzione per risolvere il problema.