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.

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

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

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

Words and actions

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

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

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

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

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

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

Adding to HTML5

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

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

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

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

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

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

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

So what about Flash?

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

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

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

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

The post obviously hit home, as I realised when the Adobe evangelist demonstrating Dreamweaver CS5 at the press launch began his talk by referring to it and, when he discovered that I was in the audience, suggested that I might want to “eat crow”.

Well I’m delighted to say that he was right… largely.

Before I explain why Dreamweaver CS5 is such an eye-opener, let me explain where I’m coming from. Basically, like the majority of web designers, I grew up with Dreamweaver learning the HTML and later CSS necessary to create the linked web pages that make up the traditional website.

However I now believe that this manual “static” page-based model has pretty much reached the end of its road. Firstly it just isn’t powerful enough as these days site visitors expect features such as in-built commenting, RSS feeds and so on. Most importantly, the system just isn’t scalable. Funnelling the creation of every page through the web designer is disastrously inefficient and ultimately bound to throttle off the lifeblood of any site: new and up-to-date content.

In other words, the static web page authoring with which Dreamweaver made its name and which built the web as we know it, is in terminal decline. The solution is to turn to a dedicated content management system such as the big three open source options: WordPress, Joomla and, my personal favourite, Drupal.

Using a CMS the web master doesn’t create each website page, but rather builds the framework to enable end users (whether workgroup members or site visitors) to create the content. In addition a CMS comes with features such as commenting and feeds built-in, while access to thousands of add-on modules provides the ability to produce sites that the static designer can only dream of.

Best of all, thanks to the open-source principle of community sharing, this power is made available to non-coding designers for free. Indeed, once the CMS has been installed, all the site designer and content contributors need is a browser (helped greatly by invaluable browser add-ins such as Firebug and FireFTP).

So how does Dreamweaver fit in to this new browser-based model of community-based development and community-based authoring?

Good question. Once you’ve been won over to the power and elegance of CMS-based development, Dreamweaver suddenly looks inherently old-fashioned and out-of-step – a standalone, offline, desktop application fundamentally at odds with the community-based, online, browser-based web. Remember that Tim Berners-Lee always envisaged the browser as the authoring application. CMS can be seen as a natural return to the web’s roots and Dreamweaver and static authoring in general as a temporary aberration.

That’s why, when Devin Fernandez, senior product manager for the web products at Adobe responded to my post promising that Dreamweaver CS5 would adapt, I remained unconvinced. Essentially I couldn’t see how that would be possible. As I said at the time: “The future for creating web design is in the browser not in Dreamweaver.”

A new hope

So what is so exciting about the new Dreamweaver? As you’ll see from my full Dreamweaver CS5 review there’s plenty of interest but, most important in this context, Dreamweaver CS5 embraces the concept of a CMS with a vengeance. This is immediately apparent in the far deeper support for PHP, the scripting language with which the main CMS are built. Deeper still is Dreamweaver CS5’s new support for site-specific code hints, in particular for the big three open-source CMS: WordPress, Joomla and Drupal.

To take full control of your CMS site developing, PHP skills are a real advantage, but CMS-based community sharing is designed to cut down on the need for programming and to enable the creation of fully customised sites without it. So what does Dreamweaver CS5 offer the non-coding CMS designer, as opposed to developer?

It’s here that Dreamweaver CS5 really surprised me. Previously Dreamweaver’s Live View mode was designed to let you view a single local static page as rendered in the built-in WebKit browser. That was pretty much hopeless for managing a CMS because the pages on a CMS site don’t actually exist (apart from via caching) until all the contributing logic and CSS files are processed on the server and the final page generated and returned to the browser. Now in Dreamweaver CS5 you can load a local CMS or even enter a live URL and then, thanks to new Live Navigation, drill through the site to any CMS page.

