A quick win:
Instead of Photoshop, which is overkill for web graphics, use Fireworks or Pixelmator.
Designers read this and developers will love you
11–20 of 67 posts
Re: Designers read this and developers will love you
#12I'm a frontend developer and I think some of these expectations make little sense. Giving a name to every layer is a lot of work and I don't care about it that much. I'll do my work with layers like "Layer 0 copy copy" as long as they're grouped. Having designer rename all the layers is a lot of work that would be better spent creatively. (Does your boss want to pay the designer for it?) Another example: "#34 Be fami…
"this is just your, developer's job" 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 hav…
Really? Most agencies I know in NYC/London/SF have a clear separation of roles.
Re: Designers read this and developers will love you
#13Can anyone expand on layer comps? Is this something that our designer can use to show different states? E.g. A list with items / a list without items (rather than 2 layer groups)
Re: Designers read this and developers will love you
#14Can anyone expand on layer comps? Is this something that our designer can use to show different states? E.g. A list with items / a list without items (rather than 2 layer groups)
In a nutshell a layer comp is a saved state for your layers. It can include any/all of: visibility, position and layer style. A combination of these should let you create alternative views for practically any sets of states provided the original layers give you what you need.
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.
Re: Designers read this and developers will love you
#15I'm a frontend developer and I think some of these expectations make little sense. Giving a name to every layer is a lot of work and I don't care about it that much. I'll do my work with layers like "Layer 0 copy copy" as long as they're grouped. Having designer rename all the layers is a lot of work that would be better spent creatively. (Does your boss want to pay the designer for it?) Another example: "#34 Be fami…
Designer turned coder, here.
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.
Re: Designers read this and developers will love you
#16There's only one advice from me - ditch Photoshop and use InDesign. Do not ever bring PSD to me. Ever.
Re: Designers read this and developers will love you
#17There's only one advice from me - ditch Photoshop and use InDesign. Do not ever bring PSD to me. Ever.
When I'm doing print design, I love me some InDesign. But I don't understand your comment.
How do you (you-you, not the proverbial "you") turn an INDD into good assets for the web?
Re: Designers read this and developers will love you
#18A quick win: Instead of Photoshop, which is overkill for web graphics, use Fireworks or Pixelmator.
A major high five for Fireworks. It's like the "object"-ness of InDesign and the "graphic manipulation"-ness of Photoshop had a beautiful baby.
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.
Re: Designers read this and developers will love you
#19I know this isn't the gospel and there is no right/wrong way to hand the files to the developers, but I was wondering if anyone else slice up all the images and organize them before handing it off to their developers?
Especially when drop shadows for images/png are involved, I tend to slice it all myself for pixel perfection and organize into appropriately file names for the developers.
Re: Designers read this and developers will love you
#20I'm a frontend developer and I think some of these expectations make little sense. Giving a name to every layer is a lot of work and I don't care about it that much. I'll do my work with layers like "Layer 0 copy copy" as long as they're grouped. Having designer rename all the layers is a lot of work that would be better spent creatively. (Does your boss want to pay the designer for it?) Another example: "#34 Be fami…
Another example: "#34 Be familiar with browser compatibility" - this is just your, developer's job. I cannot imagine expecting a designer to know about IE6 limitations (and tons of hacks and techniques to overcome them).
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.