Your Source for Learning
Technology, Strategy, and News
ARTICLES       RSS feed RSS feed

Beyond the Hype: Understanding HTML5 and its Potential for e-Learning and mLearning

by Judy Katz

May 31, 2010


by Judy Katz

May 31, 2010

What does HTML5 mean to us as e-Learning and mLearning designers and developers? What – if anything – does HTML5 add to our capabilities? What are its limitations? What will have to happen for it to be truly useful to our industry? And what don’t we know yet?

The Internet is on fire. It’s now genuinely difficult to follow technology news or commentary without reading something each day about HTML5 vs. Flash, or at least Apple vs. Adobe. Read one article and it’s easy to come away with the impression that HTML5 is a “Flash killer”. Read a different one, and you’ll be convinced that HTML5 is just a flash in the pan.

There has been considerably less controversy in the e-Learning world – at least in the part of our discourse that gets published on the Internet. But the debate could have a pretty significant impact on our industry, if only because we’re very heavily invested in Flash and development software that outputs to Flash formats.

According to the e-Learning Guild’s 2009 report, Getting Started in e-Learning: Technologies, Tools, and Media for e-Learning, among the top 15 development tools used by their members, only two of the actual authoring tools don’t output to Flash formats at all, and those are pretty far down on the list. The rest primarily publish to Flash formats, including Flash itself and the software in the #1 spot: Adobe Captivate. Go a little further off the grid (for example, to see Cammy Bean’s mind map of which authoring tools people are using) and you’ll see even more software, much of which outputs to Flash formats.

And it’s easy to see why Flash delivery is popular: Some version of Flash Player, the plugin needed to play Flash content in a Web browser, is on just about every computer in the world. As e-Learning developers, we know it’s only smart to meet our audience where it is, with the technology our learners already have. And anyway, Flash makes stuff pretty. It anti-aliases text and makes things move around onscreen. And not least, it gives us interactivity. Want to create branching scenarios, games, even virtual worlds? Flash can do that and much more.

So I think it’s time we start taking a good look at this new technology that some say is a threat to an authoring program and delivery format that is pervasive in our industry. But I’m going to try to give you a break from what’s happening all over the Internet, and not talk about whether Steve Jobs is an evil overlord, or whether Adobe is lazy about maintaining one of its most important products, or whether open source and Web standards will save us all. I’d like to talk about what HTML5 means to us as e-Learning and mLearning designers and developers. What – if anything – does HTML5 add to our capabilities? What are its limitations? What will have to happen for it to be truly useful to our industry? And what don’t we know yet?

What is HTML5?

If you’re not familiar with exactly what HTML5 is yet, here are a few definitions before we go further.

HTML5 is technically the latest version of the HTML specification, but it's commonly used to refer to the combination of three technologies together: HTML5, CSS3 (the latest version of Cascading Style Sheets), and JavaScript. Together, they are known as the HTML5 stack, and that’s what “HTML5” will refer to in this article. HTML is the markup language, CSS determines how it is rendered, and JavaScript is the programming language; the combination of them provides the capability for a rich user experience similar to what we normally think of as the product of Flash or Silverlight. At the end of this article, I have provided links to examples that I hope will help illustrate what HTML5 can do where dry, technical explanations fail – but remember, you’ll need an HTML5-compatible Internet browser to view them (more on that later).

The features and elements of HTML5

HTML5 provides that aforementioned rich user experience primarily through the use of the new <canvas> and <SVG> elements, which can be placed in the HTML code much like the <image> tag has been used for decades. When a SWF is inserted in HTML, the browser needs the Flash Player plugin to be able to play it – and, for that matter, different plugins are needed to play anything output by Silverlight, Quicktime, or Authorware. These new elements won't require the use of plugins. In addition, HTML5 supports drag and drop – an extremely common interaction type in e-Learning development – within the code itself.

There is also a number of features that allow more data to be stored on the learner's computer, either temporarily or long-term. localStorage and sessionStorage allow for text to be stored locally by a browser either indefinitely (in the case of localStorage) or while that browser window is still open (in the case of sessionStorage). Offline Web applications are pretty much what they sound like: to quote the HTML5 Working Draft, they “enable users to continue interacting with Web applications and documents even when their network connection is unavailable.” Like, when our users are on planes? Or submarines? Sounds good to me … as long as it works!

