Software Review: Macromedia Dreamweaver 8 and Adobe GoLive CS2, Part 1

The Role of Visual Editors, and the Current Leaders in the Field

Readers of our previous review of Dreamweaver MX will know that the main reason packages like Dreamweaver originally came into existence was to provide a way for users to build and edit web pages in an environment where they could see how the page would actually look when displayed by a browser, as distinct from the code-centric environment of the underlying HTML or XHTML. Although many sites nowadays are created and maintained with a CMS (content management system), which enables webmasters to separate the job of handling content from the job of determining how pages will look, nonetheless visual editors still occupy an important or even essential role for anyone interested in modifying or creating that look in the first place.

So for the many mental health professionals who do want to have a hand in crafting their site's look and feel -- and certainly for those who manage their site's structure and organisation directly, rather than through a CMS -- packages like Dreamweaver and GoLive are worth evaluating.

For years, Dreamweaver and GoLive have been duking it out for the title of most capable visual editor; although many different low-end packages are available for building web sites, none compares to these two heavyweights. While the competition has long centred on Dreamweaver and GoLive, however, I believe most would agree that GoLive has been struggling for quite awhile. Since Adobe's acquisition of Dreamweaver publisher Macromedia, however, both products are now owned by the same company, and it remains to be seen what impact that may have on the two product lines.

This review takes a look at each software package in its current state and offers views for those who need to create a web site now, without waiting until some time next year for whatever Adobe will be producing next. As with our earlier review of Dreamweaver, it's impossible to do justice to the full feature set of programs as large and complex as these. As before, I'll highlight a few areas of particular interest from the standpoint of the individual mental health practitioner considering these packages as tools for site building.

CSS Support and Rendering

Whereas the previous version of Dreamweaver offered a quantum leap in CSS support, Dreamweaver 8 offers subtle improvements that make a surprisingly large difference in terms of ease of use. Gone are Dreamweaver's many separate CSS panels, replaced with one single pane that makes it much easier to create, edit, and understand complex style declarations. Even designers accustomed to writing style sheets by hand may find Dreamweaver's unified style pane an attractive alternative.

Even better, Dreamweaver now shows not only all the properties which apply to a given XHTML element, but also where those properties have been inherited from. Can't work out why your <h3> tags seem to have an unusual amount of right padding? No problem: Dreamweaver can immediately show you that the property was inherited from something you set in a style declaration for a containing <div> you were working on last week and subsequently forgot about. For all but the simplest style sheets, this capability alone can be a real time saver when it comes to debugging.

Dreamweaver has also added simple style sheet switching so you can see how a page looks with style sheets applied for different media types (or with styles disabled altogether) -- for example, to enable you to see how a print-only style sheet will cause the page to be rendered. This is vastly simpler than manually connecting and disconnecting style sheets, and changing media types just to see how another style sheet looks.

During my testing, I also found that the CSS rendering glitches of previous versions are gone: no more randomly shrinking column widths or other annoyances.

What about GoLive CS2?

Here, the news is not so encouraging. On the positive side, the CSS editing palette of Adobe's product has improved (although it is still no match for Dreamweaver's), and those who rely on GoLive's Layout Grids for positioning will be relieved to know that the package has finally abandoned tables in favour of CSS-based positioning.

But it's the fact that Adobe has clearly put such significant effort into improving support for CSS-based layouts that makes one big hiccup all the more astonishing: GoLive CS2 still cannot properly render complex CSS-based layouts in visual editing mode (called 'Layout Mode'). As far as I can tell, the problems seem to crop up as soon as GoLive encounters absolutely positioned or relatively positioned <div>s, and problems are worsened by the presence of CSS-defined background images. For example, the image below shows how this site's page describing our discussion forum looks from within GoLive:

The purple shading in this image is entirely normal behaviour: this is simply how GoLive indicates template elements that are fixed for each page. However, the peculiar rendering of background images makes it difficult to see what is where, while the incorrect rendering of width for the <div> containing the main text of the page requires continual scrolling left and right even to read the main text. In short, GoLive's rendering of complex CSS-based layouts is so bad that it becomes virtually impossible to work in visual mode effectively. (Dreamweaver 8 renders the very same page just fine.)

