When the iPad was launched in 2010, the world was somewhat shocked about Steve Jobs’ “Flash Attack,” banning Adobe’s popular multi-media player from iOS devices, claiming it was buggy and insecure.
It took five years for the rest of the world to openly subscribe to Jobs’ sentiments, but there’s no denying it now – Flash has supplanted Internet Explorer 6 as public Web enemy No. 1.
- Google now blocks auto-playing of Flash videos.
- Amazon has axed Flash ads.
- Facebook has called for an end-of-life date on Flash.
- Firefox kills Flash by default in its browser.
And while rigor mortis has not set in quite yet, the ripple effects of Flash’s pending demise have many publishers wondering how they will sufficiently serve all of their readers when the underlying publishing technology they use is Flash-based.
Many of those platform vendors are announcing moves to HTML5, which is great. But that doesn’t solve the problem for the millions of readers who still use older browsers that don’t, and never will, adequately support HTML5.
Stuck in the past
Would it shock you to know that one-fifth of all computers still run Windows XP? Released in 2001, the highly popular operating system (which should have been put to bed in 2009) was given an end-of-life extension by Microsoft until 2014. And even though it’s no longer supported and is vulnerable to security risks, it still retains a sizable fan base.
I’ve seen this mind-boggling reality in action in the 16,000+ libraries worldwide that offer sponsored access to PressReader for their patrons. Many still use antiquated browsers and see no reason to invest in an upgrade.
To understand how big that audience really is, I decided to look at one month of PressReader access to see what percentage of our 30 million readers were using older browsers without ample HTML5 support.
I discovered that more than 15% of our readers (approximately four million people) still use HTML4 browsers to consume our publishing partners’ content. If one were to extrapolate that to all online newspaper readers in just the United States, we’d be looking at more than 26 million people!
Suggesting that they all upgrade their browsers to enjoy an HTML5 reading experience is like asking Donald Trump to don a new hair style. It just ain’t going to happen unless “The Donald” does the unthinkable and becomes the next president of the United States.
There needs to be another solution – one that offers support for older browsers without the baggage that’s been inherent in Flash from the beginning.
In 1993, two years before the consumerisation of the Internet, two talented techies set out to create a graphics editor for “pen” computers. Their vector-drawing programme evolved into a Web animation tool and was snapped up by Macromedia in 1996 (after Adobe turned down an offer to buy it in 1995).
Over the next nine years, the technology matured and evolved into the ubiquitous Web application platform of this century; Macromedia Flash was everywhere.
There was little competition for the “de facto standard” at the time, except for one – SVG (scalable vector graphics) – the official W3C standard that provided an XML-based vector image format for two-dimensional graphics with support for interactivity and animation.
Now, unless you’re a software developer, you might never have heard of SVG. But the 16-year-old standard has been supported by every major browser for many years and is a key element of HTML5.
The use of SVG in the design of most publishing platforms today is almost non-existent, not because it’s not a superior technology to Flash, but because Flash was perceived to be the easier and faster road to revenues.
SVG vs. Flash
SVG and Flash have a lot in common. They are both vector-based and support animation, hyperlinking, database connectivity, and scripting.
But there are some significant differences between them, not the least of which is the fact that Flash is a proprietary technology controlled by a single vendor, while SVG is an open standard supported by many.
SVG also trumps Flash with all the advantages of XML, including:
- Easy integration with emerging XML standards, standard APIs, and Web services.
- No need for plug-ins on major browsers.
- Being mobile-friendly.
But developing digital publishing solutions using only open standard technologies (e.g. HTML, SVG) takes more time and talent than building a Flash-based one. Which is why there are dozens of platforms that use Flash for newspaper and magazine publishing, all of which are vulnerable to Flash’s critical security issues, poor performance, and chronic instabilities.
I only know of one publishing platform that is completely “Flash-free” and supports both HTML4 and HTML5 browsers. If you know of any others that meet all that criteria, please share what they are in the comments below.
History keeps repeating itself
Flash wasn’t the only technology bandwagon that publishers hopped on with high hopes. Banner ads were also the easy choice for newspaper and magazines executives looking to capitalise on digital.
But look what happened to them. Not only did they not deliver more than digital dimes to the bottom lines of headlines, they annoyed readers to the point that a growing list of more than 200 million people are now using ad blocking software to avoid ever having to see them again.
And ads aren’t the only things being blocked. More and more browsers are also offering users a clutter-free reading experience by stripping out all the “non-essential” content with just a click.
It won’t be long before the Web will be an ad- and image-free zone, where the only content readers will see is what they opt-in for.
Beware of what’s too good to be true
Like many other industries fooled by Flash, the publishing community has been too quick to jump on cheaper short-term solutions without considering the longer-term consequences of their actions.
If history has taught us anything, it’s that we need to think several steps ahead of where we are now when choosing technologies. Flash and banner ads were just two myopic moves of many we’ve made throughout the last decade. Heading down the proprietary native app development road was another.
It seemed so easy five years ago to build apps in-house, but, in the end, the development:
- Cost too much.
- Didn’t pay back anticipated dividends.
- Limited the distribution of content to only a few select platforms.
Publishers need to be more like chess masters, making strategic decisions based on long-term gain, not on short-term pain. No one ever said it would be easy; but it really is that simple.