Rather than buy a new laptop, I recently decided to recondition a four-year-old Acer to see whether it was up to the relatively light duties intended of it. This laptop had been my workhorse during a period when I was regularly flitting between my home office and business headquarters, and had almost no available space on its 140GB hard disk. The first job, then, was to do some weeding.

Microsoft Office was the first package to go, now that I use Google Docs almost exclusively. I found plenty of dross in the Downloads folder of course, but the real shock came when I looked through the list of Adobe programs installed on this machine and realised that I use almost none of them regularly any more.

When I bought this laptop, I reckon I spent around two thirds of my working day using Fireworks, Photoshop, Illustrator, Flash and Flex Builder – with the last of these accounting for the lion’s share. And yet, over the past year, Flash based development has dropped away almost entirely.

The rot began with Dreamweaver, which I’d been using since it was first launched in the mid 1990s. Since I began creating websites using PHP, and especially when WordPress became the basis of most of my web development, Dreamweaver became irrelevant and I’ve not used it for over five years now.

As I contemplate the future of my online development, for the first time I can’t see a place for Flash

Flash was a different matter. In the early 2000s, I moved from Adobe’s Director product to its lightweight cousin (at least, it was lightweight at the time) for e-learning development and created a series of authoring tools and online playback plugins based on it. There’s much to like about the platform, and our perception of what’s possible with rich internet applications was largely shaped, for better or worse, by the capabilities of the Flash player. So I have much expertise invested in my ActionScript knowledge and a big library of code.

And yet, as I contemplate the future of my online development, for the first time I can’t see a place for Flash. In the short term, this means extra work for me as I recreate these sophisticated applications using PHP and jQuery, but I can’t countenance investing time updating software created for a defunct platform.

The irony is that it isn’t Steve Jobs’ famous hatred of Flash that has caused this turnaround – the true villain of the piece is Adobe itself. By abandoning development of Flash for mobile, it eliminates Flash as an option for most websites. One in ten of the visitors to my sites uses a mobile device, a seven-fold increase over a year ago, so I’d be mad to develop in a form that excludes them. Had Adobe continued to improve the Flash platform for Android, I might have persevered – at least for sites that attract smartphone users rather than tablet owners. Perhaps I should thank Adobe, then, for making my decision easy. It’s now either HTML/CSS/JavaScript or app – and Flash makes for a very expensive app development platform.

In fact, the only Adobe product I use day-to-day now is Fireworks and that’s the only reason I’m keeping Web Premium on my main desktop. It’s also hard to see on what basis I would, in the medium term, be likely to upgrade even that one remaining product. Assuming that I’m not the only one re-evaluating in this way, this poses serious questions for Adobe’s future income. I think that’s sad because they’ve played an important role in shaping today’s web. Whilst it is making efforts, with Muse, Edge and updates to Dreamweaver, I can’t help feeling that the momentum is swinging away from Adobe. What I really want is a fully working browser-based versions of Photoshop, Fireworks and Illustrator that I can pay for on a per-use basis, and unless it has something quite remarkable up its sleeve, I can’t see myself upgrading to CS6.

The good news for me as a businessman is that I no longer need to budget for expensive licences. Adobe’s pricing policy has long been a bone of contention and, given the downward momentum placed on software costs by the advent of apps, Adobe’s looking increasingly isolated. And don’t even get me started on the fact that Web Premium costs £300 more to buy in the UK than the US (and yes, that’s comparing figures net of sales tax). Photoshop is the one remaining crown jewel – heaven help Adobe if a competitor comes along with a compatible application for a fraction of the cost.

Farewell Adobe. Delete.

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)

That’s the kind of feature you expect to find on paid-for software such as Photoshop CS5 and Photoshop Elements, but there’s an app that’ll do the same thing for free on Android and iOS devices – TouchRetouch. Here’s how it’s worked its magic on one of my holiday snaps, with a couple of inconveniently-placed tourists removed from in front of this Cretan ruin:

Here’s the after picture, with those tourists in front of the ruin removed:

