App Development
IT & Services
Blog

Mutual Mobile Designer Guest Posts on Ericsson Developer Blog

by
Mutual Mobile
No items found.
June 14, 2011
4
Min(s)

Have you ever spent fruitless hours trying to come up with an attractive user interface design for your mobile application, one that looks good and works well across various Android™ devices? Adam Beckley has. As one of the designers at the mobile solutions company, Mutual Mobile, Beckley had to contend with many of the obstacles that the Android platform presents to designers. The variety of devices and the growing number of form factors make UI design difficult – especially difficult with the lack of design guidelines. So Beckley did something about it. He created an Android Design Guidelines document that addresses some of the key elements of good UI design in an Android environment.

Developer World asked Beckley about the background that led up to the development of the Android Design Guidelines, and to highlight some of the important recommendations in the document. Here is Adam’s view on this subject.

Android fragmentation is a legitimate fear, but a lot of that bellyaching comes from designers who are intimidated by the platform and its lack of helpful resources. I was one of those designers once, and I realised it was time to do something about it.

As a designer who cut his teeth on iOS, I have to admit that Android has been a difficult platform to take on. The number of devices, screen sizes and operating systems, combined with a scarcity of designer-friendly instruction, make the move to Android a daunting experience. After stumbling through the dark on several projects, I set out to write a set of unofficial design guidelines for Android that would help both me, and the designers at Mutual Mobile where I work, avoid the same pitfalls I’d been encountering.

It took considerable time, trial and error and the support of some extremely patient Android developers. But we finally assembled a document called Android Design Guidelines to fill the holes left in Google’s documentation and to speak to designers in their own language. I invite you to download the Android Design Guidelines, which we recently updated to include Honeycomb, the Android 3.0 Platform. (You can find the download link for the Android Design Guidelines in the More information section below.)

Whether you’re embarking on your first Android app or are charged with porting an Android app from another platform, here are some of the building blocks of the Android Design Guidelines that will steer you in the right direction.

Know Your SDK

It’s wise for designers to brush up on their technical skills before taking on an Android project. Start by downloading Android’s SDK, which you can find at Android’s developer website. The SDK isn’t the easiest thing to get working (or at least it wasn’t for me), but once you get familiar with it, you will have sample assets from which to match sizes, a handy draw9patch tool, a better understanding of naming conventions and a fun emulator to play with.

Draw9patching

When you draw9patch an image, you make it adaptable to resizing without distortion (or at least that is the hope). Draw9patching, or 9-slicing, is the action of selecting certain portions of a PNG that will be allowed to stretch and expand, leaving the rest of the image intact. Since you will likely be designing for different DPIs and screen sizes, it is important to know what images should and shouldn’t be draw9patched. When applied to a heavy gradient, for example, an element that looks great on some devices will look bloated and uneven on others. Playing with the draw9patch program can be challenging, but is usually instantly gratifying because the program shows you the results of your 9patching immediately.

Naming Conventions

Naming your files correctly is extremely important particularly when it comes to Honeycomb. Android tablets, for example, are medium density devices with extra large-sized screens. If you’re building an app that should run on both a phone and a tablet, your medium density images won’t look so good on an extra large screen. In previous projects, I would defer to three folders: ldpi, mdpi, hdpi. After researching how to get around this extra large mpdi issue, I learned that you need to call out your folders more specifically. In the case of designing for a tablet, you should name a folder something like this: project/res/drawable-xlarge-mpdi.

Android UI Elements

While the Android developers website is pretty specific about how to create icons, there isn’t much information on how to make UI elements that will provide for a good user experience. Creating an app that functions like it would on an iPhone will undermine Android’s native functionality. To create a great app, it’s important to understand when to use a menu versus a context menu, or how to standardize a fixed size for a tab bar. Menus contain high priority operations that affect the application as a whole (for example, search or settings). The options menu operates much like the iPhone’s navbar. The context menu affects a field or instance and should be avoided if possible. Context menus, while sometimes necessary, are not always intuitive. Tab Bars are tricky. Since there isn’t a standard size for a tab bar, I set out researching trends in order to define a consistent pattern. After measuring countless screenshots, the size that is most common is 320×64 mdpi.

Working with Development in the Moment

A well-designed Android application is as much up to the developer as it is the designer. Since there isn’t really a standard in Android design, you should have a conversation with Development before creating an element that may look amazing but functions poorly. Additionally, you can create plenty of elements in code, and they may even work better that way. Developers and designers may be notoriously bad at communicating with each other, so perhaps with Android we can find that roadmap to peace in our quest to create amazing applications.

Feel free to download the Android design guidelines from the Mutual Mobile website.