Steve Jobs isn’t here to enjoy his triumph, but this week’s announcement that Adobe has stopped developing the mobile version of the Flash player would undoubtedly have delighted him. The title of yesterday’s Guardian story says it all: “Adobe kills mobile Flash, giving Steve Jobs the last laugh”. The first comment is even starker: “Flash – good riddance!”

So why has Adobe taken the decision? Is this really the end of the road for Flash? And is it really good news?

Inevitably most commentators are presenting the move as a vindication of Steve Jobs’ argument that Flash was inherently unsuited for lightweight mobile delivery.

Regular readers will know that I’ve never bought this argument,  largely because it’s untrue and ignores the fact that Flash was specifically developed to deliver the richest possible experience down narrow web pipelines and on everyday systems – and that it has kept to this strict mission throughout its life.

Retrospectively banning an established web technology – in use on an astonishing 62% of the top 97,000 sites according to Microsoft figures – was an extraordinary coup

As such, the lightweight rich Flash player and the new generation of lightweight rich handheld devices should have been the perfect match. If Apple had wanted to make Flash work on mobiles, it could have. I think that the existence and success of the Android player shows this is true (and performance would only get better) and that Jobs’ carefully crafted list of objections to Flash were entirely bogus.

My view, as I’ve argued before, is that Steve Jobs’ real motivation was entirely business driven. What is truly revolutionary about the new iOS platform is its business model, in which rich content and applications are delivered exclusively through native apps and through the App Store with its 30% commission. Seen in this light, the threat that Flash poses is clear: enabling the same rich content/apps to be delivered efficiently and securely, direct from producer to consumer, across all platforms, within the browser, and without commission.

You have to admire the man. Retrospectively banning an established web technology – in use on an astonishing 62% of the top 97,000 sites according to Microsoft figures – was an extraordinary coup. Somehow Steve Jobs pulled it off and even managed to make it seem that denying his users functionality, freedom of choice and competition was doing them a favour. Imagine what would have happened if Microsoft had tried to pull off the same trick.

Crucially Jobs’ action and success also made it possible – perhaps even inevitable – that Microsoft would follow suit. I think that the final straw for Adobe came with the recent announcement that Windows 8’s IE10 would only support the Flash player in its desktop mode and not under the new iOS-style, tablet-oriented Metro front end.

Of course that still left Android and the other Open Screen Project (OSP) partners  - who, incidentally, remain free to develop their own future mobile players (a possible USP for Google?). However, with both Apple and now Microsoft lined up against it, the writing on the wall was clear.

Flash could never become universal in the mobile space as it is on the desktop, not because it couldn’t deliver the goods and build the audience – it could – but because it wasn’t going to be allowed to. There was nothing Adobe could do about it; the mobile Flash player’s fate was entirely out of its hands. Adobe’s decision isn’t a vindication of Steve Jobs’ position, it’s just a direct consequence.

The future for Flash and HTML5 – in practice

That said, it’s the reality to be faced and, with even Adobe now turning its back on its mobile player in favour of HTML5, is this the end of the road for Flash?

It’s important not to get carried away and to stress that Adobe is only stopping development of the mobile player. The Flash player will still be developed for the desktop where it remains ubiquitous and reigns supreme and indeed unchallenged, now that Microsoft has effectively ditched Silverlight.

If Flash can no longer deliver to all users then developers and designers are going to look for a solution that can

However, to pretend that Flash on the desktop is unaffected is wishful thinking. Ultimately it comes down to the same argument: the web is all about universality. If Flash can no longer deliver to all users then developers and designers are going to look for a solution that can.

As soon as Steve Jobs banned cross-platform web extensions (Silverlight and Java as well as Flash) and established the iOS platform, then HTML5 became the only viable universal web solution for the long term. If you can do what you want to do in HTML5 then there’s little question that that’s the best way to do it. The fundamental shift from Flash to HTML5 in the browser is unavoidable, and now even Adobe is fully and clearly on board.

However while “doing Flash in HTML5” sounds simple and desirable, that doesn’t mean it is. Take the easiest example: the ubiquitous Flash-based animated vector ad. Now it’s certainly possible that this can be delivered via HTML5 rather than Flash (as the Flash blockers are now discovering). However what does this actually mean in practice?

Are you really going to code the vectors of the SVG objects by hand? And then the keyframes of the animation? And then what about the output? HTML5 browser support isn’t simple and varying HTML5 capabilities and implementations will likely need specialised handling. Again theoretically you could learn all the foibles and test against all the platforms and browsers, or then again, you might have better things to do.

The bottom line is that open coding is all very well in principle but Notepad isn’t going to cut it – to produce rich Flash-style results you’re going to need a dedicated Flash-style tool for design and output. And the most likely provider will be Adobe. No doubt the next version of Dreamweaver will add canvas tag capabilities while for more complex scenarios you will be able to use the all-new, dedicated, HTML5-native Adobe Edge.

Ironically, using Flash tools in this way will actually be the only option if you want to remain truly universal

Alternatively, Adobe has made it clear that it plans to graft HTML5 output onto its existing Flash tools whenever that’s possible, so why not stick with what you know?

Ironically, using Flash tools in this way will actually be the only option if you want to remain truly universal as it means that you will be able to cater for the HTML5-only tablet audience, including iOS and Metro, as well as the Flash-based desktop audience using pre-HTML5 browsers such as IE6, 7 and 8.

Sticking with Flash for authoring has other advantages. HTML5 has just about caught up with Flash-style banner ads circa 1995, but nowadays Flash Professional, Builder and Catalyst are powerful all-round rich internet authoring applications. Again, as I’ve written before it’s important to realise that HTML5 is not a direct and wholesale Flash replacement. There are plenty of scenarios – starting with simple and secure video streaming and stretching all the way to line-of-business applications – where HTML5/JavaScript simply isn’t up to the job.

The widespread assumption is that HTML5 will quickly close the gap, but is this realistic? For the foreseeable future all efforts will rightly be focused on getting browser support and compliance for HTML5’s existing features (with the official W3C HTML5 Recommendation not expected to be finalised for another three years). In the meantime Adobe is free to add more advanced capabilities, which is exactly what it is doing with the new 3D games engine in its new Flash player. If anything the gap is widening.

Flash goes native – and under cover

But what on earth is the point of adding such cutting-edge new features if you can’t deliver them on the future of computing, the cutting-edge new mobile devices?

Who said you can’t? Most commentators are assuming that Adobe is effectively throwing in the towel when it comes to Flash for the mobile market, but again this is a mistake. Yes the Flash player has been ruled out, but, as I discuss in my current RWC column in the January edition of PC Pro, the Flash tools remain as relevant as ever. In fact even more so.

In particular it’s important to note that Adobe’s recent announcement says:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores

Which makes it pretty clear that Adobe is planning to build on its existing Android and iOS native output with new support for Metro.

In other words, the mobile market isn’t a no-go area for Flash – quite the reverse. In fact if you want to produce work for all major desktop platforms – Windows, OS X, Linux and Chrome – and for all the major mobile platforms – Android, iOS, BlackBerry and Metro – Flash is the only way to go. When Adobe says that Flash/AIR is reaching more devices and more users than ever, it’s not just hype.

It turns out (again) that the rumours of the death of Flash are greatly exaggerated in both the desktop and mobile arenas. In fact the technology and platform is arguably healthier and more relevant than it has ever been, just in the new guise of AIR. Certainly the opening up of the new mobile form factor and of the new mobile app stores is an incredibly exciting opportunity for Flash developers.

In fact if Flash developers were given the choice between the app stores and the browser, I’m sure that most would choose the former. Likewise with end users. But the point is why should they have to choose? Why not have both? Or rather all three: universal HTML5, native code and Flash in between.

Web Flash: good riddance to bad rubbish?

Let’s stand back and think about what we’re losing as Flash is driven out of the browser.

