Five suggestions for Dreamwaver

25 Sep 2008

I'm a regular user of Dreamweaver, and while CS4 has demonstrated some excellent new features and enhancements, there are still several areas of the product I would like to see improved. While it may be too late for CS4, here's my top five areas I'd like to see addressed in the future (in no particular order)

1. Code hinting - JS and PHP

CS4 has massively improved the way it deals with custom JS coding - in terms of smart introspection of functions, classes and objects, and how it code hints and colours them. Brilliant! I take it as an indication that Adobe is catering not just for the WYSIWYG audience, but for the professional developer who hand codes, rather than relying on out-of-the-box widgets.

However, these currently assume that everything is done through one static HTML document, with scripts linked off it. If you use more than one JS file or a library (such as jQuery or Prototype) and want to work on a script file directly, you're out of luck because DW will only code-hint what it can see on the page. Basically, it needs to recognise that JS comes from external libraries, possibly even hosted elsewhere (e.g. Google-hosted AJAX libraries).

It's great that Adobe has recognised not everyone will use Spry, but it still needs better recognition of libraries such as the object shortcuts in jQuery like $(), which are not currently hinted correctly.

They've done it with Javascript, now I hope they can do it with PHP too. Having DW able to code hint custom functions and objects while writing PHP (and other server-side languages), from your own code or frameworks such as Code Ignitor or CakePHP would be the icing on the, er, cake.

2. Consolidate the interface

Away from editing code, the GUI for editing HTML and CSS in DW is a multi-headed beast. There are many ways of doing everything - for example editing CSS can be done through the CSS panel (which itself has multiple configurations), through an "Edit CSS rule" dialog, new Code Navigator, and through the Property Inspector (the context-sensitive panel usually along the bottom of the interface). HTML can be edited in design view via the Property Inspector and Tag Inspector, both of which offer different and inconsistent control over the HTML which is generated. Over the years, like a website in need of updating, the content and presentation has blurred together, meaning it's not always clear whether changing something in the Property Inspector will affect HTML or CSS. This has lead to compromises like the "Page properties" button which has to duplicate many of it's values for both CSS and HTML - presumably hugely confusing to the beginners this type of feature is aimed at!

On one hand, these multiple routes into everything mean it is very flexible, with lots of ways of doing things. But this strength is also it's downfall - as the interface has grown, it makes for user experience hell - for example, you can create a link and add a class it in the Property Inspector, but have to go to the Tag Inspector to add a title attribute to it. It presumably makes it developer hell for Adobe, too.

I'd like to see this distilled down to just two panels - one for HTML, and one for CSS. They should be sensitive to the document's DTD, and only present attributes that are appropriate for the document you're working on, in the context that you're working in, and alert you if you're using attributes you shouldn't or have forgotten ones which are required.

3. Improve site management

Dreamweaver's concept of "sites" is one of the key features that (to me) sets it above using separate code editors, FTP software, etc.

But when you've got quite a few sites, DW's interface doesn't cope very well. In the files panel, you basically have a long dropdown list of site names. I end up with a particularly long list, because I quite often have to create separate site definitions for different versions of the same site - e.g.

Sitename 1 [ Holding page]
Sitename 1 [ Development ]
Sitename 1 [ Live ]

I'd suggest the site management's utility and usability could be improved by:

a) Allowing sites to be grouped into folders
b) Giving each site a different icon (based on the site's favicon, just like web browsers do)
c) Instead of allowing one remote server and one local folder, allow any number of "states" - for example live, development and holding - each with their own set of paths and login details.

4. FTP

FTP is a key part of my workflow with DW, and really goes hand in hand with the Site Management functionality. It is a feature that claims to have improvements to it at every release, but to me, still doesn't compete with even the most basic free FTP software.

The main gripes of DW's FTP compared with software such as Filezilla or CyberDuck are:

  • that there is no overall progress meter (so I don't know whether I should go and grab a cuppa or not while I wait for it to upload).
  • it's incredibly slow, compared with other FTP clients - in a large part because DW only uploads one file at once, whereas others upload many files in parallel.
  • file synchronising isn't always accurate - not deleting folders that should be deleted, and not always picking up changes
  • you can only do one thing at once. While an FTP operation is in progress, you can't do anything else that involves interacting with the server.

5. Working with others

A long time ago DW added check in/out functionality - perfect to prevent files being accidentally overwritten by others, for sites where more than one person works on it.

Unfortunately, this is where DW's workgroup facilities end. Even in our small team, it's incredibly frustrating that we can't share site definitions, assets (such as favourite colours) and so on. Having these in a centralised location would also make backing them up a darn site easier!

Obviously there's no way the Adobe team can provide every enhancement that's suggested to it, and satisfy every customer is impossible - but I can't be alone in feeling these would be valuable additions.

Permalink
Share it with the world:

Write a comment

  • Required fields are marked with *.

If you have trouble reading the code, click on the code itself to generate a new random code.
Security Code: