Something I just wanted to highlight - because I don’t think it’s been mentioned yet (and because, quite frankly, I’ve put a LOT of time and effort into it!) are the improvements in SCORM tracking in New Evolve… specifically:
When publishing for SCORM 2004, you now get FULL save/restore support - no need to enable Local Storage if you want the answers the learner selected to be remembered & restored each session!
When publishing for SCORM 2004, all question elements (at the time of writing) have support for ‘interaction reporting’
‘Bookmarking’ is based on ‘last thing viewed’ (not ‘last thing completed’) so is an improvement in that it will return the learner back to the last thing they were looking at - not just the last thing they completed (SCORM 1.2 & 2004)
If the learner closes the course using the Exit Course button (or the Button element’s ‘Exit Course’ action) this should ensure that tracking data gets saved even on browsers like Safari for iOS that don’t have any kind of ‘page has been closed’ event (SCORM 1.2 & 2004)
We don’t have any equivalent to those in New Evolve yet.
If we end up adding an equivalent to the Text Input question component then yes I would certainly expect this to be setup to have full save/restore support.
For the Open Input component - that’s a very different beast as saving/restoring the learner’s input via the normal route (SCORM suspend data) opens up the possibility that the learner enters so much text they break the course tracking. So I need to come up with an alternative solution. I can certainly say I would like to try and allow for it to be saved/restored without having to involve Local Storage but I can’t confirm that for sure at this time.
Thanks @Matt_Leathes — this is really exciting to hear!
The Open Input–style questions tend to be very popular with our learning designers, especially for short reflection activities. The only recurring challenge has been when learners switch devices or browsers and feel like their answers have “disappeared,” which leads us into the whole local-storage conversation.
I was wondering whether it might be possible to offer authors a max character limit for any future Open Input component. A gentle limit could help authors keep things consistent and manageable across different LMS environments.
Something in the range of 500–750 characters per response seems to suit most short reflections, and even an optional extended range of 1,000–1,500 characters should still fit comfortably within typical SCORM tracking expectations.
If a course includes several Open Input components, the combined amount of text can also add up, so even a course-level indicator or soft warning (e.g., around 3,000–4,000 characters across all Open Inputs) could help authors plan how much learner input they’re collecting within a single module.
Just a thought — but this would be really helpful for teams designing reflective activities while keeping everything SCORM-friendly. Happy to clarify anything if useful!
@ShaunP the other solution I have in mind is to take advantage of the fact that, in SCORM 2004, cmi.interactions are read-write (they were write-only in SCORM 1.2) - so it would in theory be possible to use a 'long_fill_in' interaction type for each open input component as that would allow for the learner_response for each one to be up to 4000 chars.
It’s just an idea at this stage though - not only is it fairly complex to implement - but there are some LMSs (Totara, for example) that don’t have great support for cmi.interactions in SCORM 2004.
I tried to upload scorm 2004 to Exceed, but got the message that it’s incompatible. It worked after I uploaded scorm 1.2 Does Exceed not support scorm 2004 for new Evolve?
Hi @sliao no, Exceed has never had support for SCORM 2004.
To be honest, although you can upload Evolve courses as SCORM (1.2) to Exceed, the preferred method is to use Cloud Sync. Unfortunately this isn’t yet available for New Evolve - but it is something we are currently working on and hope to have available quite soon!
Yeah it’s a bummer that cloud sync isn’t available. I saw your post regarding improvement for scorm 2004 and wanted to try it, didn’t realize Intellum’s own product doesn’t support it.
I just wanted to say that I really appreciate that @Matt_Leathes is thinking about the SCORM data challenges and even considering how to leverage SCORM 2004’s cmi.interactions to allow larger open text input fields. It’s also good to see that Totara’s limitations are being taken into account, because not all LMSs implement the full SCORM 2004 feature set consistently.
It seems that SCORM 1.2 is still very widely supported across LMSs, and many content providers continue to target that version for maximum compatibility. This means that solutions relying heavily on SCORM 2004 features may not work equally well everywhere, simply because not every LMS fully supports those advanced data models.
Overall, I think it’s great to see ideas being discussed that could improve authoring and tracking, so I just wanted to add my appreciation for the thought that’s going into this.