Crucially you aren’t limited to simply viewing the rendered page. Using the Related Files toolbar and Dreamweaver CS5’s new Dynamically Related Files capability you can view and edit (if it’s your site) all of the files – HTML, PHP, JavaScript and CSS – that together define the page. Using the new Inspect mode you can also quickly inspect the cascade of CSS rules that are determining current formatting and then quickly edit them Firebug-style.

Essentially Adobe has recognised that the only way to manage CMS-based site development is within the browser, so has enabled Dreamweaver CS5 to act as one. More than this, it offers all of Dreamweaver’s longstanding offline power and more within the new live environment to provide a browser turbo-charged for both CMS-based developer and designer.

It’s exciting stuff on two main fronts: Firstly Dreamweaver CS5 promises to play a major part in enhancing the quality of the user-contributed modules and themes that define the core CMS, something that will benefit all users (and in the process render Dreamweaver unnecessary for many). Secondly it provides a natural and powerful route for those professional users who stick with Dreamweaver to learn how to customise and move beyond off-the-shelf modules and themes, the main limitation of the CMS approach. Eventually these users will become experts themselves and can contribute back to the CMS community.

I’m delighted to admit that I was wrong to believe that Dreamweaver couldn’t adapt to the browser-based future of CMS-based web design. However, I still believe I was right on the major thrust of my argument, namely that static page-based publishing is dying and that the future for web design lies with the major content management systems. Based on Dreamweaver CS5, it looks like Adobe agrees.

Dreamweaver CS5 has embraced CMS; now it’s time for the average web designer to do the same.

Adobe is playing down the significance of its decision and seems to be hoping that no-one will notice and will simply upgrade to CS5 Web Premium. However it’s not just a fundamental repositioning, it’s the end of an era: effectively it’s the end of the veteran Macromedia Studio combination – Dreamweaver / Fireworks / Flash (and to a lesser extent Contribute) – which has played such a crucial role in building the web as we know it today.

So what is Adobe up to? Is it right? And what should end users do?

In its press briefings, Adobe presented its decision as if it was somehow a response to popular demand – presumably “we demand less choice!” – which is clearly preposterous. However the company has sweetened the pill considerably by offering the Web Premium upgrade price to Web Standard users which, at £476 (exc VAT) for upgrades to the four Standard apps and five new programs costing £2,250 (exc VAT) as standalones, may well seem like an unmissable bargain.

No doubt many existing users will upgrade, but as Kevin Partner points out in his “Adobe: friend-or-foe of the web design community?” post, what about new users? Do you really now have to spend £1,429 (exc VAT) to become a modern web designer? What happened to creating the Web in Notepad!

More to the point is upgrading a good choice for existing users? It may look good value this time around, but what about next time? And is Web Premium actually a bargain and the right move?

Let’s look at what you get for your money over and above the former Web Standard.

First of all, you get the new Photoshop Extended and Illustrator. These are Adobe’s powerful bitmap and vector flagships, but do they really add useful new power to web workflows? (see my “What’s the point of Photoshop Extended?”) In fact the reverse is more likely: they add unnecessary complexity when you already have the web-optimised, combined graphics handling of Fireworks.

In addition Web Premium, users get the new Flash Builder for creating full-blown Rich Internet Applications (RIAs) and the brand-new Flash Catalyst which can be used to design the interfaces for Builder. That’s clearly a major step forward for Flash developers, but while most web designers can stretch to editing HTML/CSS, they aren’t programmers and don’t want to be. Which is where Catalyst proves its real importance because it is also designed to convert designs created with Photoshop and Illustrator into simple Flash applications with no coding. It’s Flash Catalyst, then, that becomes the core of the Web Premium suite and makes real sense of the inclusion of Photoshop and Illustrator.

Flash front and centre

Ultimately, apart from Acrobat Pro (which is included in all CS editions), all the new Web Premium additions are concerned with one thing: helping both developer and non-coding designer to embrace Flash. And not just any Flash. In the old Macromedia days, Flash was used as a way to add some impact to your HTML/CSS web pages; now it’s promoted as a self-sufficient web platform in its own right, with the browser’s primary function being to host the cross-platform player and self-contained content.

