Content formats? Where should one start?
(As an aside, you may have noticed that the original blog has undergone mitosis with the eLearning content remaining at this URL and everything else moved over to the new Duck? Starfish? …But23 site. If you are a current follower of this blog and your interest is not primarily eLearning then you might consider switching your “follow” to the alter-ego site.)
Maybe a good first stop would be the Tower of Babel. Recall the story recorded in Genesis of how the ancient people’s arrogance in constructing a tower intended to reach the heavens themselves so angered the deity that he scrambled their speech, de-unifying the single language they once spoke so that, forevermore, they were destined to be scattered upon the face of the earth, never able to properly communicate.
How true that rings in the world of eLearning, but now it’s not so much about language but, rather about standards or more to the point, the lack of them. Years ago it was mainly about application-specific files. Remember the Word/WordPerfect/WordStar/etc. fun from the eighties and nineties? The dominant word processors never seemed too worried about making files that were inter-operable. It almost seemed that each gain was offered grudgingly, “we don’t really want you working with the other guy’s files but if you must we’ll get them to open but you can forget about the formatting being very useful.”
So, too, with eLearning; file formats, it seems, still have not really come very far. They all have their strengths but none, unfortunately, is an ideal for eLearning.
HTML and embedded graphics
This combination is fine for general usage but it has serious limitations. You can get it to depict anything that can be read on paper but there are always compromises. Math notation is particularly problematic. While there are solutions, most notably MathML, you still cannot get math notation, or for that matter anything besides text, to display consistently across browsers.
Besides, today’s consumers of online content have been conditioned to express extreme displeasure whenever they are confronted with something that does not allow interaction, show moving pictures or otherwise do things that move, distort or otherwise amuse. Complex prose, when subject to the whims of the semi- and fully-fledged-trolls who love to fill in the comment fields will ultimately fall victim to reams of complaints, most of which contain something like, “Holy wall of text, Batman!” or some other phrase they figure is unique and witty (which it is not; it is, more often, a pathetic admission of inability to grapple with complex thought).
Perhaps it’s best to consider this combination format as a good general purpose tool. A consideration of the audience is probably a good distinction point. For school-aged learners you need to acknowledge that (1) the reading ability and (2) the attention span have serious age-dependent limits. Limit both the length and depth of any given learning object paying particular attention to the age of the audience. Keep it as short as possible while still creating an age-appropriate degree of challenge. That is, strike a balance between easy & trivial and difficult & extended.
If this is a format you use often, be sure to obtain or create an appropriate css file and stick to it to ensure that the visual presentation is effective and consistent.
Video Formats such as MP4
Once shied away from, in general, owing to bandwidth restrictions it’s safe to say that these are now just fine for all but a very few applications, where even consumer-grade high-speed is unavailable. What’s more, even the most inexpensive hardware is now more than capable of doing the background work required to produce decent quality video-based learning objects. You can do a good enough job with even at $400 laptop or a smartphone, and using the software that typically comes free with any camera capable of doing video.
That said, there are still considerations that need to be attended to. Chief among these is the fact that there are few things more unpleasant than having to endure bad video. A video production using any combination of these flaws: shaky camera work, poor quality audio, choppy splicing and, most importantly, a poorly prepared storyboard and/or script is a total disaster.
Besides, those who read well can do so significantly faster than they can listen, so if the content does not expressly require the use of moving pictures you should consider at least supplementing the video presentation with either a transcript that can be quickly read or an audio file that can be listened to while exercising or commuting.
As a last comment it’s worth stating that while self-produced video now has every possibility of being of good quality there’s still no substitute for the degree of excellence that can come from a team-based approach. If you can find any way of funding the production using a professional crew go for it.
Adobe Flash (SWF)
This format is Compact and versatile and is, at least in theory, an ideal format for eLearning as it handles text, images, animation as well as sound and video. It does it all very well. Unfortunately it suffers from three fatal flaws: (1) it is proprietary, owned by Adobe and, as such, is subject to the whims of its owner; it requires an external plug-in/player. (2) SWF is inherently vulnerable, despite continuing efforts on behalf of its owner to plug the numerous security leaks and exploits, once discovered. And (3) Apple’s decision not to support the SWF on its IOS based (iPads, iPhones, IPods) devices means that use of this format in eLearning means it cannot be used by some of the most popular devices around; one step away from being a non-starter in public education if not private industry.
Notwithstanding the above complaints SWF continues to be a reliable workhorse (albeit something of an aging one). Adobe’s Flash product is still, hands down, the most versatile development platform from which to create powerful and creative interactive learning objects on a budget, assuming you have access to an appropriately trained multimedia professional. Yes, it is possible to learn how to “do it yourself” inasmuch as you can learn to play your own cello piece for your class introduction video. Just as most would find it much more efficient and, in the end, cheaper, to briefly engage a suitably trained musician for that task most instructors and instructional designers would judge it wise to do something similar.
But it turns out that if you choose to use Adobe Flash you don’t have to do that at all. Flash is not the only product that produces SWF files. Articulate’s Storyline and Studio (Around $1400 US each) as well as Adobe’s own Captivate ($20 US/month – subscription) can create SWF files either based on original content or from pre-existing content created in PowerPoint. All of these products are relatively easy to use by just about anyone—they can be learned in about a day of training and practice. In either case you can go as far as your current expertise and comfort level let you go. That is, after a couple of hours of training you can easily convert a PowerPoint presentation into a stand-alone presentation, including animations and narration, that a student can experience at a time of their choosing. With just a bit more training you can learn to add interactions (embedded questions, opportunities to do sorting and matching exercises and such) to the presentation.
The end result can be very professional and effective. In general, the result is as good as the content you have for it. For an experienced instructor, this is indeed a good option.
But there’s one big catch: SWF content cannot be properly viewed with iPhones and iPads. There are various web-based services that convert the SWF files, on the fly, to video which can be played but you generally lose the interactions—why you used SWF and not video in the first place—and the work-arounds are often sluggish and buggy. Still, if IOS compatibility is not an issue than SWF is an excellent choice.
HTML5
By using JavaScript to handle animation, this format offers, perhaps, the most hope for the future. Like SWF, HTML5 handles text, graphics, animations, audio and video very well but unlike SWF if does not necessarily require an external player and is not proprietary. It also runs on IOS based devices. Unfortunately it, too, suffers from serious flaws. (1) While it does not require a separate player it does require a modern, up-to-date browser. This means it will not run on older systems or on ones that, for corporate reasons, cannot use updated browsers. (2) HTML5 is not a “current” standard in that the project is still incomplete and will be in that state for several years to come. It short, HTML5 is still very much a moving target which brings us to (3) there is currently a lack of sophisticated, affordable development tools that can prepare content for this environment. It’s still very much limited to those who can either afford the expensive tools or who have programming skills and do not need them.
The aforementioned Articulate tools as well as Adobe Captivate, for example, do support HTML5. That is, they can produce HTML5 output. Unfortunately, at the time this was written (Feb. 2014) neither product fully supported the standard, Many of the interactions that the products supported could only be implemented when you output the file as SWF. If you choose, instead, to output your project as HTML5 you will only get a crippled version, one missing some of the interactions you designed in because the software cannot handle them yet in HTML5 format. In practical terms this means if you use those products you have to say either:
(1) Never mind HTML5, I will stick to SWF for now but may go back and republish as HTML5 if a later version supports what I need.
OR
(2) Never mind the complex interactions. I will remove them from the design and stick with a simpler, less interactive version of my design; one that is currently supported by the software.
In short, as I see it right now here is the situation with HTML5: There is a lot of hype and promise, both from the technical community developing the HTML5 standard and from the community of product providers, all anxious to be able to say, “our product does a GREAT job on HTML5.” Unfortunately, when you drill down and try do get some serious work done with it you will realize that to do the work properly either you will have to engage the services of highly trained professionals who can work with the expensive and complex tools that currently exist or you can dumb down your project to make it fit with the constraints that currently exist within the few user-friendly and affordable tools that currently exist.
Or you could wait 5 to 7 years for the technology to catch up. Just kidding.
In summary
So, where does that leave the instructor and developer? Unfortunately the answer is, “still very much up in the air.” No matter which way you turn you are faced with a world of compromises. The best advice is the following:
- As always, focus first on the outcomes and on the learners. Take good stock of what it is you need the learners to be able to do at the end of the process.
- Take a good hard look at the current content and strategies you have.
- Make a judgment on how best to rework them for your online learners, given the constraints that have already been elaborated for each format, as well as the money, time and skills you can bring to the table.
- Go ahead and develop with your best effort knowing full-well that we all live in a world of compromises. You can never do a perfect job—in fact; striving for perfection is an excellent way to stall completely in the here and now.
- Put a mental time-stamp on your work. Give it a “best before” date. If you do that as you produce it you will be prepared—cognitively, emotionally and strategically—for the changes that will need to be made at some time in the future.