This is the fourth part in the ongoing series about responsive mobile design. The main goal of this series is to answer three underlying questions: what are we designing, why are we designing it in a certain way and how are we implementing the target design. The first part highlighted the basic principles of responsive mobile design, the second part took a detailed look at a few examples of responsive web design, and the third part talked about the implementation aspects of responsive mobile and web design, and what is available to Android developers that want to take advantage of these principles. Today I’m going to talk about additional, slightly more focused, aspects of responsive mobile design – using smallest width resource selectors, displaying different content for the same page on different contexts and applying the high-level principles on a lower-level mechanics of a single page.

Using different resource qualifiers

The decision which resource qualifier to use to optimize the presentation of your content to the particular context should always be based on the logical hierarchy of your content, the logical complexity and density within each building block of your content, and the pixel-perfect metrics of the specific visual styling. You can use multiple qualifiers, consulting the full list with order of preference. There is no silver bullet, and as with any new capabilities provided by the platform, it takes time and experimentation to identify what works best for your specific application. Our current implementation in the Android Market client relies, for the most part, on using the -w (width dp) to switch to two-column representations of our content. As we continue refining and polishing our UX across a wide variety of device form factors, screen sizes, ratios and resolutions we will be revisiting these specific implementation details.

There are two places where we’re using the -sw (smallest width dp) resource qualifier. The first is the decision to switch to the dialog representation of purchase UI:

While the purchase UI is displayed as a full-screen fragment on devices with smaller form factor, there’s just not enough content to display it as a full-screen UI on larger devices. We went through a number of UX exercises. Replace the right column of details page with purchase UI did not feel right from the navigation perspective, as the overall system behavior of back button is on the level of either full-screen UI or the current dialog. And displaying this rather sparse content as a single-column full-screen UI with large side margins would result in a jarring transition from dense details page. The eventual decision was to show the purchase UI as a dialog.

In values-v11/themes.xml we define a style that extends android:style/Theme.Holo.DialogWhenLarge. This provides decent support for devices running Android 3.0 and 3.1. In addition, we override this style in values-sw600dp/themes.xml to extend android:style/Theme.Holo.Dialog instead. This gives us a more precise control over the decision to switch to the dialog representation of our content. In addition, using the smallest width dp as the qualifier we make sure that rotating the device while the purchase UI is showing is not going to switch between a dialog and a full-screen UI:

Another usage of -sw resource qualifier in the current implementation of Android Market client is around the fonts.

We have a small set of three font sizes that account for the vast majority of typography that you see in our application, creating a consistent typographical language across all our screens. There was an interesting thing we found as we started refining the UX on larger form factors. At first we used the same sp (scale independent pixel) values across all form factors (only defining them in values/dimens.xml). However, the font sizes that looked well on smaller form factors fell somewhat flat on larger screens. The entire UI felt weak and faint, with typography almost disappearing – instead of serving as the backbone skeleton of the entire content. After experimenting a little, we saw that we had to bump up the font sizes by 1 or 2 sps (depending on the screen size) to “get back” to strong typography. At first we encoded this transition (for all three fonts) together with the transition to double-column representations. This presented two problems. First, we have different switching points for different pages, some at 800dp and some at 1000dp. Making a rather arbitrary decision about font switch as well would have broken the consistency of our typographical language. The second is more interesting.

We found that you can find a good solution to rearrange the content from single-column to double-column representation if you properly maintain logical and visual hierarchy during these transitions. However, if the transition also involves changing the font sizes, it is by far much more noticeable, and it takes by far much more time for the eye to detect where each block moved and where do you find the specific piece of content after device rotation. This is why the transition to larger font sizes is currently encoded in values-sw600dp/dimens.xml. What does it mean for the content displayed on configurations that have between 600dp and 800dp of smallest width (for example, the 1024*600 Flyer in portrait mode)? Same thing as before – the design and implementation must be flexible enough to scale the representation based on the available space, where in this case the increased font sizes will contribute to increased visual density of the content.

Displaying different content

