The need to adapt content to a variety of electronic devices can easily be traced back to the concerted effort for ‘mobile-compatible websites’… There is even a top-level domain established with the vision of everyone having a “.mobi” version of their website available for folks who were visiting via their handheld devices. Fortunately, CSS advances continued to enable more fluid layouts so sites could adapt to the visiting device without having to shunt them to a different URL.
While there ultimately may evolve no distinction between ‘eLearning’ and ‘mLearning’, both terms will remain until online training content is designed to be responsive to the device – a concept more commonly referred to as ‘Responsive eLearning Design’ or RED – as adapted from the better known ‘RWD’ concept (Responsive Web Design). Ideally, ‘eLearning’ should be the only term we need to cover all forms of online training.
The (forced) move to HTML5 as a primary tool in eLearning development opens a few doors – one of which being the establishment of CSS and the concept of ‘separate content from design’. Now instead of trying to access an eLearning course designed for a desktop screen by pinching, swiping, and scrolling on a mobile phone, the entire structure of the course can adapt and allow for more natural access (and that’s not to say that wasn’t possible with Flash, it’s just a longer-established principle with HTML).
And that’s also not to imply that adaptive/responsive design is the only component of ‘mLearning’ – certainly not. Being a completely different device, different functionality is possible. It’ll take a bit more work between the mobile-OS developers and the W3C, but someday having access to, say, a phone’s GPS or camera through HTML5 will allow a course to adapt its available features as well as its overall design to the device. Until then, creating an ‘App’ version of your courseware is the only option for accessing device-specific features…which is a valid option…but gets into difficulties of distribution and compatibility. Overall, developing a single product which adapts to the device is almost always the most elegant and cost-effective approach.
That aside, it’s not that developing for mobile devices is more expensive or complex; it just requires different design principles to be applied. The biggest impediment to Responsive eLearning Design is the authoring tool – very few offer any sort of adaptive design capabilities and those that do are pretty limited.
More and more of our customers are requesting their custom courseware be mobile-compatible but often that means ‘will work with iPads and other tablets’ instead of a true, globally-mobile solution. With the resolution and capabilities of tablets, the customer then likely does not need the additional effort of responsive design…which allows for greater toolset options and lower costs.
However, where true mobile-compliance is required, and thus a solid ‘RED’ approach to allow optimal product development, we often turn to our custom HTML-based framework.
When eLearning tools were starting out and their features were limited, we created a much more efficient and flexible SCORM-compliant, Flash-based framework for custom projects. With the advent of mobile and a preferred HTML approach, we’ve rewritten this ‘shell code’ for pure HTML output. So where an off-the-shelf authoring tool may be the best solution for some projects, our ‘HTML Shell’ provides the ultimate flexibility when designing for adaptive courseware. The next step on our plate is integrating TinCan (xAPI) features into the framework. Stay tuned!
Footnote: yes, there are technical differences between ‘responsive’ and ‘adaptive’ design approaches – but the essential goal is the same. Regardless of the technology and approach you use, the now age-old concept of ‘write once, run anywhere’ must take into consideration responsive/adaptive design for truly effective eLearning courseware.