in User Interface

When small features are show-stoppers

Since posting this, I’ve been working a lot with FW CS3 and have realized that some of the points I make below are inaccurate. Inline text styling is actually possible in FW. What is not possible, at least from what I can tell, is applying text styles at a level more granular than the text object. So, my love affair with FW CS3 is *not* over – we just needed a little time apart ;)

Thanks again to Alan Musselman at Adobe!

I recently wrote about how I had high hopes for Fireworks CS3, in part because of how the prototyping process had been integrated into the design process, and because of the generally increased integration between former Macromedia products and Adobe products. But alas, after having now worked with the tool for a while, it turns out that, at least for now, FW will not be added to my design toolbox. But why oh why you say? After all, with the new version, it’s so easy to sketch out some ideas, hotlink them together into pages, and post it for discussion (I was able to crank out some simple prototypes literally in minutes.)

Well, as it happens, one seemingly innocuous missing feature spelled the end of my short (but intense) love affair with Fireworks CS3: no inline styling of text boxes. Huh? Why would that be such as big deal? Well, here take a look at this example:

Sample from a Contact Us wireframe

So here we’ve got a snippet from a pretty generic contact form wireframe. Notice the privacy policy link. I was working on this wireframe and wanted to add this seemingly simple little text link. The only way I was able do it was by placing any differently styled text in its own layer. Not good if you’ve got loads and loads of these links on a page, like on a search results page, for example. Here is a snippet from a wireframe of one:

snippet of a search results wireframe

Ok, so this one is pretty crazy-busy, but even so, having this many links on a page is not out of the question. Can you imagine having each of them in their own layer?! FW apparently treats text boxes as the most granularly defined object, so for example if you want to apply a style, you have to apply it to the whole block of text. Considering how critical the ability is to control the style of virtually every character on a page is in the world of modern user interface design, I’m very surprised that FW doesn’t have better support for this, especially considering that old clunkers like Visio have amazing formatting capabilities (clunky to do sometimes, but at least you can do it.) Hopefully, better support for this will be part of a future version of FW. Or, more likely, someone somewhere will figure out a hack for getting around this issue….

  1. Hi Alan – thanks for the great feedback! I’m going to check this out and let you know how it goes.

  2. Hey Anders –

    This is great feedback for the Fireworks Team!

    Today, you can create a custom Rich Symbol that contains say a text box and use the Symbol properties panel to update the text on a per symbol basis. This means you can have multiple instances of a symbol with various properties. Say you decided to make a change to the symbol like adding a underline to the link. This will be updated across all symbols, yet each symbol will retain its own properties.

    btw- your examples above are not crazy. Feel free to contact me so I can help you do better prototyping in Fireworks with CSS in mind using Rich Symbols.

  3. I’ve definitely found myself on both sides of the to do or not do wireframes discussion, but I think it may be a question of semantics and process. I don’t think anyone would argue against the need for architect to first build small models of buildings before actually building them. But once the building has been built, that’s what will be looked at to evaluate the quality of the work and not the models. In the same way, I think wireframes still have their place as sketches and ideation/communication tools – but only for the early part of the process. So I would say that, instead of not doing wireframes, let’s learn to discard them once the design has evolved beyond that stage.

  4. Interesting. The more I think about it, the more I think interface design should be direct design — crafting prototypes of the website or device. Indirect design (like wireframes) are fine if they serve another purpose (like industrial designers’ CAD work that tests stress points) but they usually don’t. Web designers were limited to indirect design by the lack of tools and programming ability, but I don’t think that’s the case anymore due to tools like Fireworks.

    In other words, I’m starting to think we should not do wireframes any longer.

  5. This is a very good question. From my perspective, it’s not so much about replacing FW, since I actually never really added it to my toolbox – ok, it’s in my toolbox, but currently collecting dust in the bottom bin :), but more about finding the tool that I had imagined FW to be – a tool that is as well designed as FW in many other respects, and also supports the features I find critical, one of them being inline text styling.

    The short answer is that I’m not aware of a single tool out there right now that supports what I’m looking for – instead, the “replacement” will continue to be a combination of familiar (and mature) tools, such as Dreamweaver (i.e. xhtml/css), Photoshop, Flash, and Visio (Yes, good old Visio. For all it’s bugs and quirks, I think it’s a tribute to the original engineering-focused designers of this tool, in the face of the near-total lack of support by MS, that it continues to play a role in the world of UX.) Sure, there are prototyping tools out there, like Axure, Intuitecht, iRise, and Serena, to name a few off the top of my head, each of which I’ve tried, some of which I’ve used for professional work, but none of which I found acceptable. Am I maybe being too picky? Are the features I’m looking for too idiosyncratic and personal? While it might seem that way, I would say that is not the case. To get back to the original issue at hand, I don’t think the need for inline text styling is an idiosyncratic feature; in fact, I think it’s a fundamental feature. Granted, some of the other tools I listed do support inline text styling (and linking), but they’ve got their own show-stopper issues (iRise for example, is just too darn expensive, and also makes the IMO terrible blunder of using the MS Word style paradigm rather than the CSS paradigm.) As you know, Victor, I’ve been thinking about and very slowly started the process of designing my own prototyping tool (or framework) – maybe that’s what will turn out to be the real replacement :)

  6. Taking a look at FW CS3, the prototyping abilities do look great. If this is a show stopper, then what else comes close for you to replace it?

Comments are closed.