75 Replies
Tristan Hunt

Hi Adam,

I can see where you're coming from, but on a mobile device, you don't see the tabs so it's not obvious or intuitive how to get back. You get to the end and then it's like cool now what, now I'm stuck.

A large proportion of our audience isn't IT savvy at all, so we have to ensure the UX is very intuitive.

I haven't played around with a window containing a course so I will look at that. Not sure how that affects the responsiveness. Also, it will reduce the screen real estate due to the padding of the moodle frame.

Thanks

 

Andrew Smith

Just another perspective on the rationale for this.  A lot of our users don't complete courses in a single pass, they need to be able to save their state and resume later (cmi.core.exit/cmi.exit == "suspend" + LMSFinish/Terminate).  It's not intuitive that closing a browser window will save state.  You wouldn't expect this if you were part way through an airline ticket purchase for example, why would you assume it for your eLearning?

For state to be saved reliably across LMS and be resumable, up until completion we would need a way to exit and set the exit status to "suspend" and after completion an exit button that exited normally.

Just lastly, please don't make the exit button close the window.  It's not the prerogative of the scorm activity to do this, the LMS chooses whether a scorm package is loaded in a new window and can close or navigate away accordingly when it receives a call to LMSFinish/Terminate.

Thanks in advance

Andrew Smith

Hi Adam, on mobile in particular, but even on the desktop I try and steer clients away from popups.  If the course is inline then when you click the "Save & Exit" button or equivalent, the LMS just takes you back to the appropriate page, most often the course list page.

Using a popup model still works, the scorm API (provided by the LMS) completes its exit routine, redirects/refreshes the opener and closes the popup window.  Popups just aren't a very nice experience on mobile in my experience, so I try to avoid them.  They're only really useful when using development tools that aren't responsive and require a fixed/optimal stage size.  Popups then allow you to open a window sized appropriately which can give a nicer experience on the desktop.

Whether on mobile or on the desktop though I feel really strongly about supporting the user with screen elements that clearly explain what your options are.  The big 3 being next, back and exit (preferably "Save & Exit").  Particularly when you are working in sectors that don't do a lot of online training I find people get worried/frustrated if there isn't a clear safe way to save their session and resume later.  I also think it's pretty important from an accessibility point of view.

James Landrigan

Hi Adam,

Just to reinforce the need for this function with a quote from the first client we are presenting with a Rise course.

" I think there needs to be a link back to the main (LMS) course page at the end of each topic. Currently when I get to the end of a topic...there is no link back to the main course page. I know you have to close the window but a link would be a handy reminder of what to do next." 

So a close button for a course opened in a new window and an "open in same window" option on your button interaction would be great for when the course has opened in the same window as the LMS page.

Thanks again for all your efforts.

Bret Weinraub
Ashley Terwilliger

Hi Bret and Kati, 

Rise works similar to Storyline in that we're sending the lmscommit to your LMS when you exit the course (using the browser close in Rise, or in Storyline you could also have an exit course button) or when you reach the completion element.  You can see and test this behavior at SCORM Cloud, which is an industry standard in LMS testing, and has a built in debug mode which I included snippet of a tested Rise course below, and on this attempt I closed the browser window:

On another attempt, the quiz was passed but we were still viewing the 2nd to last slide. At that time, my colleague looked at the reporting within SCORM Cloud to show it had the completion status correctly based on the quiz. So based on that the LMS should not need to close the browser window to record the completion. In case you'd like to test this as well, here is a great article on how to upload and test content at SCORM Cloud. 

If your LMS is still not recognizing completion with either the quiz or the browser close, we'll want to know a bit more information to help figure out next steps. What LMS are you using and SCORM Version have you published with? Does the LMS have access to any debug data like SCORM Cloud to see what is/isn't being passed? If you'd like to share a copy of your Rise export with our team to do some additional testing we're happy to take a look. You can upload the Rise export here. 

Andrew Smith

Hi everyone, Just to highlight how critical a close button within the content actually is, here's a small test to show you how much can actually be achieved in an onbeforeunload handler.  The source code is linked to the page below, so feel free to download it and create your own test.  As you'll see Internet Explorer is the only browser that will give you near infinite time to execute requests when someone closes the browser.

http://www.andrewsmith.com.au/delay.html

While you might be finalising before the browser closes if the student completes the content, what about the scenario where someone wants to exit/bookmark and return?  Without a clear exit button within the content, the only way to do this is onunload or onbeforeunload.

The  time your browser will wait for whatever calls you make within these handlers varies per browser, but most only wait a very short period of time.  If you intend to set the session time, the score and the exit type for example in sequential requests (SCORM requires synchronous ajax), in a high latency environment, it's highly likely that 1 or all of these will fail.

So aside from the human side of this issue (be kind and let people know that they can safely save and exit) it simply isn't reasonable to expect that any synchronous ajax will complete during window close.

Andrew