Dear Adobe,

I beg of you, don’t let Dreamweaver go the way of GoLive. With each subsequent release leading up to its death, you added more and more design-centric features to GoLive until it basically became an exporter for InDesign. Yes, designers need tools too, but they have them already; they’re called web developers. And web developers need an advanced development environment in which to bring modern web sites to life. With your acquisition of Macromedia, you have a responsibility to the web development community to support and extend the only viable development tool left in the marketplace.

With your latest release of Dreamweaver CS3, I am seeing ominous signs that your bias towards web design rather than web development is unchanged. For starters, DW CS3 has hardly changed at all from its Studio8 predecessor. What few new features that were added pay little more than PR lip service to the so-called Web 2.0 movement with anemic support for AJAX, an non-existent support for framework based sites.

With CS3, you had an opportunity to provide a next-gen IDE that would support the creation of Web 3.0, not Web 1.5. So, I write this open letter at this early stage in the sincere hope that the feature set you choose for Dreamweaver CS4–or even a CS3 service pack–will realize this dream. With this in mind, I offer the following ten suggestions for sorely needed features and updates.

1. Framework Support
   Modern web sites are built upon frameworks like Ruby on Rails, Cake, or custom solutions. These frameworks utilize non-linear structures like MVC and templates. The IDE should be smart enough to see the page as PHP and Apache (or other language/server combos) do. This means following required and included pages, recognizing variables, functions and classes (see next), and, most importantly, rendering the pages accurately in design view (see next).
2. Accurate Page Rendering and Design View

   I gave up back in the MX days being able to use Design View to predict what my dynamic pages will look like in the various browsers. For all but the most simple of pages, elements break apart and are pushed all over the screen even on CSS validated pages. And if you have dynamic content, template-driven, or framework-based pages (see #1 above), the feature is useless. It’s time for a serious overhaul of this system. Design view needs to see the page as the web server sees it, including required files and libraries, and drawing the page accurately and using dummy content where applicable. In fact, why not integrate an emulated LAMP server right in the app?

3. More Flexible Server Behaviors
   While the built-in PHP, etc. functionality is great, working with it can be difficult, especially if you are using a custom framework. One small example, the GetSQLValueString() function is ubiquitous, and the first thing I do with every site is move this function to a core library. As part of better framework support (see #1 above), DW should recognize included files and spare me from having to delete volumes of redundant code every time I add a server behavior to a page. It should also recognize that my Connections file is included in my main settings file, or, better yet, let me specify the required connection file replacing the standard “../Connections/mysite.php” file with “../lib/settings.php” in a site preference.
4. Persistent Development Environment States
   For dynamic sites requiring log-ins, rendering a dynamic page in Design View can’t be accomplished. Yes, you can specify a GET variable on a per-page basis, but even your own canned log-in functionality isn’t GET-based, nor should it be for security reasons. Being able to log in once and set a cookie–or something equivalent to that–on a per-site basis would facilitate more robust and secure testing and page previews. Better still, provide the means to define a set of login states and dummy users on a persistent, site-wide basis. These would be selectable in Design View or preview mode.
5. Included Function and Class Recognition
   Every modern site relies upon a core set of libraries that contain custom classes and functions, not only for PHP, etc., but also for JavaScript. Dreamweaver needs to see these included files reliably and consistently and provide code coloring, tool-tips, and auto-complete capabilities just as it does for built-in or native language functions.
6. Integrated SVN and CVS Version Control Support
   It is inexcusable that Dreamweaver does not have built-in client support for Subversion and CVS. No self-respecting developer builds a site without version control, and integrating them directly into the IDE seems a logical feature.
7. Much Better Snippet Support
   Snippets are great, but the feature is unchanged since MX. The ability to assign snippets to hotkeys and buttons would be incredibly helpful. If you want to go even further, look at QuickSilver and TextExpander on the Mac for ultra-efficient ways to support Snippet use.
8. Visual Query Builder
   Like the Snippets feature, the MySQL query builder has remained unchanged since MX. A visual query builder that allows dragging & dropping of tables & fields and the creation of complex joins, order-bys, and group-bys is long overdue. Microsoft Access has had this feature literally since version 2.0 back in the early 90’s, and to this day, I fire up Access in Parallels to build complex queries. Building queries efficiently and reliably is a core task that is performed dozens of times every day when developing a site. Features aimed at better supporting this task are sorely needed in Dreamweaver.
9. Native Support for Ruby
   Add Ruby to your set of supported languages and integrated server behaviors.
10. Overhaul the Interface and Add Workflow Efficiencies
    As with Photoshop CS3’s interface overhaul, Dreamweaver could benefit from a serious overhaul of its interface that take into consideration widespread use of wide-screen and multiple-monitor development environments (for example, splitting the screen vertically instead of horizontally in Split view). In addition, tweak existing features to improve workflow efficiencies with improvements such as the ability to Sync open documents, cloak individual files, code collapsing integrated into the document save/undo structure, and improved searching (including file-level searches).

I believe I speak for many others in the web development community when I ask that you consider these features carefully and reverse the trend apparent in the release of CS3 towards designer-centric web development at the expense of those of us who actually bring the next generation of sites to life.

Regards,
Steve Stringer
Principal - Stringer Sites, LLC

Adobe Certified Expert (ACE)

Related stories:

• Review: Dreamweaver CS3: What a Disappointment
• Review: Dreamweaver Developer Toolkit: Good Idea, Poor Execution

This entry was posted on Tuesday, May 8th, 2007 at 9:03 am and is filed under Tips & Tricks . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.