If you look closely then you’ll see it’s not perfect – the area of modification is just about evident. Still, it’s extremely impressive for a free app. There’s a paid version available, too, for a mere 62p. Upgrading allows you to output at the same image resolution as the original photo – both of the pics in this post are at 648 x 388 – alongside a Clone Stamp tool for advanced retouching.

Here’s another before and after shot, this time from last week’s LITS. It’s members of the PC Pro team recording our live podcast, and I don’t like the look of that lectern to the right of the stage.

See? Gone:

Once again, it’s not perfect – there’s some pixellation where the app has struggled with the glow of the lamp that was behind the lectern. But even so, for a free app – that’s pretty impressive, right?

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.

My review of the new Creative Suite 5.5 (CS5.5) has just been posted and there’s plenty to talk about in terms of new functionality and what this means in relation to the future of cross-platform design.

However, it’s not so much the extraordinary and mouth-watering creativity of CS5.5 that is likely to strike users as the extraordinary and eye-watering cost.

The Difference Between Price and Value

If you’re downloading software online and subscribing to it online what difference does it make what country you’re doing it from?

Straight up, it’s important to stress that a high price does not necessarily mean poor value. It’s also worth stressing that the full CS5.5 Master Collection is a formidable achievement, offering state-of-the-art creative power stretching from photo-editing and vector illustration through desktop publishing and website creation, to video production and rich internet application development.

Compared to professional 3D applications such as Maya (SRP $3,495), for example, that makes the US cost of $2,599 for the full Master Collection an absolute bargain. The same is true of the $549 upgrade price when you bear in mind that it includes no fewer than 11 updated component applications.

It might be good value but it’s still a seriously intimidating headline figure. Of course most users don’t need the full range of power and Adobe provides the targeted Suite Editions to help keep things more affordable. However while the cheapest Design Standard suite for graphic designers comes in at around half the price of the full Master Collection, $1,399 is still a lot of money. There’s no doubt that the huge upfront cost is putting off new users from joining up to Adobe’s CS-based design platform.

The Difference Between Buying and Renting

Adobe has recognised as much and, with CS5.5, it has introduced a completely new subscription pricing model that effectively lets users rent Adobe’s main CS5.5 suite editions and apps rather than buy them. Prices vary widely but, to give an idea of rates, if you’re willing to commit to an annual subscription (complete with automatic upgrades), the monthly cost for the full Master Collection is $129.

Subscribing won’t be of much interest to current users as there’s no discounted rate if you already own CS5. Moreover, the fact that after two years you’ll have spent more on renting than buying means that, if cash flow isn’t an issue, then the traditional retail route is almost certainly your best option. Especially so if you investigate Adobe’s various upgrade and cross-grade possibilities.

However the subscription pricing will certainly prove attractive to new users who simply can’t afford the upfront cost and also to users of older releases of the software who are generally happy with what they can do, but might occasionally want to try out a new program or the latest functionality.

The Difference between the US and the UK

That’s the good news. Here’s the bad news. I gave the US$ pricing deliberately. At today’s exchange rate, US $2,599 should convert to around £1,575 for the full Master Collection, the $549 upgrade to £333, and the annual monthly subscription rate of $129 to £78. In each case I’d argue that that’s really good value.

Instead the equivalent UK pricing to buy the CS5.5 Master Collection is £2,268, it’s £476 for the upgrade and £116 for the annual monthly cost. And that’s before you add in 20% VAT!

Yes, you can still make a good case for value for the CS5.5 suites in terms of what you can achieve with them, especially with CS5.5’s new ability to deliver rich design and functionality to mobile devices including the potentially lucrative iPhone and iPad markets.

However it’s impossible not to feel exploited and angry when US designers are getting the same products for so much less. The CS5 suites aren’t a rip-off, but the UK pricing certainly is.

I really don’t understand this. The new CS5.5 subscription model shows that Adobe is aware of the importance of affordability. This isn’t done out of the goodness of its heart – Adobe knows that the best way to optimise profits is to maximize its userbase. However for some reason this doesn’t seem to apply in the UK.

