Design Patterns for Responsive Android Design

According to Andy Rubin there are about 600 different Android devices available in the market right now. Supporting all of them is impossible, right? At least that is what we see in tech blogs throughout the Internet. Funnily enough, fragmentation seems to be much bigger problem to people who don't work in Android development or have good understanding of the platform than to people who do.

iOS got a big head start when the latest smartphone revolution started. That is why building for a single device and single screen size became the standard way of approaching mobile app design. Google's response to the smartphone race was very different though. Android was build from ground up to support any screen size or resolution. Building an UI for multitude of devices requires, of course, more work than building for just one but with the platform support it isn't impossible.

Almost a year ago Google released Android Honeycomb (3.0). At that point Android was forked into two separate branches, one for tablets and one for phones. At that time it looked like Android was going to follow the same way iOS did and every app would have two versions. One for tablets and one for phones. But is that a good approach? Just look at the following devices and their screen sizes:


2.6" - Sony Ericsson Xperia Mini
3.7" - Nexus One
4.0" - Galaxy S
4.6" - Galaxy Nexus
5.3" - Galaxy Note
7.0" - Toshiba Thrive
8.9" - Galaxy Tab 8.9
10.1" - Asus Transformer


Where does a tablet begin and phone end? Would one interface be good for 7" tablet and 10" tablet?


Solution - Responsive Design
Designing for multiple different screen sizes is not a new problem. Web designers and developers have been wrestling with it for a long time. Similarities between web and Android do not end with screen sizes. When building for web we also have to take into account multiple browsers and multiple versions of each one of them.

In web design a rising trend is to use responsive design. Simply put responsive design means that the website rearranges its components when size of the browser window changes therefore providing users the best possible user experience on different size browser windows on desktop, tablets and phones.

In web the technique is based on CSS3. On Android we can use screen size selector, introduced in 3.2, to define which layout to use.


Responsive Android Design Patterns
Let's look at some options we have when we think about scalable design on Android.

In our example we have three components: A, B and C. Each of these components are build using Android's scalable layout managers and can therefore be resized to fill in all space they have. Components, in this case, don't mean single buttons etc. but complex components and panels containing multiple simple components.

Pattern 1 - Component resizing
In the most simplest form each component will stretch to fill in all room given to them. This can easily be achieved by following Android bes practices and using layout managers correctly.

As we know simply stretching components is often good enough to cover small differences in screen size but using only this approach is not good enough to cover everything. This approach will most of the time need to be combined with the other approaches.

First step to move towards more scalable UI is to find out minimum and maximum sizes of each component and therefore minimum and maximum sizes of the whole UI.

Pattern 2 - Rearranging, 2D, 3D
Simply resizing components is not enough in most cases. See this example of a phone UI simply scaled up to a 10.1" tablet screen:

It is worth to explore limits of resizing the components and note in which point more drastic measures are required.

Let's use the same example as above. There are two basic options to rearrange components to fit a smaller screen (and of course visa versa to add more content to screen). Option 1 (bellow) is the way that is most commonly used in web design. In that option components are placed on top of each other and users can access the component by scrolling. Let's call this approach 2D rearranging as the component stay on the same level.

Option 2 (bellow) is to take component C and make it accessible through navigation. This is probably the best approach to arrange hierarchical components, for example emails and email headers). A list of items in component B allow navigation to component C which will replace B in the UI when user selects an item and dismissed again by using back button. Let's call this 3D rearranging as the components are placed on different levels in the navigation hierarchy.

Pattern 3 - Component swapping
When neither of the above options are not good enough we have to swap the component out and replace it with another better suiting one. This adds much more work but in some cases just has to be done.

Sometimes we can rely on libraries to handle this for us. For example Action Bar is now provided as part of the Android library. It also knows how to adapt automatically to large or small screen.

Image from android-developers.blogspot.com

In our example above components A are replaced by A* when screen size is too small for component A to work properly.


Pattern 4 - Optional components
Sometimes components reach their maximum size but the screen still has more room and no deeper navigation hierarchy is available for us to use 3D rearranging. In this case we can consider adding optional components that are only shown on larger screens.

When using this approach it is vital to make sure that the app is still usable to its fullest without these optional components. These additional components might be purely ornamental or contain secondary information that is not required in the smaller versions.

Conclusion
Android design cannot be approached the same way one would design for iOS. Android device categories are a continuum not tablet / phone steps. If we understand how to approach the problem of design from the beginning we endup building apps that suit most of the devices much better.

Don't build two separate versions! Build one scalable one!