paint-brush
Developer — Ready specifications (part 1)by@jacquesgiraudel
417 reads
417 reads

Developer — Ready specifications (part 1)

by March 2nd, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

As a developer, I imagine that you have already met <strong>UI specifications</strong> too <strong>blurred</strong> or not conform with Android guidelines leading you to <strong>useless back-and-forth</strong> with the designers. How to limit these back-and-forth&nbsp;? How to ensure that the UI specifications are ready for the development&nbsp;? In this article, I give some points to keep in head and, in a 2nd, I will propose a “Ready” checklist.

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Developer — Ready specifications (part 1)
 HackerNoon profile picture

As a developer, I imagine that you have already met UI specifications too blurred or not conform with Android guidelines leading you to useless back-and-forth with the designers. How to limit these back-and-forth ? How to ensure that the UI specifications are ready for the development ? In this article, I give some points to keep in head and, in a 2nd, I will propose a “Ready” checklist.

1) Are you aware of the target devices : smartphone, tablet, both ?

Most of the applications target both smartphones and tablets but some are specific to 1 kind of device.

Stats USA — Top 10 smartphone, Top 10 tablet : only apps existing on both smartphones and tablets (under the same package name)

Smartphone usages : mobile and during the day the week, exclusive, all ages

Smartphone only app example : a running app

Tablet usages : sedentary and evening (sofa surfing), not exclusive, older

Tablet only app example : an in-store payment app for business

2) Do you know the possibilities given by Android to manage easily smartphones and tablets ?

The directory qualifiers permit realizing specific layouts for smartphones and tablets.

The multi-pane layouts, appeared with fragments, permit combining on a same screen multiple smartphone screens (eg : list-detail screens in landscape mode).

3) Are you in a Responsive or Adaptive perspective ?

Responsive : simple layout change upon device

Adaptive : screens specifically designed for tablets or smartphones

Are you searching to optimize your product to fit more with the usages of the concerned device (smartphone / tablet) ? Have you a larger vision and are you satisfied by a simple layout adjustment ?

4) Do you have a UI charter ? How is it positioned in regard to the Android guidelines ?

A UI charter (graphical and ergonomic) permits consolidating UI rules across the application to maintain visual coherence and usability.

Guidelines are based on the Material Design, recommend amongst other things the use of the Android UI components to not lose in platform coherence, etc.

This does not mean that you necessarily have to follow them for all aspects of your app. You obviously can take some liberties but the whole can’t be too far in terms of platform coherence (impact on usability and attractiveness).

Can you identify and justify each gap then evaluate their impact on the global coherence of the app against the Android guidelines ?

5) Have you framed the screen configurations to support (min dp screen size and orientation) ?

The dp is a unit of measure independent from the screen density and so corresponds more or less to a physical size whatever the device. Then, one dp approach is more interesting than using resolution, density or screen size in inches.

The minimal dp dimensions covering the large majority of Android smartphones is 320x480 dp (1) and 480x800 dp for tablets (2).

Moreover, you have to add the Multi-Window mode support starting from Android Nougat. It is not necessary to allow it on every screen : is there an interest to use your screen with another app ? Is there shareable elements between apps ?

The official recommendations are 220x220 dp to support both standard layout splits : 1/3–2/3 in portrait and 1/2–1/2 in landscape, but also the free mode used on larger devices (tablets but also Chromebooks). If we only target smartphones, we can be less restrictive. Based on a target of 360x640 dp (min size covering the large majority of Android N compatible devices (3)), we can go for a min of 360x220 dp in portrait and 320x360 dp in landscape (4).

The landscape mode is to evaluate well. It is mainly used on tablets, not much on smartphones.

Search on gsmarena (Feb 2017)




(1) Smartphones :- for HVGA (320x480) with API >= 15, there is 139 mdpi devices (140–200 ppi) so 320x480 dp and only 6 with density > mdpi- for WVGA (480x800) with API >= 15, there is 415 hdpi devices (200–280 ppi) so 320x533 dp and only 1 with density > hdpi- no configuration superior with a superior density which lower the minimum dimensions obtained above


(2) Tablets :- between HD (720x1280 dp) and FHD (1080x1920 dp) with API >= 15, there is 43 hdpi devices (200–280 ppi) for a general minimum dimension of 533x853 dp




(3) Android N Smartphone :- for HD (720x1280), there is 12 xhdpi devices (280–400 ppi) so 360x640 dp- for FHD (1080x1920), there is 33 xxhdpi devices (400–560 ppi) so 360x640 dp too- for QHD (1440x2560), there is 18 xxxhdpi devices (> 560 ppi) so 360x640 dp still

(4) Minimum dimension Android N compatible Smartphones 360x640 dp so to support MultiWindow mode :

Images Google CC 2.5

Android Developer at jacquesgiraudel.com