It Could Go Really Well (or Really, Really Badly) - Macadamian

YOUR FIRST ANDROID RELEASE

It Could Go Really Well (or Really, Really Badly) by Martin Larochelle

In May 2011, Android became the leading US smartphone platform with a market share that surpassed both RIM and iOS1. As a result, an increasing number of established software organizations are now taking the plunge and extending their product line to Android. Unfortunately, between the rush to “get something out on Android” and the expectation that mobile projects should be quick and easy, teams often do not invest in the up-front product planning required to make their first foray into Android a success. Google created Android to be open and fully customizable. However, Google also created Android with specific design and development concepts the entire product team needs to take advantage of for success. In our experience, overlooking or ignoring these concepts results in team conflicts, schedule overruns, fragmentation issues, and ultimately failure in the market.

Successful Android Planning In this paper, Macadamian’s product creation experts give an overview of the Android planning process, including: • An outline of the UI key concepts in the Android experience. Leverage these to get an intuitive product to market quickly. • An overview of the tools provided by Android to translate a killer design concept to a fully engineered product. • A checklist of DOs and DON’Ts when porting an iOS app to Android. And here’s the catch — the entire product team — product manager, designers, developers, and QA — needs to ensure a common, up-front understanding of these concepts, because they are intrinsically linked. For success, we recommend you go through this paper together as a team.

3

1. Source: Android Blasts iPhone, Blackberry in Market Share, www.vision2mobile.com/ news/2011/05/android-leads-smartphone-market.aspx

1

Understand These Seven Key Android Concepts

Although the Android platform is open and customizable, Android users have become accustomed to constructs developed by Google for Android devices. Moreover, the use of these constructs is vital in developing an application quickly – custom Android designs can take up to 10 times longer!

Android UI Controls Android provides a number of standard UI controls that enable a rich user experience. Designers and developers should thoroughly understand all of these controls for the following reasons: • They are faster to implement. It can take up to ten times longer to develop a custom control than to implement a user interface with standard Android controls. • They ensure good performance. Custom controls rarely function as expected in their first implementation. By implementing standard controls, you can eliminate the need to test, revise and improve custom controls. Moreover, while designers will spend a great deal of time thinking about how a control should look, they may not always consider the many ways in which a custom control will behave in the user’s hands. Items on a mobile device often need to grow and shrink in size as they are pinched, or scroll if they are part of a list. As a result, creating a “clean” custom control from scratch can take a significant amount of design and development time. Google, however, has already thought about these interactions and developed standard controls to properly address them.

4

• Android users expect standard controls. Through their interactions with other Android apps, users become accustomed to Android’s standard controls. Deviating from the standard Android user experience can confuse and frustrate users, making them less likely to want to use your app and incorporate it into their daily activities.

With a solid awareness of Android’s standard controls, designers and developers can speed app development while offering users an intuitive experience that feels instantly familiar.

Activities Android applications are composed of “activities” which are unique, focused actions a user can take. Because it can be difficult or time consuming to scroll, zoom in, or click links on a small screen, it is recommended that an app display only one activity per screen. This practice presents the user with only the most relevant information and allows them to launch a new screen for additional information, or click the “back” button to view the previous activity. While a screen can expose multiple tasks, it should help the user complete just one activity at a time.

Your app should display only one activity per screen.

In Gmail for example, a user can only read the body of an e-mail (right) once he has clicked the relevant message (left). This layout reduces the amount of information displayed on each screen and allows the user to easily navigate between the Inbox and the message text.

Figure1: Due to the small size of a mobile device, only one activity should be shown per screen.

User Interactions When a user first downloads your application, he will make snap judgments on the usability and intuitiveness of the application within the first few minutes of use. It is therefore crucial to balance the creativity of your app with the standard user interactions Android users have come to expect. These include: • Hard buttons: including Back, Menu, Home and Search buttons. Soft buttons that duplicate these features will only confuse or frustrate Android users.

5

Moreover, back button behavior can be tricky and needs to be defined up-front for every screen, as it is not always as simple as returning to the previous activities. Most mobile phones, for example, offer both an “incoming

call” activity and an “active call” activity. Once a user has answered and completed the call, the user would not expect to return to the “incoming call” activity upon pressing the “back” button, but rather to the activity that occurred before the incoming call. If the app offers only one activity, the back button should return the user to the device’s home page. • Long press elements: Items of a list can be long pressed to open a context menu that provides secondary information. “ToDo” list apps, for example, often use a touch interaction to mark a task as completed and a long press interaction to display a menu with “edit” or “delete” functionality. Figure 2 shows an example of a menu that is displayed when the user performs a long press on a contact name.

