Top 6 HTML5 Challenges

While HTML5 has certainly opened up opportunities for learning on mobiles and tablets, it has also introduced certain challenges from the development perspective. For instance, one must now, as compared to developing in Flash, consider a wide range of browsers, operating systems, screens sizes, pixel densities (PPI), aspect ratios, keyboard alternatives, touch interfaces, device modes, and other aspects. These challenges were limited with Flash as there was very little device and browser dependency.

Based on our experience in developing eLearning using HTML5, we have listed some key challenges a developer might face, along with possible workarounds.

1. Browser Challenges

HTML project performance depends largely on browsers, unlike Flash where the Flash Player was able to overcome most browser variations.

A few years back (2001 to 2005), Internet Explorer was the market leader with a 90-95% share in desktops and laptops. Today, that has come down to 20% as Chrome, Firefox, Safari, and Opera; Android Browser; Mobile Safari; and Dolphin have all picked up market share. This adds significantly to the challenges, as an HTML5-compliant application may need to be coded differently to ensure similar if not identical behavior on different browsers. The testing too increases as the number of browsers targeted increases. You can overcome these challenges if you avoid the use of features not supported by targeted browsers or provide alternatives to those browsers that don’t support those features.

Here is a quick view of how some browser versions support HTML5 features:

Ref: http://html5test.com/compare/browser/firefox-26/chrome-31/ie-11/opera-18/ie-8.html

IE is Special

Big domains like medical and banking sectors are still using Internet Explorer as a primary browser; however, many of the HTML5 elements do not work or work only partially with IE versions 8 and lower.

There is also a problem with external libraries/frameworks. For instance, if you are using external files in the project and are using JQuery’s “$.ajax” to load those files then JQuery may fail to load files in IE 11 locally. IE 11 handles “window.ActiveXObject” in a strange way. It still returns a function, but if you try to get its type “typeof(window.ActiveXObject)” it will return “undefined” (though in IE 10 it returns “function”). We faced this issue in JQuery 1.8.3, which eventually got fixed in the next release of JQuery.

Before using any external framework/libraries, do check the compatibility with different browsers and devices. It is generally best to use the latest release of the framework/library.

User Agents

Every software application – browsers included – has a user agent that sends information about the application as well as the device on which it is running to identify itself to the network. This information is provided in the form of a unique user-agent string specifying the software application type, name, and revision, and the operating system.

Here is the sample user-agent string for Google Chrome 32 on a Windows 7 Desktop PC:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

And here is the sample user-agent string for Google Chrome 31 on an iPhone running iOS 6:

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_2 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko)CriOS/31.0.1650.18 Mobile/10A551 Safari/8536.25(BD6D0651-5072-4F26-B5D9-7A3FD57A65D8)

If you take close look at these strings, you’ll see that the browser name is different for different devices – the Chrome user agent for the desktop returns “Chrome” as the browser name whereas the user agent for the iPhone returns “CriOS” (“Cr” for Chrome and “iOS” for the OS). Similarly, there can be other parameter values within user-agent strings that differ based on device-software application combinations. Here’s another example – the sample user-agent string for Google Chrome running on a Nexus 5 is:

Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36

The sample user-agent string for Firefox running on the same Nexus 5 is:

Mozilla/5.0 (Android; Mobile; rv:27.0) Gecko/27.0 Firefox/27.0

Here, you can see that unlike for Chrome, the user-agent string for Firefox does not specify the Android version.

When developing eLearning in HTML, developers need to be aware of the different user-agent strings that will be returned for each targeted device-browser-platform combination. They need to make the eLearning compatible with all these user agents, so that information or content can be displayed accordingly. Let’s assume you want to run a system check at the beginning of a course, and display the results to the learner, indicating the areas of incompatibilities. If the course is intended to run on Google Chrome and Firefox on desktop PCs and iPads, then the developer must check for the browser names returned by the user-agent strings of all applicable device-browser-OS combinations and display the text “Google Chrome” or “Firefox” as applicable for all.

2. Code is Exposed

If the application is created using only HTML5 technologies then most of the files are rendered or cached on the user machine. This invariably means that an application’s presentation layer and business logic are exposed to the user. They can access all JavaScript, CSS, and HTML files and view code if so inclined. There are ways you can hide your business logic but if someone really wants to break in and is willing to go the extra mile, they will eventually get it.

Encrypting your HTML5 content is not really an option – because browsers cannot execute encrypted content. So here are a couple of ways in which you can protect your code to some extent.

The best way is to minify or obfuscate the code. The former involves shrinking variables to create minified versions of JavaScript files; the latter involves adding to the code to make it unintelligible. In both cases, the code can still be read by browsers without any need for decryption; however, it is difficult to understand for humans.

Note that obfuscation makes it time consuming, but not impossible, to reverse engineer a program. One drawback of this approach, however, is that some anti-virus software will alert users if they land on an application which uses obfuscated code, as one of the purposes of obfuscation is to hide malicious code.

