Designers read this and developers will love you

The best tool, that I am aware of, that is along the lines of what you describe is Fireworks. But Photoshop is more common simply because for the longest time it was far easier to obtain Photoshop than Fireworks in a suite from Adobe. For instance, right now there are five different Creative Suites and a version of Photoshop is in every one. Fireworks is in three. Therefore, in a big enough company with various people with various production needs you could assume that everyone has Photoshop. Thus, trading files in PSD is the norm. Also, I'm willing to bet most schools have a course in Photoshop but not in Fireworks.

Plus Fireworks didn't come into it's own as a HTML and prototyping tool until recently, I don't remember the version. These days it's a wonderful tool to design graphics for just about any device and I highly recommend it. But if you've been using Photoshop expect a slight learning curve since it is different.

Do I use Fireworks? Nope, much for the reasons stated above.

Does Fireworks address the developer part you mentioned? Possibly not, it just depends. Mainly because you don't really "code" in Fireworks. I'm not aware of any tool that allows a designer to create graphics and a developer to code for the same project. Usually that's broken up between software packages with different expectations, feature sets, and goals.

Now, a software tool that allowed designers to design and coders to code in the same file that outputted valid HTML (maybe even some server-side code) would be interesting. But I think it would just generate new issues to work out as opposed to solving current workflow problems.

I think it would be better for designers to learn HTML and CSS, the basics at least. Of course in my experience the same could be said of server-side developers. As a front-end developer I'm constantly amazed at the oddities I see being stuck in the middle of the design/front-end/server-side dynamic. But sometimes it makes things fun.

When we were doing work in Silverlight (god rest its soul), there was the facility to have designers working on the design and developers working on the code.

Now, what you are referring to may be the actual Expression Web product they offer. I don't know, but it sounds very familiar to the Silverlight version.

No, I am not suggesting everyone moves to PC to use this software, I am just bringing to light the possibility the software may already exist!

We personally have no issue mocking up our sites in Photoshop then them being sent over to the developers to be sliced and used. We have never really felt this process to be in-efficient either. I think so long as the designer has a clear understanding about what the developers need then it's fine. When you have print designers getting used to web development for the first time, that's when you have problems.

This is a constant frustration for web designers. Photoshop allows you to create fantastic visual effects, but the layout tools are abysmal. Fireworks is well... Fireworks – Adobe's "redheaded stepchild" in the tool chain. It's buggy with a slow, horrible UI. While some of Fireworks tools solve some of the layout problems (nine slice scaling, better vectors, grouping), their lack of decent masking and the horrible color picker and WTF interface actually slows designers down to where it become a draw.

I've given thought in the past to a hypothetical tool that I'd love to see that does a lot of what Photoshop does. It would use a nested plaintext file structure, letting it work with a version control tool (imagine being able to diff two PSDs and know that all that changed was a label value, or a single layer being removed, rather than it being a completely opaque binary change?). It would effectively provide direct access to the advanced features of CSS, only with a nicer UI. It could be built to allow testing responsive layouts all within a single document. All this and more. It'd be great.

But designers wouldn't want to use it. It wouldn't be grounded in their essentially visual workflow. Sure, you could have intermediaries translate documents between the visual and the quasi-layout-based, but that's even more work than just having designers adopt better practices. What's more, these practices don't just benefit developers: it'll make life easier for designers too! That's what makes it such a no-brainer. Sure, some lazy or precious designers might object to being told how to do their job (nobody appreciates being told they're doing things wrong), but if you introduce these practices gently I'm sure they'll pay off.

The smoke weed and try a bunch of crazy things type of designer is pretty well served by Photoshop. You can hack things up easily, try visual ideas very quickly and then clean up your files when you find a direction that works.

Systemic designers would loooooove the tool you describe. Global control of grids, headline styles, body copy styles, form elements, buttons, links, graphic elements and scaling behavior. This is how they already think. Photoshop makes them update most of these things manually. Want to make a change to every page you are working on? Time for some tedious production work. Want to see how an idea would actually function? Too bad.

Note: Smoke weed designers are not to be underestimated. They come up with things that systemic designers never would. You might want a smoke weed designer working on your branding and a systemic designer on your web app.

That can be a real pain, design-wise and image-wise (I don't want to look cheap). Creative Commons is great, but requiring attribution means that it won't be used in a lot of projects.

Fireworks' master page is a great way to keep the skeleton of your site consistent across mocks.

I'm a huge fan of using Fireworks for mockups. A heartily second (and third, and fourth) of this recommendation.

For example, a navigation interface, complete with hover and selected states can be all done with the same text and icons (say) if you have a vector shape layer for icons, and then apply separate appearances for each interaction state.

The example you give can be done as simply as toggling the visibility of a layer you don't want to see, and moving other elements up to fill the void appropriately, then saving this as a separate comp.

How do you (you-you, not the proverbial "you") turn an INDD into good assets for the web?

Going back and renaming every layer isn't supposed to happen. Instead, the designer should name them when he creates them, preferably with a consistent naming scheme that makes sense with regard to the final medium. I did it for years (and still do it) and it works very well and isn't a waste of time, at all.

> this is just your, developer's job

Part of my daily job ,halas, consists in coding HTML emails. No matter how many times we repeat (face to face, in meetings, in internal documents…) to the designers that image backgrounds are a NO-NO behind HTML text or that emails destined to be turned into .OFTs should be as simple as possible or that there must be more HTML text than images… we always receive comps with textured backgrounds or shadowed HTML text, unnamed layers, impossible font sizes (12,72px) or whatever. When I receive such comps, I usually only have a couple of hours to do the job, or less, and I spend a large part of it arguing with the AM about impossible graphic details, undoing many silly effects and trying to find my way though a jungle of Layer 256, Copy of Layer 456…

Just like the print designer MUST know how printing works, the web designer MUST know as much as possible about HTML and CSS.

Shockingly, it's not. Most places I know of are moving away from a the designer and frontend developer positions. It's a big cost savings, not just in salary but in cycle time as well. Our designer sends us his designs in HTML. There is no bickering over fonts, no pixel perfection, no stupid photoshop-isms -filters, drop shadows, embossing, etc. I'm pretty sure he doesn't even have photoshop.

If you're a web designer and you can't do this, it's time to learn. You're a theoretical web designer drawing pictures of websites.

This might be overstated. How about "know your medium?" If you, as a print designer, were tasked to design a bag for dog food, would you Photoshop your ideas, then tell the production guy it's his job to make it work? Probably not.

As a designer, you probably don't need to know every limitation of every browser, but at a minimum, you might want to work with the programmer and understand what browsers need to be supported, and whether certain designs would require three days of CSS hacks to work in a single browser.

If you don't understand the medium, you basically create pretty pictures. That's about it.

It's no different from designing newspapers, brochures, fashion.

That's shocking. That's like me as a developer naming my variables var1, var2, var3 etc. I'll get shot if I did that and would rightly do the same to anyone else that did that.

I do some Photoshop work, mainly for personal purposes and naming those layers makes it easier for me when I need to revisit those files. Stop thinking here and now and start thinking about your follow colleague that needs to take your pile of junk on.