Two other new native elements are <audio> and <video>, which (I’m sure you’ve guessed by now) allow you place audio and video files directly in the HTML code. The browser then decides which method to use to play them, much like what happens today with images. Though supported video formats have undergone some controversy, the general consensus at this point is that HTML5-compliant browsers will be able to interpret H.264-encoded movies on their own, so movies don’t need to be encapsulated as FLVs or MOVs (which, again, would require the learner to have the appropriate plugin).

The browser: if you build it, can they interpret it?

What learners will need to have, instead of a collection of plugins, is an HTML5-compliant browser. So it’s important to note that right now, the HTML5 specification is not complete, and it is not expected to reach W3C Recommendation stage (the stage the current version of HTML is in) until at least 2022. Having said that, this oft-quoted statistic can be misleading; the real test of whether HTML5 is viable for you to use is whether your learners' browsers are able to interpret the new code. You may be surprised to find out that much of an HTML5-published page is already supported on whichever browser you're already using, because much of HTML5 encompasses technology that is already in use. So a course or Website that is output to HTML5 will be perfectly readable in older browsers except for any code that is not supported in previous versions of HTML. But even then, most of the HTML5 specification is already supported on the most recent versions of Firefox, Chrome, Opera, and Safari. Even Microsoft (late to the party, but very important due to Internet Explorer's market dominance) has announced HTML5 support for IE9.

That’s a pretty impressive adoption rate for a major new technology, and it's being mirrored by more sites cropping up every day that now offer an HTML5 option in addition to the plugin-based technology they've been utilizing for years. And that "in addition to" is important: even though the debate is often framed as HTML5 vs. Flash or FLV vs. H.264, browsers have had the ability for years to customize which content you see based on which browser you're using to view the site. That's why you may get an entirely different version of a site when you visit on your mobile device instead of your desktop computer. And it can get far more granular than that: Sites that serve up video and aim to appeal to large audiences will have – or already have – different video formats available depending on who's visiting and what technology they're using. YouTube and Vimeo now offer an HTML5 option for most of their videos... again, only for users with compliant browsers.

Where's the beef?

So what, if anything, does this new technology enable us to do better?

The main reason I started getting interested in HTML5 was Flash’s security issues. Okay ... to tell the truth, I don’t care all that much about Flash’s security issues; I care about the security restrictions that I have to work around in order to do my job, designing and developing e-Learning. I try to integrate my courses with existing resources as much as possible, and these resources are usually on my company's intranet.This practice shortens development and revision timelines because some of the course content is “outsourced” to external content, it makes my learners aware of standalone resources so that they don’t have to retake whole modules, and it encourages exploration outside of the strict confines of the course.

Flash is a powerful tool; so much so that it can be used to impact your computer in malicious ways. So things like linking to external content – whether on the local computer or on a network – are limited. The same limitations exist when you integrate Flash content with HTML in a way that the SWF tells the HTML code to do something: for example, embedding a Captivate simulation in a Lectora title, and then putting actions in Captivate to make the navigation buttons in the Lectora title active when the simulation is completed successfully.

There are workarounds to the limitations, of course, but they involve tradeoffs in the final product, or more expertise, or better tools. For example, setting playback security can be done in Flash itself, but not in Captivate or in any other rapid authoring tool I’m aware of. The extra effort is worth it to me, because I try to make things just work on the learners' end as much as possible. But if I could get rid of expending that extra effort and still provide a product that is uncompromised in appearance or functionality, I would.

HTML5 doesn’t have these security issues to be worked around... at least not yet. In a page displaying only HTML5 elements, all of the interaction the learner has with the browser are just that; there is no need to manage security of elements that are delivered via plugins. Granted, eventually there may be security restrictions for HTML5 as it gets more powerful (even Tim Berners-Lee expresses uncertainty about that), but from what I can see so far, there won’t be a need for restrictions on the kinds of interactions used in even a rather robust e-Learning course.

And then there is openness. And I'm not talking about whether something is open-source or license-free, which is what a lot of the debate about HTML5 and related technologies has focused on. I'm talking about what happens when another branch of your company sends you an e-Learning module that your branch could easily adapt and reuse – if you only had the software and/or the native files originally used to develop the course. In an ideal world, the person sending the course to you would know that you need the native files, not the published files, and would have gotten the native files from the developer and archived them, and your two branches would be using the same development software as each other, and if any of these were untrue, your boss would understand and give you plenty of time to redevelop the course. But who among us develops e-Learning in that world? I’ll wait... No one? Okay then, let’s talk real life.

If what arrives at your door is all inside a SWF, you’ll need a decompiler to get at it. What you get as a result of the decompilation is going to depend on which tool was used to create the SWF. Where you go from there depends on your expertise.

On the other hand, if you’re given a collection of HTML files, minor edits can be made in Notepad or TextEdit, and they are usually pretty easy to do – even for novices – given some Find and Replace skills. If you can't figure out how to change what you want, you can hand the code to over to a vendor and at least they will have the right raw materials to work with. And that vendor won’t have to be a specialist in e-Learning development software and how each tool compiles SWFs; pretty much any Web developer who works with current technology will do. So clearly there are some benefits to working with HTML5 in the development and revision cycle.

The case for HTML5 in mLearning

Once you include mLearning in the conversation, though, the advantages to using HTML5 get more significant. MLearning designers and developers – and mLearning itself – have suffered for years because developing mLearning is like trying to hit a moving target; once you have a product out, the devices it was designed for are obsolete, due to the very short lifespan of most mobile device product cycles.

If those developers were developing desktop-based e-Learning instead, they would have a pretty good solution to this compatibility problem: Flash. But Flash Player’s ubiquity on desktops and laptops doesn’t extend to mobile devices. Currently, there are no smartphones or mobile devices that run Flash formats, because Flash Mobile – the version of Flash Player that Adobe is working on for mobile devices – has been delayed several times. Recent demonstrations meant to show how close Flash Mobile is to market have been somewhat lacking, though there are other demos that show it working just fine.

On the other hand, as of this writing, almost all mobile devices on the market today have browsers that already support much of HTML5. It’s a good choice for mobile devices because rendering HTML5 code is generally not very processor-intensive compared to alternatives we’ve seen so far, and as mobile device manufacturers push the envelope to accommodate user demand for increased speed and multitasking, it just seems smarter to develop content using technology that demands less bandwidth and processing power. And with HTML5, mobile devices' short product cycles become a good thing instead of a liability, as new devices generally mean new and more updated browsers.

But I think on some level, we all expect that Flash Mobile will be released, probably soon, and already there is no shortage of device manufacturers that want it on their machines. At that point, mLearning designers and developers will have to decide which delivery route to take based on Flash Mobile’s performance and which devices their learners are using. And it might come into play that while Apple devices (iPad, iPhone, and iPod Touch) already support HTML5 very well, right now it looks pretty unlikely that they will ever support Flash. Or that might not matter… again, depending on your audience.

The final challenges

That brings me to the final challenges we will face in developing HTML5 content for both e-Learning and mLearning.

Browser adoption

The first challenge is browser adoption, which we've already touched on. This is an area in which you really need to know your learners and their technology; if you’re developing for a corporation, you most likely have the advantage of knowing exactly which browser your learners will be using, but you may well also have the disadvantage of developing for an older browser than consumers would have. The older-browser issue may be problematic for mLearning developers who are working for corporations as well, because Blackberries and other RIM devices – generally more popular in corporations than other mobile devices – are behind other smartphones in terms of having a browser that supports HTML5.

Development software

The second challenge is development software. Rapid development tools are proliferating in the e-Learning world, and whether that’s due to shrinking training departments or faster development times needed in a down economy or some other cause, it’s pretty clear that few e-Learning designers roll their own code. We have software that does it for us, or we have developers who run that software for us, and most of that software outputs to Flash delivery formats. Right now, HTML5 is so new that if you look around Web development forums, you will see developers asking each other if there any programs already out that create HTML5 output. From what I can tell, there aren't many. And that leads me to believe that it will be a while before we will see any such software that is specialized for creating learning experiences.

That is, except for these two considerations:

First, there are already specialized e-Learning/mLearning development tools that output to HTML; Lectora would be the one that currently has the most market share. The introduction of HTML5 (and, specifically, its prevalence on mobile devices) could be a tremendous opportunity for those software publishers who, despite a lot of pressure from their users, never rewrote their software to export everything to SWF.

Second, even if Flash were to go away next year as a delivery format, that doesn’t mean for a second that Adobe would go with it. Adobe has Dreamweaver, which is already a premiere HTML development tool, and it has Flash, which is a premiere animation tool, and both of them are already very much in use in learning development. Adobe has already demonstrated HTML5-output tools for both programs, and while those features didn't end up shipping with CS5, the company has now announced an upgrade pack for Dreamweaver that will allow for HTML5 output.

And while neither Dreamweaver nor Flash is a specialized learning development tool, Captivate certainly is, and if Flash can be adapted to output to <canvas>, Captivate can too… if Adobe wants it to. And Adobe could have something else up its sleeve, as well, but whatever it is, it has vowed to make tools that produce HTML5 output, and it’s clearly determined to stay in the game… even when the rules of the game change.


So after all of this, what is the future of HTML5 in e-Learning and mLearning? I’m not going to make any wild predictions, particularly because there have been so many made over the years about where e-Learning and mLearning should be already, and many of them have fallen flat. I think it’s pretty obvious that we will see HTML5’s prevalence increase on the Internet – both because it’s a promising technology and because it’s at such an early stage that pretty much the only place it can go is up. And when we see that our learners are ready, and we have the tools to provide the content, we will get there too.

But that’s enough talk for now. I’ve collected the 20 examples below to show a few things that Web developers are already doing with HTML5, and I’ve tried to keep it relevant to the kinds of output we want and need in developing e-Learning and mLearning. You won’t see any learning objectives below, but I think you’ll be able to see a few ways HTML5 could be used in your courses and applications.

Remember, you’ll need an HTML5-friendly browser to use these. I’ve tested all of the below in the latest versions of Firefox and Safari, and noted some that don’t work as well in one browser or the other. If you’d like to explore other browsers, click here to see which ones support the different HTML5 elements. (Or click here for a cool graphical view.)

Twenty examples of HTML5 in use

  1. HTML5 Canvas and Audio Experiment
    Chosen for: Visual impressiveness, interactivity. Click on the bubbles to see tweets about HTML5 and related technologies. Some tweets feature active hyperlinks from inside the <canvas> tag… a feature I’m particularly interested in.

  2. Dynamic Content Injection
    Chosen for: Interactivity. Works best in Firefox 3.5+. Click any of the boxes on the right to add images, text, videos, etc. to the video on the left. The video changes dynamically as you change the input.

  3. Bonadies Architect
    Chosen for: Visual impressiveness (at least for an HTML-only site). This reminds me of a lot of basic Flash sites out there today. I think some of the functionality requires more clicks than it should, but it shows that you can make good or bad design choices on any platform.

  4. Sketchpad - Online Paint/Drawing application
    Chosen for: Interactivity. This is an impressively full-featured sketch program.

  5. Gartic - Canvas Sketch
    Chosen for: Interactivity. This is a much simpler sketch program, but it has a cool feature that allows you to reanimate your drawing process. Try the drawing game, too.

  6. A simple drawing program using javascript
    Chosen for: Interactivity. Another sketch program, with a slightly different take.

  7. Harmony
    Chosen for: Interactivity and visual impressiveness. This is the last sketch program, I promise... It’s so cool I absolutely couldn’t leave it out. Be sure to try different options at the top.

  8. Function Plotter
    Chosen for: Interactivity. I may not ever teach math in corporate e-Learning courses, but I would definitely use graphs to show the results of different choices. And of course, you might use something just like this in an academic course.

  9. Matrix Rain
    Chosen for: Visual impressiveness. Works best in Firefox 3.5+. It’s just pretty.

  10. HTML5 Canvas Animation
    Chosen for: Similarity to e-Learning staples. Just an animated cartoon, similar to some uses of Flash or Silverlight.

  11. spread
    Chosen for: Visual impressiveness and interactivity. However, you can determine how the drawing evolves, so it’s interactive, as well.

  12. Chrome Canopy

  13. making waves with HTML5
    Ditto again.

  14. html 5 canvas test
    Ditto again.

  15. Hypertree - Tree Animation
    Chosen for: Interactivity. I could see using this kind of functionality to let learners explore a map or org chart. Bonus: Here is another one, based on a similar idea.

  16. ContentEditable
    Chosen for: Interactivity. This is a good, simple demonstration of editable text and localStorage; edit text in the box, close the window, and then click the link again.

  17. Drag and drop
    Chosen for: Similarity to e-Learning staples. Because what would we do without drag and drop?

  18. Internet Graffiti Board
    Chosen for: Interactivity. Anyone can come and draw on this, and the graffiti stays around for the public to play with. Not so impressive as a sketch program, but cool for its “bulletin board”-like functionality.

  19. jsCanvasBike
    Chosen for: Interactivity. There are tons of HTML5 games out there, many of which are more complex; I just liked that this one was easy to get the hang of immediately.

  20. Spark
    Chosen for: Interactivity. Since most of the above examples assume a keyboard or mouse (or both) instead of a touchscreen, here’s a cool touch-only example. Be sure to change the mode at the top, and touch using as many fingers as you can!

Want more? Many of the above examples are referenced in the following collections:


Topics Covered

Appreciate this!
Google Plusone Twitter LinkedIn Pinterest Facebook Email Print

Login or subscribe to comment

Please add to your list, which converts SWFs to Javascript on the fly. Only in preview now and reviews point out its imperfection, but the idea has significant implications for what part of the future of Flash might look like.
Great article, thank you.

Yes, there are several new technologies coming out now that convert Flash output to an HTML5-compatible output of some sort. Brightcove, for instance, enables conversion from Flash video to HTML5-compatible video on iPads and other non-Flash-enabled devices... For a more complete explanation, see this TechCrunch article:

Thanks for adding to the conversation... there is new information coming out on this topic every day! I've focused on providing examples of what HTML5 can do in this article, but there are certainly many resources and tools out there, as well. Feel free to list and discuss them here.
Thanks for the article, Judy (and LSM). I'm one of those guys who has always hated developing in Flash, so my feelings won't be hurt if HTML5 takes over. The only reason I can think of to support Flash at all is in hopes of giving Apple a black eye. ;-}