By contrast , GoLive's ability to preview a page -- showing how it will look when viewed with a browser, but without enabling the content on the page to be edited -- appears to work almost flawlessly. GoLive CS2's previews are now so good that you can almost rely on them as a replacement for direct testing in a real web browser. If only the rendering prowess which GoLive displays in previews could be available in GoLive's Layout Mode, the product could be a real winner in this department.

On a related note, GoLive CS2 has added robust support for previewing and working with small screen sizes (including mobile devices).

Site Management

Both products offer significant improvements in terms of site management, with GoLive CS2 adding SFTP as well as FTP tunneled through SSH and over SSL, and Dreamweaver adding (at long last!) uploading of files in the background, so that updating the site no longer ties up the whole program until the update is finished.

Unfortunately, both also suffer from annoying site management bugs and shortcomings in usability. For example, my test copy of GoLive CS2 seemed pathologically prone to crashing when using the function to upload modified files to the web server, and using GoLive to accomplish simple tasks at the server end -- such as deleting a couple of files -- turned out to be so slow as to be nearly useless. It was far quicker simply to SSH to the web server separately and delete or rename files from the UNIX command line.

Having said that, in my view, GoLive remains the vastly superior product when it comes to handling site updates performed by a single author. (I cannot comment on the merits of either product for multi-user environments where different authors may be changing different parts of a site a the same time, simply because I haven't had the opportunity to try it.) GoLive's abilities to synchronize local and remote files, as well as basic functions like uploading modified files, work much more reliably than Dreamweaver's (even accounting for the crashes).

And in terms of usability, Dreamweaver still suffers from what has become a real pet peeve of mine: an apparent inability simply to upload site files stripped of template tags or comments. Yes, it can be done, but it requires a circuitous journey of first exporting a template-free version of the site to a separate folder, and then separately uploading files from that exported version of the site to the actual web server Worse yet, the export function does not work reliably, sometimes inserting additional "notes" folders or other detritus into the exported version even when explicitly told not to do so, and sometimes exporting parts of the site that have not been modified since the last export, even when told not to do so.

By comparison, uploading without template tags or comments is a picture of simplicity with GoLive.

A simple checkbox sets a preference -- which can be site-specific or for all sites -- to upload pages without template tags ("Adobe GoLive Elements"), comments, or even extraneous spaces (like those used to indent lines of code). What could be simpler! If this is ever something you need to do, GoLive makes it so simple you hardly even notice it, while Dreamweaver makes it a nightmare.

One other aspect of site management, re-usable code snippets -- called 'Library' items by Dreamweaver and 'Components' by GoLive -- deserves a mention in the nightmare department, especially on the GoLive side (even though I generally prefer the GoLive approach to components). Once upon a time, changing which component would appear throughout a whole set of GoLive documents within a site would actually update the contents of all those documents using that component. For example, suppose you wanted to change 100 pages from incorporating one piece of footer code to incorporating a different piece of footer code stored in a different component. Using the 'In & Out Links' pane, you can easily change all 100 pages to use the new component via a simple click and drag. Once upon a time, this move would both change the pointer within each of those 100 pages indicating which component should be used on that page and change the actual component code (in this case the footer code) being stored within those 100 pages. Now, however, changing the pointer updates all 100 pages to indicate that a different component should be used, but the old component code remains in place. The new footer code will not appear in all those files until you update the component itself and save it, requiring a second run-through of all 100 pages to get the updated code in place. Worse, if the new component is actually in use across the site more widely, then this action of updating the component to force the new code into the updated pages will update all those pages, even the ones which otherwise wouldn't have needed updating. The tedium of going through this process to get component code updated properly is nothing compared to the bafflement caused by assuming CS2 works like previous GoLive versions and then finding all those bits of code you thought you changed actually haven't changed at all!

Continue to Part 2...