December 5th, 2012

Android layout aliasing

In an earlier post I talked how we restyled the “Similar artists” section in the latest release of Google Play Store app. Here is how the details page for an artist used to look like:

We display up to four similar artists (if we have that info), and using full-bleed artist images with overlayed names creates this gigantic block that completely overpowers the main artist image. It’s just too heavy, and it constantly draws your attention away from the rest of the content on this page. Here is the restyled version that provides the same information, but scales down the presentation to match its relative logical importance in the overall content hierarchy. The artist image takes half the cell, and the artist name is displayed to its right. And now we can also fit more of these cells above the fold.

Tapping on the header of “Similar Artists” section opens the full list. Cells in that list are full-bleed to provide a richer listing, where each element has the same logical and visual importance. In the absence of a more “important” visual element (such as the main artist hero image on the details page) we can go back to the full-bleed presentation:

The implementation behind these two screens is quite straightforward. We define two XML layouts, let’s call them artist_reduced.xml and artist_full_bleed.xml. The first is used on the details page, and the second is used on the full listing. But what happens on smaller devices?

The first two screens show the details page of the specific artist, and the third screen is the full list of similar artists. As shown here, the target design is to use the full-bleed cell in both cases, preserving the existing presentation. The main reason not to switch to cells that display artist image side by side with artist title is that the current presentation is already following the logical importance of that content. The main artist image takes the full width of the screen, while similar artists section displays two cells side by side. Not only each such image is smaller, the vertical position of that section and full scrolling ensure that we won’t end up with both main and related images being visible on the screen at the same time. Finally, if we switch to the new presentation, we won’t have enough horizontal space to display two cells side by side (which is, by the way, why we switched from 3 columns to 2 columns in “Similar Artists” section on album details page on larger devices). So, to continue displaying two similar artists we’d need to add another row of content, which is not an immediate UX improvement.

Preserving the existing design poses an interesting problem. On smaller devices we want to use the same layout for both usages, while on larger devices we want to switch from “reduced” to “full bleed” layout. Suppose our switching point to differentiate between smaller and larger devices is -sw600dp. Then, the first approach would be to have:

  • layout/artist_reduced.xml
  • layout/artist_full_bleed.xml
  • layout-sw600dp/artist_reduced.xml

In this approach, layout/artist_reduced.xml is a copy of layout/artist_full_bleed.xml which lays out the content as full-bleed image and overlapping title, while layout-sw600dp/artist_reduced.xml lays out the content as a smaller image in the left part of the container, and multi-line to its right. At runtime the system decides which layout bucket is used for the specific layout. For the full view that references R.layout.artist_full_bleed in its adapter it will return the instance inflated from layout/artist_full_bleed.xml. For the “Similar Artists” section on details page R.layout.artist_reduced will be resolved to either layout/artist_reduced.xml or layout-sw600dp/artist_reduced.xml based on the device.

The main disadvantage of this approach is maintaining two identical copies of the full-bleed layout in the layout/ folder. Even though we only have two child views in this cell, you still need to remember to sync any tweaks you make between the two copies. This can be addressed by extracting the content into yet another layout that has parent <merge> tag, and <include> that content in both XML files in the layout/ folder. That still doesn’t completely remove the sync problem as you still have identical parents defined in the two original files, and increases the amount of information you need to “parse” in understanding what is the right place to tweak the specific layout. Here is where we can use layout aliases.

What do we want in an ideal world? We want to define two basic layouts and, depending on which layout bucket we’re in, to map R.layout to one of them depending on which page / section we’re in. So this is what we’re going to do:

  • Define the “full bleed” layout in layout/artist_full_bleed.xml
  • Define the “reduced” layout in the bucket that is actually going to use it – layout-sw600dp/artist_reduced.xml

How do we make the code that uses R.layout.artist_reduced to be resolved to layout/artist_full_bleed.xml on smaller devices? By using this layout alias placed in values/layout.xml:

    <item type=”layout” name=”artist_reduced”>@layout/artist_full_bleed</item>

This effectively maps R.layout.artist_reduced reference to layout/artist_full_bleed.xml on smaller devices, while layout-sw600dp/artist_full_bleed.xml is used on larger ones. Any change to layout/artist_full_bleed.xml will be reflected in all places that use it without need to remember syncing it across multiple XML files.

December 3rd, 2012

Physical and perceived view bounds

Some of your Android nine-patch assets may have transparent outer areas. For example, the buttons in Google Play Store have 4dip transparent outer area for the normal state. The assets for pressed and focused states then use that area for outer glows. What does this mean for aligning such controls with the rest of the UI?

If you place such a button in, say a vertical LinearLayout and set android:paddingRight on that container, you will get correct alignment for the physical content bounds, but not for the perceived content bounds. That transparent 4dip-space on the right side of the button will push it further inside the container, while the rest of the content (which does not have that extra space encoded in its asset) will be aligned on a different perceived vertical line.

Let’s take a look at the purchase dialog displayed on devices with larger form factor:

