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.

There’s an excellent Labs round-up of Superzoom cameras (also commonly called “bridge cameras”) in the latest issue of PC Pro. My only criticism is that it doesn’t makes a strong enough case for its subject.

Most people tend to think that there are only two types of digital camera to choose from: point-and-click compact cameras majoring in convenience, and high-end DSLRs majoring in picture quality. Anything in between is – almost by definition – seen as an uncomfortable compromise. However I think that the vast majority of users would actually be far better off with this intermediate format.

From my own experience I think that the bridge cameras offer two overwhelming advantages.

The first is the zoom. I just don’t understand why this is generally seen as an optional extra – and an incredibly expensive and awkward one for DSLRs where you have to buy and carry separate lenses. Taking a good photo is as much about content and composition as it is about light gathering, and a good optical zoom opens up so many more creative options. Go to the zoo or park with a superzoom – anything from around 20x to the Nikon Coolpix P500’s amazing 36x – and you really can bring back genuinely interesting and exciting photos; go without and your photos will almost certainly be as dull as everyone else’s.

The second is video. I have to admit that this was very low down on my list of priorities when I bought my Panasonic Lumix a few years back (a long way below full manual control and RAW support). However I was amazed by the quality of the 720p HD video, which was actually far better than that from my admittedly ancient, dedicated device. Now the latest Lumix DMC-FZ100 is offering 1080i.

Having impressive video handling conveniently to hand dramatically increases your creative options. There are just so many occasions where a static image doesn’t do the subject justice and other scenarios where video is the only way to be sure of getting the still. Now I would find it as unthinkable to buy a camera that doesn’t also shoot HD video (complete with a dedicated video record button) as I would to buy one with an ordinary zoom.

Ultimately bridge cameras don’t just offer a bridge between two camps, they offer a bridge between three. Moreover, the result isn’t an awkward compromise that is neither-one-thing-nor-another, but a creative mix that is greater than the sum of its parts (including zooming video).

Of course dedicated DSLRs and video cameras will still be required for professionals and the keenest enthusiasts, but compact cameras and Flip-style video devices are disappearing into the smartphone where they belong. That leaves the bridge camera holding the high centre ground – precisely the ground that most users are looking to occupy.

Is it time for a new A-List category?

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.

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.

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.

I’m sure that everyone has the odd infuriating niggle with the software that they use most regularly, but I’m delighted to say that I’ve just found the solution to a problem with CorelDRAW that has been driving me mad for almost 19 years.

That’s how long I’ve been producing a regular quarterly publication based on charts that I tidy up ready for print. Key to this is the ability to resize whole series of elements in the same way. No problem you might think; simply use CorelDRAW’s Transformations palette.

The problem is that this treats the selection as a group. I need to be able to change each object’s scale independently, without changing its positioning, and that’s just not possible automatically. Instead I’ve been forced to apply the transformation to a single object then select all the others in turn (Tab is useful here) and then repeat the last command (Ctrl+R). Trust me, after a hundred or so times, the attraction soon fades.

Transforming objects like this is such a common requirement and it’s such an obvious capability to add to an application that prides itself on its efficiency and productivity, that I’ve always assumed that Corel would fix it in the next release. Some dozen or so releases later, I’m not so sure.

If Corel’s not going to do it, what about the Corel community? I’ve been looking on and off for years, and finally I’ve found a solution. Hidden away in the Sawmill Creek Woodworkers’ Forums – “The biggest and best online community for woodworkers on the Internet” – is the answer.

It’s a simple macro called Transform Each written by Steve Willis based on an original attempt by Manuel Rivas. It’s pretty awkward in use and I strongly recommend that you save your file before applying, and you’ll also need to close and reopen the dialog between transformations. You’ll also have to sign up to  Sawmill Creek to download it (which might help explain the site’s popularity).