But the BIGGER question, the one not even addressed in this article, is this:

WHY "e-Learning" (w/ dash) and "mLearning" (w/out dash)?

Down with the dashes: Long live eLearning!
Some background before I take issue with some assumptions in this article: I've written several how-to books (several years ago) on using Flash and Dreamweaver to create e-learning and have built e-learning in both HTML/CSS/Javascript and in Flash, have been doing e-learning for over 12 years, so I have some pretty strong opinions.

First of all, very good article. Appreciate the sample links. HTML is impressive and will surely take market share from Flash, but trying to compare the current state of HTML to Flash capabilities is like comparing a nice low-end Hyundai to a Ferrari. The examples shown here are a lot like old Flash 2 samples. Let's be real. There is NO COMPARISON in HTML 5 to what you can do in Flash. Actionscript 3 as an object-oriented language along with Flash Player 10 is several magnitudes more powerful in its capabilities for interactive e-learning than HTML5. HTML5 will grow in its adoption, but replacing Flash in a serious way will take years and unless adoption of the specification is more robust than adoptions of CSS and Javascript in the past, it will be plagued with cross-browser compatibility problems, which is why Flash has been a God-send to the e-learning development community.

Fortunately at Rapid Intake we store data in XML which means learning content can be re-purposed to HTML5 if needed. That said, my prediction is that Flash is and will remain the most powerful influence on e-learning for years to come, in spite of what Steve Jobs says. The ecosystem built up around Flash is enormous and cannot be discounted with a few web articles.

