Designers read this and developers will love you(photoshopetiquette.com)
photoshopetiquette.com
Designers read this and developers will love you
http://photoshopetiquette.com
66 comments
Now I am going to get killed for saying this but it's almost like you are referring to Microsoft Expression Web or something to that effect.
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.
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.
I would love for this hypothetical tool to exist, but the problem doesn't lie with the tool, but that you're talking about essentially different workflows. Designers tend to use the tools that they're most familiar with, that give them what they need. Usually that means Illustrator + Photoshop (or sometimes, Fireworks).
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.
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.
I'll take a stab at this.
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.
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.
Note to interested developers... there is a HUGE market for a disruptive tool in this space. If anyone is interested in working on such a tool, I'm game.
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.
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.
The Illustrator-style layer selection is enough of a reason to use Fireworks over Photoshop. You spend more time trying to navigate the layers in a PSD than actually designing. Drives me crazy.
Check this first: http://www.pixelmator.com/ - works like a lighter/prettier Fireworks, currently only 30 bucks, and no annoying licensing thingy. Mac-only, but most designers are on mac anyway.
I'd like to talk to you about this. Drop me a line on gmail, it's jayson.elliot
Some designers would love to use this tool you speak of.
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.
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.
These are basically the same things that make good code.
• Organising files = project structure
• Resource & layer naming = variable naming
• Using templates & sharing common elements = DRY
• Keeping vectors when rasterising = keeping source code when compiling
• Minimising filters, blending modes, colour overlays, etc. = KISS
• Grid = idioms and “design patterns”
• Understanding licensing = understanding licensing
• Proofreading = code review
• Browser compatibility = platform compatibility
• Conservation of file sizes = consideration of performance
• Organising files = project structure
• Resource & layer naming = variable naming
• Using templates & sharing common elements = DRY
• Keeping vectors when rasterising = keeping source code when compiling
• Minimising filters, blending modes, colour overlays, etc. = KISS
• Grid = idioms and “design patterns”
• Understanding licensing = understanding licensing
• Proofreading = code review
• Browser compatibility = platform compatibility
• Conservation of file sizes = consideration of performance
Thank you so much for this, I'll forward the link to a couple of developers I work with and I always have to explain how things should be done.
The last design I got was in pdf! :S
The last design I got was in pdf! :S
In the USE LICENSED ICONS/PHOTOS, try this first:
http://flickr.com/search/?l=4&q=hamster
support the Creative Commons!
http://flickr.com/search/?l=4&q=hamster
support the Creative Commons!
"content requiring attribution"
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.
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.
Attribution doesn't necessarily mean it has to be in the users' face, just ask her/him if a line in the footer or in a credits page or even just in the source is OK.
A 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.
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.
Absolutely agree. Initiative should be software agnostic. Currently it looks like "Use separate css file instead of inline styles to control you table layout and developers will love you". Also, who gives developers PSD files anyway?
I like the content - but not the tone - it’s just a bit too snarky to send to a designer that you have to work with. Particularly if she’s getting much of it right - and you’ve clashed over this stuff before.
Totally agree! I was hoping to have something to send to a few of the designers I work with, but the tone is totally insulting. (ie "Nice try!")
I started to bookmark it because of the idea, but once I started reading the descriptions, I cannot agree more. I would be offended if someone sent this to me.
Can 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.
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.
That's a good description. Layer comps are one of the most underutilized PS features IMO.
I've used them myself to design alternative navigation styles for a site. For example, since the bulk of the site is the same, I managed a sample horizontal navigation in one layer group and a vertical navigation in a separate layer group. Layer comps allow you to progress on these simultaneously.
I've also used them as "snapshot" states before if I'm trying something experimental. It's a faster way to rollback than a chain of undos, etc.
I've used them myself to design alternative navigation styles for a site. For example, since the bulk of the site is the same, I managed a sample horizontal navigation in one layer group and a vertical navigation in a separate layer group. Layer comps allow you to progress on these simultaneously.
I've also used them as "snapshot" states before if I'm trying something experimental. It's a faster way to rollback than a chain of undos, etc.
Wonderful list, the only thing I'd add is to convert a PSD to sRGB before handing off if using a different color space.
Regarding export: the Monitor Color vs. Document Profile popup: http://photoshopetiquette.com/#exporting unless I'm mistaken, this only pertains to the preview of the optimized image within Photoshop.
And if you must embed a color profile on export, save it for photos only.
Regarding export: the Monitor Color vs. Document Profile popup: http://photoshopetiquette.com/#exporting unless I'm mistaken, this only pertains to the preview of the optimized image within Photoshop.
And if you must embed a color profile on export, save it for photos only.
I 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.
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.
I don't think a lot of people are still slicing up photoshop mockups? At least I hope not as the need for it should be fairly limited with CSS3.
In practice much of those go away with -- we need to support ie7 (or even ie8).
Sadly.
Sadly.
css3pie[0] fixes most of that!
[0]http://css3pie.com/
[0]http://css3pie.com/
Sorry, I'm not very proficient with CSS3 yet – you can create drop shadows along the free form outline of png images?
Well you can't create PNG images with free form outline I'm afraid (if I'm understanding you correctly, you're talking about ignoring the transparant parts of a png right?) so that won't be possible, the drop shadow would just wrap around the actual outlines. Although it is possible to apply a border radius to your png and add a drop shadow to those, so rounded corners or circle pictures should work.
But yes, if you have actual free form outlines you would want to shade you'll have to resort to adding them to the PNG, but for most elements we can use CSS.
But yes, if you have actual free form outlines you would want to shade you'll have to resort to adding them to the PNG, but for most elements we can use CSS.
[deleted]
Here are comparable thoughts in a more approachable, useful, and digestible manner -- http://methodandcraft.com/articles/streamlining-the-handoff.
FYI its impossible to read on an iPhone, since the sidebar blocks the view. I tried to click the buttons on top, since they like close/hide buttons, but no reaction.
All that work to create a responsive layout, then they put an omnipresent, fixed position social bar that covers the text when viewed on a phone.
These also often break Page Down on desktop browsers as well. After paging, I always have to scroll up a little bit to see the line of text where I left off.
I absolutely love your sidebar. Permission to mooch? :)
[deleted]
I'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 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).
That said, I agree with many points, like naming files properly (which costs almost nothing) or careful use of blending modes (which are a lot of pain for the developer). Or careful use of gradients, especially over repeating patterns (#22).
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).
That said, I agree with many points, like naming files properly (which costs almost nothing) or careful use of blending modes (which are a lot of pain for the developer). Or careful use of gradients, especially over repeating patterns (#22).
"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 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.
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.
Most places I know of are moving away from a the designer and frontend developer positions.
Is just in regards to bare HTML/CSS or JavaScript interaction as well? I’d think most companies would be hard-pressed to find a designer that could write in the full HTML/CSS/JS stack needed for webapps these days and be equally competent in interaction or visual design – as ironic as that sounds – in which case FEDs are still very important in the process.
Is just in regards to bare HTML/CSS or JavaScript interaction as well? I’d think most companies would be hard-pressed to find a designer that could write in the full HTML/CSS/JS stack needed for webapps these days and be equally competent in interaction or visual design – as ironic as that sounds – in which case FEDs are still very important in the process.
You'd think that, but I've met some very good designers that can work that full stack. The world is changing and people need to upskill or get left behind.
HTML/CSS is not that difficult. Even jQuery is pretty simple. Good jQuery is hard. Good Javascript harder still.
HTML/CSS is not that difficult. Even jQuery is pretty simple. Good jQuery is hard. Good Javascript harder still.
I also think developers are getting much savvier about design, and the tools helping developers with design are getting better and better. So the person who winds up doing all the design/html/css/js may not be the person who started out as the designer. So designers, by all means, harvest that fear and push yourself to learn some new skills.
But then such designer is not a target for this "Manifesto".
BTW, I see value in having one person create designs as HTML files, but I also know a lot of designers who create beautiful, graphics-rich designs and don't know much about code. I suppose it's much harder to find people who can do both as good as separate people.
BTW, I see value in having one person create designs as HTML files, but I also know a lot of designers who create beautiful, graphics-rich designs and don't know much about code. I suppose it's much harder to find people who can do both as good as separate people.
Graphics rich designs that don't come with the markup, aren't beautiful. Any designer that can't code his own markup isn't a designer worth having, and certainly isn't a web designer. He's a print designer who doesn't know he's obsolete.
If you can't build me a complete cross browser HTML template, a skin, for a website, you aren't a web designer. That means you must know HTML, CSS, browser idiosyncrocies, and possibly some very light JavaScript. Developers should never even see a PSD file or worry about what it looks like in IE. That's a designers job.
If you can't build me a complete cross browser HTML template, a skin, for a website, you aren't a web designer. That means you must know HTML, CSS, browser idiosyncrocies, and possibly some very light JavaScript. Developers should never even see a PSD file or worry about what it looks like in IE. That's a designers job.
> If you can't build me a complete cross browser HTML template, a skin, for a website, you aren't a web designer.
If you've found such people - great. In places I've worked it was different. And designers did exceptionally beautiful things which I really appreciate. I'm proud that I've worked with them, even if they left some mess to be cleaned.
There is some knowledge and experience needed in dealing with IE6, having CSS well organized, images optimized, adding even light JavaScript.
If I was hiring (I do not), I'd totally prefer to have two people who can together build something great, than look for one person and receive worse results.
And I'd prefer my people to do what they do best. The skillset required in designing rich graphics is different than coding.
If you've found such people - great. In places I've worked it was different. And designers did exceptionally beautiful things which I really appreciate. I'm proud that I've worked with them, even if they left some mess to be cleaned.
There is some knowledge and experience needed in dealing with IE6, having CSS well organized, images optimized, adding even light JavaScript.
If I was hiring (I do not), I'd totally prefer to have two people who can together build something great, than look for one person and receive worse results.
And I'd prefer my people to do what they do best. The skillset required in designing rich graphics is different than coding.
Hate to tell you bub, but none of that is coding. It's all simple markup, and a designer that can't do his own markup just isn't qualified, there are far too many available candidates that can to even bother talking to one who can't.
If all someone knows is making pretty images in photoshop, they simply aren't web designers, they're print designers who dabble in the web, amateurs.
If all someone knows is making pretty images in photoshop, they simply aren't web designers, they're print designers who dabble in the web, amateurs.
> they're print designers who dabble in the web, amateurs
They're print designers but definitely not amateurs.
In the end, what really matters is that the client receives very high quality work and it is cost effective for the company. I understand that not every company works this way, but I have worked for and know some that do exactly this.
I don't really want to discuss it anymore, I feel we're repeating the same arguments over and over.
They're print designers but definitely not amateurs.
In the end, what really matters is that the client receives very high quality work and it is cost effective for the company. I understand that not every company works this way, but I have worked for and know some that do exactly this.
I don't really want to discuss it anymore, I feel we're repeating the same arguments over and over.
I couldn't disagree more. Good HTML/CSS/JS code is not easy. It's hard work to make it look right for all browsers.. and these days you use actual programming languages (i.e. less/Sass) instead of CSS, anyway. It's hard work involving programming expertise to implement all JavaScript bells and whistles a modern website is expected to have. So it requires a good front end PROGRAMMER to do.
On other hand, a good designer is a creative person. They're not coders and shouldn't be expected to muck around with code. They're artists, who draw beautiful designs from blank page. The need for separation of roles couldn't be clearer to me, and I run a company that makes websites.
On other hand, a good designer is a creative person. They're not coders and shouldn't be expected to muck around with code. They're artists, who draw beautiful designs from blank page. The need for separation of roles couldn't be clearer to me, and I run a company that makes websites.
Right off I wanted to disagree about the preprocessor use for CSS. I just can't see that something like those has taken off so much that it's on the same level as something like jQuery.
But then it made me curious, I can't say that since I have no numbers and it's just an assumption. Are there any indicators of how popular tools like less or sass have become as opposed to regular CSS?
But then it made me curious, I can't say that since I have no numbers and it's just an assumption. Are there any indicators of how popular tools like less or sass have become as opposed to regular CSS?
Totally agree with you, it was the same in places I've worked.
"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."
I couldn't agree more. At this point, if you're still designing the same way you would for print (and honestly, most designers I've worked with still do), you are going to be replaced.
I couldn't agree more. At this point, if you're still designing the same way you would for print (and honestly, most designers I've worked with still do), you are going to be replaced.
Really? Most agencies I know in NYC/London/SF have a clear separation of roles.
No, the designer has to know the medium he or she designs for.
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.
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.
[deleted]
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.
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.
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.
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.
OK, you (and other commenters) are right. It was an overstatement. I agree with your last paragraph.
I'll do my work with layers like "Layer 0 copy copy" as long as they're grouped.
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.
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.
It's different than code. First of all, if the designer gets the job done without renaming layers, then it's his business. (In my experience, a lot of them don't need to name layers). Unless he hands over the design to someone else. I'm not sure how often it happens. Code is very often handed to different people. I doubt graphics need the same level of maintainability.
But anyway, that's a thing between designers, and we're talking about designer vs. developers.
The other difference is that in Photoshop you can easily find layer by using Move tool and CMD+clicking on the picture. And you can find text layers with Text tool.
But anyway, that's a thing between designers, and we're talking about designer vs. developers.
The other difference is that in Photoshop you can easily find layer by using Move tool and CMD+clicking on the picture. And you can find text layers with Text tool.
You don't rename anything, you name them correctly when you first create them. He's right, your behavior is shocking, and worse, you're trying to defend such bad practices.
Sorry to be shocking :)
I defend them because they're paid to do beautiful work and lack of layer names was never really an issue for me. Maybe just a couple of times. If the mess they left would be too big for me, then I'd complain. As long as I can deal with it, it's their decision whether they name layers or not. I definitely don't need every layer to have a name.
I defend them because they're paid to do beautiful work and lack of layer names was never really an issue for me. Maybe just a couple of times. If the mess they left would be too big for me, then I'd complain. As long as I can deal with it, it's their decision whether they name layers or not. I definitely don't need every layer to have a name.
You say this now, but unless you have crystal ball you can't look into the future. I've worked in many places where something is designed, shelved, resurrected several months later, design tweeked, shelved, budget approved, resurrected...
Anyway, we're not talking about a thing between designers alone, we're talking about the fact that a lot of designs are passed on to developers to then code in html. You yourself highlight the fact that designers may not be familiar with browser incompatibility. We they can't factor these into the design then IMO it's pointless having them create the html.
That said, I agree with many points, like naming files properly (which costs almost nothing)
So naming files costs almost nothing nothing, but naming a layer correctly in the first place is a pain in the arse/takes up too much time... not much consistency to your logic here. As I recall, hitting F2 will take you into rename mode.
As gnaritas says, name it properly in the first place then there is no need to rename!
Anyway, we're not talking about a thing between designers alone, we're talking about the fact that a lot of designs are passed on to developers to then code in html. You yourself highlight the fact that designers may not be familiar with browser incompatibility. We they can't factor these into the design then IMO it's pointless having them create the html.
That said, I agree with many points, like naming files properly (which costs almost nothing)
So naming files costs almost nothing nothing, but naming a layer correctly in the first place is a pain in the arse/takes up too much time... not much consistency to your logic here. As I recall, hitting F2 will take you into rename mode.
As gnaritas says, name it properly in the first place then there is no need to rename!
> not much consistency to your logic here
It is logical, because there are often hundreds of layers and presumably even more during the design process. Naming each one is a lot of work.
There are much less files in the end so it's totally different.
It is logical, because there are often hundreds of layers and presumably even more during the design process. Naming each one is a lot of work.
There are much less files in the end so it's totally different.
I don't find it shocking at all. That's what groups are for. Unless there are dozens of layers then a proper group name is all you really need. It's inefficient to name every layer of a group when there's only a handful of layers. Especially when sometimes the thumbnail of the layer gives an indication of the contents.
Look at it in terms of arrays; sometimes you use an associative array and sometimes you just go with simple index numbering.
Look at it in terms of arrays; sometimes you use an associative array and sometimes you just go with simple index numbering.
This reminds me of a problem I've pondered for a long time now, without coming up with an answer. Why are web pages designed with Photoshop in the first place?
Photoshop was never meant to be used for web design, any more than Visio was meant to make wireframes. It's simply the best tool available for the job, and requires a lot of workarounds and good behavior on the part of the designer.
Spending days or even weeks designing Photoshop comps that then have to be cut up, converted, and manually translated into suitable graphics for coders to work with is inefficient, and often leads to final products that don't match the designer's work. Text is the most obvious example, but I'm sure anyone can think of myriad places where this happens.
Is there a tool that lets designers think about the structure coders will have to build WHILE they're designing the screens? I'm not talking about a WYSIWYG code generator—those have been tried over and over again, and they all suck. I'm talking about a tool that lets designers design, lets coders code, but helps the designer think about what the coder will have to do with the graphics, including keeping text as text, identifying UI elements that need to be reused, seeing how layouts will look when the browser resizes, etc.
If this tool doesn't exist, it sure would be a great project for someone to build.