Experiential differences in publishing to Web vs SCORM 1.2

I'm aware that general (web) speed won't necessarily match true LMS speeds as well.

Hey, Simon! 

Not sure this is what you are looking for but why not just publish once to the LMS?  If people have to view outside of the LMS, just point them directly to story.html as part of the launch URL for just reviewing content? 

With that, you have only one version of the course to maintain.

We used to do that for Presenter a lot and everything worked fine.  Articulate AICC/SCORM content uses index_lms.html to start. Index_lms.html, among other things, loads all the JavaScript required for AICC or SCORM communication and then calls player.html. 

Believe it works the same for Storyline except it uses story.html instead of player.html. 

Just tried that with a Storyline AICC course and it launched and played just fine starting out with story.html instead on index_lms.html.

If your content loads into the LMS directly and you don't have access to the server to know what the URL is, just use something like HTTP Watch or HTTP Analyzer to see where the content is and find the URL info.

This ability to have one version of a published course serve both the LMS, and be accessible outside the LMS, is a great advantage of Articulate content, one that doesn't get talked about enough, IMVHO.

Hey Gerry!

I like your idea but I should have been more precise because I'm looking at a more simple way to host production drafts (for review) as opposed to anything live.  The devs have enough on their plate without having newly published versions to upload (to our LMS) X times a day, hence trialling SCORM Cloud for a while but it's been somewhat unreliable.  Now looking at pushing up Web versions to one of our sites and wondering what we'll 'lose' over their SCORM equivalents.  

Does that make more sense?

Cheers

I hope I understand.   Other then the reporting to the LMS, I'll don't think you'll lose a thing when publishing to web.

Maybe you can talk Articulate into selling you their tempshare code and then developers would be able to quickly post content?

Or look at something like this--PeerSync.   Create a share on a server that developers can use to post their content and then let PeerSync sync it up.

Yeah, I'm hoping the only losses so far are speed and tracking.  The former could be an issue on some courses but so far SL is quicker out the box that Studio anyway (although we still occasionally work in Studio).  I can't remember if we used to see QM-based issues - maybe not.  A recent demo seems to be behaving as it should when published to Web.  

Will ask the devs to check out PeerSync - not heard of that.

Good idea  Guys, if you're reading, is this an option?  We'd probably need it to work with Studio too (I believe it's currently only SL-compliant).

Cheers

Yeah, I've not timed publishing to web versus publishing to LMS but I've not noticed any significant differences.  Pretty fast with either depending on the complexity of the content and length.  That seems a bigger differentiator.

Plus the speed at which the course runs at.  Slides can load a lot slower running off a web page than in an LMS.

FTR we've tried the Dropbox method but in addition to it being a little sluggish, we'd prefer something integrated into one of our sites.

One reason why, when I was a LMS manager, I liked having separate content servers outside the LMS environment. 

We used Saba and this was possible with both AICC and SCORM (though SCORM required more setup and a Java app server on the content servers).  All the content servers did was serve up e-learning content (and we had three load-balanced as one) and nothing else for the LMS.

I suppose a lot depends on how your LMS stores content and manages things behind the scenes.

Actually, load-balancing might be something to look at if your LMS supports it for content or it has to be for the entire LMS.