Responsive mobile design: implementation tips

The main principle of responsive mobile design is to adapt the presentation of the content to the current context. Let’s take a look at the redesigned item details page in the latest release of Android Market client (shown here are Galaxy Nexus, Iconia A100 and Xoom):

In order to take advantage of the available screen estate, the layout and styling of different elements differ between the various size ranges (with two switching points at 600dp and 800dp). The thumbnail becomes progressively larger, application title and developer name are displayed with different foreground colors, the rating stars move from the byline section into the summary section in left column and the overall styling of the top banner is different.

Having three different layout definitions for the same page can result in a lot of duplicate resources and Java code. To prevent this from happening, we strive to follow these two guidelines:

• Use include and merge tags to extract common pieces of layouts for reusal. For example, all three layouts above have the same inner layout for screenshots, +1 and description sections (and many others not shown here). Having a single definition means less maintenance and simpler bug fixes.
• Use the same android:id values for elements that display the specific content, even if they are located in different parts of your layouts. For example, the text views that show the application title and developer name live in layouts that are not reused across the different representations – due to different target designs. However, the Java code that populates the values does not have to be aware of the layout differences. Using the same android:id means that you can use View.findViewById() API and confine the differences to XML files only.

Support for multiple presentation buckets is implemented with the resource selectors introduced in Android 3.2. Earlier implementations of large screen support in Android Market client used the -w resource selector, switching to two column representation of the details page at 1000dp (depending on the specific page). A new, more compact layout for the two-column representation allows us to switch as early as 800dp, with an additional switching point at 600dp to take advantage of the available width for better layout of the summary section. Instead of using -w600dp and -w800dp, we use a combination of -w and -h. Here is why.

When you identify the target layout (in our case two-column layout with different scrolling points in the columns), when you identify where does each piece of your content go, where you create the visual language for styling the content and finalize the pixel-perfect metrics – this is when you identify how much space do you need at minimum to switch to that representation. Knowing the complexity and density of the content, and knowing the visual styling of the building blocks you then decide what is the specific value where switching to the different representation not only allows the user to complete the target flows in a much more comfortable fashion, but also results in a balanced and pleasing visual appearance.

Using -w selector only ignores the restrictions imposed by non-scrollable content. In the 600dp-800dp range, the summary section is taller and remains locked. If we use this representation on a device with, say, 600*300dp viewable area, the scrolling content will take an uncomfortably small screen area. In the 800dp+ range that displays two column view, the colored banned area is even taller and remains locked as well (with action buttons in left column snapping). The same scrolling considerations apply here as well. And so, in addition to using -w selector, we “augment” it with -h:

• layout/details.xml for the default size bucket
• layout-w600dp-h540dp for the medium size bucket
• layout-w800dp-h540dp for the large size bucket
• values-w1000dp-h540dp for some additional value for extra large size bucket

A few things to note.

• The current most common hardware configuration for 7″ tablets is 1024*600dp. In landscape mode, the position of the system status bar means that applications have less than 600dp height available to them. If your target switching point is around 1024dp (and our two-column layout switching point is 800dp), the value for -h should take this into consideration. Note that things may change in the future, and the set of best practices will follow.
• Once you start using the new resource selectors, you should get familiar with the rules for finding the best-match resource.
• For example, -sw600dp will “win” over -w800dp, -w800dp-h540dp or -w1000dp even for landscape Xoom (which is 1280*800 without the system bar). This means that if you want to use a combination of -w and -h, you should use them in all folders, even when the values are the same and you think that -sw is just a shortcut. It’s not.
• As another example, -w800dp-h540dp will “win” over -w1000dp even for landscape Xoom. This is the reason to have -w1000dp-h540dp in our current implementation.

Stay tuned for more in the coming months as we continue refining and polishing the application across the entire gamut of supported devices.

Designing in iterations

While the main focus of release 3.4 of Android Market client was improving performance and stability, we also continued refining and polishing the visuals of the different screens. Instead of taking a long hiatus, the philosophy is to release often, adding new features and polishing the existing ones in every single release. Release 3.4.4 (which is now at 100% rollout target) is not an exception, and today I want to talk about improving the layout and visuals of the details page for various screen sizes.

This is how the details page looked like in version 3.3.12 (Nexus S on left, Galaxy Nexus on right):

And this is how the details page looked like on a larger screen – a 10″ Xoom tablet in landscape mode:

First (and long overdue), we’ve moved the video preview into the screenshot gallery. It used to be in its own section below the fold, unbalanced and quite awkward. Here is its new place:

Note how the video thumbnail goes into the left margin, with the left sprocket strip aligned with the content in the sections below it.

