1. Dreamweaver (Find/Replace, FTP, Split View—seeing Design View while working in Code View, working on sites with DW templates/Contribute)
2. Eclipse (JSEclipse, CFEclipse, PHP, synching with CVS)
3. Firefox/ Firebug/ WebDev Toolbar (debugging & tweaking styles, testing standards & accessibility, debugging javascript)

Find-and-replace and ftp are hardly the main things for which DW is designed. That these are primary tasks for me in DW perhaps reflects the software’s (previous) focus on designers. CS4 represents strong attention to developer needs and workflow. It will be some time before I know if I can be as fast/effective with the new built-in tools for my tasks. I think it is likely that new features will reduce but not eliminate the need for round-tripping to more robust debugging tools. Nevertheless, it feels like someone was watching us work when they decided on a lot of the new functionality: hooray!

My Fave Efficiency Improvement Features

JavaScript Code Hints

The javascript code-hinting is far more robust than in the past, dynamically generating hints based on user-defined functions and classes. It offers hints for primitive and DOM objects and identifies syntax errors with the error line number. I love that includes deprecation indicators. The error information is not nearly as robust as JSEclipse (Adobe’s free Eclipse plugin) or the Firefox Firebug extension, which describe likely syntax errors, undefined objects, etc. I hope the team will add JSEclipse code-highlighting such as highlighting every instance of an object or method when you select one instance, or marking the opening bracket when you click next to the closing bracket.

Subversion

CS4 does not claim to offer a replacement for command line or 3rd party SVN tools, but it will certainly reduce the frequency of tool-switching. After establishing a site-wide connection to an SVN project, you can update, check in, revert, and mark conflicts resolved. Check in gives options to add, commit (with comments) and ignore. The revision history is available. You can compare to local, but you still need a 3rd party diff tool. There is an offline setting and you can do SSH connections (w?3rd party tool).

Live View, Live Code View, Split Code View

Live view rocks and is a leader on the tool-switching reducer train. Live View shows a browser-based (standards-based WebKit!) rendering of the code, including javascript events. You can alter the state of the page (e.g. click on a js-activating link), and see the resulting code changes. You can then make CSS changes to the state, watching the results as you go. Firebug has made this possible for a while, but still involves heading back to your editor to make the change you tested while in the browser. CS4 offers a vertical split view, which seems far more efficient and pleasing to use than the stacked horizontal split. Live view will also display results of server-side behaviors if the site is connected to a test server. The split code view is another gem: view different parts of the same document with the ability to scroll each part separately. (Changes can be made in either section.)

Related Files and Code Navigator

The related files feature and the code navigator each assist in navigating directly to relevant code in an external file.