The “Accept & Buy” button is visually aligned with the “Secured by Google Wallet” text below it. But, the actual right edge of the button view is 4dips to the right of the right edge of that text view. Another option would be to set the right padding on that text view to 4dips as well. Sometimes, if you have such a button along the right edge of the container, you would need to set different paddings / margins on the content, depending on which side of the container it aligns to. And yes, the “Accept & buy” in pressed state shows the highlight halo that goes beyond the rest of the content that is aligned to the right edge of the screen. This, however, is a better compromise than having the button moved inwards when it’s in the normal state.

Sometimes you need to consider how view / background colors blend when you’re working on perceived alignment. Here’s how the app editorial cells looked like in the previous release of Google Play Store. It’s functional, and if you open hierarchy viewer to look at the physical bounds of promo image and the blue button below it, they are at the same right edge. But the outer transparent area encoded in the 9-patch asset (for outer glow of pressed / focused state) causes perceived misalignment.

The next screen accounts for that transparent area by moving the button to the right. So now you have the right edge of the image aligning with the right visible edge of the button. But there’s still misalignment, and now it’s even more pronounced (aka the uncanny valley). In most cases the blue action button is displayed on dark grey background, and its outer white edge is quite visible there. But in this context we have very light gray fill, and the button’s outer white edge is almost unnoticeable:

Our current solution is to nudge the button even further to the right, aligning the right edge of the promo image with the inner blue fill of the button, as shown here:

December 3rd, 2012

Content presentation: logical and visual importance

Here’s how an artist page used to look like in the Google Play Store app:

And this is its new look:

In addition to displaying the section that launches Music Explorer, we also scaled down the appearance of cells in the Similar Artists section in the left column. Why?

Take a look at the first image. We display up to four similar artists (if we have that info), and using full-bleed artist images with overlayed names creates this gigantic block that completely overpowers the main artist image. It’s just too heavy, and it constantly draws your attention away from the rest of the content on this page. The second image shows how we tweaked the visuals of that section to be more scaled down. The artist image takes half the cell, and the artist name is displayed to its right. And now we can also fit more of these cells above the fold.

This highlights how the visual styling of a content block follows its logical importance in the overall hierarchy of the screen content. Here’s the same principle applied to the album page. First, this is how the album page used to look like:

And this is how it looks like now:

Once again here, we are breaking this big heavy block into smaller pieces. As we’re displaying the artist image side by side with the artist name, we switched from 3 columns to 2. This provides enough space for reasonably short artist names, and we wrap them if necessary to multi-line mode.

July 3rd, 2012

No control is an island

As we are completing the external rollout of the latest version of Google Play Store client for supported Android devices, I want to talk about the reasons behind the redesign of the top part of item details pages. Our main goal is to expose the most relevant and fresh content to our users, and make purchasing this content as quick and simple as possible.

There are multiple ways to get to the details page of the specific item – from curated top-level lists, from category listings, from search results, from shared links in your G+ stream, from the widgets and more. When the user eventually lands on the specific details page we want to do two things. The first goal is to help the user reach the decision whether he wants to buy the item, or continue browsing elsewhere in the store. And in case the user has decided to make the purchase, the second goal is to make the purchase process itself as quick and seamless as possible. The main intent behind the first part is to “support” the decision to view the item details by exposing additional relevant content that would work further towards making the user click the Buy button. We aim to help the user find what he’s looking for (explicitly or implicitly) without overwhelming him with too many choices or too much information. This also goes to support the second part – in our quest to make the purchasing experience as seamless as possible we do not aim to enable accidental purchases or skip important steps such as showing application permissions or movie rental terms. If the user decides to part with his money, it’s good for the entire ecosystem, including our content providers (app developers, studios, book publishers) and our partners (carriers), but we do not want the user to feel taken advantage of.

With these two complimentary goals in mind you can now take a longer look at the logical and visual structure of the details page. Each and every single element is there to support these two goals, with visual styling working to both present a unified look across the different blocks, as well as create a distinct separation for those blocks that are deemed crucial to achieve the goals.

The vertical order of the sections is crafted to expose the most important information above the fold – where importance is weighed based on how well it supports the user’s decision to click the buy button. This is why you see app screenshots, movie trailer and album tracks above the fold. This is why we worked on moving the app preview trailer into the unified screenshot section in the last two releases. This is why you see badges (where applicable), rating stars and +1 count above the fold. This is why the item title and creator (app developer, book author, album artist) are larger and bold. This is also why we have a distinctly styled summary section. It contains the most important information about the item – the title, the creator name, the thumbnail and the action buttons.

If we did our job right, there’s enough information above the fold to guide the user to click the Buy button. But what if the user wants to read the full description or browse the reviews? That brings him below the fold, and if the action buttons scroll away with the rest of the content, the user will have to take an explicit action to scroll all the way up once he decides to buy. This is why the summary section stays anchored below the action bar while the rest of the content scrolls. Here I’d like to point out – and I’ll return to this point later – that this design decision has a side effect. Reserving a certain amount of vertical space to non-scrollable content necessarily means that you have less vertical space for the scroll container. This means that those users who do want to read full descriptions or read user reviews will have to scroll more. By the way, you would note that the entire content, including the summary with action buttons scrolls vertically on phones in landscape mode. Here we felt that taking half of the available height makes the scrollable area too small and severely affects the user experience.

