Microsoft is famous for developing new technologies only to abandon them later, leaving early adopters high and dry. WebMatrix is one of those rare exceptions to get a second life (or third, depending upon how you count them) after being dropped like a stone six years ago.

In a nutshell, WebMatrix provides a free web development environment for .NET and, to a lesser extent, PHP. The aim appears to be to provide a simple entry point to .NET web development for beginner coders – the hope being that once snared within the Microsoft development environment, programmers will upgrade to Visual Studio. The initial install includes the IIS Express web server, the SQL Server Compact Edition for databases and support for the new Razor mark-up syntax.

This base WebMatrix installation allows you to create standard page and database-driven websites from within a lightweight IDE, as long as you’re content with using .NET technologies for development. The IDE includes simple tools for creating and editing web pages and SQL Server databases. Microsoft’s tutorials walk you competently through the standard “hello world” equivalents – including pulling data from a database. My initial impression is that WebMatrix does indeed make database interaction simpler than with any other technology I’ve seen, since most of the work is done within the GUI.

WebMatrix has another side, however, perhaps indicative of Microsoft’s habit of wanting to be all things to all people. Rather than choosing to create a site from scratch, you can use an existing web framework through WebMatrix’s integrated “Web Gallery”. WebMatrix includes support for PHP frameworks including WordPress and Drupal, as well as more natural bedfellows such as DotNetNuke.

This highlights an intriguing possibility. Despite excellent tools such as WAMP, getting a fully working Apache, PHP and MySQL system working on your Windows PC can be tricky and less than intuitive. WebMatrix offers the potential to reduce that hassle to a few mouse clicks.

By choosing the WordPress framework, for example, WebMatrix will install and configure a fully working WordPress site running locally. The intention is that you’d put your site together on your PC and then upload it to a compatible host using Microsoft’s Web Deploy technology, but I haven’t yet had time to find out if that works in practice. Of more use, perhaps, is the sheer simplicity of being able to create multiple WordPress sites for developing themes and plugins, or testing new code before deploying by hand to your live site. None of this was impossible before using other tools, but WebMatrix makes it more convenient.

Choosing WordPress or Drupal for the first time will cause WebMatrix to download the underlying PHP and MySQL technologies as well as the chosen framework. This caused a major problem for me because WebMatrix couldn’t get the MySQL download to successfully complete. The workaround was to download it from within a browser  – choose mysql-5.1.53-win32.msi.

The end result is a fully working WordPress installation with the underlying files and database accessible from the WebMatrix control panel – yes, you can even edit a MySQL database this way.

Deployment is more problematic. The FTP method built into WebMatrix doesn’t upload the database, so the only answer would be to manually create a WordPress installation on your server with identical details. Microsoft’s Web Deploy function looks fiddly and typically idiosyncratic – hosting providers need to change their systems in order to work with it. This may prove to be the Achilles heel of WebMatrix.

Overall, a promising technology. I can see a potential use as a testbed for plugin and theme development in WordPress, Drupal and other frameworks. It remains to be seen whether the final step in integrating with web hosts proves to be a problem, but it could well be a good way for newcomers to .NET technologies for the web to get started with the minimum of fuss and no financial outlay. Let’s just hope Microsoft don’t drop it again.

The beauty of WordPress.com is that it makes exploring what WordPress has to offer so painless. Essentially all you need is an email address and, within a couple of minutes, you can be creating your first posts and pages, changing your theme, monitoring your stats and so on. If you like what you see, you can either stick with WordPress.com’s default free hosting package, upgrade to get your own domain name ($15 a year), redirect an existing domain ($10 a year) or, most powerfully, switch to an independent WordPress host where you’ll be able to extend the framework’s capabilities via third-party plug-ins.

Generally the response has been amazingly enthusiastic – “the difference is night and day” – especially from those owners of existing sites who had previously been paying a fortune to traditional web designers whenever they’d needed to update existing pages.

Recently, however, for one correspondent the dream descended into a nightmare…

Having created a site on WordPress.com he decided it was so good he wanted to replace his existing site with it and sent out a mailshot to advertise the fact. Unfortunately as soon as he switched to his new primary domain (ie. example.com rather than example.wordpress.com) his email stopped working.

Domain mapping, email and custom DNS

Unfortunately things are not as simple as they seem. Indeed the WordPress.com support page includes this:

