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).
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.