martymoo

How do you organize your photoshop files?

I prototype my designs in HTML as much as possible, but drawing in Photoshop is usually a precursor to digging into markup. I love looking through other designers’ photoshop files. Sometimes I’m overawed by the elaborate structures that people build with layer groups and precisely named layers. Sometimes I’m appalled that people can even function in photoshop: I’ve worked with amazing designers who don’t apparently name or group their photoshop layers at all.

I don’t know how people live like this.

I’m in the middle – I organize my photoshop files with a flat system of layer groups. I prefer broad, shallow organizational structures over narrow and deep ones: scrolling through a list is easier for me than digging through a big tree of nested layer groups. I make one layer set per “page” of the application or site I’m designing, and only add sub-groups to those layers if absolutely necessary. I try to name all my layers, but in the heat of the moment I’ll often wind up with a ton of “layer name copy 56″ that I need to rename at the end of a project.

My Photoshop files are all structured pretty much like this

A colleauge just sent me a file that has blown my mind a little – he follows a similar structure to me, but has added in visual cues for photoshop file workflow. He uses layer colors for this, a feature I’ve glanced at but never once used. It is simple and seems very effective: red layers for guides, yellow layers for in-progress, and green layers for “done”.  This seems like a very nice way to work – you can scan through the file and quickly see what you should work on without resorting to external checklists.

It seems so obvious! Does everyone do this?

So I ask you, designers of the world: how do you organize your photoshop files? Is there some better method that I’m not aware of?

A Checklist for App Assets

IBM is starting to put together a large number of apps for Android and iOS, and one thing you’ll find when producing native apps is that you produce a virtual mountain of graphics for each app: homescreen icons, notification icons, launch screens, market artwork, and on and on and on. I’ve made some photoshop templates to make producing these icons easier, but sometimes it’s hard to keep track of all tiny pieces-parts involved in submitting an app to the various app stores.

A Photoshop File  for Android App Icons – HDPI, MDPI, LDPI, Oh my!

I recently spent some time making an activity template using IBM Connections to make it easier to keep track of all these assets. Activities and  activity templates are one of the least-used but most useful features in IBM Connections. It lets you assemble a reusable, collaborative checklist that you can make a new copy of and share with people or a community. Each time I start a new app, BAM, I make a new activity from the template and I’m good to go. The template includes links to photoshop templates and official documentation from Apple and Google, so anyone within IBM is able to pick up the checklist and run with it.

I’d link directly to the template here, but sadly it’s only available inside IBM’s intranet for now. If there’s enough interest, I may rebuild it for use on LotusLive or IBM Greenhouse. In the meantime, look on and despair at the size of this checklist:

click image to embiggen!

Occupied!

It frustrates me when a design problem with an obvious solution (at low cost!) isn’t fixed. This brings me to toilets. In particular, restaurant toilets. No, not the grotty public toilets at McDonald’s that you use only as a last-resort; I’m talking about toilets at upscale restaurants all over New York City. Even more particularly, restaurants that have individual bathrooms (as opposed to a big bathroom with two or more stalls in it).

This weekend I was at Le Monde for brunch, a nice french restaurant near my apartment. I went into the bathroom and was washing my son’s hands when someone started rattling the bathroom handle and banging on the door. It’s such a universally uncomfortable feeling – you are trapped in a tiny room with a toilet and someone else is urgently trying to get in. The best I can ever muster is to awkwardly shout out “I’m in here” or something equally inane. The thing that frustrates me is that there is an obvious solution to this problem, one that airplanes and busses have used for years:

Now, was that so hard? Image courtesy of Slack12 on Flickr.

The “occupied” sign is a modern masterpiece. It is linked with the door’s lock, so it takes advantage of what people are doing already (locking the bathroom door as soon as they go in). My only guess is that restaurants think it’s tacky to have an “occupied” indicator on a toilet, but that tiny sign would make for a much more pleasant overall restaurant bathroom experience. All you restauranteurs out there take note: put these on your bathroom doors!

Objects on device are smaller than they appear

I’ve seen a lot of design comps for iPhone, Android, and iPad apps that all suffer from the same problem: they were designed on a desktop monitor and weren’t reviewed on an actual device. This is an understandable issue for people new to mobile design. When making desktop web sites, photoshop offers a nice 1:1 view of what your app will actually look like. Mobile devices are a different beast, though. Devices tend to have tighter pixel density which means that items on the device look much smaller than they do when viewing them at 100% on your desktop.

Can you see me now?

Photoshop Lies!

As an example, look at the Twitter app for the iPad. On device, the user interface is easy to read and feels nicely balanced. Take a screenshot from the device and open it up on your desktop and the same screen has a dramatically different aspect: the type feels horsey and out of proportion.  By the same measure, an illustration that looks perfect in Photoshop can prove difficult to read when viewed on the actual device.

Emulators Lie!

Worse than photoshop are the device emulators. The android emulator is the worst – while developing an app, I got into a comfortable bubble using the emulator to make sure that all the UI pieces were coming together. The problem is that the resolution shown on the emulator is vastly different than on actual devices, and what looks great on emulators winds up impossibly small in real life. Don’t trust that something is too big while using the emulator-  try it out on a variety of devices to make sure.

Testing a mobile website in Chrome is not testing at all!

My biggest pet peeve is when someone builds a mobile website exclusively testing on Chrome or Safari. Sure, they both use the same webkit engine that most modern phones use, but using a desktop browser to test a mobile site will lead to heartache in the end. Desktop browsers are very useful for debugging, but it’s too easy to get lulled into smaller tap-targets and over-dense screens. Things that perform great on chrome on a top-of-the-line desktop machine often perform terribly on mobile devices, and elements that seem to position perfectly on a desktop browser can get all out of alignment when switching between portrait and landscape orientation. Keep testing on many different devices to make sure your mobile site is striking the right balance!

Practical solutions to viewing work on-device

Testing on devices can make for a more disruptive workflow, but there are some simple tricks that can help you work more efficiently:

1. Save ful-screen PNG images and view them on the device photo gallery.
   It’s easy to do and very effective for android, iOS and blackberry and gives you 100% fidelity for sizing purposes. The downside is that you wind up saving tons of in-progress comp images, which can be annoying.
2. Use an app to get live previews on-device.
   If you’re using a mac and developing for iOS check out Liveview. It’s an app that lets you get live previews from photoshop (or anything on your desktop) onto your device. Best of all, it’s free!
3. If you’re building a web app, test it on the device browser.
   No excuses! If you want to test things before deploying on the internet, install a local web server (I use MAMP for my mac, but XAMPP will do the same) so you can look at your work on a real device.