It’s certainly not pretty, but it can be made to work, letting you automatically and independently stretch, rotate and flip multiple selected objects. It might only save me 15 minutes every three months, but small efficiencies mount up. I can’t quite believe that I’ve spent two entire working days pressing Ctrl+R.

Just a few days after the launch of the long-awaited Drupal 7.0 version, arch-rival Joomla launched its latest 1.6 release…

It’s interesting to note that, apart from some significant interface improvements, 1.6’s two main additions are specifically designed to meet Drupal head-on.

The Most Powerful CMS?

Firstly Joomla 1.6 integrates its previously separate Section and Category Managers to provide a more flexible system built on categories that can now be nested to any depth. Secondly it introduces a new Access Control system where you can create custom user groups and control what they can see via access levels, and what they can do via permission levels.

These are both major advances, but they still don’t go as far as Drupal’s core taxonomy handling and user role/permission systems. For example, you still can’t apply multiple categories with Joomla 1.6 nor get Drupal’s completely granular control over custom permissions. For deep power and granular control, Drupal wins.

Moreover, as Joomla digs deeper to graft on similar power, it actually ends up becoming more complicated than Drupal. To those who have tried Drupal that might sound near impossible but, if you don’t believe me, check out the later stages of the video below (The Art of Joomla’s video introduction to Joomla’s new Access Control).

Joomla 1.6 — Access Control from Captain Courageous on Vimeo.

The bottom line is that if category/term or access/permissions handling are crucial to what you want to achieve (especially for Web 2.0 sites where content is contributed by casual site visitors) then Drupal offers the more powerful and flexible implementation.

It’s also important to note that Joomla 1.6 doesn’t offer anything like Drupal 7.0’s biggest new attraction, its field-based handling of content in core (see my full Drupal 7.0 review).

Such granular control can take content management to an entirely new level, especially when allied with add-on field modules (for example, when handling embedded media or maps) and Drupal’s brilliant Views, a semi-core module that lets you build custom queries to pull out and display your field data.

The Best CMS?

Drupal 7.0 is certainly the more powerful CMS on paper, but it’s on the ground that counts

Drupal 7.0 remains the more powerful framework and indeed extends its lead. However that doesn’t mean that it’s the most powerful out of the box. In fact, out-of-the-box Drupal is pretty dreadful; it’s only when you’ve created your custom fields, content types, user roles and module mix that it comes into its own.

This ground-up building block approach is the secret of Drupal’s power but has two important downsides. To begin with, it goes a long way to explaining Drupal’s famously precipitous learning curve, which makes Joomla’s less-than-brilliant usability seem almost intuitive.

It also means that Drupal core is only half of the story. In fact it’s only when all the contributed modules that you want to use have been upgraded to be compliant with the 7.0 core – and with each other – that you’re ready to start building your site.

While Drupal 7.0 is certainly the more powerful CMS on paper, it’s on the ground that counts and here the comparatively self-contained Joomla scores highly. Joomla’s great strength is that it provides ready-to-go power that’s more than capable of producing the majority of websites.

Overall then, Drupal wins as the best, totally customisable framework for producing unique state-of-the-art Web 2.0 sites where content is contributed by site visitors, whereas Joomla victors as the best, largely customisable, off-the-shelf system for producing more traditional sites where content is contributed at organisation level by controlled workgroups.

And that still leaves plenty of room for WordPress as the best, partly customisable turnkey system for producing standard sites and blogs for individuals and small businesses (see my WordPress 3.0 review). Other systems, such as TYPO3, press the claims of their own particular mix of content management power and control.

Ultimately the best CMS depends entirely on you and what you want to do.

And the winner is…

That said, if a particularly odd person put a gun to my head and forced me to name the best CMS, there would be one clear winner. For basic photo enhancement Photoshop is complete overkill and most users are far better off with Photoshop Elements or Paint Shop Pro, but we still all accept that Photoshop is the “best” photo editor.

On the same grounds, if you can master it, Drupal 7.0 is the best CMS.