Next it was time to take a much closer look at arranging the information for larger screen sizes. The existing layout and styling were functional, but not very pretty. The location of action buttons to the right of the thumbnail made the entire left column too wide for the rest of the content, while at the same time restricting the maximum width of the thumbnail itself. This also had another chain effect – due to large width of the left column, we only switched to two column layout at 1000dips, resulting in a very sparse (and quite ugly) single column layout on 10″ tablets in portrait mode.

Our designers had a good starting point for reimagining this layout. The addition of music support in version 3.3.12 added a new type of page – music artist:

Using this layout as a starting point, the new layout for the details page moves the item title and owner into the colored banner, and the action button(s) below the now larger thumbnail:

Tracing the alignment and contents of the screenshot section, you would notice a couple of things (in addition to hosting the video thumbnail). First, the bottom edge of this section is perfectly aligned with the bottom edge of the summary block in the left column, providing nice anchored balance of predominantly image-based content. Second, the screenshots extend into the right margin, taking full advantage of the available screen estate, while the rest of the sections in the right column are restricted to improve scannability and readability of predominantly text-based content.

As with the artist page, the right column scrolls below the colored banner. However, the left column has a new scroll-to-snap behavior “borrowed” from the purchase page. The content scrolls fully, until the rating stars reach the top edge. Then, the rest of the content continues scrolling while the rating stars and the action buttons snap to remain always visible:

While full vertical scrolling, as will be shown later, is particularly relevant for smaller device sizes, snapping the action buttons to always be visible reinforces their functional importance.

A more balanced two-column layout means that we can switch to it at an earlier point. Switching to two-column layout at 800dip means that a 10″ Xoom in portrait mode looks like this (with better layout for embedded cells coming in the next Market release):

The same layout structure is used for details pages of all media verticals. Here is the details page of a movie (note the new and consistent styling of the movie preview section, with darker background extending into the right margin, and the video preview thumbnail horizontally centered in a black box that is bottom aligned with the summary section in left column):

Here is the details page of a book (note that, as with movies, a more non-square thumbnail is right-aligned with the action buttons below it). Some items have very long titles, and in this case the title extends into the right margin and, if necessary, wraps to a second line.

And here is the details page of an album (note that, as with books, the right column is mainly text-based content that starts scrolling directly below the colored banner):

A more compact two-column layout scales down well to smaller 7″ screens. Here is the details page on an Acer Iconia A100 in landscape mode:

This highlights the importance of full scrolling left column – limiting the scrolling to the area below the summary section would have resulted in a very frustrating experience. What about portrait orientation for a device such as Acer Iconia A100 or HTC Flyer?

These are 7″ tablets with 1024*600 pixel screens at MDPI resolution. In landscape we have enough space to show the two-column layout (as mentioned above, we switch at 800 dips). There is not enough space to display this layout in portrait mode (at 600 dips), but we wanted to use the little extra width that we have – compared to the phone screens – to revisit the layout of the summary section. Here is how the details page looks like on a portrait Iconia A100:

Here you see the same visual language, from layout to styling to margins, paddings and gaps. This effectively means that we have three “buckets” of screen configurations for the details page:

• Default single column layout
• Single column layout with a different look for the summary section. This is enabled at 600dp.
• Two-column layout. This is enabled at 800dp.

The numbers are, effectively, switching points of the responsive mobile design, where the presentation of the content adapts to the current context. In addition, a more compact two-column layout has the margin point of 1000dp, with only item title and screenshot section extending into the right margin. The next entry will talk about the technical aspects of implementing the switching points in the current version of the Android Market client. In the meantime, I wanted to show another element of the details page, and how it fits into these different layouts. Here, once again, is the details page on devices with small form factor (Nexus S and Galaxy Nexus):

When the user initiates the download sequence, we show a dynamic section just below the summary to keep track of the download and install process:

Instead of making room for this dynamic section on larger form factors, we show it “embedded” in the summary section for the 600dp-800dp range:

Note how nicely it fits to the right of the thumbnail, as there is no need for a full-width progress bar that will look unnecessarily wide and unbalanced. And in two column layout, the dynamic download progress is shown in the summary section in the left column, replacing the action buttons as long as the download is running:

Stay tuned for more in the coming months as we continue refining and polishing the application across the entire gamut of supported devices.

Deep dive into responsive mobile design, the conclusion

The main goal of responsive mobile design is to take your application content and present it in a way that makes the most effective use of the available context, or the available screen estate. The three most essential principles of responsive mobile design are: you have the same content, with the same logical and visual hierarchy, but the representation of the content adapts to the current context.

The main goal of this series wass 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
• 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.
• The fourth part dealt about additional, slightly more focused, aspects of responsive mobile design

The series has followed the presentation I have earlier this week at AnDevCon, and you can use the following slidedeck as the refresher reference. Stay tuned for more in the coming months as we continue refining and polishing the application across the entire gamut of supported devices.

Deep dive into responsive mobile design, part 4

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.