Designing for the RIM BlackBerry PlayBook

Designing mobile content for the RIM BlackBerry PlayBook offers many new opportunities to engage audiences in exciting new ways. At the time of this writing, BlackBerry smartphones hold 17.5 percent of the global smartphone market share—so your target audience could be quite large. By leveraging its simple navigational model, you can easily create business and productivity applications. You can also choose to extend the core components and design a rich, immersive experience from the ground up.

In this article, I describe some fundamental design strategies and highlight some interesting user interactions that are exclusive to the BlackBerry PlayBook. I also cover some important design choices to consider when creating content for the BlackBerry Tablet OS.

The BlackBerry PlayBook has a seven-inch LCD display with a 1024 x 600 screen resolution (resulting in a display area of 6 x 3.5 inches) at 169 pixels per inch. If you design your apps with Adobe Photoshop, use those dimensions when creating a new document. The PlayBook also supports a landscape-oriented display. In most cases, you'll lay out your application in landscape view. When designing your app, consider using designs that offer a widescreen experience for users. For example, position the UI components on the left and right sides of the screen, rather than the top or bottom, to take advantage of the additional width. This approach is also helpful because the user's thumbs are naturally positioned near the buttons when holding the tablet (see Figure 1).

The PlayBook also supports portrait view. You can enable your content to adjust for portrait view or create a design for portrait view explicitly. Portrait view is commonly used when developing reading applications and navigating long lists. It's important to consider that the user will probably be typing with their thumbs when the app is displayed in portrait view (see Figure 2).

In many cases, readers and applications displaying long lists are ideal candidates for portrait view. However, choosing between portrait or landscape view doesn't have to be an either/or decision. You can set the view to adjust based on the tablet's orientation if your content looks acceptable both ways. Changing from one orientation to the other isn't as simple as scaling the content. If your app switches between views, decide how your content will change when viewed in different orientations (see Figure 3).

Users interact with content using gestures, such as swiping a finger across the touchscreen, rather than poking UI components, such as clicking buttons and scroll bars. The core interactions generally take place on the bezel (the frame surrounding the display area of the screen). The key swipe to keep in mind when developing any touchscreen app is the swipe moving vertically from the top downwards, which invokes a contextual menu (see Figure 4). Additionally there are interactions such as dragging content across screens and pinching items to open and close them (see Table 1).

Table 1. Different ways of interacting with content on the PlayBook

Leveraging the contextual menu

As I mentioned, the bezel swipe that you'll find especially useful when developing your application is the bezel swipe downward to reveal contextual menus. You can edit contextual menus to add custom buttons and interactions that are appropriate for your content. Contextual menus make it easy for users to access controls without always taking up valuable screen real estate (see Figure 5).

Understanding the fundamentals of mobile design

Touch interfaces are different from desktop interfaces for many obvious and not-so-obvious reasons. Users often navigate touchscreens with their finger or thumb, and their digits are attached to their hand. Design interfaces with larger "hit" areas to accommodate finger taps. Consider an "iceberg" approach: just as two-thirds of an iceberg's mass is underwater, create a "hit" area of a button that's two-thirds the size of the visual button because some of the content may be hidden by the user's hand.

Since tablet users are on the go, consider that your app may be used in many different locations and in varying circumstances. Develop apps with two-minute tasks, so that users can achieve a simple goal while waiting in line at a coffee shop. When developing games, include intuitive options that make it easy to jump into the game's interface and quickly jump back out again. Strive to develop levels that do not exceed two minutes in length. Also, since tablets are portable devices, the user may be accessing your application in many different lighting environments. When you design the app, use contrasting colors to make the UI legible in high glare situations (see Figure 6).

Note: In the example above, the button at the top is 40 pixels high by 200 pixels wide, which makes it easy to select.

The following list of user interface considerations are important to keep in mind:

