Adobe Dreamweaver has long been a staple of Web design. With Dreamweaver CS5.5, Adobe steps up to enhance this app for the mobile app universe. (Pricing, as of 6/17/11, is $119 to upgrade to the standard version, or $399 to upgrade to the Web Premium version.)
This step is logical and necessary.
Step into any elevator, and half the people in it are staring at their phones. Your boss is probably one of them, and he or she knows that all the cool companies are developing mobile versions of their Web sites–and iPhone applications and Android applications–and it’s all up to you to develop them (while you also keep the doors from falling off the old Web site). And while you’re at it, you should update all your old code to HTML 5, because that’s what everyone else is doing, right? The good news is that the new Dreamweaver CS5.5 Web-authoring application has several new features that can do all of that, and more.
Related stories
Adobe Contribute CS5 — a costly Web editor for non-techies
HTML5: What does it mean for you?
6 reasons why HTML 5 won’t kill Flash
Surviving the move to HTML 5
The previous version of the HTML standard, version 4.01, was approved in 1999. HTML 5, on which work was begun in 2007, offers many snazzy enhancements, including the ability to present transparencies, customize box types, and deliver video in multiple formats–and it’s supposed to do all that and much more on any device, and on any size of screen. However, many pieces of HTML 5 and the associated Cascading Style Sheets 3 (CSS 3) are still in various stages of development, and as a result, the level of support for HTML 5 and CSS3 by the various browsers–Google’s Chrome, Mozilla’s Firefox, Microsoft’s Internet Explorer, Opera, and Apple’s Safari–varies wildly. The latest version of Apple’s Safari and Google’s Chrome support the greatest number of new features, while even the latest version of Internet Explorer has many holes in its support for HTML 5 and CSS 3.
Adobe is committed to HTML 5 support; the company, for its part, says that it waits until code elements are “solid,” or pretty late in the development process before it adds them to Dreamweaver’s code library. Adobe has also added some vendor-specific prefix codes, such as -moz (Mozilla Firefox), -o (Opera), and -Webkit (Webkit-based browsers) on top of those, though one could argue that bloating your code with multiple vendor-specific prefixes only encourages browser makers to shun conformity–and it’s a great way to drive yourself nuts.
Dreamweaver CS5.5 tries to stay ahead of the curve in other ways too. Adobe updated its support for WebKit, the open-source page rendering engine used by Android’s browser, Google Chrome, Apple Safari (on Macs, iPhones, and iPads), and even the Amazon Kindle’s built-in browser. The result is that in Dreamweaver’s Live View mode, which is meant to give you a quick look at your Web design as it would be seen by a browser, you do see a more-accurate representation of your page as it would appear on devices running those browsers. However, some of the new CSS 3 styles–for example, border radius–can only be seen in Live View; if you change a value in Design View or Source Code View, you must click the Live View button to see the change’s effect. Adobe says that it set up Dreamweaver in this way to preserve objects’ editability, and that Live View is better for gauging how well pages appear in their dynamic or interactive states.
And unfortunately, Internet Explorer, the browser that a large majority of Web users favour, does not rely on WebKit. IE’s lack of support, combined with its lack of support for many other Web standards, means that you can’t rely exclusively on Live View to proof your pages. I use it mainly to check basic functionality–for example, whether I’ve entered image URLs properly–but fine-level browser compatibility checks still must be performed by loading them into multiple browsers and eyeballing the layouts.
Of course, previewing designs is difficult to impossible if you need to accommodate ancient browser versions, such as Internet Explorer 6, which is still a stubborn mainstay in many companies (and IE 7 and IE 8 aren’t much better, standards-wise). You can’t have multiple versions of Internet Explorer installed on your system, of course, so the next best thing is Adobe’s BrowserLab, a component of its CS Live online services. In Dreamweaver, you can click a button to send your current page to BrowserLab, which is a Web site where you can see screenshots of the page as it would be rendered in many different browser versions: Chrome 9 and 10, Firefox 3 to Firefox 4, IE 6 to IE 10, and Safari 4 and 5.
BrowserLab isn’t new, but the reason I call it out here is that Adobe says that it’s free until April 2012, when it will begin charging $20 to $30 a month or $200 to $300 a year for it (it hasn’t decided on the final pricing yet). Furthermore, Dreamweaver’s integration with BrowserLab is only a button that delivers your page to the Web site. I would much prefer that Adobe build BrowserLab’s functionality into the Dreamweaver application–after all, it is Internet-connected in so many ways–but Adobe says that, if BrowserLab were to be built into Dreamweaver, it would have to deliver a new screenshot every time you make a change in your design–times however many browser versions you’ve requested–and the cost to maintain such a service would be prohibitive. I don’t have a great answer for that, but I have to think that one day there’ll be a better way. For now, BrowserLab addresses a need sufficiently, even if it is a kludge.
Furthermore, if you’re tasked with developing HTML newsletters, neither the updated Live View nor BrowserLab will help you in the least. Not only must you worry about how your newsletter looks in desktop applications such as Outlook (and its past versions), you must worry about how it looks in the various online email services–Yahoo Mail, GMail, and so on–and how those services mangle HTML in various browsers and operating systems. A couple of email clients–Apple Mail and Entourage 2008–rely on WebKit, but the vast majority of them do their own thing, and Dreamweaver CS5.5 plays see-no-evil with them. Adobe’s response is that Dreamweaver’s primary duty is to help you create Web sites and applications for desktops and mobile devices, not newsletters.
One of Dreamweaver CS5.5’s new Internet-connected features is its live W3C (Worldwide Web Consortium) code validation service. Dreamweaver already had a code validator, to identify HTML coding errors or code that won’t work in certain browser versions, but it was built into the application. The W3C has a code-validation service on its Web site, but you have to copy and paste your code into it, get a report, then go back to your code and try to find the right line numbers. Dreamweaver CS5.5 sends your current page’s code to the W3C and reports any errors in a window; you can then click on an error report to be taken directly to the line with a problem. It’s a convenient timesaver.
Mobile Web sites, mobile apps
You can build a mobile-specific site from scratch using Dreamweaver’s new jQuery Mobile templates and associated jQuery components library. The heavy lifting within these pages is done with JavaScript; jQuery is a form of JavaScript that lets you string multiple commands together, rather each on its own line, in sequence. Because Dreamweaver CS5.5 ships with a library of jQuery components and commands, weak coders like me can often get by browsing this library and simply inserting them, and possibly modifying the code that it generates. Furthermore, if you do need to generate raw jQuery code, Dreamweaver now offers jQuery code hinting in Source Code View.
But even if you’re not ready for that level of JavaScript programming, you’ll still go a long way in developing a mobile-friendly site with Dreamweaver CS5.5’s new Multiscreen Preview feature. You use a dialog box to specify screen sizes–for example, one for a low-resolution phone, one for an iPad, and one for a desktop–and Dreamweaver inserts meta tags with the sizes into your HTML code. Then, when you choose Multiscreen preview, you see your page in various sizes in a window. You can specify specific style sheets for each screen size, so that your content fits properly in them, and you can see that it fits when you look at the pages in Multiscreen preview. Genius!
Even more awesome: A new feature lets you package up a version–presumably one you’ve designed for a mobile screen–and create either an iPhone app or an Android app from it. Dreamweaver lets you download the latest iOS or Android software developers kit (SDK) with the click of a button, and then it’s only a few steps to build your app; you can even incorporate phone-specific functions that use devices’ GPS and even accelerometer features. The Dreamweaver dialog lets you specify a .png file for use as your application’s icon, and it will scale and otherwise process that image so that it conforms to the respective platform’s requirements. Dreamweaver does not provide explicit instructions on how to transfer your app to a phone or to iTunes or an Android app market, but I found easy instructions on how to do it (Adobe says it will soon offer video tutorials on its Web site covering the subject).
The only problem with Dreamweaver CS5.5’s app development features is that, if you’re on a Windows PC, you can’t output an iPhone or iPad app. This problem is not Adobe’s fault: Apple does not offer a Windows version of its iOS SDK. You also have to keep in mind that, for really heavy-duty apps–Angry Birds?–you’re going to need more than just Dreamweaver, but it’ll work perfectly if all you want to do is to create an app version of a mobile Web site.
Mobile-ready, mobile-friendly
If you’re tasked with building a mobile Web site or a mobile application, Dreamweaver CS5.5 could be a savior, especially if you need some handholding along the way. Its clunky integration with Adobe’s BrowserLab won’t help you deal with browser support issues as much as it could, but Dreamweaver CS5.5 is still a powerful, innovative application.