Android developers must specify whether each screen should follow a linear or relative layout. Figure 2: The Android “long press” is a key usability feature of which all designers and developers must be aware.

Layouts Android UI screens are frequently resized, both on the fly via pinch and zoom as well as at startup when Android adjusts the size of the UI to fit the screen size of the mobile device on which it’s running. In order to make the most of the screen size and handle this resizing gracefully, Android provides a number of screen layout options. First, Android developers must specify whether each screen should follow a linear layout which manages controls in a horizontal or vertical fashion, or a relative layout which manages controls in relation to one another. Linear layouts are the most common, as in the example below. At left, the controls only stretch to accommodate the text and are positioned in a horizontal line. In the middle image, the same rules apply but in a vertical layout. At right, the vertical layout is maintained but the middle button stretches to accommodate the screen rather than the text.

6

2. Source: http://droidcake.com/2010/12/16/relative-layout-sample-tutorial/

The Android Patterns website, androidpatterns.com, is an excellent resource for shorthand summaries and

Figure 3: Designers must specify the way in which controls should be resized across Android devices.

A relative layout defines the position of controls by their relationship to other components on the same screen. In the example below from the Droidcake.com blog, the “OK” button was specified to be set below the radio button group. The “Cancel” button was specified to be set to the right of the OK button with its right edge extended to the edge of the screen. This relative layout positioning ensures the position of the buttons remains constant across a variety of screen sizes.

depictions of Android design solutions.

Figure 42: Complicated designs may require a relative layout that defines the position of controls by their relationship to other screen elements.

Android also offers specific layout properties to control the way in which screen elements are displayed across Android devices and during use: • Weight: The weight property allows the developer to determine how free space is divided on the screen. • Gravity: Gravity is the term used for control alignment (right, bottom, top, or left) on an Android device. • Density independence: Your application achieves “density independence” when it preserves the physical size (from the user’s point of view) of user interface elements displayed on screens with different densities. Without density independence, a UI element (such as a button) will appear larger on a low-density screen and smaller on a high-density screen.

7

So who specifies all of these properties? If an Android application is designed in a vacuum and then “thrown over the wall” to the development team, you must rely on the developers’ interpretation of the design which may vary significantly from the original intent. On the other hand, the development team shouldn’t be expecting the designer to specify the weight, gravity and other layout properties of each screen and control.

A common misconception is that an Android app should be

In our experience, best practice is to have the designer document the layout and resize behavior of each screen to the development team via a series of wireframes, if not a full style guide. The designer should then stay in close communication with the development team as the developers work to determine the right combination of Android layout properties to realize the design.

Screen Size A common misconception is that an Android app should be designed to support only a specific set of Android devices. Many teams assume their app will only look right on a screen of a particular screen size and limit their design to suit only a handful of devices supporting that size. In reality, Android offers you tools needed to develop a visually impressive interface that supports the full range of devices and screen sizes on the market.

designed to support only a specific set of Android devices.

To help you accommodate the range of Android screen sizes, Android recommends designing four versions of the application UI: • A small version for screens under 3”. • A normal version to accommodate 3” to 4.5” screens. • A large version for viewing on 4.5” to 10” screens. • An extra large version for devices with screens larger than 10” (tablet). It is not strictly necessary to create a design for all four versions – in some cases; one “normal” and one “extra large” version may suffice. If, however, you need to display a large number of controls on your screen, or your organization wishes to ensure perfect consistency across screen sizes, you may decide to accommodate all four size categories listed above.

8

Fragments A smart phone should only display one activity per screen due to its small screen size. Tablet devices, however, offer additional screen real estate and are often used in a similar setting as a desktop or notebook, meaning the application could show more information at once on the screen. Using an Android construct called fragments, designers and developers can merge portions of the UI onto one large screen or split them into individual screens for use on small screens. This can help to reduce the number of interactions a user must perform on a device with a large screen and eliminate wasted space.

OR

Activity A

If you anticipate that your app will someday be

Activity B

Activity A with two fragments

Figure 53: Fragments allow you to merge (or separate) activities and can help your app accommodate both large and small screens.

The example below shows a Gmail interface on a tablet display. This design uses fragments to display both the navigation list at left and the Inbox content at right. The design reduces the number of screens that must load before the user reaches the desired message.

used on a tablet device, be sure to incorporate fragments into your design. Figure 63: Fragments help you to create a visually appealing interface on larger screens.