The main goal of “my apps” is to maintain and groom your collection of apps, and this is why the “update” and “uninstall” buttons are displayed in a prominent location on the details page. Even though you can get to the details page of an installed application from a variety of sources, we want to address the “maintenance” part of the flows, and this is why we show the action buttons in a consistent location (below the summary section).

On devices with a larger form factor, we have enough horizontal space to transition to what effectively is a master-details view of your app collection. As on a smaller form factor, maintaining this collection is the main user flow that we aim to support. In addition, we have two other major UX considerations for “my apps” screen on a larger form factor:

• Expose the main user flows – installing an owned app, accepting a new update, uninstalling an app – without leaving the screen or showing any extra UI (such as floating dialogs, for example).
• Require minimum amount of scrolling – or prevent scrolling altogether – as much as possible.

This page illustrates that different representations of the same content can remove (in a somewhat drastic fashion at times) some of the content building blocks. The decision to show a much more sparse details view of the selected app in “my apps” on a large form factor was not taken lightly, and we’re going to revisit and refine this experience in the near future. There are pros and cons to stripping down the details pane of the selected app.

On one hand, this is the list of applications owned by the current account – either already installed on the device or purchased elsewhere (web / other device). As such, we don’t absolutely have to display the full details to enable the major target flows. Displaying too much content will explicitly go against the UX considerations above – too much details is too much scrolling, and adding links to developer website, reviews or related apps is taking the user out of the current context. In addition, you can argue that you don’t need to see screenshots or full description as this information was already processed when you purchased / installed this app.

On the other hand, you can say that we’ve removed too many sections. For example, “what’s new” provides relevant information when you are deciding whether you want to update the app. And what about the reviews? Perhaps the latest update is not the great, and you want to skip it. What about the download size – did it grow dramatically in the last update? What about “rate and review” – these are the apps that i own, why not let me star them directly?

These are valid questions that raise good UX points, and as I said before, we will be revisiting and refining the “My apps” experience on larger form factors. Nonetheless, this is an example of a situation where the target user flows and UX considerations can result in removing some content blocks, or taking content blocks that are shown on multiple screens on smaller form factors and combining them into one screen on larger devices.

Lower-level mechanics

The purchase screen has four major building blocks – item summary, purchase table (including the account name), purchase button and tab container that shows additional information relevant to the specific item (permissions, terms & conditions, rental terms, …). The arrangement of content follows the logical hierarchy, and supports the decision the user is making to part with his attention, time and money. Specifically, the decision to click the “Accept & buy” button is done based on what is purchased (the summary), how am I going to pay and how much am I paying (purchase table). As the supporting information might not fully fit above the fold, some of the content needs to be placed in a scrollable container.

You can start by saying that the first three sections are very important, and should stay locked while the bottom half scrolls. This is a very bad UX decision. If you rotate the device, you will effectively push the entire tab container below the fold, with no way to even get to it. If you show this screen on a small 2.8″ device, you will effectively push the entire tab container below the fold, with no way to even get to it. And even on larger phones you’re restricting the scrollable viewport to very small part of the screen. Let’s see what happens when you start scrolling the content vertically:

In addition to having a consistent styling and layout of the summary section (same as on details page), it has a consistent scrolling behavior – it does not scroll, staying locked below the action bar. But trace what happens in the middle and right screenshots as the purchase button gets to the bottom edge of the summary section – it snaps and does not scroll anymore.

We consider the purchase button to be such an important UX element that we always want to show it on the screen, but the logical flow detailed above prevented us from displaying it above the purchase table. And so, we have three distinct scroll behaviors on this page – content that is locked, content that scrolls, and content that scrolls to snap. In fact, we consider the purchase button to be so important that it is always displayed on landscape orientation – even when the summary scrolls away with the rest of the page:

If you want to see the specific implementation details, they are available in an earlier post. However, these are minor details that follow a much more important decision on how the content is organized, and what is the scrolling behavior of different blocks – within the context of target flows.

Stay tuned for the next (and last) entry which will summarize this series.