Finally, in addition to having the Buy button always there in portrait phones and tablets, note that it is styled in bright blue. Here the intent is to make it stand out as much as possible – without using kitschy oversaturated neons – so that it can be found quickly scanning up the screen.

Now that I’ve talked about what we show on the details page, why we show it and how important is the summary section, let’s take a look at how we redesigned it in the latest version of Google Play Store – the screenshots below have the previous release on the left and the current redesign on the right. Our directive was that there were two things that were not working for movies, books and music. First, the cover art for these types of items is much more complex than for apps. Second, the horizontal layout of action buttons has resulted in an unbalanced distribution of section content for predominantly short titles of popular books, movies and albums.

The first part relates directly to the goal of providing the right information above the fold to help the user reach the decision to buy the item. If we show a very small artwork for book / movie / album cover, we are working explicitly against this goal. The second part is a little more subtle. If there are two action buttons, such as Rent SD / Rent HD for movies or Buy / Preview for books, then the user has to switch from vertical scanning of the sections to horizontal scanning of the buttons once the decision to act is reached. It’s a small bump, but a bump nevertheless. And so, the request was to show larger covers and to layout the buttons vertically.

At this point it is a pure design / eng exercise to come up with a solution that addresses these two requirements and improves the user experience as measured by the explicitly stated goals and as restricted by physical characteristics of small mobile devices.

If you look at the first screenshot that compares the details page of the same book in the two designs, you will note that indeed the cover is larger and that the buttons are stacked vertically. But changing the metrics and layout of an element cannot be viewed within the tight context of that specific element. We must consider the effect it has on its immediate vicinity, as well as more far-reaching impact on the sections around it.

Making the thumbnail bigger works well with stacking the buttons vertically. After all, it was the left button that “prevented” us from making the thumbnail taller to begin with. But if we leave the metrics of the title unchanged we will have to make the entire summary section taller to accomodate the height of two buttons. That, in turn, would make the scrollable area even shorter. That, in turn, requires revisiting the decision of smaller scrollable area vs. ever-present action buttons. Making the entire summary taller was ruled out pretty early on, and the only choice left was to lose the multi-line mode on the title – as you can see in the comparison of books details page. The immediate result is that books with longer titles kick off marqueeing and make it more cumbersome to read the full title. On the other hand, you can argue that showing a much bigger cover art balances this out, as most book covers (as well as movies) use large high-contrast typography so that it can be quickly scanned among other items on magazine shelves. So here you can see how changing the metrics of one element necessarily affects elements around it, and how it impacts the parameters that influence the overall design decision on where each element goes and how much space it gets – all based on how the entire design works towards achieving the target goals.

There’s yet another, although less noticeable impact caused by larger cover art. If it’s taller, it must be wider. The vast majority of covers for books and music are oblong, and we add more height than width. But the end result is that the new larger cover art takes more horizontal space. This necessarily means that both title and creator texts have less horizontal space than they had before – you can see how much extra space is left after the specific book author name. So not only we’ve switched from three-line to single-line for the title, but we’re also giving it less horizontal space. And we’ll also have to elide the author name sooner (it was single-line before, and you really don’t want to marquee more than one element on any screen).

This screenshot compares the movie details pages. Here you can see how the old and new design supported shorter texts. The smaller cover art was completely overwhelmed by the two gigantic blue buttons, and the entire summary section was leaning heavily towards left in case of two buttons, or was completely disjoint in case of a single button. The new layout makes things much more balanced and shows a much more attractive cover, all at the expense of a few extra vertical pixels. By the way, the extra pixels are actually the result of using a consistent layout – the height of the summary section for books and movies used to depend on how long the title was.

This screenshot shows how the new design supports album details. The predominant aspect ratio of album covers is 1:1 and we only have a single action button (to either buy an album or to listen to an owned album). Here, the cover art is slightly wider and taller which results in less horizontal space available for the title. In addition, the single consistent layout has eliminated stray vertical space between the Explicit tipper sticker and the Buy button, giving a few extra pixels to the track list. Last but not the least, we’ve eliminated much of the hanging whitespace below the album cover. Not all whitespace is bad, but that whitespace was.

This is the latest addition to Google Play Store – magazines. You can see the same grid being used for the magazine summary, where we show an extra label above the Subscribe button. The right alignment of this label makes it clear that it is associated not with the label above it (magazine issue date), but rather with the button below it. The offer resolution dialog on the right is our new dialog that is shown in case we have more than two actions you can take on an item that you don’t own – such as multiple magazine subscriptions, or renting / purchasing a movie with SD / HD quality.

And here you can see details pages for books, movies, magazines and music albums side by side. Consistent cover size, button placement, paddings and margins ensure consistent user experience across all the different items, even if the user is not consciously aware of these changes.

The TL;DR version is quite simple. A design does not live on its own. Every single element in it, and the design as a whole must work explicitly towards the precisely stated goals. As the goals change, so does the design. It is a living breathing thing. Design turns a functional piece into a usable piece, and maintains the usability as the function changes. Don’t leave your screens to rot. Laziness begets laziness, and vigor begets vigor.