About a week before my planned talk, I was shocked to receive an email reminder from the Meetup website advertising the meeting as being about Balsamiq, jQTouch, QUnit, advertising, and the App Store. I immediately contacted Reynold and told him this bore no relationship to what I was planning to talk about. He said it didn’t matter. As an established author and Adobe Community Professional, I felt it did matter. People who had signed up for the meeting would be expecting me to talk about those subjects, something which I was not prepared to do—for the simple reason that most of them are out of my sphere of expertise. So, I decided to cancel. Reynold then bombarded me with a series of direct messages on Twitter. One did include an offer to change the description on the website, but I found his attitude aggressive, so decided to leave a 24-hour cooling off period.

The following day, I sent a lengthy email explaining why I had been offended, but saying I was still willing to give the previously arranged talk as long as a revised title and description were published. I know that Reynold received the email, because his account sent an automatic receipt. However, the only other response was an email from Meetup informing me that I had been removed from the group.

The way things have turned out is a pity. As I told Reynold and his predecessor, Nigel Muris, in November, I don’t have time to organize a Dreamweaver user group myself. But I am willing to share my knowledge either through formal presentations or troubleshooting sessions. I can also make arrangements with my publishers for free or discounted copies of my books.

Reynold has changed the name from The London Dreamweaver Meetup Group to The Adobe & Web Open Source London Meetup Group. However, the website still uses the Dreamweaver URL, and the group’s description refers frequently to Dreamweaver. At one point, it even uses the name, London Dreamweaver (Zero coding) Meetup Group. Anyone hoping to use the most recent version of Dreamweaver without a strong understanding of HTML, CSS, and JavaScript (or at least jQuery) is likely to be seriously disappointed.

In spite of using Adobe in the revised name, it’s not an official Adobe user group. I know that Reynold has applied for official recognition, but Adobe’s position is that the organizer must first show that it’s a viable user group. It hasn’t got off to an auspicious start.

To get the group going, I have agreed to give a talk on Thursday 26 January demonstrating how to create a simple mobile website using jQuery Mobile, which is integrated in Dreamweaver CS5.5. The time and location have yet to be decided, but we’re trying to fix somewhere in easy reach of central London.

Reynold has put a lot of effort into planning the relaunch of the Dreamweaver group, so I’ll leave it up to him to announce the details of what he’s got in mind. In the meantime, I’d like to share some thoughts of my own about Dreamweaver’s reputation and how it can be improved.

Does Dreamweaver produce bad code?

I’ve been using Dreamweaver on an almost daily basis for about ten years, so I know the program pretty much inside out. Even before I started writing books about Dreamweaver in 2003, I always updated to the latest version as soon as it was released. As a result, I also know how the program has developed over the years. Yet whenever I meet professional web developers in Britain, they’re almost unanimous in their hostility towards Dreamweaver. Time and again I’ve been told that no serious professional would consider using Dreamweaver because it produces such terrible code. However, when I ask how long ago it was since they last used Dreamweaver, the answer is usually “ten years ago”.

How is it possible to judge the quality of any product—let alone a piece of software—based on impressions of it ten years ago? I freely admit that the quality of the code created by Dreamweaver all those years ago was far from perfect. Back in 2001, the Web Standards Project (WaSP) set up the Dreamweaver Task Force (later renamed the Adobe Task Force) under the leadership of Rachel Andrew and Drew McLellan, working together with Jeffrey “Mr Web Standards” Zeldman. The task force had two basic aims:

1. Improve the standards compliance and accessibility of web pages produced with Dreamweaver.
2. Raise awareness of web standards among the Dreamweaver community.

When Dreamweaver MX was released in 2002, the WaSP task force released its findings, which concluded—among other things—that “Dreamweaver produces valid markup ‘out of the box’”, and that “the most important thing about this release is that it recognizes the importance of web standards and tries to promote them within the constraints placed on it.” So, even as far back as 2002, WaSP acknowledged Dreamweaver’s support for web standards and the quality of the code it produces. But what were the constraints the task force referred to? The main problem was that Dreamweaver MX still used <font> tags as the default for styling text—although the user could switch to CSS. That changed with the following release, MX 2004, when CSS became the default. And since Dreamweaver CS4 (released in 2008), the only way to use <font> tags has been to insert them manually.