Flash is a fundamentally different technology to HTML that seamlessly extends what the browser can do into new territory based upon vectors, animation, media, interactivity and advanced programmability. It’s a single, robust, actively and rapidly developed runtime running alongside and in partnership with the HTML-focused browser.

Crucially designers and developers can confidently target this single Flash runtime knowing that it will work on all supported platforms and browsers including, amazingly and uniquely, all curent versions of all browsers. Create and upload your single SWF and you can be confident that it will work as expected for all web users.

Apple and now Microsoft have conspired to drive an entirely legitimate and useful web standard with near ubiquitous support out of the mobile browser and into their app stores

Or rather you could. In its place, we have the promise of “just-do-it-in-HTML5”. As we’ve seen this is far more complicated than it sounds. To begin with it puts the onus on the HTML/SVG/CSS/JavaScript standards to deliver results way beyond their comfort zone (another assumption is that HTML5 is somehow going to be less flakey than Flash).

At the same time the shift to HTML5 is going to put the future of the rich web back in the hands of the multiple browser developers, meaning that the single Flash runtime is replaced by a mish-mash of competing capabilities. Does anyone else remember the Browser Wars?

And to top it all, how is the brave new world of HTML5 most likely to be implemented? Using the existing Adobe Flash platform and tools but outputting cut-down capabilities targeted at the multiple, less efficient HTML5 browser runtimes and with Flash fallback for the older desktop browsers!

What’s most depressing of all is the realisation that this entire mess is completely unnecessary. The obvious and overwhelmingly simpler alternative would be for Apple and Microsoft to remove their bans and to work with Adobe to make sure that the Flash player worked brilliantly on their new mobile platforms.

Instead, to further their own business interests, Apple and now Microsoft have conspired to drive an entirely legitimate and useful web standard with near ubiquitous support out of the mobile browser and into their app stores. In the process they have shattered the universal, write-once-view-anywhere rich web dream, added huge and unnecessary complexity to the process of web design and development and ensured that the future of the web for everyone on all devices and all platforms will be far poorer.

Yes Steve Jobs’ extraordinary decision to ban the Flash player has been entirely vindicated from his business-determined point of view. From the perspective of the web developer and the web user, this last laugh is anything but funny.

(Steve Jobs photo taken by Jon Snyder, c/o Wired.com Creative Commons Library)

In amongst the flood of details emerging about Windows 8 is the news that the IE 10 browser in the lightweight Metro front-end won’t support plugins. In the scheme of things this might sound pretty small beer, but it’s hugely significant for the long term future of Rich Internet Application (RIA) development and for the web in general.

Most immediately it’s another kick in the teeth for Flash, still reeling from Apple’s iOS ban. It’s not exactly a death blow, as the Windows 8 desktop version of IE will still support the player, but it’s clearly another major disincentive for developers who believed Flash was as universal as HTML.

Understandably all the focus has been on Flash, but even more telling and extraordinary is the realisation that the new no-plugin policy means that the Metro browser won’t even support Microsoft’s own cross-platform RIA technology, Silverlight!

So just what is going on?

Why has Microsoft changed course so dramatically, betraying its Silverlight vision and shafting its developers in the process?

Details on such a major announcement are disappointingly thin on the ground and largely based on an MSDN blog post (Metro style browsing and plug-in free HTML5). However the few reasons given to justify the decision such as they are – “the experience that plugins provide today is not a good match with Metro style browsing and the modern HTML5 web” – are very familiar. Essentially it’s the same argument Steve Jobs gave – “leaving the past behind” – when he outlawed plugins for iOS some 18 months ago. In short, it’s time for the web to move on from old-fashioned “legacy plugins”.

Regular readers will know that I have never bought this argument. More to the point, I know that Microsoft doesn’t either. After all, the company has spent the past five years arguing the exact opposite: namely that page-based HTML is great but that there are certain things that it just isn’t well suited to deliver: little things like high quality media streaming, digital rights management, interactive vector animations, device-based capabilities such as camera and microphone handling and, more generally, the richest possible, desktop-style web experience.

XAML & Silverlight

It’s precisely because Microsoft recognised the limitations of HTML – which remain true for HTML5/ CSS3/JavaScript/SVG – that the company has spent millions rethinking and entirely reworking its application development tools around XAML (eXtensible Application Markup Language). XAML is an open, XML-based markup language for building the user-facing front-end for both full-blown WPF-based desktop applications and, crucially, Silverlight-based lightweight RIAs ready for delivery via its own Flash-style cross-platform in-browser plugin.

So why has Microsoft changed course so dramatically, betraying its Silverlight vision and shafting its developers in the process?

Well of course Microsoft would say that it hasn’t. After all, the beautiful XAML-based technology lives on and thrives in Windows 8, it’s just that the end product won’t be delivered in the browser via Silverlight, but rather as standalone Metro apps. Moreover, with the promised Metro App Store, Microsoft is offering its developers a simple way to get their work out to users and to make real money from it based on the now well-established Apple model.

There’s a lot of truth to this and Metro is undoubtedly an exciting opportunity for XAML-based developers – but why not support Silverlight browser delivery too? How can Microsoft possibly argue that it can’t support its own existing lightweight Silverlight player within its own lightweight Metro front-end? In fact, if you really wanted to help Silverlight deliver on its potential, gain market share and reward your long-suffering developers, why not build Silverlight support into the Metro version of IE10 while relegating Flash to the desktop version?

It’s business – as usual

I think that the real answer to this question is also the real answer behind Steve Jobs’ decision to ban Flash: follow the money. Cross-platform, in-browser RIAs extending the universal browser to deliver rich and protected apps and content directly between producer and consumer aren’t a legacy problem to be solved; rather, they are a leading-edge, cloud-based threat to the platform-dependent empires that Microsoft and Apple have built up, and to the App Store and in-app content empires that they are currently building.

Keep the lid on the universal, browser-based user experience by killing off the in-browser RIA technologies and restricting the web to HTML5 and you get to deliver the full RIA experience outside the browser via your iOS and Metro apps, and via your platform-specific App Stores and in-app subscriptions. Not only is your all-important operating system and software ecosystem protected from third-party, cloud-based, cross-platform alternatives; you also get to take 30% of all paid-for app content, with no possibility of competition within your platform.

Look at it like this and Microsoft’s decision to effectively sacrifice its in-browser Silverlight vision makes absolute sense. The RIA vision behind Flash and Silverlight in which the web delivers on its full potential as a cross-platform, universal, open and truly rich connection direct between producer and consumer is a wonderful dream, but this is business.

Adobe has announced a 5.5 release for its various Creative Suite offerings. As CS5 was only released a year ago, most creatives will be surprised by the news and may well assume that it’s little more than a holding operation at best.

That’s not the case.

Adobe Creative Suite 5.5 is a significant release on a number of fronts with important new 5.5 upgrades for InDesign, Dreamweaver, Flash Professional, Flash Builder, Flash Catalyst as well as all the core video production apps. In fact, the only flagship applications left untouched are Adobe’s graphics power houses, Photoshop and Illustrator.

The crucial handheld market

The choice of applications that have been upgraded isn’t accidental. And nor is the focus of each update. With the arrival of the smartphone and the tablet, the very nature of computing is changing and in particular the way that we interact with and consume content. The entire focus of 5.5 is therefore all about enabling designers to deliver rich content to the new handheld audience.

It’s an exciting platform and market, and represents a massive opportunity for the designer. Naturally Adobe has long been aware of its potential – it will dwarf the desktop market – and has been working on how best to deliver rich content to such a wide range of devices and screens.

The vision it came up with is based on a combination of the lightweight cross-platform Flash runtime for rich browser-based delivery and the middleweight cross-platform Adobe Integrated Runtime (AIR) for rich standalone app delivery, based on integrated online/offline handling of Flash, PDF and HTML.

Adobe’s iPad problem