• Create buttons that are at least 40 x 40 pixels.
• Determine the best location when positioning buttons. Try to keep a 15-pixel margin around each button and the edge of the screen, especially along the top and bottom of the screen area. Otherwise, users may inadvertently open a menu or display the navigator.
• Place buttons close to the sides where the user's thumbs are positioned when they are holding the tablet.
• Add gestures when appropriate and provide visual cues. For example, when displaying contact information, lay it out in a Rolodex fashion and allow the user to swipe vertically to move through the list.
• Position important information near the top of the screen. Remember that information at the bottom of the screen may be obstructed by a hand or by the soft keyboard.
• Use the built-in components of the PlayBook for consistency with your app and the native features of the device.

Take a moment to review the component used to display the BlackBerry PlayBook picker list (see Figure 7).

Creating navigation without using buttons

Interactive touchscreen UI elements do not always require a button or a slider bar. Gestures and touch events offer an exciting new way to enable users to interact with content. When a user is presented with a photo on a mobile app, they often intuitively recognize that they can pinch the image to zoom and use gestures to rotate the photo (see Figure 8).

The example above replaces the right and left arrow buttons that were previously used to review other images with a SWIPE event. Zoom in and out buttons are replaced by GESTURE_ZOOM and GESTURE_ROTATE events. The More Info button is replaced by a long tap. Consider using the following gestures to replace buttons in a mobile touchscreen interface:

• Tap Event instead of a mouse click, although a mouse click will work as well.
• Touch Begin/End to drag items into a shopping cart.
• Long Tap or Two-Finger Tap to display a submenu of the selected item.
• Zoom Event is executed by using two fingers to pinch and zoom in or out of an image.
• Rotate Event is executed by using two fingers to rotate an image.
• Pan Event is helpful to move an image or text block that is larger than the screen size.
• Swipe Up/Down/Left/Right can be used to move through multiple screens.

Using real-world metaphors

We interact with objects every day. And you can generate object icons to use when designing buttons. Consider the Recycle Bin used in Windows operating systems. It looks like an actual recycle bin and its purpose is conveyed in the design of that icon. In the same way, look for real-world metaphors that can be used in your application. If you need to display a database of names, try using a Rolodex style. Need to organize things into categories? Consider using folder tabs. A drawing app might display brush icons and a canvas, ensuring that most users will intuitively know how to use the tools on the screen (see Figure 9).

Note: The Polaroid icon at the bottom of the screen is a button used to take photos of a sketch.

In this last section, I describe some best practices for typography. Typography's main purpose is to convey information in writing. Clarity and legibility are the primary goals. There are two categories of fonts: serif and sans-serif. Serifs are the extending curves and points usually displayed at the ends of characters. Times New Roman is an example of a popular serif font. Times New Roman, like other serif fonts, can communicate a more classic and traditional style. Conversely, sans-serif fonts (characters without serifs) tend to be more modern and legible. This may be due to the popularity of Arial and Helvetica fonts used on desktop computers. Sans-serif fonts are usually simpler in structure and some designers feel that they are easier to read when viewed on monitors and screens. But this opinion may also be based on a user's familiarity with them. Adobe has been providing beautiful typography since 1985. Visit the Adobe Type site for more fonts and resources.

On the BlackBerry PlayBook, the default font is Myriad Pro. It is a very elegant sans-serif font that is clean and easy to read. To add consistency between the user interface of the device and your app, consider using Myriad Pro. Of course, there are many other fonts available on the device that you can use. The following list contains the other major fonts:

Designing apps for tablet devices can seem like a brand-new frontier but the design fundamentals are the same for any project. Understand your target audience and consider how users will access the information, and then design your content accordingly. The BlackBerry PlayBook is an exciting new device. Explore ways to expose a new audience to unique content, while making the experience intuitive at the same time.

Consider the design tips described in this article when developing your own projects. Also review the UI Guidelines for the BlackBerry PlayBook Tablet provided by RIM. After planning and designing the layout of your content, you can use applications such as Flash Builder or Flash Professional and the BlackBerry Tablet OS SDK for Adobe AIR to build your app.

You will find other resources for BlackBerry Tablet OS development in the Adobe Developer Connection.