Never heard of video2brain? It’s an Austrian company that has been providing video training in German, French, and Spanish for the past decade. It started creating courses in English in 2009, and now has more than 500 hours of English-language instruction on Photoshop, InDesign, Dreamweaver, and many other aspects of digital media. The videos have been created by some of the top names in their fields, including Rufus Deuchler, Tom Green, Angie Taylor, Todd Kopriva—not to mention me. The company has also created a large number of videos for Peachpit, one of the best known names in computer technology publishing. So, it’s no fly-by-night company.

As a video2brain author, I’m able to offer a substantial discount on the already competitive prices for the new subscription service. There are three levels of subscription:

• Standard—$129 a year or $12.99 a month (normally $149/$14.99). This gives you unlimited access to all English courses streamed online.
• Gold—$179 a year or $17.99 a month (normally $199/$19.99). In addition to the courses, you also get access to all project files and PDF books.
• Platinum—$279 a year (normally $299). In addition to the the project files and PDF books, you can download the courses to view them offline.

Students and teachers can purchase the academic version of the standard subscription for $99 a year.

If you subscribe during the introductory period, video2brain says it will lock the subscription price for three years. And as the collection of courses grows, you’ll get immediate access to all new titles. It’s planned to add at least four new courses each month. So, if you’re looking to brush up your digital skills and keep abreast of the latest developments, you can do so for as little as 35 cents a day. Many of the courses have sample videos that you can view free of charge, so you can judge the quality for yourself before committing your hard-earned cash.

I have to admit that I’m far from being an expert in JavaScript. I’ve used it for about eight years, but it’s never come as easy to me as PHP. So, earlier this month, I headed down to Brighton for the third Full Frontal JavaScript Conference organized by JavaScript whiz kid, Remy Sharp. I had attended Remy’s Node.js workshop in London in May, and realized he was not only knowledgeable, but also well organized. That gave me high hopes for the conference, although I was a little concerned about immersing myself for a full day in a series of talks about different aspects of JavaScript. Unlike a dedicated workshop, you can’t raise your hand and get the speaker to go over a point you didn’t quite understand. Well, you could, if you wanted to make a fool of yourself in front of 300 people, most of whom were likely to be pretty hot on JavaScript.

I needn’t have worried. Remy had invited an excellent mix of speakers, and each talk was limited to 40 minutes. As a result, even the technical presentations by Jeremy Ashkenas (about CoffeeScript) and Marijn Haverbeke (about code editing in the browser with Code Mirror) served more to inspire than to fill me with dread. In fact, that’s the main thing I took away from the conference—inspiration at the incredible ways you can use JavaScript. Glenn Jones demonstrated some really cool uses of the new drag and drop API in HTML5. Nicholas Zakas’s talk was more theoretical, emphasizing the value of building applications in loose coupled modules—something that applies to most programming languages.

Two of the most inspiring talks came from Brendan Dawes and Marcin Wichary. Brendan presented a witty tour-de-force that somehow got from his obsession with pencils to a fascinating series of demonstrations of visual navigation systems that encourage exploration. With a background in Flash development, Brendan’s showing that—with skill and imagination—you can do visually amazing things with JavaScript. Equally amazing things are done by Marcin Wichary, who unveiled some of the secrets of Google doodles. What really impressed me was the length he goes to in order to ensure that even users of older browsers get a similar, if not equal experience.

JavaScript is becoming easier thanks to libraries such as jQuery and Microsoft’s decision to follow the World Wide Web Consortium’s Document Object Model (W3C DOM) since Internet Explorer 8. The HTML5-related APIs are also adding lots of new functionality to browsers, but there’s a danger of slipping back to the days of animated GIFs if designers/developers add new bells and whistles to their sites “just because they can”. So, Phil Hawksworth’s witty presentation was timely, warning against shizzle for the sake of shizzle.

All in all, a good day out. Any regrets? Yes, Brighton is only an hour’s train ride from London, so I decided to make it a day trip. But I had to get up so early to make it to the venue in time that I was dog tired and began nodding off in the afternoon. I was also too tired to go to the after-conference party—and missed all the free beer! Next time, I’ll book myself into a local hotel.

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.

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.)

I answer a lot of questions in the Dreamweaver forums, and realized that a lot of the solutions I was coming up with for people weren’t easy to find after a couple of days. So, rather than letting them disappear into cyberoblivion, I decided to add any of general interest to the cookbook when I had a few spare moments. The Dreamweaver Cookbook is intended for code samples, and doesn’t have the capability of including screenshots, so I’ll continue posting longer tutorials on my own site. But I hope you’ll find my contributions to the cookbook useful.

Here are direct links to some of the articles I have added to the Dreamweaver Cookbook:

• Create nested lists from a recordset
• Set a time limit on a login session
• Registration system that requires the user to validate the email address (in two parts)
• Alternate colours for table rows (using PHP, Spry, or jQuery)
• Upload image to website
• Format date for insertion into MySQL
• Formatting dates stored in MySQL

The Dreamweaver Cookbook is open to anyone to either request recipes or contribute recipes of their own. It could turn into a very useful resource if people start using it regularly. Check it out!

That’s a shame, because Bridge has some very useful features. I use it frequently for batch renumbering my photos and for selecting photos to use in websites. The thumbnail images can be resized, making light work of choosing the best photo to zap into Photoshop and optimize for a web page. The other great feature in Bridge is what is called the Adobe Output Module. Among other things, this creates Flash-based web galleries of your visual assets. It’s incredibly easy to use, and produces really nice results.

The only problem is that the HTML file generated by Bridge makes the Flash movie fill the entire browser window, making it impossible to incorporate the gallery into an existing website. Well, it’s not really impossible. All it needs is a little editing of the HTML and JavaScript. I have created a new tutorial with step-by-step instructions to show how to incorporate an Adobe Bridge web gallery into a website. I hope you find it useful.

It’s obvious that people love the ability to create a menu bar in seconds, but they hate banging their head on their keyboard trying to figure out how to edit the CSS. In response, I’ve created a couple of tutorials that are now live on my site. The first one goes into considerable detail, explaining the basics of customizing the CSS of a Spry Menu Bar, with instructions for both horizontal and vertical menu bars. The other, shorter tutorial shows how to centre a horizontal menu bar. I hope you find them useful.