I was tasked with writing some basic UI guidelines for our designers.
While this is by no means authoritative, I thought it would be worth sharing:
These guidelines apply to Android specifically. Design guidelines for other platforms will be appended to this documents once they come into scope.
For Android, the first thing is to get some guideline info from the horse’s mouth. Familiarize yourself with the ‘official’ UI guidelines on the android developer documentation.
Yeah, I know you’re probably thinking, wow, those are lame. They certainly don’t hold up to the Gold Standard resource that is Apple’s Human Interface Guidelines.
The Apple guidelines are simply excellent and it is highly highly highly highly recommended that you read them. (It’s long, but worth the time )
In addition to all the great info in those resources here are a few more things to keep in mind.
Understand what it means to support multiple screens. Design for Density Independence:
The android documentation offers a lengthy article on supporting multiple screens here:
Be sure to understand the basic terms and how screen density affects your measurements and placement of your assets.
Also be sure to understand the best practices and what this means for your asset production. Keep in mind that this will often mean you will have to create bitmaps for each type of screen density.
Further reading of how these concepts apply to web views can be found here:
Keep interactive controls simple:
Avoid the use of image effects or complex lighting/ gradients that would require the use of a bitmap instead of a programmatically created asset. Keep controls simple and consistent.
When designing buttons or any other type of UI control, you should make every effort to make sure it can be drawn programmatically. Complex gradients, layering, lighting or image effects should be avoided whenever possible. You should also avoid the use of custom fonts for labels.
You should approach asset creation for controls by asking yourself these questions:
example here: http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
3. If I can’t use the Shape Drawable and I can’t really create a 9 patch image, can I make my assets into jpgs? This means no transparent backgrounds. PNG images use considerably more resources than a well compressed jpg image. You should strive to use jpgs wherever possible if your first two options don’t meet your needs.
It is very important to understand how the 9 patch tool works. Knowing about 9 patch will inform many of your design decisions.
You should think of android fonts in a similar way as HTML fonts.
There are a couple of different fonts available and they can be styled in a similar fashion to CSS.
The Android Text View supports a fairly large number of style customizations and other attributes. For a sense of everything TextView can do, see the full list of XML attributes.
You should try to keep backgrounds simple. Avoid complicated patterns that are difficult to tile, or scale. Take the same basic image approach when designing backgrounds.
Can it be created programmatically with a Shape Drawable?
How will it scale and stretch when created as a 9 patch image?
If your requirements prevent you from using a Shape Drawable you should always try to use a 9 patch background. In some cases it may be ok to create more intricate backgrounds that aren’t 9 patch friendly. Just keep in mind that this type of background will have to be re-created specifically for each device we support. It is very important to understand how the 9 patch tool works. Knowing about 9 patch will inform many of your design decisions.
The main thing to take away here is: use them sparingly! UI animations are expensive and should be used primarily to re-enforce user actions.
Try to avoid the need to have multiple assets animating at once.
Constant, looping animations should be avoided and should only be used when it makes sense to re-enforce functionality. There is a limited set of View animations that are available. They are common translate (x, y, rotation, scale and alpha) animations.
Transition animations (screen to screen) should be considered and defined by R/GA to ensure a consistent experience. Some device manufacturers implement transition animation differently, so we will have to override them to ensure a consistent experience across devices.
Because animations create such a strain on device performance, we would like to encourage an iterative approach to implementing animations. Prototyping should be done early and should start simply.
It should be expected to have to go through several animation iterations before arriving at animations that are both visually appealing and do not overtax device performance.
Also remember that most of the content will be video, which will allow for strong, stunning, beautiful animation. Don’t try to compete with that in the UI!
From a technical perspective the preferred encoding methods should be what’s listed below with the exception of video resolution.
Video aspect ratios and pixel dimensions will need to take into account the device’s resolution, it’s “native” orientation (landscape or portrait + how it will be displayed in-store)
Video Encoding Recommendations
Below are examples of video encoding profiles and parameters that the Android media framework supports for playback.
Lower quality video
Video codec H.264 Baseline Profile
Video resolution 176 x 144 px
Video frame rate 12 fps
Video bitrate 56 Kbps
Audio codec AAC-LC
Audio channels 1 (mono)
Audio bitrate 24 Kbps
Higher quality video
Video codec H.264 Baseline Profile
Video resolution 480 x 360 px
Video frame rate 30 fps
Video bitrate 500 Kbps
Audio codec AAC-LC
Audio channels 2 (stereo)
Audio bitrate 128 Kbps
In addition to the encoding parameters above, a device’s available video recording profiles can be used as a proxy for media playback capabilities. These profiles can be inspected using theCamcorderProfile class, which is available since API level 8.
Update: here is a pretty good set of guidelines from mobile marketer: