Whenever a programmer and a designer get together they need to agree on a common language. That often involves mock-ups, aspect ratios, points, pixels and work-flow.
On a recent project we were given Adobe Illustrator files of mockups. As a programmer and knowing enough about Photoshop to be dangerous I still couldn't make heads or tails of size, grouping, locking and many other things that were blocking me from just outputting Png files. The great part about vector graphics is that you can make them any size. The horrible part of illustrator files is that I know of no easy workflow to make rasterized graphics out of a larger more complex file. Furthermore the need to keep certain elements the same size came into play and we desperately needed logically organized photoshop files.
This is incredibly frustrating situation because I need to spend time grouping, resizing, recreating and validating my assets. I just want to program and get things rolling, not roll it my own after a designer already spent good time and energy on it. To make matters a bit more difficult we are doing modern iPhone programming so we also need to account for 1x, 2x and 3x resources. If a sprite is 32x32 the 2x version would be 64x64 and the 3x is then 96x96. Therefore the actual image needs to be 96x96 or larger. It also means that the largest size of an image needs to be divisible by 3 so that we don't get gaps and incorrect sizing on various screen sizes. Therefore a large (3x) image the size of 95x95 would necessitate a 2x image in 63.3333x63.3333 and a 1x of 31.666x31.666. Since the pixel is our lowest size that simply won't work since we are then not working to the correct scale.
As an example I have a 32x32 pixel sprite animation. It is a pretty good size for 1x but a bit of a smaller target for touches. I could just use this one image for the 1x,2x and 3x but it's going to look horrible scaled up. Therefore this 32x32 image actually needs to be 96x96. For any animations or objects that have multiple image states (on/off, walking, active/backgrounded) they need to be precisely placed so that the animation doesn't look jumpy and so that multiple similarly sized objects look correct. For larger UI projects it is best to have a representative Photoshop mockup and also the elements all organized into their own photoshop files. This provides clear indicator of scale and placement from the first file and ease of creating the final assets in the second.
For my latest project I asked for graphics that were put in a very specific photoshop format. It involved hundreds of files all in their own layer folders named the final filename and also including an '@bounds' element to set the size. The @bounds element is simply a path or a vector rectangle or bitmap mask (example psds http://macrabbit.com/slicy/help/ ). This specific format is used by a great program called Slicy. This program then lets me take this large photoshop file and bump out all the png files with their correct name and sizing (1x,2x,3x). Currently it only deals with 1x and 2x files so to generate the 1x,2x and 3x we'll need a 2x version and a 3x version. Slicy conveniently makes the 1x version from the 2x. Hopefully soon we'll only need a 3x version and then all of the correct pngs will be exported.
Naming files and naming conventions are a very important thing as well. With many projects the names of things at the beginning may be drastically different than those at the end, but it is rarely necessary to rename files that will not be seen anyway. Some Photoshop experts might say that Photoshop does indeed bump out png files and there are many 3rd party scripts, but there are many gotchas including exported files named '_0001_yourName.png'. Having to rename 250 similarly named files is a pain. That is one of the main features of Slicy that I am enamored with. The other salient detail about naming is that with series of images or animations there needs to be a standardization about naming. An animation might be named 'animation_00.png' and immediately you will be keyed in that there are or may be other 'animation_' files named 'animation_01', 'animation_02', etc. That way your code can iterate through a number and have all of the animation frames played out in perfect order.
Apple has been incredibly careful to keep their iOS devices standardized. For a long time we only had 320x480. Everything could be pixel perfect because there was only one ratio 2:3. Then the 4s introduced retina graphics at 640x960. This was still an easy transition because the aspect ratio didn't change and it just doubled the pixels. Then we got a new aspect ratio, 16:9. It started with what to do with the extra length or width of the iPhone 5,5c,5s then it got a little more difficult when we toss the (still 16:9) iPhone 6 and 6+. Thankfully this app required the M7 or M8 pedometer chip so we were able to drop support for the iPhone 4s, leaving us with just 16:9 ratio screens.
This all necessitated using points for programming and letting the devices parse out our 2x and 3x graphics. The graphics world is created with points sizes, so even though we did not use the 1x graphics on this project it did define the size of a sprite. The only wrench in the works being the 6 and 6+ having different points sizes, which instead of 320x568 points we have 375x667 and 414x736 points respectively.
So, I will leave you with a few good rules when starting a designer/programmer relationship:
1. Decide aspect ratio, scaling, device sizing and naming in advance.
2. Ask for Photoshop files that are organized in layer folders and show any extra state images in different folders (button on, button off).
4. Find a workflow to get from the given designs to files your project needs.
5. Don't waste time doing things that your designer/programmer can do quickly and easily.
6. Always be friendly and succinct. Batch bug reports or requests for graphics/programming for ease of reading and quashing.