Warning: Changing the name servers will make any previously setup custom DNS records such as A, CNAME, or MX records stop working. To continue using them, you’ll need to enter new Custom DNS records once you have set up your domain on WordPress.com.

Unfortunately you need to know quite a bit about DNS to realise that this is a serious issue. In particular the Mail eXchanger MX record specifies a mail server responsible for accepting email messages.

At least this pointed to the solution, namely updating the MX record in WordPress.com as discussed on a Custom DNS support page. However, with pitiful support from WordPress.com and existing host alike, this proved easier said than done, as simply adding a pointer back to the original server didn’t solve the problem.

Moreover, based on the support page’s advice that, “it can take up to 48 hours for all the DNS changes to filter through the internet. Don’t panic if it doesn’t work right away”, my correspondent naturally panicked at the prospect of tweaking settings and then having to wait two days without email to see if they had worked.

Thankfully I was able to help him find a fix. On the same page where you enter your custom DNS records, WordPress.com has provided a link to Google Apps for Domains.  This is how WordPress.com provides email handling for those registering a domain with them and, by signing up, my correspondent was able to enter the code Google provided and then click the Generate DNS records command to automatically create the necessary custom MX code to get his domain name-based email back up and running almost instantly. In fact with Outlook-based desktop access as well as webmail access, plus the other benefits of Gmail handling, he was probably better off.

To be honest, I’m not sure how big an issue this is. With well over 10 million sites hosted on WordPress.com, the site must be one of the world’s biggest hosts and domain mapping targets, and clearly most redirects haven’t gone through the same nightmare. Certainly most hosting/domain providers should have experience of how to redirect web traffic to WordPress.com without messing up email. Quite possibly my correspondent’s setup was unusual in some way and I don’t know enough about DNS or email handling to say how (hopefully more experienced readers may be able to shed more light).

However the fact that it happened at all shows that it can be an issue and one that users should be aware of before mapping their existing domain. More importantly it shows that even the simplest content management system (CMS) can occasionally turn around and bite you – failing to backup your all-important database being the prime route from dream to nightmare for those who choose independent hosting.

I still strongly believe that the enormous benefits of CMS handling far outweigh its occasional pitfalls and that the best solution for those looking to create simple sites is WordPress, and that the easiest way to explore how WordPress works and what it can do is via WordPress.com. However I’ll now include a link to this post too.

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.

I’m glad to say that I think I’ve come across a near-perfect solution…

There really shouldn’t be a problem in the first place: a CMS provides efficient, flexible and scalable centralized control over content while CSS (the Cascading Style Sheet markup language) is designed to provide efficient, flexible and scalable centralized control over presentation. In theory it’s a match made in heaven.

In practice it’s anything but. The problem is that creating a comprehensive style sheet that takes in every possible design element (heading, table, block, list, menu, button and so on) as well as every foible of CSS and, crucially, every bug in the various browser implementations (IE take a bow) is way beyond most users’ capabilities.

The current best workaround for the average user brave enough to move beyond the in-built default themes is to take advantage of the designs that you find on free template sites. It’s a huge advance but it’s only a partial solution. Off-the-shelf templates inherently mean design that is neither unique to your site nor tailor-made to your content.

Now however there’s an alternative.

At first sight Artisteer looks seriously unpromising – an automatic theme creator that generates unique designs every time you click the Suggest Design button sounds like a recipe for design disaster. In practice it really delivers the goods as I discuss in the full Artisteer 2.1 review . And with version 2.x’s ability to export your designs as ready-to-go themes for Joomla, Wordpress and Drupal you can begin exploring your new custom design live on your site within minutes.

With Artisteer’s various Suggestion commands you can quickly hone in on an overall look-and-feel, but what about the inevitable tweaks and iterations involved in any real world design process? It’s here that Artisteer really proves itself a worthy partner to CMS / CSS with its own beautifully efficient, flexible and scalable centralized design engine letting you take ever more granular control over your presentation as-and-when you need it.

The end result, as I say in the review, is that Artisteer makes it “child’s play to automatically create fully customised tailor-made themes that look good and work well”. By providing the bridge that connects CMS and CSS, Artisteer could be the key to unlocking the full and extraordinary potential of both. I strongly recommend giving the free trial a spin.

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