Like many instructional designers and developers, I have a love/hate relationship with the rapid development tools I use. On the one hand, it’s comforting to know that I can fire up a rapid development tool to produce a piece of content that works as expected, complete with an interface learners can understand easily. When the development tool has built-in support for navigating the content, for 508-compliance, or for user interactions, I’m free to concentrate solely on the content of my training. Cue the love.
On the other hand, rapid development tools also tend to generate much larger files than a developer would. Quick development time can come at the cost of a project that downloads or runs more slowly than it should. Worse, some of these applications don’t provide users with an easy way to view or modify the code they generate. If things do go wrong, this black-box approach can make it incredibly frustrating to troubleshoot, for example, why the application’s implementation of SCORM doesn’t work with the organization’s LMS. If I were able to modify the code directly, I’d own the problem, but I’d also know where to make the correction.
If I’m really honest, though, my most substantial frustration with using rapid development tools is the rigidity that standardization imposes. My customers generally prefer to have an interface that’s unique to their project, rather than a color variation of a standard menu. I tend to wish for the ability to include elements that my tools don’t readily support. The standardization that makes these interfaces useful and reliable can sometimes make them look a little, well, boring.
I will probably always use rapid development tools to help me create online learning. It just makes sense to take advantage of the things they do well, like creating screen captures or displaying a sequence of slides. But the tinkerer in me thinks that the best feature any of these tools offers is the ability to create output files in a variety of formats.
Most of my projects these days are a hybrid of content that I created with a rapid-development tool, and some interface and interactive elements that I built using Flash. A project I’m currently developing loads its menu from an .xml file and its content from a .swf file exported from a rapid development tool (see Figure 1); it also provides PDF documents so that the learners can print job aids for future reference. This particular project doesn’t play .mp3s, or .flvs, or use CSS to format the text, but I could have easily included any or all of these options if I needed them. I could even display an RSS feed in the sidebar, to provide links to current articles or conversations taking place in social media related to my topic. The RSS feed would keep my content fresh without any additional intervention.
Figure 1: Content hybrids can make good use of XML to manage the mix of interface and content.
Mixing content sources to create a custom interface can enhance a finished project greatly, but this practice is paradoxical: it is the best and the worst of both worlds. A custom interface comes with its own set of pitfalls, the most obvious of which is the time it takes to program and debug. Each new element introduces the potential to interfere with other sections of code. When I was still a relatively inexperienced developer, I used to think that my troubles were over after the debugging was finished. It never occurred to me that I might need to re-visit a project someday.
The best piece of advice I can offer to anyone thinking about mixing content sources is to keep detailed notes about the project. The locations of the source files, locations of edited or compiled files, the RGB or hex values of the color scheme, the dimensions of the graphics, and the program’s architecture are all easy to catalog while you’re working on the project, and nearly impossible to remember six months later.
It’s also worth writing developer’s notes when you come up with an unusual or clever solution to a coding problem. As tempting as it is to believe that the genius of a clever solution will make it memorable, clever code is abstract code. The complexity of the coding problem is often the reason you needed a clever solution in the first place.
So, keeping in mind the output options rapid development tools offer, the occasional off-label hacks, and the tips and tricks we all pick up as developers, I still fall mostly on the love side of the love/hate relationship. A little tinkering is good for the soul.