Even so, some horrors remained inside Dreamweaver, the worst of which was Layout Mode. This was aimed at visual designers with an aversion for code, but it created a tangled mass of nested tables that collapsed like a house of cards if you tried to alter the design. As a result of behind-the-scenes lobbying, Layout Mode was deliberately hidden in Dreamweaver CS3, before being removed completely from Dreamweaver CS4. At the same time, all the sample pages that used nested tables and deprecated markup were replaced by standards-compliant CSS layouts designed by WaSP evangelist, Stephanie Sullivan (now Rewis). Another monstrosity that bit the dust in Dreamweaver CS5 was the Web Photo Album. Many of the outdated JavaScript “behaviors” have also been quietly swept away.

As well as removing the bad aspects of the program, the Dreamweaver engineers have added new features—some of them highly successful, others not quite so good. One that I would put in the latter category is Spry, Adobe’s attempt at creating an Ajax library. The idea behind Spry was good, but lack of investment, combined with the runaway success of jQuery, meant that it never fulfilled its potential. Although Spry widgets still live on in Dreamweaver, Adobe has focused its efforts on jQuery—not only incorporating code hinting for it, but also becoming a major corporate sponsor and donating the full-time efforts of several engineers. Among the really positive improvements in Dreamweaver, I would cite syntax checking and code introspection for both JavaScript and PHP, plus the dynamic incorporation of full documentation for PHP 5.3. Dreamweaver’s handling of CSS3 media queries is also a great timesaver, keeping its features in tune with web standards as they evolve.

At the recent HTML5 Live conference in London, Opera evangelist Bruce Lawson jokingly asked me when Dreamweaver was going to stop writing crap code. I’ve known Bruce for some time, and realize that it was meant as a gentle leg-pull, but such thoughts are a decade out of date. Many web professionals use TextMate or Coda to build their websites, but it isn’t the software they use that makes them professionals. It’s their knowledge of HTML, CSS, and other web technologies. In the hands of an unskilled person, TextMate and Coda will produce rubbish. If you know what you’re doing with Dreamweaver, you can produce just as clean code—and possibly a lot quicker.

Raising awareness of web standards in the Dreamweaver community

I’m not a member of WaSP, but I’m passionate about web standards. Getting a Dreamweaver group off the ground is going to take a lot of effort, but I hope that it attracts a wide range of people who use Dreamweaver or are simply interested in web development. Although it will be important to show people the mechanics of using the program, I would like the topics discussed to cover web development and standards in general. When I teach Dreamweaver, I tell students to forget about the mechanics and to concentrate on understanding the markup that is being generated. Once you know HTML and CSS, using Dreamweaver falls easily into place.

Of course, some people might ask why London needs another group devoted to web development and web standards. After all, London Web and London Web Standards (LWS) are both well established and thriving. My hope is that the Dreamweaver Meetup Group can play a complementary rather than a rival role. Both London Web and LWS tend to gather large crowds, which could be intimidating for someone who is just starting out in web development or who has responsibility for maintaining a website as part of wider duties. I also hope that by showing people how to create standards-compliant sites in Dreamweaver, we can remove some of the unjustified prejudice against the program. Dreamweaver isn’t perfect, but nor is it the horror that some people portray.

The invitation to review the rival book came from the marketing department of Packt, the company that published it. I sent a polite reply saying that I didn’t think it would be appropriate for me to review a book that had an almost identical title to mine. I thought that would be the end of it. However, I received an email from Packt saying they knew I had written a book with an identical title, and that’s why I would be the perfect person to write an honest review.

At first I wasn’t sure whether to be flattered or horrified. It’s nice to think that I have such a great reputation for fairness that I would write a glowing review of a book that’s in direct competition with mine. Of course, there’s always the temptation to savage the book in public, but I would never want to do that to a fellow author. I know how much a bad review hurts. Since my book was published three months earlier (and was available even before that as Rough Cuts in the Safari Online Library), Packt can have no excuse for not knowing the title of its rival book was almost identical. I’ve no idea if the title was chosen as a deliberate spoiler, but asking me to review Packt’s book is rather like asking Coca Cola to endorse Pepsi’s latest offering.