If you anticipate your app will someday be used on a tablet device, we strongly recommend you incorporate fragments into your design. Designers need to be aware of the concept of fragments in order to design by fragment, and developers also need to be aware of this concept and its implementation details. By designing custom, reusable fragments for each screen activity at the beginning of the project, you can eliminate the need to create an entirely new layout for a tablet device.

9

3. Source: www.greatereader.org/posts/developer/why-android-smartphone-apps-are-about-toimprove_18900.html

Intents Android applications typically borrow from other applications already on the device. Using intents you can simplify both the programming requirements for your app and offer simpler, less cluttered screens.

The entire team must be immersed in Android to coordinate design, workflow and execution into a Figure 7: If the Android device finds multiple applications to handle an intent, it will display a popup screen with a set of options.

single intuitive application.

If your app needs to perform a function beyond its core abilities such as opening a photo, looking up a contact, or playing a video, the team should investigate whether a tool that can perform that function already exists in the OS or in a popular third-party app. If so, you can leverage that functionality using intents. For example, if your app accesses user contacts, you can use intent objects to launch the device’s existing Contacts application. This will eliminate programming duplication and speed up the user’s interaction with the device since the user will not need to re-learn how to add a contact to your particular app. Android offers specific UI controls, activities, interactions, layout and resize options, as well as special constructs like fragments and intents. While on the surface these appear to be things that the design team needs to work with, we contend that the entire team must be immersed in Android to coordinate design, workflow and execution into a single, intuitive application — one that grabs users’ attentions and draws them in to the real value of your product.

10

2

From Stunning Design to Stunning Product using Android Tools

Too often, designers and developers work as two separate teams. Designers try to express what the product should look like via Photoshop mock-ups, and developers may or may not carry out their vision due to a number of factors that could include: • Whether the designer communicated the design effectively • Whether the designer is available over the course of implementation for questions • Whether the design can be realistically implemented. Android provides tools that effectively bridge the gap between design and development. If your team is not using these tools — designers using them as input and developers as output — you are subjecting your project to the above risks! To ensure your app’s interface looks as good as your designer’s Photoshop concept designs, your team will need to leverage the following Android tools and features:

9-patch Tool Android supports 9-patch PNG images, which are images that can specify the area that should be stretched when it is re-sized. These PNG files will scale properly for all screen sizes and contained text, making them ideal for most control backgrounds. For example, a single 9-patch PNG can be used for all buttons of your app in all languages. Certain developers may be able to create these resources, but very few are artists, so it makes sense to have your visual designers create these images.

11

Figure 8: 9-patch PNGs will scale properly on all screen sizes.

ShapeDrawable objects give your interface a “slick” look by preventing the banding effect

While 9-patch images take longer to create than regular imagery, they can greatly reduce overall app development time by eliminating the need to create custom imagery for a variety of screen sizes.

ShapeDrawable Objects ShapeDrawable objects are a programming construct that developers can use to create basic shapes and manage their presence on the screen. ShapeDrawable objects give your interface a “slick” look by preventing the banding effect that occurs with re-scaled PNGs.

that occurs with re-scaled PNGs.

Figure 9: The background of this interface uses a ShapeDrawable object to ensure a smooth gradient on all screen sizes.

12

To use ShapeDrawable images, designers should simply provide the start and stop color of the gradient and its angle. With this information, developers will be able to ensure that shapes are drawn correctly and dynamically.

Alternate Resources In cases where 9-patch PNGs and ShapeDrawable

9-patch PNGs and ShapeDrawable objects should be used as often as possible to ensure buttons and backgrounds scale smoothly across screen sizes. In cases where they cannot be used, designers should provide alternate design resources such as standard PNG images for various Android screen densities.

objects cannot be

As with screen sizes, designers and developers only need to handle four main screen densities:

used, designers

• Low: around 120 dpi

should provide

• Medium: around 160 dpi

alternate design

• Large: around 240 dpi

resources such

• Extra Large: around 320 dpi

as standard PNG

The Android OS can rescale images, but the image quality will not be as high as when designed in Photoshop. Providing four PNGs of each image that accommodate the screen densities listed above will allow imagery to look crisp on all devices.

images for various Android screen densities.

13

By designing for the most popular screen densities and leveraging Androidspecific tools such as ShapeDrawable objects and the 9-patch tool, developers and designers can ensure the stunning visual mock-ups developed during the design phase of the project are translated quickly and accurately to the app’s final design.

3

Do Your Homework Before Porting an iOS app to Android