In case anyone is interested, here's my blog entry on the subject:

Garin Hess | CEO
Rapid Intake
garinhess, I’m struck by how much we agree on the facts of this debate. However, nowhere did I assume that HTML5 currently has all of the capabilities of Flash; in fact, I implied or stated just the opposite in a few places.

Flash is a mature technology and HTML5 currently is not; I wrote the article to clear up some of the confusion about whether this new technology is useful to our industry at this time, and it takes a very wait-and-see approach. Even if the development technology were there right now (which it’s not), the delivery technology is still very much in the future for most corporations (which I stated)… at least as regards elearning. With mlearning, I would (and did) take a more pro-HTML5 stance.

I’m also not attacking Flash; Flash just serves as a useful point of comparison right now because of its market dominance. It has been a boon for years to web developers trying to create more interesting and interactive experiences, and now there are technologies being developed that aim to do as well at this as Flash has done, without some of the issues presented by Flash and other plugin-based technologies. This article was just about examining the current state of those technologies. I intend to continue that exploration as progress is made, focusing specifically on whether HTML5 serves the needs of the elearning community.

Clearly, as I’ve written, this is a hugely controversial topic, and it’s not just authoring tool vendors that are heavily invested in Flash-based technology… developers and designers are, as well. I applaud tools and developers who use solutions like XML to address some of the limitations in Flash and Silverlight; this is exactly the kind of openness I addressed in the article as being an inherent advantage to HTML (5 or otherwise). Integrating these solutions promotes much greater flexibility in development and delivery, and it allows all of us to weather changes in technology that are sure to come.