Flash-phobics will be appalled but a strong case can be made that moving towards full-blown Flash/Flex is the natural progression for web design, as end users increasingly expect a design-rich, fully-engaging, desktop-style experience that HTML/CSS and the browser just can’t deliver. Moreover they now expect this experience from any and all devices which is why the Flash- and AIR-based Open Screen Project is so important.

With its cross-platform penetration (apart from Apple), unrivalled design power and Creative Suite integration and user base, Adobe clearly believes (or hopes) that Flash will become the high-end web platform of the future and Web Premium the primary authoring environment. As such, you could argue that Adobe’s repositioning is just helping its users to move on from the increasingly old-fashioned static page-based model of web design and adapt to the bright new future of coded and uncoded Flash.

Other options

However before you upgrade to Web Premium, I’d recommend thinking carefully about your other options.

Firstly I’d argue that non-programming web designers would actually be  better advised to spend a little extra and upgrade to CS5 Design Premium, which is effectively Web Premium but with Flash Builder and Contribute swapped for InDesign. The latest CS5 release of InDesign is now capable of acting as a powerful authoring tool to produce Flash-based publications and is actually a much better option than the awkward and shaky first release of Catalyst for non-coding designers.

More importantly should you upgrade to a suite at all? If you’re not convinced about Flash then there’s very little attraction in either of the Premium suite options and, of course, they only represent good value if you are actually going to use the additional apps that they contain.

So what about upgrading the individual Web Standard components? The changes to Fireworks CS5 are minimal and Contribute is looking terminally old-fashioned, underpowered and misconceived. The new Flash Professional CS5 is certainly more impressive but, with the increasing design strength of HTML/CSS, the need for embedded, as opposed to full-blown, Flash is actually becoming less pressing. And the advent of HTML 5 is likely to go even further and rob Flash of its current crucial media playback role.

Which leaves Dreamweaver. This is a subject I plan to return to, but from my Dreamweaver CS5 review it should be clear that I’m seriously impressed by the latest release. Rather than upgrading to Web Premium, most page-based Web Standard users could save a lot of money by just upgrading Dreamweaver.

Or they could save their money entirely. The most powerful new feature in Dreamweaver CS5 is the way that it embraces the three main open-source content management systems (CMS): WordPress, Joomla and Drupal. I’ve written before about how content management systems can take page-based authoring into new and exciting Web 2.0 territory – most notably enabling end user content contribution. Now Adobe has brought this thinking right into Dreamweaver and into the mainstream.

For advanced CMS workflows Dreamweaver CS5 now has a surprising amount to offer, but that comes later. For now, my advice to the majority of new users and current Web Standard users who aren’t won over by Adobe’s Flash-based vision is to save your money and instead invest your time in getting to grips with a CMS.

Now I’ve come across a brand name that’s possibly even worse…

Mollom.  Mollom is an interesting new online service designed to help cut down the amount of spam comments and content that Web 2.0 sites have to deal with while avoiding putting off genuine contributors with unnecessary captcha barriers. The technology might be cutting-edge but the name certainly isn’t, in fact it sounds medieval. Moreover, like “Drupal”, “Mollom” manages to pull off the difficult trick of being pathetically comical and seriously depressing at the same time.

Astonishingly the man behind Mollom is none other than… Dries Buytaert.

Surely this has to be too much of a coincidence? And I think I’ve found a clue to what’s going on. While selecting a language for Mollom to operate in, I was rather surprised to be offered the choice of Old English and Middle English (I’m not joking, take a look at the screenshot).

Mollom's language choice

Two obvious possibilities spring to mind. Does anyone know if there’s a thriving community of Old English speakers that has somehow lived on in Belgium? Alternatively, does anyone know if there are a pair of ugly giants or dwarves in Beowulf or Tolkein called “Drupal” and “Mollom”?

And does anyone have any suitably uninspiring suggestions for Dries’ next project?