With the rise of Android’s popularity, product managers with an existing iPhone or iPad product are under pressure to port it to Android. While porting from iOS to Android is certainly possible, we have found teams almost always underestimate the amount of effort required. Porting an iOS app is not a trivial matter because there are a number of Android elements not present in iOS, and vice versa. When the product manager or designer tries to preserve as much of the iOS design as possible, developers frequently devote a great deal of time replicating the iOS controls and workflow because they do not exist on Android. The result is a product that releases late, and ultimately alienates Android users who have become accustomed to Android-specific interactions. For those who are planning to port an application from iOS to Android (or are already knee-deep in this surprisingly challenging endeavour), we’ve put together a list of recommendations.

Re-use Data Organization and Grouping of Controls The data organization and grouping of controls into screens can be reused from an iOS product in a direct mapping. The relative control placement does not need to change, although it is typical to move the “tab” control from the bottom to the top of the screen.

Use Native Android Controls As described in the first section of this paper, Android controls are much easier (and less costly) to implement than custom controls so they should be used

wherever possible. Google, like other UI toolkit makers, spent more effort on its UI controls than most app developers can afford. This makes it difficult or impossible to replicate many iPhone interactions on the Android platform. For example, “lists” on the iPhone can be pulled down to reveal a search control. While this can be easily replicated on an iPhone app, implementing the same behavior on an Android app, and making the transition smooth, would require a significant investment.

Figure 104: Android offers standard controls that eliminate the need to replicate iOS controls.

Your Android

Eliminate the “Back” Button

design should

Android devices feature a back button in their physical design. A “soft” back button (such as the one found in iOS apps) could confuse the user or unnecessarily clutter the UI, so it should be eliminated. Even on Honeycomb tablets, on which the hardware back button was removed, there is no need for a soft back button because it is provided by the Android OS.

leverage the “Search”, “Menu”, and “Long Press” buttons.

Leverage the “Search” Button In addition to a “back” button, Android devices feature a hard “search” button. Be sure to eliminate any unnecessary soft search buttons and configure your app to leverage the built-in back button.

5

5

Leverage the “Menu” Button and the “Long Press” Android menu options can be moved off-screen to a menu that is displayed when the hard button is clicked. Similarly, secondary options can be made accessible by doing a “long press” on a control. For example, long pressing a list item is one way to obtain the option to delete it.

15

4. Source: http://note19.com/2009/05/20/uipickerview-sample/ 5. Source: http://noscope.com/journal/2010/01/android-on-context-buttons

5

Design the Selected State When a control is selected, a visual representation of the controlled state is needed for designs that incorporate custom backgrounds. Buttons, for example, may need to change color when selected, so your design will need to specify the look and color of the specified state.

Use 9-patch PNGs As mentioned earlier in this paper, 9-patch images allow Android controls to automatically resize images and display them properly on an Android device.

Set Controls to Density-Independent Pixel Sizes If your Android UI is defined in pixels, the controls will be large on some screens and tiny on high-resolution screens. To remedy this, set your controls to densityindependent pixel sizes so that the physical size of the control is maintained on all screens. Figure 11: 9-patch images are scalable

By tailoring your iOS design to suit the Android platform, you can ensure your ported app looks and acts like an Android app — not simply an iPhone app running on an Android phone. What’s more, you will dramatically speed up development and release of the application by eliminating the complicated steps required to replicate the iOS experience on Android.

Summing It Up

The Android Developer website: developer. android.com is a useful resource for information on density independence.

Delivering value to app users who are interacting with dozens of different Android mobile devices is challenging and requires the collaboration of product management, design teams and developers. By leveraging Android design tools and understanding the differences between the iOS and Android platforms, you can quickly design and develop an Android app that is visually appealing, intuitive and easily adopted by Android users.

Talk With the Experts User researchers trained in User-Centered Design techniques can help you to understand your prospective Android users and how they will be interacting with your app. We invite you consult with our accredited UCD researchers and Android experts who can work alongside you to develop a UI that will maximize the value of your design across the user base. At Macadamian, our experience and proven ability to design and develop groundbreaking mobile products make us the ultimate partner to support your Android application project.

16

Contact Us For questions or comments about this white paper, or for more information on a consultation, please contact: Stephane Lussier Vice President of Engineering 1-877-779-6336 x102 Macadamian [email protected]

About Macadamian Macadamian is a global UI design and software innovation studio that provides a complete range of highest quality usability, design, and software engineering services to industry leaders across North America. Our experience, and proven ability to work seamlessly with product management executives and software teams is why companies turn to Macadamian to develop product strategies, design compelling user experiences, and build quality software. Whether you’re a small start-up or a corporate giant, we can help you transform ideas into market-ready features or products that will stand out from your competition and delight customers. Additional information can be found at www.macadamian.com.

17