Ongoing Misunderstanding of Flash and HTML5

The latest article that uses absolutes and broad generalizations to imply an otherwise non-existent struggle between Flash and HTML5 is from UX Booth, "What the Demise of Flash Means for the User Experience." To be fair to this article, I see regular missives on Flash vs. HTML5 and this particular UX Booth article is just an example of many of them in one easy to cite place.

The opening gives away the false premises for the rest of the piece:

Adobe's decision to cease development of the mobile Flash platform and increase their investment in HTML5-related efforts created perhaps the final piece of conclusive evidence that HTML5 is the current go-to technology for creating ubiquitous user experiences regardless of device.

First I have to accept that the author is talking about more than the HTML5 specification and is also referring to CSS3, JavaScript, and the W3C specifications that are related to HTML5. This lack of clear delineation chips away at the argument.

Adobe has held that the fragmentation of mobile devices is too hard to keep up with on its own. Flash will still exist for mobile wrapped in AIR applications instead, and Flash is not going away from the desktop. Adobe's decision to increase investment in HTML5 (via Edge and to a lesser extent Muse) is mostly unrelated since there is a market for an HTML5 authoring tool independent of Flash.

Not only is this neither conclusive nor the final piece of evidence that HTML5 is the current go-to technology, this is anecdotal evidence at best. In addition, HTML5 itself is nowhere near complete and the element often regarded as the Flash-killer, canvas, isn't anywhere near as robust as Flash and still lacks strong scripting or styling support in the specs.

I think it's fair to challenge the claim that HTML5 creates "ubiquitous user experiences regardless of device" when you consider all the polyfills and shims that need to be implemented to create similar experiences on a few devices. It's also fair to say that my netbook does not handle some of the related HTML5 specifications the same as my tablet or mobile phone, partly due to various levels of hardware and browser support. Let's not even get into video and audio codecs or the touch events specification (neither of which are part of the core HTML5 specification).

HTML5 excels at giving users a delightfully inconsistent experience on any device through the concepts of "graceful degradation" and "progressive enhancement."

Those terms pre-date HTML5 and I can do both with HTML4 and CSS2. The author continues on and cites responsive design as a feature of HTML5, even though my own site is an example of an HTML4 site using responsive design to adapt to assorted displays.

Additionally, more than 90 percent of all smartphones and tablets are HTML5-enabled, which means that all the benefits of HTML5 can be utilized today to provide impressive mobile websites.

The author's math doesn't bear out the assertion — by the author's numbers, 10% are not HTML5-enabled and so cannot benefit from HTML5. For the other 90% that are, even they cannot enjoy all (author's word) the benefits of HTML5 today.

Making or upgrading to an HTML5 site can be as minimal as simply using HTML5's doctype [...]

The implication here is that simply changing a doctype gets you all the benefits of HTML5, when in reality you still have the same HTML, CSS and script.

The post never does answer its own question — what does the demise of Flash mean for the user experience? From the article, more HTML5 use. In itself that doesn't tell me how the user experience is affected, just how developers are affected. If the developer does a good job, the user experience doesn't need to change. The user shouldn't need to worry about the underlying technology.