Admittedly I’m biased on this, but I couldn’t help feeling that the responses were divided into two camps: those who had actually tried both approaches who largely agreed and those who hadn’t, who didn’t and who felt threatened by the suggestion and who wanted to close down the debate. 

Between these two extremes I hope that there were plenty of more open-minded designers who were intrigued and ideally excited about the possibilities. After all, the cms approach doesn’t just offer more power, each of the cms solutions is open source and so free. That should mean that there’s nothing to stop you exploring both approaches and then making your mind up…

Unfortunately it’s not quite as simple as this. However, with a little help, it can be…

The problem hits immediately – installation. Visit the big three cms sites and you can quickly download the latest releases but you then have to set these up on your own hosting space. The ease with which this is done varies with each cms but suddenly you’re talking about MySQL databases, permissions, configuration files and so on and before you know it you’re reading through reams of baffling support pages discussing the finer points of table prefixes. This is frankly terrifying for your average page-based designer used to the simplicity of copying their local pages to their remote host.

It doesn’t have to be this way. To avoid such installation nightmares all you need is a host that provides decent cPanel support. This will provide you with a control panel that provides all the tools that you need to set up your database, ftp and unzip the cms files into position, back up your database, flush caches, manage table prefixes and so on…

Oh dear this is beginning to sound almost as bad. But it doesn’t have to be this way either. 

Instead you can just click on your cPanel’s Fantastico button (the one with a nice smiley face) and take advantage of one-click installs. Within a minute or so you can have copies of each of the main three cms options up and running (and plenty of others too). It really is unbelievably simple and I strongly recommend that you give it a go – visit the Fantastico site and there’s a list of hosting partners offering Fantastico support for a pittance a month. 

Fantastico is a huge step forward, but immediately I’ll put in two major caveats.

Firstly Fantastico isn’t foolproof. I remember first recommending it a couple of years ago for installing Drupal and, by the time the article came out, the current version simply didn’t work (due to a clash in table character set). I think the cms developers have now appreciated the importance of Fantastico to initial set up and first impressions and crucially, in its latest Fantastico Deluxe form, to encouraging prompt security fix updating complete with built in backup, so hopefully compatibility shouldn’t be an issue nowadays…

But in any case I’m not suggesting that you should rely on Fantastico. If you’re going to get serious about cms you have to realise just how fundamentally different it is to static page-based publishing and you have to get fully grips with how and why, and the implications.

Switching from Dreamweaver to cms-based publishing is not something you can do in a minute. Expect it to take at least a year (and don’t judge the possibilities on the default set-ups!) and in that time make sure that you do learn about MySQL and cms handling and in particular get to grips with installation, backup, migration and security updating without Fantastico. This is where all those other cPanel utilities like phpMyAdmin come in. Fantastico shouldn’t be seen as a replacement to these but as an addition.  

Crucially what Fantastico does offer is the chance to freely and painlessly put your toe in the Web 2.0 cms water. Thanks to Fantastico there really is no excuse not to give content management systems a try.

In fact if your current host is cPanel-based you might well find that you already have access to Fantastico and could be exploring what WordPress, Joomla and Drupal – my favoured option – have to offer in a matter of minutes. If not, you could sign up for a month’s trial with an ISP that does provide Fantastico support for as little as $7. If you’re currently a static page-based Dreamweaver author, that could prove the best investment you ever make.

Based on my core argument – that the future of web design lies with content management systems (cms) rather than Dreamweaver – I was expecting an uncomfortable time. Thankfully Devin is far too nice for that. More than that he seemed genuinely pleased to have had a debate opened up and a chance to hear what the community is thinking about Dreamweaver and the future of web design…

Naturally Devin hopes and believes that Dreamweaver is going to remain central to future web workflows and was keen to stress that the program is always evolving. As such we chatted about some of the introductions in the latest Dreamweaver CS4 such as the HTML table-based Ajax handling, the new compound file support and advanced CSS navigation.