The new subscription model brings home the unfairness of Adobe’s international pricing even more directly. The beauty of internet-based delivery is that it provides a truly global audience, as Adobe knows better than anyone. But if you’re downloading software online and subscribing to it online what difference does it make what country you’re doing it from? Why should the UK-based CS5.5 user be charged 50% more (before VAT) for a month’s use of exactly the same software? I really think we can live with US spellings if that’s what it takes to get a fair price.

This isn’t just a question of best business practice. Adobe’s whole cross-platform design vision is built on the principle of a universal and level playing field. The same can’t be said of its pricing policy and it needs to be changed.

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.

When Quark announced the launch of the free QuarkXPress 8.5 release, I was seriously unimpressed. Firstly it offered almost no new power, second it implied that the launch of version 9 was some way off, and third it looked like Quark was squandering a once-in-a-lifetime opportunity to get back at market leader, InDesign.

Based on a press briefing introducing the new QuarkXPress 9, my main concerns have been answered – at least partly.

With today’s announcement of QuarkXPress 9 coming only a few months after 8.5, it’s clear that Quark is very aware of the need for speed. More importantly this looks to be a feature-packed update and it’s clear that Quark realises exactly what needs to be done.

In particular, while there are plenty of significant new design capabilities – such as conditional styles, improved callout handling, shapemaker and cloner tools and, not before time, a story editor – the real focus of the new release is exactly what it should be: digital publishing to the all-important tablet market.

In many ways events have played into Quark’s hands. Adobe’s digital publishing strategy since it took over Macromedia has been all about delivering rich content through Flash. No-one ever imagined that Steve Jobs would simply refuse to allow such a near-universal standard format onto his devices. It might be shockingly anti-competitive, but it’s happened and it left Adobe completely wrong-footed.

Publishing to the iPad

Steve Jobs might disagree but competition is always good for the end user.

The race is therefore on to enable professional designers to publish rich content to the iPad (aka actually making some money from publishing) and QuarkXPress 9 offers three routes:

The first, export to ePub, is welcome but as a lowest common denominator static eBook format, it has one huge drawback: no-one is going to pay for the end product.

The second is support for the Blio format. As I discussed recently, this is a truly rich interactive format based upon XPS (a XAML-based cross between Flash and PDF) and should be viewable across iOS, Silverlight and Android devices. The big problem here is that currently the Blio eReader is still only available for Windows.

The third route is by far the most interesting. With the new App Studio for QuarkXPress 9,  designers can create rich layouts including slideshows, pop-ups, scrollable regions, video and so on, much as they currently can for Flash output,  while taking full advantage of all Quark’s repurposing capabilities such as multiple layouts and shared components.

Crucially they can then turn these into native iOS apps for distribution through Apple’s App Store. Moreover, once on the iPad, Quark’s primary userbase of magazine publishers can publish new content targeted to the app based on Quark’s issue-based tariff rather than Apple’s flat 30%.

It’s potentially exciting, but there are a number of issues that need to be borne in mind. Firstly the App Studio isn’t actually going to be included with the initial launch of QuarkXPress 9 but is instead due to follow as a free upgrade within 90 days. Only then will we see what the full iPad publishing experience is like – and users will realise that they need to sign up to become Apple developers ($99 per year) and will need a Mac or iPad if they want to preview their output (all of which is out of Quark’s hands but still significant). There’s also some confusion over how regular issue-based publishing will work based on Apple’s recent announcements regarding in-app subscriptions.

It’s also not clear how and when Quark intends to deliver similar capabilities for the expected tsunami of Android tablets. It’s important to realise that while Adobe has been wrong-footed over Flash, it certainly hasn’t given up and has come up with its own very different Adobe Digital Publishing platform which supports the iPad alongside all other devices.

It will take a while for the dust to settle, and for publishers to work out which solution suits them best but, after the disappointment of 8.5, QuarkXPress 9 certainly looks to be a serious contender.