As for the *real* controversy... FatherEric, I believe the e-Learning/mLearning thing is LS Mag’s standard… I typically just treat both as regular words (like email) but clearly this is still highly debatable topic in our world, too! ;D
Extremely well written and formulated piece. I agree with most of your observations and thank you for the informative and beneficial links. Time will tell if a true "winner" will prevail.
EduCons Canada
What a wonderfully level-headed article. Question: HTML 5 won't allow for the syncing of say audio or video to text? My impression of working with Flash and eLearning is that ActionScript and the timeline of Flash allow for the development of more interactive, engaging and high quality product. Right? HTML5 as it's currently being discussed does not allow for this?
To everyone I have not addressed, thank you so much for your comments.

hrichman, I have not seen any examples yet of the audio/video-to-text syncing that you've mentioned yet. I have seen interactivity demonstrated between video and the encompassing HTML (such as links embedded in the video); however, video is still one of the bigger question marks about HTML5, as no video format has been decided upon definitively (and it's possible that the format could drive different capabilities). If anyone can provide examples, please do.

As for interactivity/engagement, first, I should acknowledge again that HTML5 is not "done", so any comments on its potential have to be considered "as of this writing".

Second -- and this is really the tricky part -- what is your definition of interactivity and engagement? I'm sure you know that in elearning, those words are pretty loaded. If you mean visual impressiveness, I think you'll see in some of the examples above that HTML5 is a pretty good match for Flash. If you want the learning module to be able to respond to the learners' inputs, remember that JavaScript is the programming part of the HTML5 stack, so when you talk about HTML5's capabilities in terms of programming, you're really talking about what's possible with JavaScript, which is very powerful.

