The Problem with Fireworks

Khoi

19 years ago

Every time I complain about Adobe Photoshop’s handicapped suitability for web production, people tell me to give Macromedia Fireworks a try, so today, I finally did. I spent a few hours in the program re-creating a layout that originated in Photoshop, and, after acclimating myself to the new application’s interface, I was generally pleased. It is indeed faster and more flexible in terms of shifting elements around, and it does in fact match a web designer’s frame of mind better than does Photoshop — I’ll almost certainly use it as the primary comping tool for my next project. However, I’m still not completely sold on Fireworks as the solution for all the problems that web production presents to a designer.

Face the Fireworks

To begin with, I’ve never felt entirely comfortable with the interaction quality of Macromedia’s user interfaces. They’ve always felt a bit shaky and slightly unpredictable to me, and to be honest, I’ve just got a predilection for Adobe’s interfaces, which have always seemed reliable and stable (at least until recently). For example: the way Fireworks’ layers palette functions, the way it responds to mouse-clicks, and the latitude with which it allows me to manipulate the layers — these things are not bad, but I’d much rather just have it function exactly like Photoshop’s layers palette. This is at least one reason to look forward to the fruits of the pending Adobe/Macromedia merger, but that doesn’t do me a lot of good right now.

My bigger problem is that Fireworks — and web design applications in general — remain too exclusively focused on single documents to be as useful as they really need to be. Combine Fireworks with a truly robust database that can keep track of objects and pages, and the result might be something much closer to what I want. The trouble with this approach is that doing so starts to suggest site management and from there, it’s a very short leap over to offering — and perhaps emphasizing — code production features, too. I imagine that, in the conference room of any software company, it would be very hard to argue for the R & D budget for a web tool that doesn’t produce any actual HTML.

Design vs. Code

To be fair, combining design and coding functionalities is a strategy that software publishers have more or less left behind. The line between web design and coding may be blurry, but the way the market has shaken out, virtually all of the advancements we’ve seen in this area have focused on the development of code, usually at the expense of tools for design. (Even Fireworks has seen scant improvements in the past several years, and I don’t count Macromedia Dreamweaver, which I’m not sure anyone should seriously use as either a comping tool or a production-ready coding tool.) To be clear about what I’m saying here: there’s been very little progress in the tools to enable just the visual design of interactive media.

In an ideal world, comping Web sites would be the very same act as developing semantically correct XHTML and CSS, and there would be a host of programs on the market that would enable this act. But I’m pragmatic enough to realize that such a union of sensibilities requires too major a leap forward in the ability of design software to accurately interpret a designer’s intent, and to balance that intent with implementation issues. We᾿re not nearly there yet, and I’ll forgive Fireworks for lacking XHTML knowledge entirely.

All of which is to say that there’s an idea in my head for a perfect production tool for the practice of web design — the rapid visual conceptualization of how interactive solutions might look — and it looks something like Fireworks, and maybe something like Adobe InDesign and Microsoft Visio too… but I don’t expect to see it on the market anytime soon, unfortunately. However, that doesn’t mean I’m going to stop talking about it.