I haven’t read the Packt book, which is written by David Karlins, an established and respected author. What I have read is David’s “Thoughts from the author” on Amazon.com. In it, he says you don’t need to know HTML, CSS, or JavaScript. In fact, you don’t even need to know what they are. That immediately tells me that our books take completely different approaches to the same subject. I think it’s a pity his new publisher has decided to muddy the waters with the confusing titles.

I firmly believe that to build a website, you need to have at least a basic understanding of the underlying technologies. Website development is becoming increasingly complex. Dreamweaver helps speed up development through dialog boxes, prepackaged widgets, and code hints; but if you rely solely on point-and-click or copy-and-paste techniques, you’ll remain severely limited in what you can achieve. My book is aimed at readers who aren’t afraid to dig into a bit of code. In fact, you’ll need to do so if you want to access features such as geolocation and web storage on mobile devices. I guide you through the code, explaining what it does so that you can adapt it to your own needs.

So, if you’re looking for a book on developing for mobile with Dreawmeaver CS5.5 with jQuery, HTML5, and CSS, make sure you choose the one that’s right for you. Don’t be confused by the titles. Oh, and as small bonus, my book is in full colour, even though it’s the same length and the same cover price ($39.99) as the one published by Packt.

I recently discovered that friends of ED has closed its website and merged it with that of its parent company, Apress. Unfortunately, none of my books’ errata are yet listed on the new site. So, I’ve scrabbled around to put them back together and host them here. You can find the corrections for the following Apress/friends of ED titles on this site:

• PHP Object-Oriented Solutions
• PHP Solutions (First edition)
• PHP Solutions (Second edition)
• The Essential Guide to Dreamweaver CS3
• Foundation PHP 5 for Flash

I find it hard to believe that there weren’t any mistakes in The Essential Guide to Dreamweaver CS4, but I can’t trace any record of corrections. I haven’t gone back to some of my older books. Good though they were, they’re based on versions of software that are no longer supported. What’s more, most of them were reprinted with corrections.

I also plan to keep up to date the corrections pages on this site for the books I have published with Adobe Press.

If you come across any errors or code that doesn’t work, please report them directly to the publisher. That way corrections can be incorporated into reprinted versions of the book. But if you don’t get an acknowledgement from the publisher within a day or so, please leave a comment here, and I’ll try to deal with the issue as quickly as possible.

If you planning to develop sites for multiple platforms, you’ll learn about CSS media queries and how to use the new features in Dreamweaver CS5.5, including setting up a site-wide media queries file. There’s a chapter on making sites available offline, and the download files contain a Dreamweaver extension that automatically builds a manifest file ready for editing. The chapters on jQuery Mobile contain extensive analysis of custom data attributes that control the look and functionality of a jQuery Mobile site.

Stephanie (Sullivan) Rewis (@stefsull) had a sneak preview of the book. Her verdict: “David’s clarity and ability to explain complex subjects clearly makes this a book not to be missed.”

Things didn’t go quite to plan. I had lined up a series of quick demos to show off the way Dreamweaver handles media queries and the creation of rounded corners with the CSS3 border-radius property. Unfortunately, the connection to the projector switched the resolution on my laptop to something crazy like 640 x 480, making it impossible to see the full workspace and preventing me from accessing the document tabs to switch between the demo pages I had prepared. Since I had only a five-minute slot, I decided—perhaps foolishly—to soldier on rather than waste valuable time trying to find a resolution compatible with the projector.

What I did manage to demonstrate was Dreamweaver CS5.5′s support for web fonts, creating and adjusting CSS3 drop shadows visually, jQuery code hinting, and PhoneGap integration. While demonstrating the support for web fonts, I was able to show how you can work in the underlying code and view the result in Live view without needing to save the document or round-trip to a browser.

I got the feeling that the audience remained sceptical about Dreamweaver, but they listened to what I had to say. And with plenty of questions, my original five minutes extended beyond ten. Matt Lucht has given a good summary of what I had to say (together with comments about the main speakers). Matt makes the comment “I’m not sure what value it gave over say a browser plugin such as Firebug.” It’s a fair point. Dreamweaver is an IDE for HTML, CSS, JavaScript, PHP, and other web-related languages, all of which are open standards. Therefore, there are plenty of authoring tools around—some free, others commercial.

