Gaia/Design/FlexibleUI

Scaling Formula for Handhelds

We are proposing a flexible UI architecture based on physical sizing which will adjust through proportional scaling once a based layout is defined. This will allow a similar if not exactly the same interaction and visual experience between many form factors.

scale factor = device pixel density / 160 ppi

160 ppi was chosen as a base number as it encompasses a large percentage of mobile devices:

• The ppi of one of the possible launch devices
• iOS: All iPhones and iPhone Touch handhelds prior to iPhone 4
• Android: Various lower end devices

Most devices will fall into these pixel density ranges:

Most devices will fall into these pixel width ranges:

Input size driven by Usability

In various usability studies it has been concluded that the minimum and optimal touch size resides between 5.5 to 9 mm, with a good average standard being 7 mm. Using the formulas above we would see this translate to (rounded up to the nearest pixel):

Reference

The iPhone Human Interface Guidelines, Apple recommends a minimum touch target size should be 44 px or about 6.8 mm at 164 ppi.

The Windows Phone UI Design and Interaction Guide (PDF), Microsoft suggests a recommended touch target size of 9mm and a minimum touch target size of 7 mm. Spacing between elements should be a minimum of 2mm. They recommend touch targets could be larger than 9 mm on frequently pressed items and items that are located near the edge of the screen as they are often prone to touch error, this would apply to items like the virtual keyboard or dial pad.

Nokia's developer resources take an even more conservative approach suggesting that touchable interface elements should not be smaller than the smallest average finger pad, so no smaller than 1 cm (0.4") in diameter or a 1 cm × 1 cm square. Minimum target sizes for a finger usable UI element are:

• 7 x 7 mm with 1 mm gaps for index finger usage
• 8 x 8 mm with 2 mm gaps for thumb usage
• List type of components should have minimum of 5 mm line spacing

Conclusion

From daily use of various operating systems it can be seen how important touch accuracy is, when using iOS its superior touch accuracy not only allows for more consumable content to be displayed (less chrome) but reduced frustration of error correction and having the need to redo tasks. Other manufacturers have opted for bigger form factors to combat accuracy, since we want to give our operating system the greatest flexibility without restricting OEMs to use 4.0”+ screens to attain average touch accuracy, touch accuracy is key. In the mobile landscape, there is a strong push for “content is king” paradigm which involves removing as much chrome as possible; large buttons are just the type of chrome we would love to reduce.

Requirements Scale Needs

Touch targets are independent of graphic size

We would need to define touch targets independently of graphic elements: 2 values need to exist in the code. ie: A button graphic is 40 x 40 px, we should be able to specify a touch target size of 46 x 46 px around the button.

Elements scale up and snap to minimum touch target sizes

Whatever the minimum touch target sizes are defined in the base scale size (160 ppi), when scaling the UI up to a larger size, each element needs to scale up to at least the minimum touch target size. ie: A button is 40 x 40 px with a touch target size of 46 x 46 px around the button at 160 ppi on a 320 x 480 device. This button will be 60 x 60 px with a touch target size of 69 x 69 px around the button at 240 ppi on a 480 x 800 device.

Percentage scaling for none interactive elements

Vector elements independent of minimum touch heights should scale up or down according the scaling factor, snapped to the nearest pixel. ie: A rule line is 2 px in width at 160 ppi. On a 217 ppi device, 2 px x 1.35 scale factor = 2.7 px but should be drawn 3 px in width.

Bitmap Images

To insure maximum quality we will need to provide (at least) 4 sizes for each bitmap image. The system should be able to determine which image to use based on device screen size / ppi.

If our base application icon size is 60 px x 60 px, we will need to provide the following sizes:

With application icons as an example, we will want to maintain a minimum touch target size and icon quantity per row. If our standard icon size is 60 px on 320 x 480 px device at 160 ppi, we’d want 4 icons across, which would allow for the necessary padding between each icon (16px or ~2.5mm).

Typography

Size should be resolution independent. Unit measurement is still TBD (could be em or mozmm), the base size will be based of points and converted to the appropriate native measurement. 8pt will likely be the base font size. The font should measure 8pt on any device, at any resolution. The system should support font scaling for user preference and accessibility needs. A user preference in the settings should allow the user to scale system wide fonts between sizes: 6pt to 12 pt.

Some additional avenues to explore

• Use of SVG graphics instead of bitmap images for ui elements.

Further Reading & Resources

• html/css implementation using bitmap and svg imagery
• looks at the details and nuances around supporting many permutations of physical screen dimensions, pixel densities, and resolutions.
• resolution independence with svg
• optimizing for high pixel densities
• Long list of pixel densities from Wikipedia
• reference for the various VGA resolutions and their aspect ratios

Test Layouts

• Sample screen layout
• Dropbox collection of test layouts and assets