Forum Discussion
Keeping SCORM package small, best practices?
Are they any documents or guides that already exist for best practices while designing in Rise to ensure you don't end up with a massive SCORM file at the end?
If not, can anyone add to this list of recommendations to avoid this issue in the future (for now, without use of an external tool):
-Compress any possible video/ image assets and pay attention to file size as you upload
-When designing in an external tool (Canva, Adobe CC, Adobe Express, etc.) make sure to watch your file size upon download
-Be mindful of use of AI audio generated within Rise, larger file sizes
-Be mindful of GIFS, background image file size, etc.
Anyone else have anything to add or know of any existing resources for this kind of guidance? Additionally, any documentation from Articulate of how much size interactive blocks, custom blocks, or anything else that might take up additional data and need to be considered for usage would be very helpful.
As the eLearning community drives toward more innovation, creativity, and interaction focused around a better end user experience, I am finding it difficult to navigate the balance of this with functionality without fully knowing the sandbox we have to play in (Rise current barrier, easier to see in Storyline).
6 Replies
You can also compress your SCORM using SCORM compressors like Doctor Elearning. Try it and let me know if it also worked for you.
This might not be feasible if you have an interconnected asset like branched learning, but we tend to break up our courses into multiple SCORMs. This is because our LMS has a hissy fit when anything gets too big (what that size is is anyone's guess) and won't save progress after a certain point.
You can think of the course as a book, with each SCORM serving as a chapter, and each Rise lesson or Storyline module acting as a section. This also helps keep your files manageable when it comes to updating.
MANY years ago, I presented "Web Delivery for the Absolute Beginner" at The Alternative Authorware Conferences (TAAC) here in the States, in the UK, and in the Netherlands. At that time, tube monitors displaying 1,024 X 768 @ 72 dpi were all the rage, 4" SoundBlaster speakers with VERY limited frequency range on the desk handled audio, dial-up was still the primary means to connect to the Internet for home users, and data rates for corporate users were not that much better. Many of the tips I offered then still apply, including:
- Reduce the resolution and the DPI of your images. Yeah, 7680 x 4320 (8k) at 1200 DPI is fabulous, but unless I'm playing "Where's Waldo?" with individual pixels, its absolutely overkill for an eLearning course. Drop both of those down to a size which is still viewable. I'd suggest starting with 1280 X 1024 @ 300 dpi and tweak from there.
- Use JPEG compression for photos and PNG for computer-generated imagery. Again, do I need to the able to study the individual hairs on a subject midway into the background? Or detect slight differences in the color of a 1 pixel horizontal line?
- Digital video: at that time, I was suggesting frame-rates of 15 fps (frames per second) or less (30 fps was the king, 29.97 for those of us who were in broadcast) and without dedicated hardware compression, you weren't getting full-screen video. Even quarter-screen was pushing the limit. Again, do you need Hollywood-style smooth motion @ 60 fps or 120 fps and full-screen to get the point across? Same goes for imported animations.
- Digital audio: do you need CD-quality 44k sound, in stereo? 22k mono was more than adequate for narration, and you ended up reducing the file size by a factor of 4.
- Text, motion, and interactivity take up next to no space. Exploit them as much as possible, just don't use every font in the list, ala a ransom note; motion for every single element, unless you want the learner to get whiplash; and every thing is a button/hotspot/hot object, unless you want to buy everyone new mice when they wear their current ones out.
Thank you for the suggestions, especially with specifics to the sizes!
When you are giving this advice, what tools do you recommend using, assuming you are receiving content at higher quality than needed? I will say, we've had lots of quality issues using compression on images for the kind of content we work with. AI audio narration seems to be taking up a lot more space, but currently I'm not seeing any options for compression there other than through a manual external tool, which defeats a lot of the purpose of the built in integrations. Otherwise, our audio assets don't appear to be an issue ever.For images, a good image editor like Photoshop or Gimp will work; before AI-generated audio (which is a black box) was a thing, I was recommending Audacity, SoundForge, or Adobe Audition; for video, tools like DaVinci Resolve, Nero, Vegas Pro, or Adobe Premier (with HandBrake on the end to fine-tune the final output).