Everything looked like plain sailing (as far as cross-platform development can ever be) until Steve Jobs blew a major hole in Adobe’s universal vision by making it clear that he wasn’t going to support either the Flash player or AIR on the iPhone or iPad. In fact when he first made it clear, deliberately spiking the launch announcement for the previous Creative Suite 5 release, it looked as if he wasn’t even going to support repackaging Flash/AIR apps for native iOS delivery.

There was a strong possibility that Adobe might respond in kind to this openly hostile act, focusing all its efforts on delivering rich Flash and AIR content for Android, BlackBerry and the other members of the Open Screen Project, and writing off iOS as effectively closed to cross-platform development. Apple would literally be left to its own devices.

The Creative Suite 5.5 partial solution

The good news is that the war that Apple declared on Adobe is effectively over. The bad news is that Steve Jobs has dictated the terms

From the Creative Suite 5.5 announcement it’s clear that this isn’t the case. Adobe is still moving forward strongly with its Flash and AIR plans, but it has also built bridges to enable the richest possible delivery to iOS devices within the limitations that Steve Jobs has imposed. In particular this sees the ability to repackage Flash applications into native iOS applications restored, dedicated iPad-compatible publishing from InDesign complete with support for Apple’s in-app subscription service (complete with Apple’s 30% commission) and new HTML5 publishing capabilities within Dreamweaver.

On one level this is clearly welcome, avoiding a catastrophic split between the richest content-creation software and the richest content-consumption hardware. It also means that Adobe’s RIA developers and publishers will finally be able to tap the lucrative App Store market, something they have been crying out for – after all 70% of something is a lot more attractive than 100% of nothing. Perhaps most important of all, it shows that Adobe remains absolutely determined to help its user base do whatever is necessary to deliver the richest possible design across all platforms.

On the other hand, it’s important to realise that targeting HTML5 at Safari and recompiling AIR to native iOS apps and diverting them through the App Store fall well short of full, ideal, universal, open solutions. The only way to enable truly robust, write-once-view-anywhere, device-independent rich design and development across any and all screens, handheld and desktop, online and offline, and freely and directly between content producer and content consumer, would be for Steve Jobs to directly support the Flash and AIR runtimes on iOS devices.

Maybe Adobe has been too flexible in its approach to handheld design. It certainly would have been interesting to see how things would have panned out if the new Creative Suite 5.5 had enabled the InDesign-based publishing industry to produce rich eMagazine content for Android and OSP tablets, but not for the iPad. Could that have been the trigger for Apple’s users to realise that Steve Jobs’ position is designed to safeguard his 30% rather than their best interests?

With the Creative Suite 5.5 it’s clear that this isn’t going to happen and that Adobe and Apple have come to an agreement. On one level, this is excellent news as it means that a compromise has been reached, that there will be links between the two camps and that the all-out war that Apple declared on Adobe is effectively over. The bad news is that Steve Jobs has dictated the terms and that content producer and consumer alike will end up paying heavily for it.

Recently I’ve been making the case that Apple’s anti-competitive ban on Flash has stopped rich cross-platform development in its tracks.

As such I was naturally intrigued by a video post I came across recently asking “Has Adobe figured out how to get Flash to play on your iPhone?”

First of all, it’s important to stress that the obvious and by far the best way to get Flash content to play on your iPhone/iPad remains as far off as ever. Much though it would love to, Adobe hasn’t been able to announce the launch of a Flash player for Apple’s iOS-based devices to match its Android player. There’s no question that Apple’s hardware – see the latest iPad 2 review – would be able to support it, but for reasons that I covered recently – money and lots of it, for ever and with no competition – Steve Jobs won’t allow it.

So if it’s not a Flash player for the iPhone and iPad, what is it?

A Bridge from Flash to HTML5

Is this a bridge from the old days of Flash and player-based development to the promised land of HTML5? Was Steve Jobs right after all?

It’s a new technology preview made available on the Adobe Labs site under the code-name “Wallaby” and it’s essentially a Flash-to-HTML5 converter. Open your FLA file and hit OK and Wallaby will attempt to output all the necessary HTML, CSS, JavaScript and other standards-based files to recreate your player project within the browser.

If anything this looks even more interesting. After all, when Steve Jobs announced that iOS wouldn’t be supporting Flash, the case he made against it was that Flash was no longer necessary and that it should be replaced by HTML5 (a blanket term covering all the W3C standards such as CSS, DOM, SVG etc). The sign-off line to his Thoughts on Flash was:

“Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticising Apple for leaving the past behind.”

At first sight it looks like Adobe has done just this and that Steve Jobs has won the argument. After all, if you can deliver Flash functionality in the browser via HTML5 why shouldn’t you? Especially so now, when there’s one overwhelming reason why you need to: if you want to access the full web audience, including the crucial iPhone/iPad demographic walled up in Steve Jobs’ closed kingdom, there’s simply no alternative. The browser is the only way to go.

So is Wallaby a bridge from the old days of Flash and player-based development to the promised land of HTML5 and truly rich browser-based development? Was Steve Jobs right after all?

I’m sure that this is exactly how it will be seen and presented by many – “don’t worry that the iPad doesn’t support Flash, you just don’t need it nowadays, everyone’s agreed that it’s much better to do it in the browser rather than the player, in fact even Adobe has given up on it now and has built its own Flash-to-HTML5 converter”.

Any such talk is misguided, misleading and dangerous. To understand why, you need to dig a little deeper and see what Flash-to-HTML5 conversion really involves in practice.

Unsupported Features

In fact you don’t need to dig very far before a very different picture begins to emerge. Read the introduction to Wallaby and it becomes clear that Flash-to-HTML5 conversion is not a simple matter.

This initial version of Wallaby has several unsupported features due to the complexity of FLA files and the inability to represent some Flash Professional features in HTML5. The major ones include no conversion of: ActionScript, Movies, Sound. Also some design elements such as Filters are not supported. For a detailed list of supported and unsupported features see the Features and Status page.

Visit the page or try and convert a typical sample FLA and you’ll see that the unsupported features certainly aren’t insignificant – my first “successful conversion” came back with 291 warnings. Many of these limitations are important particularly when it comes to text – line break differences, glyph spacing/positioning, no support for links, selectable or vertical text and so on.

However it’s the lack of ActionScript support that is the real show stopper. It means that you are not going to be able to take your advanced Flash-based Rich Internet Application (RIA), say your online word processor, XML-based news reader, live messenger widget or video conferencing portal and suddenly make them available for iOS. In fact you won’t be able to convert the simplest game if it depends on ActionScript.

So what will you be able to convert? Again the introduction is clear:

Wallaby does a good job of converting graphical content along with complex, timeline-based animation to HTML5.

In particular

The focus for this initial version of Wallaby is to do the best job possible of converting typical banner ads to HTML5.

Workflow complexity

Wallaby’s conversion capabilities are clearly very limited, but that’s not all. Don’t expect the end results to be ready-to-go. Again as the introduction puts it:

Wallaby’s design goal was not to produce final form HTML ready for deployment to web pages. Instead it focuses on converting the rich animated graphical content into a form that can easily be imported into other web pages in development with web page design tools like Dreamweaver. The web page designer will likely want to add interactivity and design elements such as video and sound before deployment.

In practice this means loading up your Wallaby output as a complex HTML file built up of multiple SVG text blocks and PNG image files that are then absolutely positioned via CSS (including each animation frame). Certainly as things stand you can forget about usability features such as LiveView and easy editability. You are then expected to add back any video, audio and what interactivity you can within Dreamweaver.

Browser incompatibilities

Assuming the original Flash project was simple enough and that you are then up to the complexities of recreating it within Dreamweaver, you are finally ready to deploy. And here you come across another very important caveat:

At this time, the Wallaby HTML5 output uses Webkit specific CSS3 tags and therefore is not compatible with Firefox, IE9, or other HTML5 browsers.

In other words the whole enterprise is focused on just one browser engine, Webkit, as used in only two browsers: Chrome and – the only one that really matters because it’s the only one that doesn’t support the Flash player – Safari on the iPhone and iPad.

All this for iPad banner ads?