I tend to communicate (and learn) by examples, and more and more impressive demonstrations are coming out every day. This one isn't brand-new but somehow I just ran across it this weekend: Google engineers have ported Quake 2 into the tag of HTML5. While it's a very common argument among Flash developers that HTML5 only has the capabilities of early versions of Flash right now, I think this video will show that that's not really the case. (Please be aware that Quake 2 is a violent video game.)
Oops, the comment system didn't like me enclosing the word "canvas" as a tag.
Thanks for the follow up comment Judy. I'm not really defending Flash either, per se. And I suppose the passion behind my comments are there because it appears many in the tech community at large and in the media are falling within that Jobs' "reality distortion field" -- very few are acknowledging the size and momentum of the Flash ecosystem that has been developed. It's great to point out the potential benefits of HTML5, but let's not forget the incredible benefits that Flash affords us and the reasons it got to where it is today. They are still so very important.
Thank you Judy for bringing up in such a detailed way and large issue that is looming in our industry. Some of us are old enough to have experienced the transition from hard coding to scripting languages like HTML and Flash. Allen as a company bloomed through the HTML to Flash transition.. As has been mentioned by others, XML strategies coupled with the capabilities of Flash scripting has enabled us to provide some truly immersive customer experiences that impact transfer of knowledge and change behavior.

As for HTML(5), it is as you mention really a matter of time and for sure less time then many of us would think. At this point in time if we use as a bench mark the ability to ensure a good consistent user experience,,, we are careful in how we are implementing HTML5. In areas of customer education or scenarios where the client has less control over the end user platform (browser and device) we are careful to utilize technologies and designs that will play on multiple platforms. Common technologies such as HTML, CSS, JavaScript, Videos, etc… can be used across multiple platforms to create an engaging experience.

Targeting specific platforms, we have also used both Flash/XML and HTML5 technologies for customers who want to provide the best experience possible for each platform device and still have the broadest audience reach.

Traditionally Flash and HTML5 technologies have been used to create Web Apps but are now also viable options to create full or hybrid Native Apps that will play on multiple platforms devices natively. Allen is using and researching tools like:

Adobe Air to deploy Flash and FlashBuilder activities and animations to multiple platforms in the form of Web and Native Apps.
Adobe Edge using Animate and PhoneGap to deploy HTML and HTML5 to multiple platforms in the form of Web and Native Apps.

Adobe Digital Publishing Suite to create and design publications for tablet devices.

Sencha Touch: which is a JavaScript framework that can deploy HTML/HTML5 based apps to multiple platforms.

Corona SDK: Which uses Lua and OpenGL to publish games and animation to multiple platforms.

RhoMobile, WebMobi and many others..

to create such engaging experiences that can be delivered to multiple platforms.

Another way of looking at this dilemma is to ignore the noise and let your business needs and specific technological and user environment inform your decision.

We are surprised at how many of our customers can make informed decisions just by targeting a select range of devices that are corporate standard issue or that are the most common Apple or Android based devices within an organization.

Taking to much of a long view in this area may lead to paralysis since platforms are not equal in technologies they employ or the technology standards they choose to implement.
Related Articles