That’s great news for all publishers including those using InDesign. Steve Jobs might disagree but competition is always good for the end user.

It’s an exciting time for publishing, as the arrival of the handheld tablet form factor (aka the iPad) promises to finally usher in the era of wysiwyg, immersive reading alongside traditional web browsing. It looks like the digital dream that print publishers have been crying out for since they first grasped the full potential of the internet – stunning content, global audiences, revenue opportunities and minimal costs – is finally coming true.

More than this, there’s a real element of turmoil and unpredictability at the moment as Steve Jobs’ open war on Adobe and his refusal to support Flash on the market-defining iPad means that Adobe’s plans for the handheld market have hit an unexpected roadblock. In short, the future of design-intensive digital publishing is up for grabs.

All in all it’s a golden opportunity for Adobe’s main publishing rival, Quark, which last week announced the new 8.5 release of its flagship software QuarkXPress.

Revolutionising Publishing. Again. And Again.

Quark’s previous publishing revolutions have all failed…

Quark has long recognized the potential of rich, screen-based digital publishing. Some 15 years ago it was working on its bitmap-based QuarkImmedia system (ridiculously optimistic in the era of dial-up modems), then it shifted to the ill-fated HTML output of QuarkXPress 5 (“Mickey Mouse” would be kind) and then its over-complicated XML-based repurposing. More recently, with its last QuarkXPress 8.0 release, Quark shifted to Flash-based interactivity and delivery under the company’s new slogan “Revolutionising Publishing. Again.”

None of the promised revolutions have come to pass largely because the crucial piece of the jigsaw, the handheld, page-like screen, wasn’t yet in place. In fact the attempts to deliver interactive wysiwyg electronic publishing have arguably proved Quark’s undoing, as the company lost focus and allowed Adobe to steal back the high-end print market with InDesign.

Quark’s previous publishing revolutions have all failed to ignite but, thanks to them, QuarkXPress has built up many repurposing strengths, such as the ability to handle multiple layouts within the same publication and to have multiple users working on the same project via composition zones. In many ways it means that QuarkXPress is ideally placed to capitalise on the potential of digital repurposing for the new tablet market.

So what does the new 8.5 version offer? Amazingly little. In fact when the “highlights” are DOCX import/export and new Pantone libraries, many users will choose not to upgrade even though the release is free.

Quark’s Digital Publishing 2.0

The 8.5 upgrade is a major disappointment but that’s not necessarily the end of the story. In particular Quark is clearly aware of the importance of the tablet market and back in June announced its Digital Publishing 2.0 initiative.

Based on the details provided and introductory video, this is centered on the interactive authoring capabilities of QuarkXPress 8.0 combined with the ability to output to a new eBook format, Blio, which will be viewable via a new cross-platform, cross-device Blio eReader complete with text-to-speech, annotation capabilities, virtual library and so on.

It could be that Blio and XPS will prove the making of Quark and the undoing of Adobe…

The obvious question is how does Blio actually deliver its content? Quark is coy on the subject but, with a bit of digging on the Blio site, I found the answer: XPS. This stands for XML Paper Standard and it’s a modern open XML standard designed to handle document presentation. Basically it’s a subset of Microsoft XAML designed to reproduce the fixed document functionality of PDF and its primary use at the moment is as Window’s native print spooler format. You can see the format in action by saving a Word file to XPS and selecting for it to open in the XPS Viewer which is built in to Windows Vista and 7.

XPS might not be a household name, but this is potentially a very neat trick on Quark’s part. Simply convert your previously Flash-based interactive publication to an equivalent, typographically rich, scalable, searchable cross-platform XPS file, create your native Windows, OSX, Android, WP7/Silverlight and (most important of all) iOS reader, and Bob’s your uncle.

Crucially the manoeuvre promises to open up the all-important iPad market while wrongfooting Adobe, which is hardly going to ditch its own Flash and PDF technologies in favour of XAML and XPS. This is almost inspired. All the focus has been on Flash and the battle between Apple and Adobe but all the time there has been a modern, open XML-based equivalent ready to take its place and developed by none other than Microsoft. How has everybody missed that?