Flash-to-HTML5 conversion has absolutely nothing to do with replacing Flash. Quite the opposite.

We’ve arrived at a very different place. It turns out that Wallaby’s Flash-to-HTML5 conversion has absolutely nothing to do with replacing Flash with a truly universal, browser-based HTML5 equivalent. Instead it’s a complex, targeted workaround designed to enable Flash users to overcome Steve Jobs’ player ban by enabling a small subset of projects to be recreated within the WebKit-based iOS browser runtime.

All in all it’s a huge amount of effort for what at first sight looks like very little gain. Again though, it’s important to dig a little deeper.

First, it’s important to recognize that eye-catching banner ads might be irritating, but they are also incredibly important. They are helping to pay for your free access to this article and to much of the high quality content on the web. Apple’s unilateral ban on Flash threatened to remove the most highly sought-after demographic (affluent early adopters) from the equation (and coincidentally open them up to Jobs’ own iAds system).

It certainly won’t be welcomed in all quarters but, by enabling rich Flash ads to again be delivered to a truly universal web audience including iPhone and iPad users, Adobe is actually doing the web economy a major service.

And if it goes some way to breaking the knee-jerk association of irritating ads with Flash that’s a good thing too. Who knows, maybe the legion of Apple-based ad haters who supported Jobs’ ban so strongly when it was first announced will now be as vociferous in their support for Flash. After all you can block Flash, but you can’t block HTML5.

Yes banner ads are central, but I also think that Adobe has bigger fish to fry. Recently I wrote about Adobe’s Digital Publishing system and was astonished to find that the early trial release seemed to depend on bitmaps to enable InDesign users to recreate their typographically-rich layouts for iPad delivery. Clearly recreating rich designs via more efficient, scalable SVGs and CSS is a far superior solution (though still nowhere near as simple, efficient or elegant as doing so via Flash).

The underlying principle: universal access

Crucially, recreating publications via WebKit provides a way for designers and publishers to ensure that their rich content can be viewed by all users including those who would otherwise be off limits in Steve Jobs’ walled kingdom.

It’s this determination to provide the richest possible experience, whether inside the browser or inside the player, that cross-platform web development is all about. It also demonstrates Adobe’s determination to be seen as the leading HTML5 force, as well as the company behind Flash.

But if you’ve shown that you can deliver rich content universally within the browser via HTML5 rather than the player, isn’t this the right thing to do? If you’ve proved that you can do it without Flash then why not just drop it entirely? Why not just extend the system to the other browsers and develop dedicated stronger HTML5 tools as Jobs suggested? In fact isn’t this proof that Jobs was right all along?

Well according to its recent AdobeMAX, Adobe is indeed working on dedicated HTML5 tools. However it’s important to understand that even these will not replace Flash. And for the same reasons that we’ve already seen in practice.

Unsupported capabilities

The unspoken assumption that of course the browser can somehow just “do Flash” is fundamentally mistaken.

Yes, Wallaby is a trial preview and its HTML5 power can certainly grow, but it will never replace Flash. This isn’t because Adobe is holding back; rather it’s because “the inability to represent some Flash Professional features in HTML5” is inherent.

In particular Flash has come a long way from its animation and banner-ad origins and nowadays the rich functionality of today’s powerful modern Flash-based RIAs are based on ActionScript’s rich APIs. These APIs are enabled by the Flash runtime and while the HTML5 browser runtime will be better than it was, and can already just about take over Flash’s animated advert duties, it can’t possibly be expected to completely replace the dedicated players.

The unspoken assumption that, of course, the browser can somehow just “do Flash” is fundamentally mistaken. After all Flash and Silverlight are modern, intensively-developed technologies representing thousands of hours of development from the world’s two major software forces, both of whom are effectively betting the company on the success of their cross-platform web platforms.

By contrast the vector-based SVG 1.1 specification, which is absolutely central to any hopes of delivering resolution-independent, scalable, Flash and Silverlight-style rich design in the browser, was developed by an ad-hoc, part-time committee of volunteers with very different plans in mind (think rollover buttons) and hasn’t been updated since January 2003.

Workflow complexities

Yes, working with Wallaby is complicated, but again this is inherent. Standards such as CSS, SVG, DOM and JavaScript have evolved independently and erratically and trying to yoke them together is not simple. Flash Professional or Builder certainly aren’t models of simplicity (Expression Blend is far superior), but clearly ground-up, integrated, wysiwyg design-oriented solutions have a major advantage here.

Adobe is only targetting the iOS version of Safari for a very good reason: every other browser supports Flash

Not least they have the huge advantage of targeting a single, reasonably robust and reliable cross-platform, cross-browser runtime. For Wallaby to extend its HTML5 output to other browsers, Adobe would have to work out the constantly moving targets of their capabilities and foibles, come up with the necessary workarounds and, assuming delivery is possible, implement browser-sniffing to serve up the desired targeted code.

Thankfully this whole nightmare is unnecessary because every other browser on every major platform (mobile as well as desktop) apart from Safari on the iPhone and iPad supports the Flash player. Crucially this includes older browsers too. After all, as Microsoft has only now added support for SVG to IE9, any truly universal HTML5 solution would otherwise have to wait not just for IE6 to be purged from the system, but IE7 and IE8 as well.

This universal cross-browser compatibility is strangely overlooked but is perhaps the web players’ greatest strength. Crucially it ensures that the web platforms that the players enable are automatically immune to the foibles, foot-dragging, incompetence and occasional sabotage of the various browser developers. As any web designer who lived through the previous browser wars knows, trying to ensure consistent delivery across all browsers while being forced to travel at the speed of the slowest is not fun.

The fact that Wallaby only targets iOS Safari isn’t a failing. There’s a very good reason for it: every other browser, including IE6, already has a far better, more efficient, more robust, more reliable, more independent, more powerful delivery mechanism in place. It’s called “Flash”.

HTML5, Flash, Silverlight: It’s your choice. Or should be

This isn’t to say that Flash is in any way a general replacement for HTML. Of course the future of the web belongs to HTML5 (though bearing in mind the reality checks above).

If you can deliver content and functionality successfully in the browser then this is what you should do. Flash isn’t an alternative to HTML and never has been; it’s a rich wysiwyg extension. 99.9% of web pages can and should live without Flash.

However when HTML5 can’t deliver the goods as simply, as efficiently, as reliably, as universally, or as well as Flash or Silverlight or any other web technology that comes along, then all designers, developers and end users should be able to take advantage of what the cross-platform extensions have to offer. It’s a simple question of freedom of choice.

The real problem and the real solution

The real problem here isn’t Flash; it’s the lack of Flash. And Steve Jobs could solve that instantly

Cross-platform web players aren’t somehow a problem that needs to be overcome to enable truly universal, truly rich, browser-based delivery; they are the solution that makes it possible.

Steve Jobs realised this and the threat that rich device-independent development poses to his native apps and to his ugly business model and that’s why he decided to kill it.

Steve Jobs is not championing HTML5 to make the browser as rich as possible; he is championing HTML5 as cover for his attempt to kill player development to ensure that the browser never becomes a truly rich, robust and open platform.

The real problem here isn’t Flash; it’s Steve Jobs.

At any time Steve Jobs could simply lift his entirely artificial ban, save everyone all this unnecessary pain and, by doing so, deliver his users what he promised them: “the best web experience”.

Until that happens, the best we can hope for is a partial, awkward, undesirable workaround to try and restore some sort of unity and universality to the rich web. It’s in this context that Adobe’s Flash-to-HTML5 conversion should be understood and appreciated.

A shaky bridge into Apple’s walled kingdom is better than nothing.

The dust has begun to settle on the announcement of the new iPad 2 and first reaction has generally been positive. Not everyone’s persuaded, however. Darien Graham-Smith’s objection – The iPad 2: yes, but still, what’s it for? – is that it’s still just a cross between a glorified smartphone and cut-down netbook, so what’s the fuss?