To my mind, Dreamweaver CS4’s HTML table-based Ajax handling is simultaneously over-complicated and underpowered and is a good example of the web 2.0 wall that Dreamweaver is hitting in the static HTML page context. However (as I pointed out in my review) the other two features are certainly significant advances and show Dreamweaver moving forwards from the old model of the simple standalone HTML page to embrace today’s more complex compound reality. 

Moreover, as Devin pointed out, these features prove especially useful in the cms context where the compound page is the norm and drilling down to find and edit CSS rules a nightmare. In short Devin made the case that Dreamweaver has a lot to offer cms-based users and doesn’t see cms as an either/or alternative but rather as a partner it can work with, just as it does with the Ajax frameworks.

Without making any explicit commitments, Devin also made it clear that Dreamweaver users can expect further developments when it comes to integration with the big three frameworks:- WordPress, Joomla and Drupal. In particular, knowing I’m a Drupal fan, he recommended that I check out the work Chris Charlton is doing with his Dreamweaver Drupal extension that integrates the Drupal API directly into Dreamweaver. 

We also discussed just how important the mission of bringing good design to cms is. I couldn’t agree more. Some people seemed to think that I was arguing that we should rip out today’s websites and replace them with blogs. That is absolutely not the case. The goal must be to produce truly attractive cms sites that look as if they were hand-crafted in Dreamweaver but with all the web 2.0 functionality – commenting, voting, rss feeds, in-browser content contribution, optimal tag-based navigation, scalability – that static HTML inherently can’t deliver. 

This design mission is crucial but I’m not convinced that Dreamweaver is necessarily central to it. Or even necessary at all for the average user. At the moment the general standard of cms design is beyond dreadful but that’s because the design potential of cms hasn’t begun to be grasped by its user base which is still primarily made up of developers. 

This is most immediately evident when it comes to theming. The ability to quickly explore hundreds of attractive high quality themes is a massive strength but incredibly most cms users still stick with the unbelievably ugly default theme. This is a travesty. If the average cms user spent just one day exploring the themes available, the design quality of their work would take off and the design reputation of cms with it. Indeed by piggy-backing off the work of leading designers, and so ensuring site-wide consistency and best practice and avoiding unhelpful design excesses, a themed cms site can embarrass many hand-crafted static sites. It might even validate!

Off-the-shelf cms themes will take most sites most of the way to where they want to go. Devin argued that Dreamweaver is the essential tool that cms users need to go the extra distance and get exactly the results they want. I’m sure that Dreamweaver does play this key role for the majority of theme developers and also for most of the module developers creating the cms logic. As many of the comments from developers on my original article pointed out, the cms frameworks that I’m talking about simply wouldn’t exist if it wasn’t for Dreamweaver. 

That’s true and a major reason to be grateful to Dreamweaver and to wish it well. However the numbers involved creating the cms framework is inherently small compared to the numbers using it. That’s the point: the module or theme creator does the hard work and generously donates it so that end users don’t have to. For the cms end user I’d argue that a 5% role for Dreamweaver is a very different role to today’s 100%. Will cms-based designers prove willing to pay $hundreds for a support tool when the cms itself, in which they do 95% of their work, is free? 

In any case, despite its undoubted power, I’m not convinced that Dreamweaver will necessarily prove the best tool for the average designer wanting to extend their cms handling. In fact Dreamweaver’s all-round power and the associated complexity becomes more of a drawback than an advantage. For tweaking a theme’s CSS, for example, a lightweight dedicated approach makes more sense – something like Chris Pederick’s excellent and free Web Developer add-on for Firefox which works live in the browser. 

In the longer term I believe that an end-to-end, high-quality design solution will be provided in the browser and largely by the cms frameworks themselves. Already image handling and wysiwyg editing have improved out of all recognition. And, using advanced modules such as Drupal’s excellent Panels (which lets you break up your layout to break out from blog-style listings) and the stunning Views 2 (which lets you pull out any content based on any criteria to drop into those panels), you can produce beautiful sites based on completely custom designs that give no indication that they were produced with a cms apart from their additional web 2.0 functionality. And the design capabilities of the cms frameworks are only going to get better. 

