Recent Blog Posts

I have been falling behind in my opinions and outrage because I am spending all my time formatting the book. I think it's starting to look believable, though: The rest of my time is panic about the Design for Mobile conference, making presentations and workshops, and... well really, slacking off on way too other stuff. But it's going well so hopefully in just a few days I'll be done (ish) and can move back to my normal level of panic.

I am still too tired from my "vacation" to work out the implications and put my own useful spin on it, but I really like this post from Timo Arnall of the well-known Graphic Language for Touch PDF.

I think we can all play along at home. Even in the US, where I no longer carry a door access card, and there are essentially no (I don't have one) touchless payment schemes I can, sitting at my desk, touch a surprising number of PAN-range and smaller (Bluetooth, NFC, etc.) devices, aside from WiFi, various cellular mobile telephony networks and 70cm LMR. My car keys have a radio bit in them.

What if, instead of waiting for the next big thing, they could all work together now? I'll bet if this sort of visualization could be revealed to the general public they would insist it stop, or some more direct, transparenty use be found for all those radios.

I'm having a busy April. Here's my current speaking schedule:

April 2 — WIPJam Day for Developers at CTIA: Making Apps Interactive & Addictive

April 16 — CHI Atlanta: Top 10 Things a Web Designer Needs to Know for Mobile April 17 - Full day workshop: Learning Mobile Web Design

April 20-22 — Design For Mobile: Gesture Design For and With Mobiles and A Foolish Consistency

The picture? It's gratuitous. I like it. Alison brought in huge fresh-picked blackberries to our office. Not recently, no.

We’re on holiday this week, so we’re only checking in intermittently. However, I’ve got the chance to catch up on some back reading (as this reduces my stress this does count as a vacation task) and wanted to point out some interesting tidbits.

The Nokia Magnifier is free software that lets you use the camera as a virtual magnifying glass. I love the concept, though I’m amused that devices that have notoriously small text are being used to magnify text elsewhere.

One of the best story-tellers in the mobile phone strategy business is Tomi Ahonen. I got from him that joke (parable?) about how to tell your age based on your text use. While I don’t always agree with his statistics or reasoning, he’s a great person to pay attention to. Last month he posted My Master and Me: Confessions of a Mobile Phone; it’s a good read. Do be sure to look for the points of failure in a typical phone day that are taken in stride.

Ajit Jaokar has started talking about the Internet of Things and the technologies needed to make it happen. He’s not the first to write of this, but his words have a lot of visibility in the industry. And I think this sort of “Internet” is emerging already.

Okay, I’ve got much of that cleared off my plate. Back to vacation.

I use the Gmail app on my n95 quite a bit; not like some folks, but still a few times a week, and typically somewhere I don’t have the laptop or other internet access. I increasingly use the “phone” as a full-on mobile computing device. In fact I’m using it to type this post as a draft as I’m out to dinner (Alison is used to me not paying attention, and just drinks more instead).

The phone has a file system, and most of the apps that I’d want to support this behavior it either came with or were a snap to find and install. But Gmail does not really support this in one key area. I often want to at least look at attachments (ideally, add, modify, etc.), but this is functionally impossible.

This is sad – and a good design lesson – because the Google folks apparently tried too hard. See, they made preview modules within Gmail. That are kinda awful, yes, but mostly bad because they are the only way to view attachments. And this is particularly sad to me because they actually spent the time to make this, whereas the let-the-phone-handle-it system comes for free.

While the gmail team did a lot of things right in mobilizing (not miniaturizing) their desktop web interface, they went overboard on the mobile and missed the most likely context, which seems to be that any phone which can install the gmail app can install other apps, and probably has a file system. I’m talking about “smartphones,” and a perception problem we encounter a fair amount around here: that while my blackberry/winmob/iphone is brilliant, frankly everyone else is an idiot and carries some stupid featurephone. And they need all the help that we can give them.

My phone, as the examples demonstrate, has a terrific PDF viewer. The Gmail viewer throws up a plain-text version instead. A few times I have wanted to review something in Word (or worse, Word Perfect, still used by the DOJ and a few others) when I am out of the office. I actually have QuickOffice, which should let me read anything at least a little. But without the ability to download from email I cannot get to the file in any useful manner.

Your customers might be similar. Some are going to be on five year old phones with no features and memory. Some are going to have the latest and greatest. Most will be in the middle somewhere. And with increasingly more capabilities by default (the line for what defines smartphone is a bit fuzzy these days) it’s a lot more about context, not of device capabilities, but of the user and what they expect their device to do for them.

Okay, enough being mean to Google. Lots of apps do this, just in subtle ways. Or so, so, very badly I de-install them within three days. When deciding how actual people will use your product, don’t make assumptions off the top of your head, or think of how you (road warrior!) and your mom (safety user!) use the phone. Go look up research on it. Make sure it’s recent, accurate and about your customers or at least your locale. Hire someone (yeah sure, like us) to help you understand where customers are today. Try to plan ahead, so there’s time to actually perform your own research, and see what your customers really want. It’ll (usually) save you money in the end, not just from happy customers but directly in lower development, test and deployment costs.

I can see the thought process in providing the previewer because I have helped execute this sort of mistake in the distant past. Adding features is not always a good thing, so spend the time to understand your true goals, and your users so you can deliver what is needed, built the right way, and no more.

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.