Commentary: Working Around the Web
This Saturday marks the beginning of new era in web development. With the launch of Apple's iPad handheld touchscreen-tablet-book-reading computer—if we can use that last word—the web as we know it is about to change.
I've held off on doing commentary on the iPad-Flash debate, for a variety of reasons. But as the speed at which the discussion of the open web versus a plug-in based web has accelerated, this launch week is the right time to discuss a broader issue around the re-shaping of the web.
Caught between Apple's "pure HTML" approach and Adobe "standards-based" plug-in approach, application developers and content owners alike are figuring out ways to work around their established web practices to accommodate a fragmenting mobile and desktop web experience, even on content displayed in the same browser.
Apple also adds that this eliminates the need for particular plug-ins that may (or may not, according to this article by Jan Ozer) cause significant performance degradation (battery life, CPU, memory and stability issues).
Adobe's claim, on the other hand, has been that it is a company whose "standards-based" approach is one that has worked well for years.
On the surface, the standards-based approach is mostly accurate, with Adobe's Dreamweaver (formerly from Macromedia) outputting content in HTML and using CSS (including CSS2 and the newer version 3). The company's After Effects compositing program and Premiere video editing tool are both able to work with a variety of video codec formats on the same timeline, without resorting to converting the content into loss-inducing intermediate codecs the way that Apple's Final Cut Pro (formerly from Macromedia, which was later acquired by Adobe) does. (If you remembered before reading this article that the ghost of Macromedia is the specter hanging over this entire debate, award yourself ten bonus points.)
The problem with Adobe's claim to be standards-based is that many of its products simply are not, or require use of Adobe proprietary formats and extensions to gain full advantage of the content creation tools. Adobe's Acrobat Reader (PDF) is a widely-used digital paper format, yet it is only a de facto standard, not an IETF, ISO, or W3C standard.
Likewise, Adobe's Flash Player (SWF) is a de facto standard that started as a Macromedia plug-in (Shockwave) for interactive Director content to be played on the web, was adopted as a good-enough interactive plug-in that successfully brushed aside Dynamic HTML, leveraged itself into the leading web video playback engine, and is now facing the challenge of HTML5 video and audio tags and the implementation HTML5 canvas (for interactive content).
From Apple's standpoint—and that of open-source advocates—the fact that Flash Player (and, to a lesser extent, PDF) content is locked up within Adobe as plug-ins for various browsers proves that SWF is only a web standard due to complacency and ubiquity, and that any true web standard needs to be backed into HTML.
From Adobe's standpoint, it makes sense to continue to maintain Flash Player as a de facto standard. The risks, though, are two-fold.
First, HTML5 video and audio tags, coupled with HTML5 canvas and the upcoming HTML device element discussed in last week's article, will allow content owners and developers to work around Flash Player.
The general consensus—up until the announcement of the iPad—was that the validity of HTML5 for video and interactivity would not be achieved within the next several years. Yet, even this week, we've seen announcements that HTML5 video conversion services will power some of the bigger names in magazine and newspaper content as they look to capture the early iPad-adopter market's news-reading (and viewing) segment.
Which leads to the second risk for Adobe. The company's Dreamweaver and Flash Professional tools are still the dominant content creation tools for web and Rich Internet Application (RIA) development, and the company used part of its Adobe MAX showcase last October to educate developers as to how they could export limited content out to a non-SWF format that would work on the iPhone.
Yet the core elements of a SWF, including those features that make Flash unique, are not part of the export pallete, in much the same way that a Photoshop file, with all its layers, is a far cry from a standard-based JPEG file that Photoshop outputs.
In other words, Adobe has a choice to make: Open Flash Pro's output to fully embrace HTML5 audio, video, and canvas functionality, at the risk of losing market-usage share of Flash Player playback, or choose to keep Flash Pro—one of the better interactive content creation tools on the market—closed to all those who opt not to use SWF playback, and risk losing a large chunk of the content creation market.
It's not an easy decision, but it's one that will potentially portend Adobe's future leadership on devices that seek to work around the current version of the plug-in web as we know it today. If Adobe opens up Flash output, I suspect Flash Pro will maintain market dominance, embraced by standards-based developers. I also suspect Flash-only developers will initially grumble over the lack of marketing flexibility, if they choose to create full-blown applications for the Apple App Store; the long-term benefit to developers, though, will be to push them beyond the "build-it-and-they-will-come" mentality and into a new era of learning how to effectively differentiate their mobile app products against the thousands of other similar products.
In closing, in almost every call I've received on this topic, I've been asked whether I'm buying an iPad. The short answer is "not yet." I had contemplated breaking my no-first-generation-mobile-technology rule, especially since I share a milestone birthday on April 3 with the launch of this product that appears to be rapidly re-defining the web. Yet, given the uncertainty around the issues of HTML5, Flash, and the development cycle of the product itself, I've opted to stick with the wait-and-see until iPad 2 appears. Or at least until next Monday.
The past weeks' events surrounding the new language in Apple's iPhone Developer Program License Agreement have exposed the San Jose software giant's shortcomings in the mobile space. Here's what went wrong.
On the eve of Adobe's official unveiling of CS5 at NAB, the announcement of the Apple iPhone 4.0 SDK might spoil the party