Screenshots of Gigbeat for Android

A few screenshots of the Gigbeat 1.1 for Android. Download on the Android Market.

Looking back at 2011

Another year is gone, and it’s time to review what has happened on this blog over the last twelve months.

2011 has been a busy year for the Android Market client that has undergone a complete redesign to bring it into the world of browsing, searching and purchasing digital media. The “Designing for the mobile form factor” presentation at AnDevCon conference in March was followed by a series of detailed entries about the design and implementation aspects of the new client. I took a deeper look at synchronized scrolling, swipey tabs and carousel animations, also talking about the reasons not to provide full source code for those areas. I also highlighted the importance of pixel-level details, and proper collaboration between developers and designers.

As we worked on bringing a unified experience to a variety of form factors, we started to define and refine principles of responsive mobile design. After making the presentation at AnDevCon II conference in November, I followed up with the four-part series that answered three underlying questions:  what are we designing, why are we designing it in a certain way and how are we implementing the target design (part 1, part 2, part 3, part 4). As we continue refining and polishing the application across the entire gamut of supported devices, this blog will be updated with more details on both the planning and implementation aspects of responsive mobile design. And on a related note, I’ve finally collected my thoughts about vector icons and put them in words.

A look at the colors of Tron: Legacy was just a beginning of a much bigger part of Pushing Pixels. A deeper look at the art of Tangled and the transition to 3D shooting and projecting has started a new chapter. Over the last nine months I’ve interviewed a number of creative artists working on various aspects of motion productions that I’ve found particularly impressive in the recent years. I’ve talked to Martin Ruhe about the cinematography of “The American”, Drew Boughton about the art direction of “Unstoppable”, Phillip Baker about the production design of “Chloe”, Claire Keane about the art of “Tangled”, Bradley GMUNK Munkowitz about the visual effects of “Tron: Legacy”, Luke Dunkley about the editing of “The Crimson Petal and the White”, Rosalina Da Silva about the make-up of “Tron: Legacy”, Mark Scruton about the art direction of “Easy Virtue”, Sarah Horton about the art direction of “The International”,  John Greaves about the storyboarding of “Edge of Love”, Jonathan Freeman ASC about the cinematography of “Edge of Love” and Anne Seibel about the production design of “Midnight in Paris”. I’ve also talked with Kyle Westphal about the craft of film projection, and with music director David McClister. You should definitely expect more interviews in 2012.

I also looked at the costume design of “The Tourist“, the rainbow colors of “Burlesque“, the colors of “How Do You Know“, the colors of “Emma“, the set design of “Mr and Mrs Smith“, the art of “Cracks“, the colors of “No Strings Attached” and the colors of “Twilight“. Finally, a smaller series looked at the iconic images of “North By Northwest“, “To Catch a Thief” and “Key Largo“.

The Retro:Active series started in October 2010 saw the total of 368 posts in 2011. This series showcases the fusion of modern and vintage in visual and industrial design, fashion, photography, typography, illustration, animation and other related areas. This is one of my main sources of inspiration, and expect it to continue well into 2012.

Pushing Pixels is here to stay, and it will only get better. If you still have not subscribed, click on the icon below to stay tuned in 2012!

Food for thought #6

Craig Villamor in Design is never “Done”:

It is foolish to think that you will get the design right the first time. It is also foolish to think that there won’t be changes to a design once development begins. And on a larger scale, software products are never done unless they are dead. Life is better when you stop kidding yourself and your team and admit that there is no “done”.

As a design manager, I use this concept of approaching done to evaluate the health of a project and the effectiveness of its designer. A designer is on the right path when his or her solution is approaching done. In the early stages of a project, there is typically a high level of variability. Designs may appear to be approaching done only to get completely reset once a new requirement or constraint is encountered. This is completely normal. But over time, this variability should become smaller and smaller. That is when you know a design is on the right path. There is a steady progression toward done.

The graph is a little awkward, conveying an incorrect illusion of the ideal target design that never changes. In reality the design is a living breathing thing that is reevaluated based on the current knowledge and understanding of the domain, and where you want to be. And the implementation is more of a staggered spiral, peeling away chunks of cruft, progressively iterating, refining and polishing.

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.