Little Springs Design. 2001 – 2010.

Okay, I'm making an assumption here: you want to have your application or web site work well on multiple devices and screen sizes. If you are designing for a single platform like for a corporation in which everybody is issued the same device, then you can disregard this essay. Maybe.

Everybody else, pay attention.

Stop using pixel-perfect layouts.

I'm not just talking to designers here. Development and test is equally at fault, led by team and project management that allows for – or even encourages – inefficient practices. One designer (not one of us) recently had her development team demand pixel perfect layouts for every application screen for every different Blackberry screen size... before she even had time to really work on design. One of our less successful clients refused to use the layout logic we gave them, instead using different layouts for different screens. Their product was late. And crippled.

This is not limited to mobile. Steven speaks of a time when his team built fluid layouts, and a prototypes as a way to deliver presentation markup and style; the project managers disregarded the design documents, snagged the prototype as screen captures and created page-by-page "spec docs," which is what the developers coded to and the testing team tested to. The result was slower, buggier and degraded the user experience.

It costs too much

It costs in time to market, design expense, development expense, and testing expense. It costs in user impact and market penetration. And tools like Photoshop, Visio, and Fireworks lead you straight to it.

Pixel-perfect layouts cause design problems.

We're designing interactive systems, ideally with consistent behaviors and easy-to-follow rules for display. Manual design risks accidentally violating your design principles, even if you don't forget a size, density or orientation.

• You can only guarantee that your pixels are perfect for one version of one browser on one device at one user setting. Even the iPhone platform experiences fragmentation. How much do you want to redo your work?
• You waste time designing everything, instead of re-using components.
• You waste a LOT of time designing everything, possibly months and months making hundreds of screens, when the real design work was completed in a few weeks.
• Designing screens gets you into a screen design mode of thinking, instead of systems, processes and interactions. Even if every page is designed brilliantly, it is easy to be inconsistent. Take, for example, the iPhone tendency to move around the Edit buttons or the Google tendency to have inconsistent behavior between properties. How do you suppose this happened?
• A specific device might have two orientations; a specific browser might have "full screen mode" and regular mode. Users may use a browser other than the default. Each of these will affect how the design is perceived, so each and every variation is done or you end up with some odd-looking screens.
• Pixels are different sizes on different devices, so even screens with the same number of pixels will have to be individually reviewed.

Pixel-perfect layouts cause engineering and development problems.

I once spent a lot of time working with a uiOne theme, coded by somebody else. It supported two screen sizes, with all the icons the same size. Just backgrounds and element positions were different. Had it been developed well, the code base and file structure would have had resources for one screen size, plus another 2%. Instead, it had about 190% of the code and resources size. And I found bugs in one screen size that were not in the other.

• Developers have a tendency to build pages whole, not reusing common components. Like footers.
• Complexity of development. Different screen sizes may be assigned to different developers for organizational simplicity. Each of those developers may solve problems in a different way. Bugs have to be logged against specific devices and pages.
• Complexity of maintenance. Marketing wants to add a new feature ... now hundreds of screens have to be re-designed and re-programmed, instead of just one.

If you're working in an object-oriented environment, there's absolutely no excuse for this. Different objects can have different display parameters in different conditions. Use inheritance wisely. Update objects and methods properly.

If you're working in a function-oriented environment, there is still no excuse for this. Learn the principles of polymorphism, apply them to displays as well.

Pixel-perfect layouts cause testing problems

Because there was different code for each screen size with that uiOne example above, the testing group had to test each screen size, 100%. This decision essentially doubled their effort. That's just one example, Steven has seen design decisions change test effort by an order of magnitude. Most organizations won't pay ten times the estimate for test, so your product goes out 90% untested.

The use of screen shots as a pass criterion are fundamentally broken. Few quality assurance testers are sufficiently trained in graphics to recognize the accuracy of screen shots; some, otherwise perfectly good people, have even failed to notice that a style sheet didn't load.

A better measure is rules for how the screen must be assembled. Don't look at "is the overall image the same" but "are these icons present, is the text at least 3 mm (yes I said millimeters) high, do the images have at least 3 pixels of padding, is the touchable area at least 1 cm?" How is the page built?

The design rules, expressed in good design specifications, can easily be followed by system testers. Because if the rules function for an intelligent subset of devices and screen sizes, then the rules work for all. A footer common to all pages in a site should be tested thoroughly on a few different devices, then merely checked for presence on other pages.

Pixel-perfect layouts cause user problems

Screen size is not closely correlated with device capability. The U.S. and Western Europe tend towards large screen devices, but South Africa, India, and Indonesia tend towards small screen devices. But look further (Admob data): those Indonesian and South African devices are more capable! More likely to support video streaming, for example.

When you do pixel-perfect layout, you tend to make assumptions about device capabilities. After all, you aren't even doing screen size detection (amongst the easiest and most documented of device capabilities) so you are unlikely to do other checks. You are less likely to consider orientation issues, or chrome issues. You tend to assume that because your device doesn't support streaming video, it's not worth it to support streaming video on your server.

And you certainly aren't future-proofing your design. That fancy new phone, the one that everybody is talking about? It has 300 pixels per inch and your beautiful design won't even be visible.

Use layout logic

• Avoid tools that start with selecting screen size. Adobe Fireworks, in particular, is bad for this both mobile and desktop. A simple note, from this tutorial on Fireworks for mobile...

  Fireworks makes it very easy to set the screen size. Simply select File > New and enter the height and width of the desired canvas. The canvas orientation and the resolution of the pages can be changed very quickly in a single document.

  ...sounds like a warning to us. You are drawing one screen size at a time, therefore you are designing one screen size at a time.
• Design and build layout logic, not screen comps.
• Create classes of relevant ranges of screen sizes. "Small" might be 128-164 pixels wide, with most at 128. Design in each class, remembering that smaller pixel counts are correlated with larger pixels. You can get away with smaller icons on smaller screens: they will be larger.
• Use px measurements where absolutely necessary, em measurements where possible. Plan white space.
• Follow Bryan Rieger's Effective Design for Multiple Screen Sizes on MobiForge for mobile web.
• Design for different classes simultaneously. Ensure that your vision works on all devices.
• Use vector graphics tools to help understand the effects of pixel count and size on perception.

There's more. There's always more. Steven's nearly done with the first version of his book on design process and theory (he mentions it in his portal theory post, and will have it available at his Design For Mobile workshop). We try to have the patterns in the mobile design resources wiki avoid pixel-perfect and even handle other aspects of device diversity. Or we can help you out with your whole process; contact us to get started.

This entry was posted on Wednesday, March 11th, 2009 at 7:52 pm and is filed under Business, Design, Design Tips, Mobile applications, Mobile web. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.