Another option is to use the Base62 compressed encoding method that only uses alphanumeric characters to represent the original data – in other words, it represents a very long normal code as a shorter version. Here, since the code is compressed, it can still be read by browsers after reconversion to its original form; however, it cannot be easily understood by humans. Compression of the code also helps reduce the file size.

Here is some sample output from Base62:

Original code:

function detectPlugins() {
for (var alias in plugins2detect) {
		if (plugins2detect.hasOwnProperty(alias)) {
			var plugin = plugins2detect[alias];
			if (detectPlugin(plugin.substrs) || 
detectObject(plugin.progIds, plugin.fns)) {
				self.plugins.push(alias);
			}
		}
	}
}

Encoded as:

eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('b'+e(c)+'b','g'),k[c]);return p}('4 7(){5(1 a 3 0){2(0.6(a)){1 b=0[a];2(8(b.9)||c(b.d,b.e)){f.g.h(a)}}}}',18,18,'plugins2detect|var|if|in|function|for|hasOwnProperty|detectPlugins|detectPlugin|substrs|||detectObject|progIds|fns|self|plugins|push'.split('|'),0,{}))

One drawback, though, of using Base62 to compress code is that it increases the execution time on the client. Every time the file is loaded, it is converted back to its original format in the application memory, which takes time and delays the execution of the script.

Some applications which can help minify/encode/obfuscate code are:

a. YUI Compressor b. Packer c. JSMIN d. dojo compressor

3. Media Issues (Audio/Video):

It was easy to have audio/video streaming or buffering in Flash with the popular FLV/F4V formats. Now, browsers use HTML5 and tags to play media, and most of them support different video formats (e.g. MP4, OGV, and WebM) and different audio formats (e.g. MP3, OGG, and WAV). You need to include audio/video files in ALL these formats to cover a wide range of devices. Furthermore, if you want the video quality to adapt to the users’ connection speed (useful when targeting mobile devices), you will have to create multiple versions of the same video. Note that this will have an effect on the size of the eLearning package and most LMSs have a size limit for a course that can be uploaded on them.

You must also provide a fallback for browsers that do not support HTML5 video/audio tags. Flash is an easy fallback option. Other fallback options are QuickTime player and Windows Media Player. We noticed that while using fallback options other than Flash, it is difficult to modify the default player skin using HTML and related technologies.

4. Animation Capability:

It was easy to create character animations, vector animations, software simulations, and animation reels in Flash. Animation is an important element used in eLearning for visual explanations and engagement value. With HTML5, the first challenge is to create animation in sync with audio – a time-consuming and complicated task to achieve with the tools that are currently available.

That said there are several ways in which animations can be created in HTML5: using HTML5 elements (e.g. Canvas, SVG), CSS3, or Spritesheet animations. Custom development with these elements requires significantly higher effort than was required with Flash. Tools such as Toolkit for CreateJS can help users to work in Flash and export HTML5 content. Edge Animate can help create animated and interactive content. These tools export HTML5 content, which will not be supported on older IE versions. Also, if these animations are going to be part of a course/project, integration, data communication, and control of these animations may not be easy. An alternative is to use Flash to create animations and then convert those into videos; however, while that works well for continuous animations, it may not be so effective for animations interspersed with interactivities.

5. Audio Synching:

It was very easy to sync audio with animations using the timeline feature of Flash Professional. We cannot do this in HTML5 as there are very few tools (like Adobe Edge) available and even those are still evolving. Read our full review here . Syncing can be achieved with ‘cue points’ but it’s a time-consuming task.

6. Testing:

Testing a web page means testing the layout, the logic inside, and the content being presented. Multiple layers of information make it difficult to test HTML5 RIAs (Rich Internet Applications).

In our experience, we see these possibilities causing the most failure: a) The code is not HTML5 compliant. b) The code is not compliant with a specific browser. c) The code is neither HTML5 nor specific browser compliant.

As browsers and the HTML5 standard continue to evolve, the process by which one identifies which of these may be causing issues will also evolve.

Today, the number of devices and operating systems in the market is huge. With the speed at which new devices and operating systems and their updates are being released, organizations are having a difficult time in coping. Procuring all types of devices and keeping them updated to test applications in real environments is proving to be a stiff challenge.

Simulators can help in initial testing but the results they provide may not be 100% accurate. At best they are good for a first pass, but running an application in the real environment on the appropriate hardware allows you to see your application exactly as your users will see it. This is the real environment that reveals application performance and behavior issues.

Again, testing responsive design or multi-device solutions on all devices is a time consuming task. The real pain is in loading a page on every device and following the same steps every time you make any changes in the code. Here, Adobe Edge Inspect and Ghostlab can help. With Adobe Edge Inspect, you can wirelessly pair multiple iOS and Android devices to your computer and sync. Use Ghostlab or web-based service like Browserstack to test how an application looks on different devices and platforms including iOS, Android, and Windows.

We hope that eventually with the formal release of HTML5, all browsers will follow standard guidelines/specifications, thereby reducing some of the challenges and helping to achieve uniform content rendering of RIAs across all browsers.

If you wish to share your experiences and challenges faced while developing your eLearning using HTML5, we would love to hear from you. Please share your views in the comment box below.