DW offers links to the external files (#1 in screenshot) it has determined to be related to the open file. While it will show links to some server side include (SSI) files, I don’t think it will recognize SSI files included via a dynamically generated path. The code navigator (#2) offers a display of the files and styles affecting a line of code, including CSS files & styles, js files, server-side include files, and DW template and library files. The navigator is a quick way to get to the right spot in a related file. With the cursor in a line of code or clicked in the area in question in Live View, invoke the code navigator (through keys, contextual click or the navigation wheel (#3). The code navigator will list the files and styles affecting the given area of the document. Hovering over a style will display the definition of the style. Clicking on a style (#4) will bring you right to that line in the external file: a clear time-reducer where it works. (So far it seems there are gaps in recognition of the full cascade. I have yet to fully investigate this: it may be styles linked through @import.)

Photoshop Integration

There are fun Photoshop integration improvements over the copy & paste from Photoshop to Dreamweaver introduced in CS3 (though copy & paste is still available). You can do insert › image and point to a psd document. An image preview dialog gives file format options and a crop tool. Save the image to your site files and DW will treat it as a “smart object:” one that maintains a connection to the PSD file (but not in the HTML code). In DW, you can resize the image and maintain the connection to the PSD file, without altering the original. In PS, you can change the file, e.g. altering layers, colors, filters, etc. then update the file in DW, maintaining the file format and size you previously set in DW. You can maintain a connection with multiple instances of the original— even in different sizes and crop areas.

Try It Out

If you have CS3, I strongly recommend downloading the beta. What are your favorite efficiency changes? Do you like the grayscale icons implemented to quiet the interface?

Last week at the Adobe Summit, I encouraged the Kuler team include a tool for testing out color combinations for accessible contrast in brightness and hue so we don’t have to go back and forth between kuler and a validator, adjusting and copy/pasting values until we have a usable combination.

Kuler’s API is available and there have been some interesting results. There are a few blogs dynamically changing background colors using kuler themes. There are panel extensions available for Dreamweaver, Fireworks, and Flash. The Adobe Labs Kuler page has links to these and others. Have fun!

During a demo, Rick Treitman, of Virtual Ubiquity, said “We don’t qualify as an accessible product, but Adobe has accessibility experts and I’m sure they’ll be crawling all over it.” Here’s hoping. He described Buzzword as an “ideal tool for students” and sees “students and educators as the bulk of early adopters.” Treitman indicated that they will be looking to Adobe to implement internationalization: “We’ve architected it properly to make that happen.” Documents can currently be saved as an MSWord doc, rich text file, html, or plain text. Encryption is not currently available.

Like other web-based word processing platforms (e.g. Google Docs), you can share a document by entering someone’s email address. You can assign levels of access (co-author, reviewer, editor). You can sort your document list: alphabetically, by author, by your own roles, by last time you viewed the docs, by last time you modified them, and by file size.

A nice innovation is that the sort by file size is based on number of pages, rather than kbs. Still, I wonder what the file list is going to look like in two years when I’ve got tons of files and I want to see a list of what I’ve got shared with Joe? Can I filter more narrowly? It’s like my gmail problem with not being able to archive labels. You can’t remove a label from your list of labels _and_ keep old items labeled with the now-defunct label. So far, folders still provide the best archiving option I’ve used.

There are some strong features that would be winners if the app could be standards-based. Virtual Ubiquity picked up on how users fight with lists and offer some nice affordances (a button to skip a paragraph within a list, start a new/continue a list). (Especially useful since your context menu doesn’t exist in the Flash environment.) Working with images in Buzzword is a pleasure compared to MSWord. Tables are easy to adjust, but options are limited. The tables default to having some padding in the cells (unlike MSWord), but you cannot adjust how much. Selecting, adding, and deleting rows and columns is downright delightful.

The interactions are peppy. I work over satellite internet, and do not experience any latency. The interface design is minimalist and, at first hammering, enjoyable (if you have hands, good fine motor skills, and excellent eyesight). You won’t find complex dialog boxes with an overload of choices.

Some keyboard shortcuts work such as basic formatting and increasing of text size. However, you can not currently insert special characters. There’s no option for alternate text for images. I asked Treitman about heading levels and styles. He said, “In doing our research when you ask people if they’re using styles, 80% of them don’t use styles. They’re just too hard to use.” I did not get the impression of awareness of the importance or utility of the semantic information behind a document.

The color picker gives a sense of how small the target size is of many of the elements in Buzzword. If fine motor coordination poses problems for you, Buzzword will not be easy to maneuver.

Comments can have images in them and can be dragged into the body of the document. The comment balloon is available in the right margin wherever the cursor is. (No need to make the ‘reviewing toolbar’ visible, select text, and then insert a comment.)

I haven’t tried editing a Buzzword doc synchronously with someone else. I love being able to do that in Google docs. “See what you think of this.” “OK, I changed a couple of words–do those look all right?” Buzzword does keep a “few” versions of docs. This will probably come in handy through the early bumps of multiple people working offline and then connecting. I haven’t heard whether they will offer merge options.

Buzzword is a good example of the tension between ensuring that accessibility be incorporated from the beginning of design and the need to encourage development of innovation and creativity tools. While I know the latter is important, it’s difficult to imagine the decision to go back and start from scratch to create an accessible version of the same application.