From MozillaWiki
< Gaia‎ | Design
Jump to: navigation, search

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:

Low 120 ppi 0.75 scale factor
Medium 160 ppi 1.0 scale factor (base standard)
High 240 ppi 1.5 scale factor
Very High 320 ppi 2.0 scale factor

Most devices will fall into these pixel width ranges:

Low 240 px 0.75 scale factor
Medium 320 px 1.0 scale factor (base standard)
High 480 px 1.5 scale factor
Very High 640+px 2.0 scale factor (HD smart phones)

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):

160 ppi 217 ppi 240 ppi
Scale 1.0x 1.35x 1.5x
9mm 59 px 79 px 88 px
8mm 52 px 70 px 78 px
7mm 46 px 62 px 69 px
6mm 38 px 53 px 59 px
5.5mm 36 px 49 px 54 px
5mm 33 px 44 px 49 px
1mm 6.5 px 8.8 px 98 px


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


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:

Low 4px 0.75 scale factor
Medium 60 px 1.0 scale factor (base standard)
High 90 px 1.5 scale factor
Very High 120 px 2.0 scale factor

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).

Screen Icon ppi Scale Factor Padding px Padding mm
320 x 480 60 px 160 1.0 16 2.5
480 x 800 90 px 217 1.5 24 2.7
480 x 800 90 px 240 1.5 24 2.4


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

Test Layouts