Darien’s right: tablets are just another form of existing computers, but I think that they are as revolutionary as Apple claims. In particular I think they will come to provide our main platform for consuming web-based content. Key to this is the tablet’s new, book-like, handheld form factor which allows computers to become truly personal and enables their users to move on from merely browsing content to actively and immersively engaging with it (the activity previously known as “reading”).

Apple, as well as pioneering the tablet format, currently produces the best implementation of it and the iPad 2 will raise the bar even higher. Moreover, by providing a superior system for the same price, end users will clearly be getting more for their money.

However, I won’t be buying an iPad for the foreseeable future. And I don’t think that you should either…

Apple v Flash: a matter of principle

The iPad isn’t designed to provide the best web-based experience, but to prevent it.

So why not? Follow the argument and it leads to fundamental principles of openness and choice, and a crucial fork in the road that will determine the very nature of the web, of computing and even of how we do business. On the surface it all comes down to the fact that the iPad 2 still doesn’t support Flash.

To most people this probably sounds trivial. Clearly the lack of Flash support is inconvenient – especially in a device supposed to be providing the best web experience – but is it really a deal breaker?

More to the point, surely it’s only a temporary inconvenience? After all wasn’t Steve Jobs’ main objection to Flash that it wasn’t suited to low-power devices? Clearly the iPad 2 is more than capable of supporting the new mobile-optimised Flash 10.1 player, so presumably it must now be in the pipeline? After all, why should Apple give Android such a clear advantage and selling-point? Just relax and wait for the iPad 3.

Well I don’t think that Flash or Silverlight support is coming and, when you unpick why, it reveals the iPad in a very different, unflattering and frankly sinister light.

Apple v Flash: war is declared

Personally the scales fell from my eyes when, the day before the launch of Adobe’s Creative Suite 5, Apple announced that it was changing its terms of service to ban third-party development tools. This deliberately hostile act completely undercut what should have been the star capability of the new Flash Professional CS5, its ability to produce native iOS apps. You could still produce them, but now there was no point as the only way to get apps through to end users is through the App Store which Apple controls, and now the company had unilaterally banned any apps that were in any way associated with Flash.

A tweak to Apple’s terms of service might again sound trivial but I was astonished and appalled. How could you possibly justify not supporting any means of writing native iOS applications? It meant that Apple was willing to deny its users choice and functionality and was willing to fight very dirty to damage Flash and to keep it off its devices.

The obvious question was: why?

The answer is simple: follow the money.

Why Apple hates Flash #1: Apps

Crucially, Apple doesn’t only make its profits from its devices. Much of its revenue also comes from native iOS apps that are only available via the App Store. Of course many of these are free but, when they aren’t, Apple takes a non-negotiable 30% of the price paid. Imagine the sort of money that Microsoft would have gained if it had taken 30% of every Windows application ever sold.

The danger for Apple would be if there was another way to deliver rich app-style functionality and deliver it outside of its App Store and, worst of all, deliver it independently of its devices. Step forward the cross-platform Flash and Silverlight players and the future of rich cloud-based computing based on browser-hosted Rich Internet Applications (RIAs).

Ultimately Steve Jobs wasn’t really concerned about Flash-derived native iOS apps and indeed has since backed down on this front. Rather, as his Thoughts on Flash show, Jobs’ hatred of Flash goes far deeper: he wants to drive the technology – currently installed on around 99% of internet-connected systems – off the web entirely.

As I wrote at the time (The fundamental differences between Flash and HTML and the real reasons that Steve Jobs wants to kill it) this isn’t actually because of Steve Jobs’ surprising and less than convincing belief in open standards, but rather the opposite: his absolute determination to stop the browser-based web becoming a platform for rich device-independent applications.

Jobs’ Thoughts on Flash succeeded better than he could possibly have hoped. The message has come over crystal clear to developers (though not end users) that Apple has absolutely no intention of ever supporting cross-platform players.

At a stroke cross-platform Flash and Silverlight development has been deprived of its major and essential attraction – universality – and the move towards delivering truly internet-based rich internet applications has hit Apple’s brick wall. By walling off its users, Apple has managed to sabotage the development of the rich cross-platform web for everyone, not just its own users. Flash has indeed been damaged, and possibly terminally so, if Apple is not forced to change its policy.

In the meantime there is no alternative. Developers realise that if they want to access the lucrative iPad market – and they do – then they need to do it the Apple-approved way. That either means producing comparatively design-poor HTML5 apps (think free) or signing up to become an xCode-based rich iOS apps developer and accepting Apple’s terms of $99 a year and 30% of any sales.

Why Apple hates Flash #2: Content

It gets worse. It turns out that Apple has an even bigger incentive to keep Flash off its devices which goes to the very heart of the new handheld tablet form factor: its ability to replace paper as the future electronic delivery route for newspaper and magazine content.

Currently just about all newspapers and magazines are produced using the two main publishing packages, InDesign and QuarkXPress. For years both packages have been developing their ability to output rich and interactive designs to Flash, ready for the arrival of tablet-based delivery.

When the first tablet did appear, everyone simply assumed that the iPad would naturally embrace such rich Flash content. Or they did until Steve Jobs made it clear that he had other intentions and that, amazingly, Apple’s devices would be kept a Flash-free zone. If publishers want to access the lucrative iPad userbase – and they do – then they need to do it the Apple way through native apps.

Both Adobe and Quark have been forced to entirely rethink their electronic strategies, ditching Flash and coming up with brand new digital publishing platforms based upon native iOS readers.

I must admit that I thought that Apple’s anti-competitive behaviour and artificial restriction on iPad functionality – holding back tablet-based publishing for over a year – was an incidental by-product of the need to keep Flash off its devices to protect its apps revenue. After all, once the free reader apps were installed, surely the publisher would simply be free to deliver content to it and charge accordingly? Guess what?

Follow the money

In mid-February Apple unveiled its new App Store subscription service, allowing publishers of content-based applications – not only newspapers and magazine publishers, but video and music broadcasters – to offer recurring billing based on its In App Purchase API.

At the same time it announced that it was enforcing terms preventing iOS software from “utilising a system other than the In App Purchase API to purchase content, functionality, or other services in an app.” and that it was therefore banning a number of existing apps such as Sony’s eReader and digital library.

For good measure it also added new terms preventing apps linking to external websites to purchase subscriptions and banning the use of lower out-of-app subscription rates to undercut the in-app rate with its 30% tax. And just in case you thought you might have spotted a possible loophole, it also warned publishers that they cannot provide free iOS-based access as part of print-focused subscription packages.

Apple’s walled garden

Apple’s real business model is to hold its users hostage within its walled garden and then to charge heavily for access to them. This isn’t “insanely great”… it needs to be stopped.

Suddenly the billions in app revenue seem like very small beer. Apple wants a non-negotiable 30% of every commercial transaction (revenue, not profit) in any way associated with its devices. And it wants it for ever with absolutely no possibility of competition.

Worse, Apple is claiming this enormous prize for one reason alone: it’s holding its users hostage within its walled garden and then charging for access to them.

Even more incredible: Apple is getting away with it. The developers, publishers and other providers can’t complain too loudly because they can’t afford to fall out with Apple – not when it owns the App Store and so controls the only way in to the walled garden.

Meanwhile the end users and reviewers seem to be so dazzled by their brilliant hardware and apps that few of them seem that interested in what’s going on behind the scenes and outside the wall.

The iPad revolution

Yes the iPad is truly revolutionary, but not in the way that Apple would like you to think.

Ultimately the iPad is not about providing the best web experience to end users, in fact quite the reverse. By trying to kill Flash and Silverlight development and so restricting the browser-based web to HTML, Apple is deliberately holding back its full potential to ensure that the next generation of rich internet apps and rich internet content are artificially tied to its own devices and routed through its App Store.

Apple’s refusal to support cross-platform web standards and its walled-garden strategy goes entirely against the extensible nature of HTML and the open cross-platform principles on which the web is built. At the same time its anti-competitive App Store, with its unavoidable 30% tax, goes against all established business standards.

