Today’s elearning tools are very powerful. Depending on what you need, you can move from something that gives you a SCORM-compliant punched-up PowerPoint show (like Articulate’s Presenter) to a full-fledged authoring environment that allows you to create, populate, and maintain variables across screens (like Trivantis’s Lectora).
Yet sometimes it seems that that power isn’t enough. Take a full screen button, for example. Working in Articulate Presenter, there’s no option to have a button that can make the course go full screen. But it turns out that you can add functionality after publishing. A simple change to Javascript and the addition of a flash file creates a button in the wrapper that, when clicked, enlarges the course to fill the screen. A brilliant, simple solution, and a nice little bit of lagniappe for the learner.
Except… the files aren’t preserved from one publish to the next. You have to add in the files after every publish. Publish for stakeholder review, add in the files. Publish for alpha review, add in the files. Publish for beta review, add in the files. Publish for deployment, add in the files. The time adds up.
And, it’s another thing on your checklist. In addition to all of the other testing, the reviews, registering testers for your course, you have to remember to do this.
So the question to ask is, is it worth it? All software comes with limitations, and there’s precious little out there that can do it all. Is it worth it to push the limits, break through them, do what the software can’t natively do to achieve new functionality?
Or is it better to respect the limits of the software? Do what you can within the confines of the tool, and just accept that some things aren’t worth the effort?
In retrospect, there was an easier and better option. F11 on most browsers will make the window full screen. It’s slicker to have it in the course, but better to let the browser do the work.
It’s not always the case that abiding by the limits of the software is the best way to save development time. In some cases, the payback is worth it. The other example I mentioned above, adjusting the default timing on an animation, was more critical. If the learner clicked through the animations too quickly, the next button wouldn’t activate, and the learner would be stuck on that screen. There was no feedback letting the learner know what was happening, either. In that case, the extra time required in development was paid back by removing a likely source of learner frustration—with the calls to tech support that would have resulted.
However, the central point is sound: Respect the power of limits. When it’s possible, stay within the confines of the development tool. When it’s not, carefully consider the impact that your adjustments will have on the overall development process, and weigh the benefits and consequences of the changes you want to make accordingly.
Contact our Learning Developers
Need to discuss developing e-learning? Creating curriculum for classroom training? Auditing and remediating e-learning for accessibility? Our learning developers would be glad to help.