When producing the learning resources for teacherLED.com lately I’ve been acutely conscious that they’re not compatible with a growing number of devices used with the internet: all Apple mobile devices.
For those who don’t follow technology developments Apple refuses to allow Flash player to run on any of its mobile devices. Microsoft is also reducing the reliance on Flash for web experiences in its new Windows 8 operating system. Flash Player is a virtual computer meaning that it works like a separate computer running on another. This virtual computer means that software designers can write for it rather than have to produce a different program for each computer that exists. In teacherLED’s case each IWB resource will work identically on a Mac, a PC or a Linux based machine. But if there is no Flash Player on a computer they cannot work on it.
Apple chose to not allow Flash Player on the iPod Touch, iPhone, or iPad for a variety of reasons. These reasons have not gone unchallenged but rather than get into whether it is right or fair this article will attempt to explain what this means for sites that produce resources and teachers who use them.
Flash Player is unlikely to disappear from desktop machines any time soon. It is on nearly all of them. Resource sites that have made heavy use of Flash, such as mine, will remain usable for a long time to come for their intended purpose. However, while it is ubiquitous on desktop machines, and likely to remain so, the growing number of mobile internet connected devices means that its overall presence across all internet using devices will decrease. Furthermore while mobile devices other than Apple’s will allow Flash the performance is not good. Flash seems powerful on a desktop machine because of the sheer amount of power available. Any virtual machine can only provide a fraction of its host’s power as it has to translate between the virtual machine and the real machine on which it resides. No problem on a desktop but an issue on the significantly less powerful mobile devices. Additionally the harder a computer has to work the more power it drains. Again not a problem when connected to the wall socket but a different matter on a mobile device. All of these conspire to leave Flash as not the universal solution it once was.
All sites will have to think about how to deal with this.
The options:
Ignore non Flash enabled devices.
Definitely an option – particularly for IWB resource sites. An IWB can display an iPad’s output but cannot yet be interacted with via the whiteboard itself but most IWBs are connected to a desktop computer. Therefore nothing changes. Flash remains a powerful and common platform which continues to evolve.
Go native.
Produce each resource specifically for each machine in its own language. Most apps fall into this case. Here the performance is not an issue. There is no need for a virtual machine to translate so no performance is lost to this. On the downside every platform needs a specifically created resource. Those produced for an Apple device will not work on any other machine. In the case of Apple a developer must also pay to be able to put his or her creations on to a device. The facility to make a program for, say an iPad, and then try it on the iPad does not exist out of the box. The outcome of this is that most apps produced this way will end up on the App store as downloadable apps that have to be paid for in some way or perpetually show advertisements.
Use HTML5.
The language of the web is undergoing revision. As part of this there are new possibilities. One is called the Canvas tag. This allows things that were previously only possible on Flash to be done on a browser that has not had any new plug-ins, such as Flash Player, added to it. In particular this allows manipulatable elements to be displayed on screen. As this is a web standard all browsers should support it and it is not dependent on a plug-in being downloaded.
The downside to HTML5 is that while it is meant to be a standard, in practise each browser does things slightly differently. Whereas a resource programmed in Flash will work the same on any machine, as the Flash Player is controlled and updated a by its owning company Adobe, HTML5 may have differences across browsers. At the moment it is also less sophisticated with less features available to the programmer, or at least they are much harder to implement. Neither is it as a powerful. The sophisticated games seen on Flash are not yet possible in a standard browser. Furthermore schools are very slow to update. Technicians often prefer to maintain the status quo that works rather than update to new software versions. HTML5 requires a recent browser. In particular Internet Explorer 9 is the first of the IE browsers to be compatible so if your technician has not upgraded the school browsers (they should) HTML5 resources will not work.
The route I have decided to take with teacherLED is to use HTML5 where possible to maximise future compatibility and not ignore the growing popularity of tablets. Where the extra features are required I will use Flash. While I hope to in the future release some natively developed apps I am keen to continue to provide free to access, advertisement free resources to teachers. At this point it is impossible to provide a working solution for all users, I either exclude newer technology which is gradually making inroads into the classroom, or I exclude those whose schools are not upgrading their browsers. If you do have an up to date browser you will have free choice over what to use. Flash or HTML5 resources.
Unfortunately as I am the only person working on this site the creation of multiple versions of each resource is not feasible. That being said the first resource to use HTML5 is a new version of the popular Clock Spin. Another post will explain why I’ve done this. Actually this post explains why I’ve changed my mind in only 2 days.
Hi Spencer,
This is a very interesting article, and an interesting decision you have taken with your development. I wish you luck with HTML 5 and will be interested to see how you get on. I have been looking at HTML 5 as a solution for delivering interactively, but from the off, it obviously provides challenges for commercial development of interactive resources, as all of the source code is left open!!! (though it is apparently possible to obfuscate Javascript classes). I note your comments on the performance of the Flash Player in terms of power usage and battery life, but what I have found thus far is that viewing HTML 5 experiments causes massive processor and memory usage for various interactive operations. Your first clock example performs particularly poorly in FireFox 7 (Win XP), and while I understand that it is essentially v0.001, I am of the opinion that HTML5 is not yet a tool with which to create the learning experiences that we are striving for. That said, I hope you get somewhere with it.
Best of luck,
Cas
P.S. If you would like to discuss what I have seen so far and any links for HTML 5 material, you can send me an email.
Thank you for thoughts. They do highlight a number of the problems that exist now in choosing the best technology. In particular your comments about poor performance in Firefox 7 on XP. On releasing the clock resource I had checked it on iPad Safari, Mac Safari, Windows Vista IE 9 and Vista Firefox 7. All seem to run fine but I don’t have any XP machines to test on (a problem as many schools are still on XP). THis was a problem I just didn’t have with Flash. The only differences would come from basic processor performance. As long as a resource ran on an average desktop machine it would be fine on all. Now I am faced with checking on every machine I have and still their might be problems on ones I don’t. The problem is compunded by the fact that HTML5 is boosted on an iPad by the support of the GPU. So this doesn’t count as a low end machine which it would if I went only be the processor. In regards to future optimisations I’m not sure what I could do. It isn’t a massively complex program and aside from, perhaps, some minor tweaks I don’t see where changes could be made to improve the performance significantly. Perhaps in the frameworks I used but they are made by far better programmers than I am so I’m sure they’re already pretty efficient.
Not only machine differences but browser differences exist. I find FIrefox to have the least pleasing rendering engine. IE9 and Safari produce the graphics as they should look, Firefox’s aren’t quite right showing less antialiasing and some graphical glitches. Although varying ones depending on the machine..
In regards to the comparison of Flash and HTML5 everything just depends it seems. Having an Android phone that can run Flash I can see why Apple decided against it as to be honest its performance is so bad its inclusion matters little to me although it was when I bought something I particularly wanted. The HTML5 clock however runs pretty good-just a little slow to pick up touch events. My comments on battery usage are based on what others have said and the fact that portable devices seem to be really struggling to keep up with Flash but are okay-ish with the clock.
The open source code is a problem but to be fair it isn’t much worse than with Flash. It is fairly trivial to decompile Flash and while it can be obfuscated swapping of graphics etc would allow illegal rebranding without too much worry. THe same is true with Javascript. I used the limejs framework for the clock resource (very nice to work with) and this uses Google Closure and hence the Google Closure Compiler which obfuscates the javascript as a side effect of increasing its efficency. Still it would be trivial to download and swap out graphics. (Note to whole world: please don’t.)
The situation at the moment is incredibly frustrating. While I understand the desire to move away from proprietary plug-ins it feels like we have taken a step backwards. I can no longer write once deploy anywhere. I also miss the power of Flash. On a desktop machine at least, Flash is capable of far more than HTML5, and it uses, in my opinion, a more powerful language. What should worry anyone who is providing online resources is suddenly realising one day that Flash player penetration has dropped to a small subsection of devices and that everything needs rewriting or a a whole swathe of users must be lost. This may never happen but the growth in the iPad makes it something we shouldn’t ignore either. For teacherLED it is just me and my free time so I can’t write a Flash and a HTML5 version as is perhaps ideal at the moment. Professional sites perhaps could but interestingly they aren’t. Releasing paid for apps seems to be the main way of addressing the iPad users. But this then means the days of free resources on line are numbered. (As a side point if the number of Education Authorities increase who filter out all advertisements in schools I can see this happening anyway – they need to stop and think about how the resources they use are free. )
So it seems that to fulfill the dream of a plugin free, non-proprietary, universal compatibility future we have to put up with a fragmented, poor performing present!
As I said in a tweet yesterday: Flash how I miss thee!