 |
Making SLS Interactives Reliable: Why Local Libraries Matter
Designing HTML5 interactives for the Student Learning Space (SLS) often feels like standard web development—until the sandbox steps in. Many developers discover that what works perfectly on a public website suddenly breaks when packaged into SLS. One of the most common causes? External libraries loaded from CDNs.
This surfaced clearly while building a Chinese Handwriting Practice interactive that relied on the excellent hanzi-writer library to animate stroke order.
The Reality of the SLS Sandbox
SLS prioritises student privacy and security. As a result, interactives that run inside ZIP packages or iframes are restricted from making external network calls.
This means that even though loading libraries from a CDN is normal web-dev practice, it won’t work once the interactive is uploaded into SLS.
During testing, the handwriting app appeared to freeze. The console showed repeated retries:
HanziWriter library not loaded yet. Retrying...
The issue wasn’t the code logic—it was that the browser inside SLS simply couldn’t fetch the library from
https://cdn.jsdelivr.net.
From SLS’s perspective, that external call is blocked by design.
A Simple but Crucial Fix
To make the interactive reliable inside SLS, the solution was to treat the entire app as a self-contained package.
1. Bundle libraries locally
Download required third-party files (JS, CSS, fonts) into the project folder and include them in the ZIP package uploaded to SLS.
In this case:
hanzi-writer.min.js
now sits inside the project directory instead of being fetched online.
2. Add smart loading logic
The script was updated to load the library in a flexible way:
-
Try the local file first
-
If running on an external site where the file isn’t present, fall back to the CDN
This ensures the interactive works both:
-
inside SLS
-
on public websites for testing or sharing
3. Keep index.html clean
Instead of hardcoding a CDN <script> tag in the HTML, the loading is handled dynamically in JavaScript.
This avoids console errors inside SLS and gives full control over fallback behaviour.
Why This Matters for SLS Developers
Many AI-generated templates or standard tutorials assume unrestricted web access. But SLS operates more like a secure intranet environment.
If an interactive depends on:
-
external JS libraries
-
CSS frameworks
-
fonts
-
images
-
APIs
it may silently fail when uploaded to SLS.
The safest design principle is:
Every SLS interactive should be fully self-contained inside its ZIP package.
Recommended Workflow for SLS Interactives
Before uploading to SLS:
-
Download all external JS libraries locally
-
Bundle CSS frameworks locally
-
Include fonts and images locally
-
Avoid external API calls unless explicitly supported
-
Test using a ZIP-loaded iframe locally if possible
Think of the ZIP file as the entire internet for your interactive.
If the resource isn’t inside it, SLS probably can’t reach it.
Bigger Picture
As more teachers create AI-assisted interactives for SLS, this issue will appear more frequently. Most generative tools default to CDN usage because it’s standard web practice.
But for LMS environments like SLS, reliability comes from self-contained design.
Once this mindset shift happens, interactives become far more robust and portable across:
-
My Drive
-
MOE Library
-
Community Gallery
-
embedded iframes
Final Takeaway
If an interactive works on your laptop but breaks in SLS, check one thing first:
Is every dependency bundled locally?
If not, start there.
A single missing CDN library can make an otherwise perfect interactive fail silently—while a fully bundled ZIP will run anywhere inside SLS without surprises.
No comments:
Post a Comment