So where does all this leave Dreamweaver? 

Working with the web’s constantly changing open standards has always been Dreamweaver’s greatest strength and, from the chat with Devin, it’s clear that Adobe is well aware of the rise of the cms frameworks and of what they can do. It will certainly be interesting to see what future releases come up with in terms of support for cms. Moving to truly dedicated support will represent a step-change and help unleash the next generation of content management systems.

And as the content management systems get more powerful, more attractive and more usable they will attract more developers and designers who will come to appreciate the enormous benefits of building on the work of others rather than trying to do everything themselves. Moreover, as some of these developers and designers put something back into the communal pool of high quality logic and design, the arguments for joining up to the cms project become more and more compelling. A standalone user can already, with a lot of effort, use today’s cms frameworks to produce a site that looks and acts as if had been built by a massive team of design and development talent (which in a way it has). Over time the results possible and the ease of use with which they can be achieved will rise dramatically. The potential is extraordinary. 

Both Devin and I agree that the cms frameworks are going to get more powerful and that Dreamweaver will play an important role in this. However we differ over how this is likely to play out and the implications. My argument is that the cms frameworks are completely different to the Ajax frameworks because they represent a far more fundamental shift; a shift that will redefine how future designers and developers go about creating the website itself – the role that Dreamweaver currently fills.

Dreamweaver has been the central player behind the page-based web and the custom-made application-based web. I believe that it will also play a major part in creating the content management systems that will come to replace it as the web’s main driving force.

Tom Arah

These were the emails from designers thanking me for pointing them in the direction of Dreamweaver when they were making the transition from print to web design. It was a decision that they had come to appreciate greatly over the years, providing them with the best possible platform for their web design careers.

The problem is that Dreamweaver is dying…

To be fair it’s not Dreamweaver’s fault. Nor is the problem Adobe and its development team – the last Dreamweaver CS4 version was the most impressive release in years. Moreover, although Microsoft Expression Web poses a far more credible threat than FrontPage could muster, Dreamweaver remains the best HTML/CSS page-based editor available.

The real problem for Dreamweaver and for its users is that the nature of the web is changing dramatically. Dynamically-generated web applications, from Amazon right down to the humble blog, all offer much more – in-built commenting, voting, RSS feeds, etc – than the best sites built on static HTML can ever hope to provide.

This isn’t a matter of bells and whistles, it’s absolutely fundamental. Ultimately a web site is all about content – posting it and making it findable – and Dreamweaver and the other static HTML editors have proven fundamentally flawed when it comes to these two core tasks (and features such as Dreamweaver’s libraries and templates are patches not solutions).

The bottom line is that the old model of the central webmaster hand-spinning every page of every website and, worse, manually adding the navigation necessary to help users find it, just isn’t scalable or viable. The only feasible course for the future is for content to be posted by the content contributor, whether that’s the site owner or site visitors, and for the best possible navigation to be constructed around that content on the fly.

In other words Web 2.0 isn’t an empty slogan, it marks a fundamental break with the past and Dreamweaver lies on the wrong side of it. So is this the end for Dreamweaver and the traditional Dreamweaver-based web designer?

Eventually yes. In the relatively near future every website will be a dynamically-generated web application and all of today’s sites built on multiple static pages will be ripped out and replaced.

The good news of course is that this is actually a huge opportunity – think Klondike gold-rush – for the web designer who can adapt. But how? After all your average designer is built along radically different lines to your average developer.

But it can be done. Just as Dreamweaver eased the transition for print-only designers to the new markup-based world of HTML; content management systems such as Joomla and Drupal can ease the transition for static Web 1.0 designers to the new Web 2.0 world of script-based PHP. Give them a chance and you’ll be amazed at what you can achieve and all without touching a line of code (that can come later just as it did with Dreamweaver).

I really can’t recommend this strongly enough. If you are a Dreamweaver user don’t bother upgrading to the latest version or exploring Adobe’s feeble attempts to graft end user content contribution onto Dreamweaver. Instead save your money and invest your time in getting to grips with the real future of web design: server-based content management systems.

