Then, if the course works properly there, it may be an issue with your LMS or how the course was set up in it or something else in your environment. If not, then we probably need to look at the course.
Use the published Storyline output in the SCORM version you have now in the LMS and import into the SCORM Cloud (usually as a zip). After testing in the SCORM Cloud, it will tell you how the test went and if there are any SCORM issues.
Scroll down to section 5 on reporting and tracking option preferences. As a heads up, we will only report a score to the LMS if you have a results slide in your project,.
As a heads up, fiddler will only show you what is passed from the LMS back to the server, but not between the content and the LMS, in the SCORM world. So if we are sending something to the LMS, and the LMS barfs on it, they likely won't send it to the server, so you won't see what was sent by the content.
Fiddler, HTTP Analyzer, HTTP Watch are all good options for checking out AICC reporting, but not perfect for SCORM Reporting. Since SCORM communication usually just happens within an iFrame via JavaScript we aren't communicating directly with the server, we just communicate via JS to the API in the iFrame and we don't directly send anything to the server, the iFramed window does that, which is controlled by the LMS. So the only data you should see using those tools when debugging SCORM content is information that is sent from the LMS iFrame back to the server, and at that point the information has been handled and processed by the LMS parent window.
Have you folks ever thought of providing something more user-friendly for debugging and helping average users view and interpret content-LMS communication real-time? Maybe even optionally generate a log that you folks could use to send to you folks for support issues when needed?
SCORM and AICC commands, as well as HTTP responses, are not very intuitive sometimes. The SCORM debugging output can be bewildering to some. Heck, I'm challenged. Too much time just using AICC.
Seems to me there's possibly an opportunity here. I know IT departments and the more technically-skilled developers needing to debug issues would probably appreciate it.
Maybe even an easier way to turn on debug mode. Maybe a built-in "double-secret probation" feature that can turn debug mode on and off without needing to edit a JS file and re-publish.
Besides you folks creating tools that are easy to use in to develop e-learning content, something that is easy to use and understand when investigating issues would be TREMENDOUS.
Since you changed the naming convention for publishing objects in Storyline, if the tool could help developers understand things there would also be created--especially since the days of slide1.swf, slide2.swf, etc. are behind us,
Not the type of glamor feature that wins some developers over to Storyline but something that's very needed, IMVHO in the LMS/authoring tools world.
Hey, you folks can help lead and set a new standard here for tools. Again, IT departments would probably love you, especially if their approval is needed when purchasing software tools or when deciding what software tools are supported in an organization. Something like "we make things easier for your developers, your learners, and your IT department with e-learning."
Just brainstorming but it makes business and technical sense to little moi . . .
14 Replies
Hi! Just curious--What LMS are you using?
In the Storyline KB, there's no article that says all that gets sent to the LMS with SCORM--but there is one on what quiz data gets sent: http://www.articulate.com/support/kb_article.php?product=st1&id=79nsl3hhgneg
When troubleshooting, it's always best to know where to start--the course itself or the LMS or other factors (e.g., network, the user's PC, etc.).
I'd do this first--test your course outside of your LMS, either via this: http://www.articulate.com/support/kb_article.php?product=st1&id=lnl8fk5cr7h1 -- or by getting a free account at the SCORM Cloud and testing your course there. I've used the SCORM Cloud with great success.
Then, if the course works properly there, it may be an issue with your LMS or how the course was set up in it or something else in your environment. If not, then we probably need to look at the course.
Also, do you use IE9 as your browser?
If so, looks like it has some possible issues: http://www.articulate.com/support/kb_article.php?product=st1&id=v3ouhz5wq5rm
Hi
Thanks !!
My clinet owns the LMS, he sent me the rejections... I am checking what kind of LMS is this....
I use google chrome.
few questions:
Thanks again,
Maya
Hi!
Not sure all the differences between the different versions of SCORM, but here's a start:
http://en.wikipedia.org/wiki/Scorm
http://scorm.com/scorm-explained/business-of-scorm/scorm-versions/
Use the published Storyline output in the SCORM version you have now in the LMS and import into the SCORM Cloud (usually as a zip). After testing in the SCORM Cloud, it will tell you how the test went and if there are any SCORM issues.
Hi Maya,
We will pass Time spent, Last location, Exit status, Score status to the LMS in SCORM 1.2, but it could be that the LMS isn't accepting them.
You might want to pass this info on to your LMS guy:
Articulate Storyline will send the data for those fields via the following:
1. Time spent - is sent via cmi.core.session_time.
2. Last location - is sent via cmi.suspend_data
3. Exit status - is sent via cmi.core.exit
4. Score status - is sent via cmi.core.score.raw which will send over the score, and cmi.core.lesson_status which will send the status.
If you want to see exactly the data that is sent, you can check it out by enabling LMS Debug mode in the content. Here is how you do that:
http://www.articulate.com/support/kb_article.php?product=ap9&id=zpn7ehj39gqe
(the instructions are for Presenter, but will be the same for Storyline).
This might be helpful for your LMS vendor to see why he isn't picking up the values that we are sending.
Also, this might be helpful to you as well:
http://community.articulate.com/tutorials/products/publishing-a-project-for-lms.aspx
Scroll down to section 5 on reporting and tracking option preferences. As a heads up, we will only report a score to the LMS if you have a results slide in your project,.
Hope this helps!
-Dave
and may I suggest fiddler (http://fiddler2.com/fiddler2/) so you can see the traffic being passed to the LMS.
Hey Dave,
As a heads up, fiddler will only show you what is passed from the LMS back to the server, but not between the content and the LMS, in the SCORM world. So if we are sending something to the LMS, and the LMS barfs on it, they likely won't send it to the server, so you won't see what was sent by the content.
For AICC it will work great though.
-Dave
Thank you!!!
I sent the LMS guy this useful information, hope it will help.
Maya
Hey, Dave! HTTP Watch and HTTP Analyzer are still okay, right?
Hey Gerry,
Fiddler, HTTP Analyzer, HTTP Watch are all good options for checking out AICC reporting, but not perfect for SCORM Reporting. Since SCORM communication usually just happens within an iFrame via JavaScript we aren't communicating directly with the server, we just communicate via JS to the API in the iFrame and we don't directly send anything to the server, the iFramed window does that, which is controlled by the LMS. So the only data you should see using those tools when debugging SCORM content is information that is sent from the LMS iFrame back to the server, and at that point the information has been handled and processed by the LMS parent window.
-Dave
Great. Thanks for the explanation, Dave. Makes sense.
Is it too soon to ask this? How will Tin Can work?
>How will Tin Can work?
Awesomely
With Tin Can data it will be PUT to the server directly, so you can debug via fiddler, http analyzer, etc.
-Dave
One more question, Dave.
Have you folks ever thought of providing something more user-friendly for debugging and helping average users view and interpret content-LMS communication real-time? Maybe even optionally generate a log that you folks could use to send to you folks for support issues when needed?
SCORM and AICC commands, as well as HTTP responses, are not very intuitive sometimes. The SCORM debugging output can be bewildering to some. Heck, I'm challenged. Too much time just using AICC.
Seems to me there's possibly an opportunity here. I know IT departments and the more technically-skilled developers needing to debug issues would probably appreciate it.
Maybe even an easier way to turn on debug mode. Maybe a built-in "double-secret probation" feature that can turn debug mode on and off without needing to edit a JS file and re-publish.
Besides you folks creating tools that are easy to use in to develop e-learning content, something that is easy to use and understand when investigating issues would be TREMENDOUS.
Since you changed the naming convention for publishing objects in Storyline, if the tool could help developers understand things there would also be created--especially since the days of slide1.swf, slide2.swf, etc. are behind us,
Not the type of glamor feature that wins some developers over to Storyline but something that's very needed, IMVHO in the LMS/authoring tools world.
Hey, you folks can help lead and set a new standard here for tools. Again, IT departments would probably love you, especially if their approval is needed when purchasing software tools or when deciding what software tools are supported in an organization. Something like "we make things easier for your developers, your learners, and your IT department with e-learning."
Just brainstorming but it makes business and technical sense to little moi . . .
This discussion is closed. You can start a new discussion or contact Articulate Support.