What I think Dreamweaver has to offer is the way in which it brings the various web technologies together. I use Firebug and similar tools, such as the Web Inspector in Safari. They’re great, but you need to switch from your IDE and back to use them. Each time you switch is time wasted. Dreamweaver gives me most of the tools I need in a single workspace. Working recently with a jQuery Mobile project, I found Dreamweaver’s Live Code one of the most useful features. It lets you inspect the dynamically generated code inside the Document window, which is essential for dealing with pages generated through DOM manipulation. Yes, I can get the same information by right-clicking in Safari or Chrome and selecting Inspect Element, but it takes me longer to do so. Live Code also lets me inspect what’s happening in response to different events by highlighing all changes in a different colour.

Judging by comments from the audience and in conversation afterwards, there seem to be two main barriers to acceptance of Dreamweaver among professional web developers/designers. The main complaint is the price. I can’t do anything about that, although I have told Adobe on more than one occasion that I think the price differential—between what you pay in dollars in North America and what you pay in pounds or euros in Europe—is totally unjustifiable, particularly for a product that is delivered electronically. Adobe is not alone in charging a premium outside the USA, but it builds up resentment and damages sales. Still, buying software is a business expense. Business must be really bad if you can’t afford the tools for the job.

That brings me to the other main barrier—many web professionals don’t think Dreamweaver is the right tool for the job they’re doing. Maybe they’re right. Far be it from me to question how another person does his or her job. But several people in the audience admitted that they hadn’t used Dreamweaver for a long time. I have used it consistently since Dreamweaver 3 (about 11 years). The Dreamweaver of yesteryear is not the program it is today.

In 2001, the Web Standards Project (WaSP), led at the time by such people as Jeffrey Zeldman, formed a task force to pressure Macromedia (the original creators of Dreamweaver) to improve the standards compliance and accessibility of pages created with Dreamweaver. The initial result was the release of Dreamweaver MX 2004, which produced much cleaner code. It wasn’t perfect, but it was close. The main problem was Layout Mode, a WYSIWYG tool that produced the most horrendous table-based spaghetti code. Another problem was the use of “layers”—absolutely positioned elements with inline styles. With the help of others, I privately lobbied Macromedia and then Adobe to get rid of Layout Mode. Partial success was achieved with the release of Dreamweaver CS3 in 2007, when access to Layout Mode was deliberately hidden. Then, in 2008, Layout Mode was finally killed off in Dreamweaver CS4. Layers also disappeared. You can still create absolutely positioned elements, but they no longer have inline styles.

The WaSP Adobe Task Force was wound up in 2009, but Stephanie (Sullivan) Rewis still acts as WaSP Industry Evangelist to Adobe. I know from my participation in private Adobe forums that she gives the Dreamweaver engineering team a tough time, pressuring them constantly to improve standards. Dreamweaver certainly hasn’t stood still. It has full code hinting support for HTML5 and for CSS3 modules that have reached a reasonable degree of stability. Its support for PHP and JavaScript code introspection has greatly improved its usefulness to developers.

As I see it, Dreamweaver’s main problem is one of perception. It gained a reputation (deservedly so) for producing bad code and for being a WYSIWYG tool. The WYSIWYG image is completely wrong. Most Dreamweaver users that I know work in Split view with the code on the left of the screen, and a visual representation of the page in Design view on the right. If you’re working in Design view, you can keep an eye on the code that’s being generated. But it gets better if you switch into Live view, which renders the page using the WebKit browser engine. You can continue working in the code, and your changes are immediately reflected in Live view by pressing F5 or clicking the refresh icon. What’s more, the Related Files toolbar gives you access to all linked files in Code view. So, I can work in an external JavaScript file while keeping the web page visible on the right of the screen.

If you haven’t used Dreamweaver for a long time, give it a try when CS5.5 is released in May. There will be a 30-day free trial. As long as you’re willing to explore its features, I think you might find there’s a lot to like. If it doesn’t match your needs, fine. But at least I hope you’ll get the chance to see that it’s not Dreamweaver that produces bad code. It’s bad designers/developers who do.

(Disclosure: I’m not an Adobe employee, but I am an Adobe Community Professional, a sort of unpaid evangelist for Dreamweaver. I write books about Dreamweaver and answer questions in the Dreamweaver Help pages. I also teach Dreamweaver and write books about PHP.)