Ultimately it’s not the beautiful design and engineering that makes Apple unique, it is the company’s ugly business model and practices. The iPad isn’t designed to provide the best web-based experience, but to prevent it. Rather than ushering in the future of internet-based computing, Apple is squatting on it.

The Android Alternative

Thankfully there is an alternative. Despite Apple’s new slogan “it’s not a tablet, it’s iPad 2″, there is nothing inherently different about the iPad; it really is just a handheld computer. The coming invasion of Android tablets will do all the things that the iPad can and will also support Flash as well as AIR (for offline apps) and Silverlight and any other cross-platform web standards that come along as the future of rich cloud-based computing develops.

Crucially Android’s unlocked tablets will also support traditional, open competition free of Apple’s 30% tax and 100% control.

Thanks to Android there is an alternative to Apple and so no reason that we should allow Steve Jobs to divert and subvert the rich future of the open web.

The iPad 2 might look attractive but that hides a much darker side. Now isn’t the time to buy into Apple’s walled garden; now is the time to break free and – ideally – break it open.

At its recent Professional Developer Conference Microsoft’s Bob Muglia signalled a major change of strategy for the company’s Silverlight technology. When first introduced Silverlight was intended to become a near universal cross-platform web runtime like Flash. Now Muglia revealed that Microsoft saw HTML5 as the future for universal in-browser development while Silverlight was being repositioned as a native application development platform for Windows Phone 7 devices. Unsurprisingly, most pundits saw this as an admission of defeat, with our own Jon Honeyball asking: “Silverlight RIP?”

Yesterday, just over a month later, Scott Guthrie announced the “Firestarter” launch of the new Silverlight 5 beta under the slogan “the future of Silverlight starts now”. So what’s going on?

Silverlight 5: What’s New

Silverlight 5 offers a whole host of major new features, with general highlights including support for GPU-based graphics and video handling, 64-bit support, a new web browser control for hosting HTML content, the ability to read and write to the user’s Documents folder, the ability to launch Office apps, reduced network latency and improved XAML parsing to boost performance, and a new class of trusted applications that will provide full desktop functionality within the browser.

For developers there are a number of additional advances including databinding and debugging enhancements and support for Model View, multiple window handling, Visual Studio profiling and Team Test. For designers the highlights include video improvements, smoother animation and greatly enhanced text handling with support for features such as tracking and leading, pixel snapping, multi-column layouts and text runaround promising “magazine-style handling”.

All in all it’s pretty impressive stuff, leveraging Microsoft’s Windows, Office and development strengths and taking web-based application delivery into places that HTML5 can only dream of. Moreover, while there isn’t an obvious immediate game-changer here, it’s clear that Microsoft isn’t exactly taking its foot off the pedal and is still pushing the cross-platform Silverlight runtime hard.

So what should we make of Microsoft’s mixed messages? In particular is Microsoft recommending HTML5 or Silverlight? Should Silverlight be used for cross-platform web development or native WP7 application development? And who’s in charge: Bob Muglia or Scott Guthrie?

I think the best way to understand what is going on is to think in terms of the near, middle and long term.

The war on the ground: handheld combat

Currently there’s no doubt that Apple is in the ascendant with the iPhone and iPad setting the standard for smartphone and tablet devices, and its native iOS applications conquering the planet. Moreover with his ban on the Flash and Silverlight runtimes, Steve Jobs has ensured that both Silverlight and Flash have lost their greatest asset: universality.

Unless that ban is dropped or users defect, Steve Jobs is effectively able to hold the all-important demographic of affluent early adopters hostage in his magical walled garden: the only open way to access them is via HTML(5) as indeed Microsoft has done with its Silverlight-free Office web apps.

Clearly Microsoft needs to become competitive in this handheld space that Apple has made its own and Windows Phone 7 is crucial to its plans. Making Silverlight the development platform for WP7 makes absolute sense in the near term, allowing the army of desktop Windows developers to take their skills to the mobile platform and begin making some money. Moreover, while Apple is holding back the potential of universal in-browser Rich Internet Applications, concentrating on native application development again makes sense: if you can’t beat him, copy him.

Thinking ahead: don’t forget the cloud

In the longer term however, the picture is likely to change completely. At the moment Apple is pretty much the only game in town and everyone is delighted with what their iOS native apps can deliver. Over the next few years devices are set to proliferate, not just WP7 devices but devices from RIM and Nokia and, even more significantly, from the wide range of Android and soon Chrome OEMs.

This will provide real competition for Apple but it will also mean that the advantages and economies of scale of cross-platform, in-browser development and delivery will again become obvious: better, cheaper, automatically up-to-date apps that aren’t tied to a particular device and are accessible to everyone from anywhere and everywhere.

Apple’s current dominance obscures the fact, but the future of computing still lies with universal rich internet applications in the browser (and content on the server), not with device-specific native applications. Apple can’t deliver to the world as a whole, but the cloud can and will. When this is recognised, the benefits of a native application platform that automatically extends to an in-browser runtime, and so to all supporting platforms and devices, will come into its own. And Apple’s closed approach, exemplified by its lack of a cross-platform runtime, will be exposed.

As things stand, Silverlight is certainly not delivering in the way that Microsoft or developers had hoped and expected. In particular its inability to make inroads against Flash in the browser and the emergence of Apple as the handheld superpower have left it caught in no-man’s land. And shooting yourself in the foot as Bob Muglia did at PDC certainly doesn’t help.

However talk of the demise of Silverlight is premature. Yes things are happening quickly, but the war for the web isn’t going to be won in a day. In particular while there is huge excitement among early adopters for the potential of the handheld space and in particular for Apple’s brilliant devices, they still make up only a tiny fraction of the market.

By the time that every user is looking to buy a smartphone and tablet (and early adopters their next smartphone and tablet), the situation will be very different. General understanding of the benefits of cloud-based delivery (online and offline) will have matured and the next generation of open, handheld devices optimised for both Silverlight and AIR will be able to deliver.

When these foundations are in place, users will be looking for an integrated approach to computing that spans their smartphone, tablet and set-top box. Crucially, they will also want to integrate their desktop (Windows) and their main applications (Office and other WPF-based applications). Thanks to its work on HTML5, WPF and especially Silverlight, Microsoft and its army of desktop developers will be well set to deliver.

Rather than an admission of defeat or forced retreat, Silverlight’s current shift towards WP7 native development should be seen as strategic repositioning and the opening up of a second front. Eventually though, as Silverlight 5 demonstrates, Microsoft is still betting that the war will be won in the air.

There’s a lot of excitement in the world of publishing regarding the massive potential of the new tablet market. The biggest news at the recent Adobe MAX 2010 was the official announcement of Adobe’s upcoming Digital Publishing platform for delivering rich, interactive electronic magazines using the Creative Suite design tools and InDesign in particular.

The reason for the excitement is obvious. Up until now the internet has been a disaster for the big publishers, as they’ve effectively been forced to cut their margins, and occasionally throats, by giving away content for free online. Now with the arrival of the tablet, it’s possible for publishers to provide a far richer, handheld, book-like, reading experience. The end user is happy because it’s a fundamental advance on both traditional print and web browsing, and the publisher is delighted because here at last is the chance to charge for content while taking full advantage of the internet in terms of its global audience and  minimal production costs.

At AdobeMAX 2010, Kevin Lynch and Martha Stewart demonstrated the new electronic magazine format in action on an iPad – it’s essentially the same system that’s behind several existing iPad publications including Dennis Publishing’s own iGIZMO (which is free). With rich wysiwyg layout and typography that fully reflects the print-based brand, dual-axis touch-based navigation (vertically to move within stories, horizontally to move between) complete with zoom overview and table of contents overlay, the ability to flip intelligently between landscape and portrait orientations and lots of interactive capabilities – embedded movies, audio, slideshows and so on – it looked suitably impressive.