Too many HTML5 articles and posts today, like this one, work to promote the markup language (and usually CSS3 and JavaScript, even if they don't know it) by contrasting it against another technology that is falling away or is just a popular target of derision. The pro-HTML5 cheering is easy when another technology has already been recognized as out-of-date, but this doesn't do anything to advance HTML5 and its related specifications.

I'd love to see more practical discussions of what HTML5 (and related specs) can do today along with all the nifty experiments that are moving the collection of specifications along.

Update: May 8, 2012

The BBC makes this same set of mistakes in its piece Coding the future: HTML5 takes the internet by storm.

Make a Better Restaurant Site

Last night I had the pleasure of moderating a panel discussion for the Buffalo chapter of Social Media Club. The panel consisted of a food blogger, a restaurant review site owner, a restaurant / cooking school owner, and a local food writer / reviewer / event planner.

As I asked questions of the panel I held off on my own question about why restaurant web sites are so stultifyingly awful, only to find the question came from the crowd itself:

This is a topic with which I have struggled mightily — not as a web developer, but as a consumer:

On far too many occasions I have been away from a computer, armed only with a smartphone, trying to make a decision on a restaurant by looking up information online. On far too many occasions I have been unable to get directions, hours, a phone number, menus, or even see photos (it's good to know if I am under- or over-dressed).

This isn't much different from the days before smartphones when I visited a restaurant web site at my work computer and had to scramble to turn down its background music, or had to close the page because its massive Flash movie brought everything to a crawl.

I was pleased to see — no, pleased is the wrong word — I was grimly satisfied to see that all four panelists reacted immediately, passionately, and in near unison when I asked what restaurants can do to improve their web sites.

What Restaurants Can Do

The takeaway, before the discussion transformed into one about general expectation management, was pretty straightforward:

1. Dump the Flash;
2. Lose the background music;
3. Forget the splash page;
4. Get your menu current;
5. Replace the PDF menu with HTML;
6. Put the hours on the home page;
7. Put the address on the home page;
8. Put the phone number on the home page;
9. Get some quality food photos;
10. Don't waste my time telling me your ethos;
11. Make sure it works on my mobile device.

None of this is new stuff. This is the exact same thing that many of us have said for years. There are comics about it, like this one from The Oatmeal:

There is even a web site dedicated to expounding the right way to build a restaurant web site (yeah, it's kind of meta):

When today I saw that the guy who built that resource was interviewed for .net Magazine ("Noel Tock on better restaurant websites," primarily to promote his product for building restaurant web sites), coupled with last night's food panel, I thought it might be about time to write something up.

Resistance?

What's that, your favorite restaurant doesn't have the budget to build a web site devoid of all those hyper-expensive features? No worries, those items I listed above can be done in plain HTML for free.

Don't have the skill? No worries there, either. With the small army of restaurant review and collection sites like Yelp, location-based services like Foursquare, the ubiquity of Facebook, and free services like Blogger, you can get the information out there for cheap, maybe doing nothing more than redirecting your own domain name to one of those platforms.

Sure there is a risk, but that's just about proper time management:

As consumers, we should be willing to tell a restaurant when its web site sucks. When you make the reservation, when you pay your bill, when the manager is playing nice with the crowd. You may feel like you're being mean, but it's truly a very nice thing to do if you really like a place. Help them not suck in the one way where we can all coach them.

Related

• Why All the Food Photos? at my site and at evolt.org.
• Buffalo Foodie Panel (it was last night) announcement on my blog.
• 13 Best Practices for Restaurants on Facebook on Mashable.
• A local site I built some time ago, but which they maintain with skill: Shango Bistro.

Some proof that I moderated last night and presented some stats (see the article linked above) about social media engagement with food retailers:

Update: January 14, 2014

Web Standards Sherpa (yes, I am a writer for it, but not this piece) has some examples of good HTML for using on menus: Question about HTML for Restaurant Menus

Flash is Dead! Long Live Flash!

Re-posted from its original home on the Algonquin Studios blog.

A lot of news has been made of Adobe’s recent move to end development of the Flash player for mobile devices (such as your smartphone or tablet). Even people outside of the tech community have heard about it and are trying to understand what it really means. I wrote up the details last month (Flash Isn’t Going Away, Except from Your Mobile) and tried to remind everyone that Adobe isn’t giving up on Flash, it’s just changing its direction on its mobile player based on industry trends.

Consider that Apple won’t allow the Flash player on its iOS devices, and that the mobile version of Windows is following suit. Consider that web developers are (finally, after a decade now) starting to focus on standards-based web development and accessibility. Consider how many different mobile devices and browser combinations exist, requiring Adobe to develop a Flash player for each.

Much of Flash on the web has been used to deliver rich multimedia experiences that either don’t translate well to mobile browsers (giant file sizes, areas too small to “click” with a finger, optimized for large displays, etc.) or can be replaced with new HTML capabilities which mobile browsers tend to support now without the Flash player (such as the lowly Flash video player).

Add all these factors together and it doesn’t make sense to push the Flash player to mobile devices any more. Adobe is instead using AIR to allow Flash developers to build native apps on the phone, bypassing the hassle of the browser plug-in altogether and still allowing those legions of Flash developers to do what they do best.

Here’s where people get confused — Flash as a platform isn’t going away. Regardless of the hype you hear about HTML5, HTML5 (including CSS3, SVG, and so on) just doesn’t have the capability (whether via the specification or by browser support) to do what Flash does. Flash is the only technology that can currently do what Flash does for such a broad audience. Its ubiquity across the web (98% installation) has guaranteed that users see what the developer wants, regardless of platform; regardless of whether or not what the developer created is any good.

This doesn’t mean we are Flash-crazy over here. Quite the opposite — we have historically counseled against Flash for web sites for many reasons, some of which are simply because it doesn’t address the goal. As we develop sites that are both mobile-friendly and desktop-friendly, we are increasingly coaching our clients on the right technologies to use to achieve their goals. Our position on Flash isn’t changing because of Adobe’s move, Adobe is simply reflecting the trend.

You can expect to see less Flash in web pages on your mobile, but you can also expect to see more of it behind the scenes in apps for mobile devices. As for your desktop browser, Adobe will release Flash players for years to come and people will still develop in it for as long as it takes HTML5 and its related specifications to finalize the rules and for the browsers to support them.

Flash Isn't Going Away, Except from Your Mobile

You may have heard some rumors that Flash is going away. You may read it as vindication for Steve Jobs. You may have decided web development will now change. You may be under the impression that HTML5 can do all the things Flash can. You can be excused when you read much of they hype, including such link-baiting headlines as Jobs Was Right: Adobe Abandons Mobile Flash Development, Report Says, clearly intended to draw Apple fanboys. Some of the news today:

• Exclusive: Adobe ceases development on mobile browser Flash, refocuses efforts on HTML5 (UPDATED)
• It’s Official: Flash Mobile Player is Dead
• Adobe stops developing Flash for mobile

Before we get too far ahead of ourselves, this cessation of development is for mobile devices only (read Adobe's release). I also want everyone to take a deep breath and stop crediting Apple with this. Adobe has long been unable to make a Flash player for mobile devices with a small enough footprint to not feel like you are wading through pudding to see some pointless animation (or worse, a navigation bar). The iOS market share in the mobile space is still below Android's (suggesting to me that Apple cannot kill it on its own), but Flash's ability to play well on anything in the mobile space is still below all of that.

We can expect this to affect how Flash will be implemented on other sites, but not immediately. Web developers worth their pay are moving toward adaptive layouts that scale and reformat themselves for mobile devices. These developers have mostly excised Flash from their toolkit because it doesn't play well with these new approaches. Younger, less experienced developers, along with developers trapped in 2001, will still use the only tool they have (insert hammer/nail metaphor) until they have exhausted it.

As someone who has been resistant to Flash on client projects for years, partly because of accessibility concerns and partly due to its resource demands, there is no love lost here for the platform. I am happy to see it wander off into a corner and yield right-of-way to CSS3, HTML5 and its related specifications. Over 10 years ago, when Flash was already causing stress to web developers and user interface designers, Jakob Nielsen finally got on board with his article Flash: 99% Bad. Today is just another step in a much larger process of web standards development, even if Flash wasn't an official one (de facto has carried it this far).

In the meantime, expect to see Flash persist on the web of desktop browsers and expect to see it persist in old, forgotten sites for years (perhaps most of the restaurant web sites I see). Until HTML5 can figure out what it wants to be when it grows up (End of time Is Not Helping the Case for HTML5) and the debate over video codecs truly ends (Are Patents Killing HTML5 Video?), things aren't going to change for most of us very soon.

I am intentionally skipping the discussion around Adobe's statement to more broadly support HTML5, since it's not really news given its latest products. I'm also skipping the statements from Adobe about using Flash to feed to app development platforms like AIR since I think we all have seen that move for a while now.

Related (on this blog)

• Adobe vs. Apple or Flash vs. HTML5, April 12, 2010.
• Adobe to Drop iPhone Support, Target Android, April 21, 2010.
• More Salvos from Apple and Adobe, to No One in Particular, May 13, 2010.
• More on HTML5 as DHTML, August 8, 2011 (for the Adobe Edge points).
• Thoughts on Muse (Obvious Pun Avoided), August 16, 2011.

Update November 10, 2011

As I suspected, the hype is starting to settle down after a day has passed. Some more news bits with more of an overall perspective:

• Adobe axes Flash for TVs too at CNet.
• Mobile Flash ISN'T dead at ZDNet.
• Some Thoughts On Flash And Devices by Ben Forta of Adobe.

Don't Let HTML5 Become the New DHTML

This photo represents some of the technologies (pint glasses) that HTML5 (t-shirt) is thought to encompass (drink). The horror of that concept is represented by the hands (defensive wounds coming).

I had the pleasure of sharing some pints with Bruce Lawson and Chris Mills last week in London. While discussing what bands are emo versus punk rock and during an exchange of favorite phrases to refer to the chronically daft, we touched on HTML5 and its perceptions a bit.

This thought process was rekindled just this week when I got in a discussion with a not-very-technical manager of web projects who insisted on mobile support and decidedly CSS3-based styling by implementing HTML5. The key here is the insistence on using HTML5. For a little context, we use HTML 4.01 Transitional for our projects. It's a valid and complete specification. It allows us to use things like WOFF, CSS3, AJAX, support mobile devices and so on.

I understand that many have co-opted "HTML5" as a brand for a suite of new technologies (most of them even from the W3C or WHATWG). I do not accept that, however, because it confuses the point when it comes time to make choices about technologies. This is a battle I have already fought repeatedly back when DHTML (and IE4!) became the rage and I had clients asking what technologies I would use to build their pages — insisting in advance that it be DHTML. I could explain that DHTML was just a terrible term coined to mean HTML4, CSS and JavaScript, but clients didn't care. It didn't matter to them. Good for them.

For developers and the people that manage them, including those who write on these topics, I have a different expectation than I have from clients. Allowing HTML5 to mean CSS3, geolocation, H.264, or any other technology just makes it harder on us who work in this space. A technology for a project should be chosen based on the goals at hand, not because a client insists on it because of a misunderstanding of a brand or because the press release will sound great when citing how cutting edge everyone is. Most importantly, a technology should not be chosen because of confusion over terminology — least of all when that term actually refers to one particular specification.

Please, fellow developer/writer/manager, make an effort to understand the technologies you reference so you do not confuse other developers/writers/managers, set incorrect expectations with clients, or generally demonstrate that you do not get it (especially if you want to work for me).

I have written on this extensively (with many links in each article that are to further details not written by me):

• W3C Clarifies HTML5 Logo Is for HTML Only
• HTML5 Finally Gets... a Logo?
• Google, Arcade Fire Confused on HTML5
• Google Doodle: Bouncy Balls Aren't HTML5
• HTML5 and CSS3 Confusion

If you are a writer (whether a journalist, blogger or analyst) then please take a few moments to read this useful and informational post: HTML5: notes for analysts and journalists (also not written by me). There will be a quiz. I don't know when, but there will be a quiz.

Now, to reveal how Bruce and Chris really felt about the HTML5 confusion:

Here are posts from both Bruce and Chris discussing this confusion, within the context of the new HTML5 logo muddying the point earlier this year:

• On the HTML5 logo, by Bruce Lawson on January 18, 2011.
• HTML5 logo: be proud, but don’t muddy the waters!, by Chris Mills on January 18, 2011.

Apple.com (Not Really) Updated to HTML5

Apple has released a revamped version of its web site today, ostensibly in HTML5. Except it doesn't use anything from HTML5.

That Apple wants to move to the platform that it touts as the Flash-killer is not surprising. Apple refuses to allow Adobe Flash on its mobile devices and claims everything Flash does can be done in HTML5. While not totally accurate, it's certainly part of Apple's motivation along with its long-standing claims to support standards. I followed this for a while until it became just senseless bickering:

• Adobe vs. Apple or Flash vs. HTML5, April 12, 2010.
• Adobe to Drop iPhone Support, Target Android, April 21, 2010.
• More Salvos from Apple and Adobe, to No One in Particular, May 13, 2010.

A few very pro-Apple sites have already carried the news about Apple's new move to HTML5, citing the new look, one even offering a screen shot of the first four lines of the HTML as proof that it's HTML5.

Except when you look past the first few lines of the code, or really past the DTD which identifies the page using the new minimalist HTML5 DTD, all similarities to HTML5 cease. I'm going to go after the low-hanging fruit here, mostly because I am writing this on a self-imposed deadline. When I opened the source code, I looked for some telltale HTML5 elements, specifically nav, header, footer or canvas (that last one is supposed to be the Flash killer). I found none of them.

Instead I see the standard tag-soup of divs being jammed into roles now replaced with the new semantic and structural elements of HTML5. As an example, this screen shot shows the HTML that drives the footer, all wrapped in nested divs. These could be replaced with the HTML5 footer element.

I understand that browser support is probably the driving concern here. Apple may not want to implement elements that don't have support in many current browsers. But this half-baked approach, which may be copied by Apple die-hards and HTML5 n00bs alike, does more damage to HTML5 than just leaving the site in HTML4. No, this is a case where prioritizing the marketing message along with ongoing battles with Adobe and now Google are causing Apple's web development team to fail to implement the specification as it is intended (or will be, when it is final). Which calls into question just how well they will implement any aspect of it, including its attempts to supplant Flash.

But this roll-out wasn't done with a mountain of HTML5 fanfare. It is possible that I am being too critical, that Apple's updated site is the first practical step toward future and ongoing implementation of the unique HTML5 elements as the browsers catch up. In that scenario Apple can be forgiven. Except I am not quite so willing to let Apple off that easily given how hard it pushed its HTML5 Showcase back in June. The showcase wasn't really as much about HTML5 as it was about Safari, and then what CSS3 and JavaScript can do. HTML5 itself didn't have much of a role in that showcase. It was just a great way to get people to download and use Safari, given that the content was riddled with Safari- and Webkit-specific features. I'm not the only one who takes Apple to task for it (for example, Apple's HTML5 Showcase Less About Web Standards, More About Apple at Webmonkey). Given Apple's prior behavior regarding HTML5 (pushing primarily CSS3 and JavaScript) and its motivations (Flash foil, Safari pusher), I'm not so sure Apple is taking the right approach with the new site.

Apple isn't the only one making this HTML5-but-not-really mistake:

• HTML5 and CSS3 Confusion
• Google, Arcade Fire Confused on HTML5
• Google Doodle: Bouncy Balls Aren't HTML5

Sadly, we are at a point in time where people are implementing HTML5 the way they implemented HTML4 (as in, poorly). It's like we just invented the screwdriver but everyone is using it to pound nails.

Smokescreen Brings Flash to iPad, iPhone

Smokescreen - iPad demo #1 from Chris @ RevShockAds on Vimeo.

Now that it's clear that Apple has no intention of letting Adobe Flash run on the iPad or iPhone, workarounds for Flash are even more compelling to developers. Smokescreen, primarily by Chris Smoak, bypasses the need for the Flash plug-in by pulling in the SWF binaries and decompressing them in JavaScript, yanking out the images and audio and putting it all back together with the vector data rendered as animated SVG. Simon Willison got the details and posted the technical process on his blog:

It runs entirely in the browser, reads in SWF binaries, unzips them (in native JS), extracts images and embedded audio and turns them in to base64 encoded data:uris, then stitches the vector graphics back together as animated SVG. Open up the Chrome Web Inspector while the demo is running and you can see the SVG changing in real time. Smokescreen even implements its own ActionScript bytecode interpreter.

You can see demos of Smokescreen running StrongBad emails and ad banners at the site. If you are running Internet Explorer (any version), then these demos won't work for you. In general, you'll need the most recent versions of Firefox, Safari, Chrome or Opera to see the demos. A couple of them run on the iPad or iPhone and there is even a video of it in action for those who don't have either device (see above).

The Flash movies don't run quite as quickly using Smokescreen as they would in the native Flash player, but that's to be expected when all the work is offloaded to the browser's JavaScript engine (8,000 lines of code weighing in at 175kb). I also noticed that sometimes text embedded in the SWF file either didn't appear at all or had some odd anti-aliasing. Given how new this is, however, I suspect these are surmountable obstacles. Given that Chris plans to release the code as open source, more developers will likely be able to contribute to pare this down.

What would make this even more interesting is if Adobe lent its support in some way. Since this has the potential to reverse the trepidation Flash developers now feel thanks to the increase in iPads and iPhones on the web, it may stave off any doomsday scenarios for Flash. It may also blow up Apple's plans to ultimately push Flash out of the market altogether unless they want to stop supporting the JavaScript and HTML5 that this utility uses to render the former-Flash movies. It's still too early to tell which way either company will go with this, if they do anything at all, but I suspect it will be interesting to watch.

Related Links

• Smokescreen makes Flash content visible on iPhone and iPad (video) at engadget.
• Smokescreen Converts Flash to JavaScript On the Fly at Gizmodo.
• Smokescreen Project Promises 'Flash Without the Plug-in' at Webmonkey.

More Salvos from Apple and Adobe, to No One in Particular

I was out of the country when Steve Jobs posted his open letter on Flash to the Apple web site. Had I been around I would have dissected it. Today Adobe published its own open letter(s) about how great Flash is, why open markets are good, and even an ad campaign promoting choice. This passive-aggressive slap-fest is really just another reason for me to use my Apple vs. Adobe graphic that I spent nearly 10 minutes creating over a month ago.

To put my own preferences out there again, I have been critical of Flash for a long time (Jakob Nielsen roasted it 10 years ago now). The technology itself is mostly harmless, but developers have latched onto it for years to create confounding, inaccessible, and cryptic interfaces for web sites. To be fair, if they hadn't used Flash, they might have still made the same terrible chum, but Flash just enabled their poor behavior. Apple has always been the plucky upstart that despite being just another corporate computer company had somehow tricked masses of designers and wanna-be-cool-but-different (as opposed to being just different, like *nix users) folks in to giving them free advertising via legions of window stickers and the like. Except now people are recognizing them as the corporate juggernaut they are (When did Apple become uncool? at Yahoo! News).

Let me compare and contrast some points from the two letters.

Open vs. Closed

From Apple:

While Adobe's Flash products are widely available, this does not mean they are open, since they are controlled entirely by Adobe and available only from Adobe. By almost any definition, Flash is a closed system.

From Adobe:

The core engine of the Flash Player (AVM+) is open source and was donated to the Mozilla foundation where it is actively maintained. The file formats supported by the Flash Player, SWF and FLV/F4V, as well as the RTMP and AMF protocols are freely available and openly published. Anyone can use the specifications without requiring permission from Adobe. Third parties can and do build audio, video, and data services that compete with those from Adobe. [...] There are no restrictions on the development of SWF authoring tools, and anyone can build their own SWF or FLV/F4V player. [...] Adobe Flex, the primary application framework for Flash, is also open source and is actively maintained and developed by Adobe and the community.

As an end-user, I need help understanding Apple's point. How is what Adobe states any different from Apple's own WebKit? Because they claim it started as open source, whereas Flash didn't? The points in these letters don't speak to the average user, that's for sure.

From Apple:

Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. [...] HTML5 is completely open and controlled by a standards committee, of which Apple is a member. [...] Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

I'm going to let Adobe off the hook on this one. As I have said before, HTML is NOT a final specification yet. Apple is clearly pleased as punch that Safari supports much of HTML5, and good for them. But they are really pushing the canvas element as the Flash replacement. Given how quickly the W3C wraps up a spec, and browser makers get it into their browsers, and users download it, it's just not a good argument. It may be worth noting that JavaScript was originally Netscape's creation and is now known as ECMAScript.

Bear in mind that HTML5 has been handed off by the standards committee (W3C, of which Adobe is also a member) to the Web Hypertext Application Technology Working Group (WHATWG, of which Apple is a founding member). It turns out that Apple, Mozilla, and Opera were unhappy with the W3C progress on XHTML and HTML, and so broke off on their own. As a result, WHATWG is working on HTML5 alongside the W3C HTML working group, using the same human editor.

Touch Interfaces

From Apple:

Apple's revolutionary multi-touch interface doesn't use a mouse, and there is no concept of a rollover. [...] Even if iPhones, iPods and iPads ran Flash, it would not solve the problem that most Flash websites need to be rewritten to support touch-based devices.

From Adobe:

Flash was actually originally created as a technology for tablets with touch interfaces. And today, Flash has full support for working on touch-based devices. [...] For new Flash content developed specifically with touch in mind, Flash Player 10.1 provides a complete set of multitouch and gesture APIs.

Ok, Apple has a point, Flash does not support multi-touch. Multi-touch is relatively new, however, and Adobe promises it in their (much delayed?) Flash 10.1. I do take issue that Flash does not support touch devices. About 4 years ago we developed a Flash application to run on touch-screen displays for a kiosk, and it worked very well. The issue is again not with Flash specifically, it's with developers who are terrible at designing interfaces.

Security

From Apple:

Symantec recently highlighted Flash for having one of the worst security records in 2009.

From Adobe:

The Symantec Global Internet Threat Report for 2009 found that Flash had the second fewest number of vulnerabilities of all Internet technologies listed (which included both web plug-ins and browsers).

Erm, so who do we believe? Neither links to a report, but they both cite Symantec. So I went to the Symantec site and grabbed the document Internet Security Threat Report: Volume XV: April 2010. I searched in the PDF for Adobe Flash and found this:

In 2009, Symantec documented 321 vulnerabilities affecting plug-ins for Web browsers (figure 9). ActiveX technologies were affected by 134 vulnerabilities, which was the highest among the plug-in technologies examined. Of the remaining technologies, Java SE had 84 vulnerabilities, Adobe Reader had 49 vulnerabilities, QuickTime had 27 vulnerabilities, and Adobe Flash Player was subject to 23 vulnerabilities. The remaining four vulnerabilities affected extensions for Firefox.

Apple QuickTime had 4 more vulnerabilities than Adobe Flash? Did I mention that when I hit the Apple site, my browser keeps trying to get me to install QuickTime? There's also this quote:

The 321 total vulnerabilities in plug-in technologies for Web browsers for 2009 is less than the 424 in 2008. Of the total for 2008, 287 vulnerabilities affected ActiveX, which is significantly more than any other plug-in technology. Of the remaining plug-ins for which vulnerabilities were documented, there were 54 vulnerabilities identified in Java SE, 40 in QuickTime, 17 in Adobe Reader, 16 in Adobe Flash Player, and 5 vulnerabilities in Firefox extensions.

16 in Adobe Flash, 40 in Apple QuickTime. I really need some help finding Apple's point. I also need help finding Adobe's point. From what I see here, Flash is safer than QuickTime, even though (in further reading) it gets targeted more. If you want clear answers, you may need to read all 97 pages of the Symantec document, which was not linked from either Apple or Adobe.

Overall

Apple's letter clearly belies frustration with may have been Adobe's missed promised delivery dates. Apple also has a point that Flash doesn't hand off the video decoding work to the processor, eating battery life. Adobe has stated this is coming in the 10.1 release. Apple points to YouTube running as an app on the iPhone, but is silent on the fact that videos embedded in a page are inaccessible but does concede, backhandedly, that users aren't missing much video. And then Apple goes on about how Flash is designed to be cross-platform, and as such doesn't enable developers to write the best iPhone/iPad apps. And this is the crux of it all. Apple just wants the control and Adobe wants in.

Update (May 14): Read Adobe and Apple: Please Spare Us the Platitudes About "Open" over at Mashable for another take on all this.

Update (May 20): Read How secure is Flash? Here's what Adobe won't tell you at ZDNet where the writer also compares the Symantec report against Adobe. He missed the point, however, that Symantec recommends both Flash and JavaScript be disabled for a secure browsing experience, something that would hamper Safari's reliance on HTML5 in lieu of Flash.

Adobe to Drop iPhone Support, Target Android

And the saga continues. If you read my post Adobe vs. Apple or Flash vs. HTML5 from a few days ago, you already know that Apple and Adobe appear locked in a battle over Flash and the iPhone OS. It's clear Apple wasn't planning on backing down and it's certainly not in Adobe's best interests to continue the fight.

It should come as no surprise that Adobe is walking away. Mike Chambers, the Principal Product Manager for developer relations for the Flash Platform at Adobe (that's how he lists it on his blog), has said as much in his blog post, On Adobe, Flash CS5 and iPhone Applications.

He starts out with the clause from Apple that started this all, noting that developers can expect to see their Flash-developed applications slowly get booted from the iTunes store. However, Adobe has already built the export features into Flash CS5 that allows developers to target iPhones and iPads and plans to ship the software with those features still intact, even if Apple still blocks acceptance of applications built with that technology.

Instead, he claims that Adobe and Google have been working together to target Android phones and Android-based tablets with Flash 10.1. In short, all the work you have already done as a Flash developer to target the iPhone OS can simply be brought over to the Android OS. He provides links to some developers who are already making the switch, targeting Android now instead of iPhone.

There are some links in the blog post which I am including here. Since Apple has been silent on this entire dust-upand the general trend has been that Apple's licensing enforcement (both for app content and programming language) is arbitrary, I can't really offer counter-links or even counter-arguments. It also justifies my cheating and just parroting links from the original blog post.

• Apple Locks iPhone Developers in Its Walled Garden at PCWorld.
• Apple Wants To Own You at Slate.
• Mark Fiore can win a Pulitzer Prize, but he can't get his iPhone cartoon app past Apple’s satire police at Nieman Journalism Lab.
• Apple's New Developer Agreement Unlevels the iAd Playing Field at Wired.

Adobe vs. Apple or Flash vs. HTML5

Any of you watching the recent iPad coverage may already know that the iPad not only does not support Flash, there is no intention on the part of Apple to support Flash. Granted, the iPhone doesn't support Flash, but neither do most other mobile devices. iPhone users had been complaining about this for a while and Apple cited its policy toward acceptance of software from third-party manufacturers as a reason not to expect it ("Why Apple Won't Allow Adobe Flash on iPhone," Wired, Nov. 17, 2008).

With Apple's pitch that the iPad would replace netbooks and slide into the average user's hands as the de facto web surfing platform, hopes were high that the iPad would support Flash. The original iPad promos even showed Flash in use, but those were quietly changed without any acknowledgment from Apple ("Apple Pulls Flash Content From iPad Promos," PCWorld, Jan. 30, 2010).

In the last couple weeks things have heated up even more. Apple modified its iPhone Developer Program License Agreement (part of the iPhone OS SDK) to expand on a section covering how external applications can be developed:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++ or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++ and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

While Flash Player 10.1 is now available (or on its way) for other mobile devices (Android, Symbian, Windows Mobile, webOS and BlackBerry), the iPhone is still not having it. This new language essentially blocks a utility Adobe created to allow Flash developers to convert their Flash projects to the iPhone app format. And that utility still didn't bring Flash support to Safari on the iPhone ("Adobe Announces Flash Support for iPhone (But Only for Apps)," Mashable, Oct. 5, 2009). On the bright side, Adobe is also planning to support exporting to the HTML5 canvas element.

Apple has been quick to point out that anything you can do in Flash can be done in HTML5. Not only is this patently not true (primarily because HTML5 isn't even a finished spec yet — see "Too Soon to Advocate HTML5?" at this blog), the Safari browser doesn't support it all (CSS3 and HTML5 support checklist). Given how many sites use Flash for even basic features like non-critical content or add-on features, the average web surfer on his or her iPhone/iPad will just see blank areas where Flash should appear. Apple is free to limit its support at no cost to itself, but if companies truly want their Flash-specific features to work on an iPhone or iPad, they now have to consider not only how they might technically do that, but how much they are willing to spend to achieve it.

If you've known me or read my posts for long enough, you know I have generally considered Flash to be a usability and accessibility nightmare, primarily because Flash developers have often abandoned best practices and made up their own rules for interaction. And I'll just gloss over search engines by only mentioning them in this sentence, because that's just low-hanging fruit for an anti-Flash rant. But while Flash may not be my ideal method to build things, it's also a de facto standard for many aspects of current web design — animated objects, integrated video, interactivity. Yes, much of this can be done using HTML and JavaScript, but the Flash development environment allows many companies to develop features for their sites at a relatively inexpensive cost and not worry about cross-browser scripting issues.

A handful of companies are already re-orienting their sites or at least their strategies, but these are companies who know they have to target iPhone and iPad users ("Virgin America Ditches Adobe Flash for New Site" at Mashable, March 3, 2010). They are also companies who have the budget to do it. For the rest of us, the best thing we can do is continue to watch the battle between Adobe and Apple and see where it goes. I predict no winner. However, I do see the losers in this battle — end users and smaller organizations who cannot afford a rebuild.

Related News

• "Apple v Adobe: this time it's executable" at The Guardian, April 9, 2010.
• "Adobe CTO Defends Flash Against Apple, HTML5" at Webmonkey, February 2, 2010.
• "Adobe CEO: Apple 'hurts customers'" at MacDailyNews, April 14, 2010.
• "Adobe vs Apple: Flash of the Titans" at Mac Observer, April 14, 2010.