The book guides you through the main new features in Dreamweaver CS5.5 with the help of three case studies. The first one centers on redesigning a website for display on desktops, tablets, and smartphones using HTML5, CSS3, and media queries. The second takes a cut-down version of the same site, and builds a dedicated mobile version using jQuery Mobile, a sophisticated JavaScript and CSS framework designed to work consistently in all major mobile platforms. The final case study uses Dreamweaver CS5.5′s PhoneGap integration to develop a simple app that stores information in a database, accesses a mobile phone’s GPS sensor, and displays a map.

More details later.

This is a major upgrade. Here’s what it contains:

• Full support for jQuery Mobile, including more than a dozen jQuery Mobile widgets.
• PhoneGap integration to create native apps for Android and iOS using HTML, CSS, and JavaScript.
• Code hinting for jQuery.
• New tools for creating CSS3 rounded corners and drop shadows.
• Support for web fonts.
• Full support for all CSS3 selectors.
• The ability to see what pages will look like at different screen resolutions without leaving the Document window.
• Support for FTPS.

The emphasis in this new version is firmly on  development for multiple screen resolutions and for mobile devices. The New Document dialog box contains starter pages for jQuery Mobile that enable you to build in minutes a simple web application that works consistently in all major mobile platforms. All you need to do is to replace the placeholder text with content of your own. Of course, to create more than just a boilerplate application, you need to do your own coding. But Dreamweaver CS5.5 has full code hinting for both jQuery core and jQuery Mobile, speeding up the development process.

The PhoneGap integration is particularly impressive. At the moment, Dreamweaver supports the development of native apps only for Android and iOS, but there are plans to expand this later to other mobile operating systems. Developing for iOS requires Mac OS X 10.6, but Android is supported on both the Windows and Mac versions of Dreamweaver. If don’t already have the Android SDK (software development kit) installed, Dreamweaver does it for you with just a single click. Having gone through the pain of the manual installation process on both Windows and Mac, I can honestly say that Dreamweaver’s automated installation is a real godsend. After developing your web app with HTML, CSS, and JavaScript, Dreamweaver runs PhoneGap to build the native version and installs it into a simulator.

Smaller, but nonetheless important enhancements that I particularly like are the tools for creating image-less drop shadows and rounded corners with CSS3. Using them in combination with Live view lets you see the effect of your style definition immediately. No constant toing and froing between the style sheet and a browser. Dreamweaver also now has support for rgba() and hsla() colour formats, simplifying the addition of transparent effects to your web pages.

Is there anything not to like? Yes. Bringing out this new version only a year after CS5 and about eight months after the 11.0.3 updater means there are a few rough edges. For example, you need to be careful where your insertion point is when you add a jQuery Mobile widget. Normally, Dreamweaver recognizes if you’re inside a paragraph or other block element and either moves outside the element or splits it. However, with jQuery Mobile widgets, it just puts the new code wherever you happen to be. It’s more of a minor irritation than a major failing; but anyone who doesn’t understand the code that’s being created will end up with a complete mess.

Dreamweaver’s implementation of HTML5 also has some way to go. But then, so has HTML5 itself. There’s full code hinting for HTML5 elements and attributes, but there’s no easy way to insert HTML5 elements except through hand-coding in Code view.

In spite of the shortcomings, I’m really enjoying working with Dreamweaver CS5.5, and hate going back to earlier versions. I strongly recommend that you give it a try when it’s released. I think you’ll like it.

The beauty of the Server Behavior Builder is that it’s not dependent on Dreamweaver’s built-in server behaviors. You can use it with your own code or in conjunction with a third-party PHP library, such as the Zend Framework.

I’m thrilled to have been chosen to present a hands-on demonstration of using the SBB at Adobe MAX in Los Angeles at 3:30pm on Tuesday, 26 October. It’s a BYOL (bring your own laptop) Lab. I’ll be showing how to create several useful tools to speed up PHP development, and I’ll also show you how to package your server behaviors as Dreamweaver extensions, so you can move them quickly to another computer or share them with friends and colleagues.

Even if you’ve learned about the SBB from my books, this session will go into greater detail, and will be based on new material. All the necessary files will be provided. Just bring yourself and a laptop. So, register for Adobe MAX 2010 and sign up for my BYOL Lab. See you in LA!