The thought that came into my mind on seeing it in action was how is the page design actually being delivered? I’ve long assumed that the underlying media would be Adobe’s own Flash format as this is perfectly suited to the task with its PostScript-style, vector-based handling of typographic text, its rich media support and interactivity, its tie-in with AIR for offline usage and its near-ubiquity across all devices. Moreover, having built up InDesign’s Flash authoring capabilities, it would certainly be simple for Adobe to deliver such a solution.

Flash out, iPad in

The problem of course is Steve Jobs and his determination to keep Flash off Apple’s handheld devices. Ultimately a tablet magazine delivery system isn’t much use if your publications can’t be viewed on the market-leading and market-defining tablet. In short the iPad is the one demographic you cannot afford to ignore.

So Flash is out and indeed hardly mentioned on the Digital Publishing FAQ which states “The Production Service will support a range of file formats, including PDF and HTML5” and which provides a dedicated section entitled “Will Adobe make HTML5 an integral part of its Digital Publishing Solution?” to which the answer is a resounding “yes”. But if Flash is out and HTML5 is in, how has Adobe managed to turn it into a wysiwyg, truly typographic design medium?

Details are still relatively thin on the ground, as the Digital Publishing platform is only aimed at major publishers (at least to begin with) and doesn’t go live until Q2 2011, but digging around on Adobe Labs I came across a PDF of the Digital Publishing User Guide. This provides tutorials explaining how you go about converting your InDesign print layouts for the iPad and provides lots of useful information about which InDesign features are supported natively – eg hyperlinks, buttons and scrollable frames – and which are handled as overlays – eg audio and video.

It also talks about the Content Bundler which is used to upload your files to the centralized hosting service and the all-important Adobe Content Viewer, which delivers the magazine along with crucial publisher support services such as usage tracking and analysis, personalised advertising and e-commerce handling. It also reveals “Currently, when you bundle an issue, images files—either PNG or JPEG—are created for each page of every stack.”

Bitmaps In 2010!

Going back to bitmaps and targeting individual screen resolutions might sound regressive, prehistoric even

I have to say I was shocked at this. This is 2010 after all and each page is being delivered as a bitmap! It reminds me of my very first article for PC Pro,written back in 1996, when I took a look at QuarkImmedia, which at the time was the company’s best hope for enabling  print-based publishers to deliver electronic interactive magazines via the internet. Even then I was shocked that Quark could think that fixed size, bandwidth-unfriendly, unsearchable, effectively unprintable bitmaps could possibly be the delivery vehicle for electronic magazines.

On reflection however, I have largely been won around. To begin with, today’s broadband/Wi-Fi/tablet environment is a completely different world and while bitmap-based delivery isn’t exactly efficient, we’re no longer dealing with dial-up 56k modems. Moreover for design-intensive layouts where you have text overlaid over an image, which is the norm for magazines such as the “Boundless Beauty” special edition of Martha Stewart Living which was demoed at AdobeMAX, you’re really going to have to send all that bitmap data anyway. In fact, if you’re going to be including full-screen videos, then a few bitmapped pages are the least of your worries.

Moreover, bitmaps do have advantages. In particular producing a bitmap targeted at a particular screen resolution (or rather two, one for each orientation) means that the text quality/aliasing can be absolutely optimised to the particular device. In other words, if you want absolute pixel perfect control then bitmaps do make a lot of sense.

More importantly, the design and overall experience as delivered by the Adobe Viewer application clearly works. In particular thanks to features such as the orientation-swapping and smooth scrolling of extended pages, it’s clear that users don’t feel that they are being short-changed with a glorified JPEG slideshow, but rather that they are reading a sophisticated page-based, screen-optimised magazine.

It might be slightly deceptive but, as the term “HTML5” is generally used to refer to all the open web standards, then the Digital Publishing platform’s combination of JPEG and PNG with some clever scripting can just about live up to the title, even if there’s very little HTML code. Most importantly, by scrupulously avoiding Flash and providing a ground-up, Objective-C, iOS-compliant Viewer and AppStore-based delivery, Steve Jobs is kept happy – or at least can’t complain. Crucially this means that publishers can use InDesign to repurpose print work for the iPad even if they have to do a bit of tailoring, tweaking and overlaying to do so.

Scalability: Flash to the rescue?

The big problem is that everything starts to fall down in terms of scalability when you remember that Apple is only one provider. What happens to the bitmap-based approach when screens of all shapes, sizes and resolutions start appearing? Moreover, when you buy a magazine do you want it to be inherently tied to just one device? Come to that, what about the next, higher-resolution iPad? Clearly it’s not viable to produce a magazine optimised for every device so maybe bitmaps aren’t a long-term solution after all.

Hmm. What we need is some sort of typographically-rich, vector-based format that can scale to deliver resolution-independent quality. Fortunately every other tablet device manufacturer isn’t taking Apple’s anti-Flash strategy and has pledged to support AIR (Adobe Integrated Runtime) and through it Flash. It looks very likely that when Adobe says “currently” all pages are being delivered as bitmaps, that’s because in future all non-Apple tablets will also have the option of using scalable Flash SWF.

Even if Flash isn’t involved in Adobe’s future plans, Adobe deserves a lot of credit for its Digital Publishing platform. Going back to bitmaps and targeting individual screen resolutions might sound regressive, prehistoric even, but the results aren’t and that’s what matters. More importantly, by jumping through Steve Jobs’ hoops and focusing on the no-Flash iPad, Adobe is making sure that Apple has no excuse to take its ball off to play on its own.

Ultimately, alongside its reading experience, the most important capability of any electronic publishing medium is its universality. By going back to bitmap basics and making sure that the foundations of the Digital Publishing framework don’t require Flash, it looks like Adobe has created a ground-up solution to Jobs’ Divide-and-Rule strategy and a brilliant way to maintain the internet as a single, integrated and universal medium.

To the intense annoyance of both firms, it appears Apple is holding sway here with its insistence that neither Silverlight nor Flash will be allowed on the iOS platform used in the iPhone and iPad. And that, in its opinion, HTML5 is the future.

Well, there is no doubt that HTML5 is the future, in that the current HTML5 implementation leaves much to be desired and it will take time and work for this to be fleshed out. But Apple says no, use native code on iOS or use HTML5.

This is a real problem for Microsoft. On the one hand, it looks forward to the HTML5 future, and the new build of IE9 shows that Microsoft is absolutely determined to be an HTML5 leader. It’s certain that it’s not going to be lagging behind as it was on previous browser versions. And its claimed adherence to the standards means that there will be less, hopefully none of the custom IE stuff we have seen in the past.

For Microsoft, Silverlight is a real problem. It has developed what is a strong development platform and runtime, and it has gone from nothing to this robust platform in just a few years. However, there is a point of view that Microsoft is up to its old tricks already – the support for COM objects on the Windows version means that the Mac version is not in sync.

And where is the real Linux version we were hoping to see? Given the HTML5 future, you might think that Silverlight is being sidelined, and maybe it is. But it’s the core development tool for the new Windows Phone 7 platform. So is it on life support, being retargeted at WP7 and away from the desktop? Microsoft won’t say other than Bob Muglia’s comment to Mary-Jo Foley that its “strategy has changed”.

If I was trying to build a rich internet application today, then the confusion surrounding Flash, Silverlight and the future HTML5 would be enough to make me tear my hair out. Maybe we need to accept that code is truly a “use, consume and dispose” item and that there is no long-term future to most anything. Build what works for today, but make sure you don’t align yourself with just one platform.

It’s a serious concern. Adobe is not only the developer of the main professional HTML authoring tool, Dreamweaver, but also of the Flash platform which promises to take the browser beyond HTML into richer, more powerful territory. Clearly there’s a possible conflict of interest here – a point I made at the launch of the latest CS5 suites when the page-oriented Web Standard suite was dropped in a blatant attempt to push designers towards the Flash-centred Web Professional suite.