It could be that Blio and XPS will prove the making of Quark and the undoing of Adobe – but it’s not quite that simple.

Adobe Digital Publishing

To begin with, Adobe hasn’t simply thrown in its hand. Jobs’ ban on Flash was a massive shock and body blow, but, as I discussed recently, Adobe has gone back to basics and come up with its own Digital Publishing platform that looks to get around the Apple problem by returning to QuarkImmedia-style bitmaps.

This approach has huge drawbacks compared to XPS (and Adobe’s preferred format Flash) in terms of efficiency, scalability, searchability, accessibility and so on, but it does open up the crucial iPad market and, as examples like Martha Stewart Living demonstrate, delivers a surprisingly sophisticated reading experience. More than this, with a hosted solution offering targeted delivery, tracking, analysis, advertising and so on, Adobe is delivering a lot more than just a new format and reader to the major publishing houses.

Most importantly, while it’s not officially launching until Q2 2011, Adobe’s Digital Publishing platform is already up-and-running and enabling the big magazine publishers to tap the iPad market with their own branded readers. Moreover, with all other tablet manufacturers (including Google and Android) signed up to the Open Screen Project and promising to support Flash and AIR, Adobe looks well placed to turn the apparent Apple roadblock into a temporary obstruction.

Questions over Blio

With Adobe’s Digital Publishing platform becoming clearer, the focus returns to Quark where promises for the future aren’t enough. The iPad is here and the tablet-market is booming now, but the all-important Blio readers aren’t available. In fact the only Blio e-reader currently available is for Windows and even here the system requirements, including the .NET 3.5 Framework 3.5 and Microsoft Playready, are seriously off-putting.

More importantly, a Windows-only reader is effectively pointless as it opens up the multiple screens problem. Plus there’s very little to gain over existing dynamic PDF delivery and, as Quark’s own history has repeatedly shown, no-one wants to sit down and read books or magazines via their desktop systems and certainly won’t pay to do so.

At the moment the only Blio eReader that matters is the one for the iPad and there’s no sign of it. Of course it might be just around the corner, but creating a reader that works well in the handheld environment is not trivial and the fact that Microsoft doesn’t seem able to deliver full support for Silverlight 4 on its own WP7 phones might well indicate problems for XPS-based delivery.

Even more worrying is the question of how the Blio reader will handle interactivity. XPS is a fixed document format more like static PDF than Flash which explains why Jobs will allow it on his systems. Of course it should be possible to add video, audio, bitmap slideshows and so on as overlays over the fixed document which is the approach that the Adobe iOS reader takes. However this response on the Quark forums – “For iOS-based devices you are only going to see a screenshot (as Flash is not available)” – is not exactly reassuring. After all, the rich immersive reading experience is what this is all about.

Even more ominous is the fact that with all its previous digital publishing efforts Quark took responsibility itself. However now, when the stakes couldn’t be higher and digital publishing is finally taking off, the company seems to have chosen to outsource and put its fate in others’ hands. In particular the Blio format and readers are being developed by K-NFB a joint venture between Ray Kurzweil (the scanning/OCR pioneer) and the National Federation for the Blind. Both parties are undoubtedly admirable, but you have to wonder what development resources they can command in what is a fast-moving, high-stakes game for major players.

Of course things can change rapidly – K-NFB is promising the iOS, Android and Silverlight readers “soon” – and before anyone has seen the technology in action on the iPad and other tablets it would be wrong to write it off. However for Quark to capitalise on this golden opportunity to get back in the game, Digital Publishing 2.0 really needs to be delivered successfully and quickly. If it isn’t, it looks like we’ll have to add another entry to the long list of Quark’s failed digital publishing formats: bitmap, HTML, XML, Flash and Blio/XPS.

I hope not. The digital publishing and reading revolution is finally happening; after working for it for 15 years, it would be a real shame for Quark and its users to miss the action.

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.