Dreamweaver is dying. Long live Drupal.

Tom Arah

——————————–

Well this article has generated a lot more comment than I was expecting (including on slashdot and digg) which is in itself a nice demonstation of web 2.0 in action and how Dreamweaver and static publishing in general is being left behind.

A lot of the comments are pretty much repeating themselves so I’m promoting the main points of an earlier response made below to try and clarify things and nip a few in the bud:

Comparing Dreamweaver and Drupal isn’t mad – they are both tools for producing websites.

Thinking about it I can see why people might assume they are entirely different – after all a cms is for producing a blog right? Absolutely not. You can reproduce any static site dynamically with a cms including simple and attractive brochureware sites.

Crucially you can’t do the opposite. This means that by using Dreamweaver you are denying your clients a lot of functionality – in-built commenting, rss feeds etc (only if you want them) – but most importantly end user content contribution and optimal on-the-fly navigation.

You’re also denying them the tag-based keywording that helps the search engines understand what your site is about. Google and cms go hand in hand and ultimately your job is to generate traffic.

Having said that it’s true that most cms sites currently do look and behave like blogs. More than that they look atrocious (most don’t even change from the default theme). There’s absolutely no reason why they should look so bad and that’s the other part of the equation and of my argument: current static designers have a lot to gain from cms but current cms also has a lot to gain from an influx of good design.

Clearly this post was aimed at the vast majority of Dreamweaver users – those designers producing static sites HTML page by HTML page. I wasn’t really addressing the developer and yes one of Dreamweaver’s great strengths has always been that it also caters for other languages and those developers manually building up their own dynamic sites.

And cms has even more to offer these users! Why reinvent the wheel and create your web application from scratch when you can take advantage of vast communal development effort that lets you achieve results that you couldn’t begin to dream of when working on your own?

Even with the fundamental shift to cms that I’m talking about there remains a role for an application to help users produce the cms logic and the CSS templates in the first place. And I’m sure a lot of the cms modules and most of the css templates were and will continue to be built in Dreamweaver.

But it’s precisely because these are then given freely to others to use and adapt that Dreamweaver becomes redundant for the vast majority of users. No one is going to pay for Dreamweaver with all its baggage if all they want to do is tweak a few lines of code. Especially as this is already more effectively done live in the browser.

Finally I carefully didn’t say that Dreamweaver is dead. To begin with, from some of the comments, it’s clear that there’s a lot of ignorance, inertia and self-interest to be overcome.

More importantly, as others have sensibly pointed out, these are early days and the cms options as they stand are currently only ready for early and adaptable adopters, not for the mainstream. You certainly shouldn’t expect to be able to switch instantly – I’m advising rethinking and retraining.

All in all Dreamweaver will be around for a while yet. However it used to be the dominant web force and the secret behind the overwhelming majority of professional web sites and it won’t be in the future.

The future for creating web design is in the browser not in Dreamweaver.

—————————–

Unsurprisingly Adobe has a slightly different take on things and I’ve now added a follow-up post based on a chat with Devin Fernandez, senior product manager for the web products at Adobe

——————————

Still getting a lot of comments 6 months on. And with comment #264 it looks like I might even have persuaded someone to consider looking in to Drupal In case anyone else is thinking about it, here’s the relevant part of my response:

“The article was primarily aimed at professional non-coding designers either starting out or recognizing that the world has moved on to web 2.0. Sadly it’s not a simple swap by any means (though things are getting easier).

However, if you are seriously looking to the future, I recommend taking a look at it – get a cheap BlueHost account and you can install it automatically and take it for a spin.

If you do, don’t judge it by first appearances (ugly and underpowered). Instead check out the add-on power available and get a better idea of what Drupal is capable of.

Essentially Drupal is harnessing the power of the data-driven web through the pooled efforts of a huge community of talented programmers meaning that you don’t have to code from scratch or even at all (though if you can that’s even better)