Unfairly promoting Flash is one danger, but far worse is the possibility that Adobe would want to hold HTML5 back. This suspicion dawned with the limited HTML5 capabilities in Dreamweaver CS5 and was reinforced by Steve Jobs’ attack on Flash which ended: “New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.”

There’s a real danger here that HTML5 and Flash could be driven into opposing camps in the war between Apple and Adobe, and you really don’t want to bet against HTML. Based on the latest Adobe MAX 2010, it looks like Adobe is well aware of the potential trap and has acted accordingly.

Words and actions

In the second keynote, Adobe evangelist Ben Forta tackled the issue head on, admitting the fact that Adobe is seen as “the Flash company” and that HTML5 is seen as “the Flash killer” doesn’t look good. However, a running theme throughout Adobe MAX 2010 has been that Flash and HTML5 shouldn’t be seen as rivals but as natural partners.

More importantly Adobe made it clear that, of the two, HTML is the senior partner and that it is absolutely committed to HTML5 and the other W3C web standards, a major change from the Flash-centric Adobe MAX 2009.

A running theme throughout Adobe MAX 2010 has been that Flash and HTML5 shouldn’t be seen as rivals but as natural partners.

The first practical indication of this is that Adobe has released an HTML5 extension pack that is part of the recent 11.03 update for Dreamweaver CS5. This adds a number of HTML5-based capabilities, the most obvious of which is the ability to target designs at multiple screen sizes via resolution-dependent style sheet swapping.

The result is adaptive layouts that can be previewed in LiveView automatically responding to the screen real estate available to them (whether they do so in the browser depends on its CSS3 media query support).

In addition Adobe announced that full support for jQuery/Mobile is coming to enable rich HTML5 development for smartphones. The company is also working on a new tool, Adobe Edge, to create interactive HTML5 experiences based on a JavaScript  framework for animations that will be contributed back to the jQuery project.

Adding to HTML5

This is impressive stuff, but Adobe is going far further to show its commitment to HTML5. Key here was the announcement that Adobe has been working on script-based extensions to HTML5 that will enable essential missing design functionality such as the real-time text flow around images that it demoed at MAX 2010. Crucially Adobe is making these extensions openly available and submitting them for inclusion in WebKit, which should help to radically improve the design quality of browser-based rendering across all platforms, devices and browsers.

Potentially this is very exciting. I’ve argued in the past that web browsing is very different from immersive reading (think of the centuries of typographic expertise built up regarding fonts, kerning, hyphenation, text compositing and so on) and just couldn’t see how a truly rich reading experience could possibly be delivered by browser developers, who have shown no typographic understanding or interest.

Nor could I see how it could be delivered via CSS which, invaluable though it is, is still effectively a sticking plaster covering up HTML’s total and deliberate indifference to content presentation. Moreover, the very nature of multiple browser development seemed to ensure that HTML/CSS could never provide a robust and universal platform where designers could know precisely how their rich designs would work across multiple implementations.

The obvious way that just this sort of rich, robust and universal web design platform can be delivered is via Flash (and alternative runtimes such as Silverlight). Now, though, it looks like there might be an alternative route through which Adobe can enable all browsers to take advantage of its typographic expertise.

I’m not sure how far this can go. The ideal would be for Adobe to effectively provide a shared universal compositing engine of the same sophistication as InDesign’s multi-line composer that would respond in real-time to the sort of CSS3-based adaptive layout handling that Dreamweaver has just introduced.

I’ve no idea whether this is practically achievable or what Adobe has in mind and clearly it’s a huge leap from a text runaround demo. However, it’s certainly something to aim for, and the fact that in his keynote Kevin Lynch, Adobe’s chief technology officer, talked of working alongside Google and the HTML5 working group sounded positive.

Coming back to earth, any design improvement for HTML5 is a welcome development. Perhaps just as importantly, it shows that Adobe is determined to be proactive when it comes to HTML5 and also that it’s not trying to prevent HTML5 moving into what might be seen as Flash territory – quite the reverse. This has to be right.

So what about Flash?

It’s clear that Adobe is acting on Steve Jobs’ advice and “creating great HTML5 tools for the future” and actively improving what the HTML5 technologies can deliver as a platform. However this certainly doesn’t mean that Flash is dead as Jobs would have everyone believe.

To begin with, even if HTML5 can eventually be made to deliver as a typographically-rich adaptive design platform, that doesn’t make Flash redundant. In particular I still think that Flash’s more fixed PostScript-style approach, and the integration with InDesign, Quark and all other Flash supporting applications that this enables, means that it will become the natural platform for wysiwyg magazine-style value-added delivery and the move from web browsing to immersive web reading.

Moreover as HTML5 moves into existing Flash territory, Flash is moving into new territory — as the demos of Google TV, Flash’s role within cross-platform AIR-based application creation and the new 3D APIs proved. In short, Flash is strong and getting stronger and doesn’t need to be protected.

Based on MAX 2010 it looks as if Adobe understands that it needs to push both HTML5 and Flash as hard as it can, both together and separately.

Now this is interesting. The New York Times has just reported talks between Microsoft and Adobe and possible discussions of a takeover. There’s certainly an apparent logic at work. The PC Pro news story quotes analyst Toan Tran saying “It may be a case of ‘the enemy of my enemy is my friend’ and both Microsoft and Adobe have a common enemy in Apple.” With both companies suffering under the current Apple surge, perhaps such consolidation makes sense.

On the other hand there are lot of arguments against.

Perhaps the biggest is that Microsoft thought long and hard about buying Macromedia to get its hands on Flash and decided against, largely because it thought it could do better. The result was Microsoft’s huge investment in XAML/Expression which ties in its current Windows and .NET strongholds via WPF, with the cross-platform browser-based future that is Silverlight. As the developer of the only realistic competitor to Flash, the idea that Microsoft can simply jump ship is clearly simplistic.

I also think that neither company would actually see its current position as hopeless – or even weak. Apple has certainly caught both companies off guard and seized the initiative, but both are readying their response. In Microsoft’s case this takes the form of its “iPhone-killer” Windows Phone 7 for which Silverlight is the application development platform. For Adobe, its new mobile-optimised 10.1 player is key and with every major device manufacturer except Apple signed up to supporting it , Flash looks set to be as big a presence in the handheld space as it is on the desktop.

I would argue that Apple’s apparently impregnable walled kingdom (actually only 1.1% of the total web market) is about to come under serious attack on two fronts and on all sides. While Microsoft and Adobe certainly have things to talk about (for example the promised 10.1 player for Windows Phone 7), the idea that they need to throw their lot in together is wrong.

More importantly it would be an anti-competitive disaster, putting Microsoft in charge of the two currently competing player-based solutions on which the future of rich cloud-based computing depends. My biggest fear would be that, rather than jumping ship to Flash, Microsoft would sign up to Steve Jobs’ narrative that Flash is yesterday’s technology and that the future belongs to WPF/Silverlight alone. The takeover could in fact be hostile.

If the possible takeover is neither necessary nor desirable does that mean it won’t happen? I certainly hope it’s just a misguided rumour and, if not, that competition laws would prevent it. However it’s clear that the ‘we-need-to-consolidate-to-compete-with-Apple’ story might play. And it’s also clear that this could be very much in Microsoft’s financial and strategic interests.

However the real benefit to Microsoft wouldn’t be in its fight with Apple (happy to cream off just the richest users and to ignore the browser-based cloud in favour of its closely controlled iOS apps) but with the far bigger threat posed by Google. Ultimately Google’s universal, browser-based vision of the future of computing (and so the end of Windows’ hegemony) depends on rich internet applications (RIA) and so largely on Flash (hence Google’s support of the format, building the player directly into Chrome and so on). If Microsoft owned both RIA technologies it would effectively own the future of rich cloud-based computing, and so the fate of Google’s competing vision would lie in its hands.

In the interests of fair competition and the future of the web, I certainly hope that if anyone is going to buy Adobe and Flash, it’s not Microsoft but Google.