Adventures in Mobile User Experience

I’ve just spent the last few weeks building a mobile banking app for the Blackberry. Now, it’s true that before I started this project, I knew the iPhone better than I knew the Blackberry. And it’s true that, to some extent, I was supposed to be tweaking and wiring together some pre-existing Blackberry components. But many of those components had been built a few years ago, and as we all know, one year in mobile technology is equal to seven years for humans. A lot has changed in that time, and a lot of that change relates to how one builds applications that provide a good user experience.

There are a number of existing tricks to creating an attractive Blackberry application, and this post describes some of the things I picked up along the way.

One of the most important initial discoveries was a set of more visually-pleasing components for the Blackberry. It’s clear that the appearance of those components have been inspired by the iPhone, but hey, imitation is the highest form of flattery. Personally, I think these components could stand to be part of the standard Blackberry toolkit, but that’s just me. This presentation also provides some good commentary about making attractive applications.

The Splash Screen

What could be harder than a splash screen? You get some good graphic designer to slap together an attractive splash image, and you throw it up on the screen while your application is initializing.

Well, that’s almost exactly what we did. The only difficulty emerges when you start thinking about all the different screen sizes possible on different Blackberry devices. Here are some pretty common widths (in pixels):

  1. 240
  2. 320
  3. 360
  4. 480
  5. 640

The image, above, shows a device with a 360×480 screen size. So the obvious question is: how big should the image be?

There are functions you can call internal to the Blackberry to take any particular image and resize it to a particular width and height. But the end result of these resized images isn’t great. There are resizing artifacts, and the look isn’t ideal. And, speaking for myself, I think that the splash screen should look sharp. People pay attention while they’re waiting for the app to start.

So my solution is to ship the application with several different versions of the splash screen, sized for different screen widths. If I encounter a screen width that I haven’t anticipated, I use in-device resizing. But if I have anticipated it, grab the appropriate image and show it.

But it’s also not quite that simple. Because in addition to different widths, many devices have different screen aspect ratios. Both the Blackberry Bold and the Bold 2 have 480px-wide screens. But the Bold is 320px tall, whereas the Bold 2 is 360px tall. If I try to provide a different splash screen for each of the different aspect ratios, I’ll be a bit overwhelmed. In practice, our app uses the screen width to choose the appropriate resolution, but then crop the image to the appropriate height. We don’t quite crop it at the centre because the logo tends to be a bit off-centre, but we have an algorithm that crops it at an appropriate spot (Rom put this code into place).

Main Menu

Here’s the main screen of our mobile banking app. Our client — uh… let’s call them Bank of Intelliware — wanted three distinct areas on this screen. The top area is marketing content that’s downloaded from a web service. The middle section provides access to the main actions. And the footer area provides links and other information.

I confess that I’m ambivalent about this design. First up, I think that the design looks kinda web-page like. I can understand why it looks that way, but I can’t claim to love it.

In particular, I feel like that footer is hard to use, especially on a touch-based device. Apple has given the mobile community pretty clear guidance that people’s fingers need a minimum of 44px (on an iPhone screen, anyway) to accurately tap a control. I’m not sure that the link for “Web” is quite 44px wide. So, the consequence is going to be that a lot of users will frustratedly tap at the screen, and frequently get the wrong result. But it’s what the cient wants.

Now, I’m also making use of three of the Blackberry’s standard screen areas. The white banner is assigned as the “banner” field — a field that always sits at the very top of the screen. I don’t have a title area, but the white bottom portion is assigned as the “status” field, so that it always appears at the very bottom of the screen. Everything else is assigned to the main content area of the screen.

Actually, that’s a bit of a simplification. As we can see, to render the whole screen without scrolling, you need a display that’s at least 450px tall. The device you see in the image has screen dimensions of 360px by 480px. On a screen like that, I want the footer to be pushed down to the bottom. But if I have a lot less screen real-estate, I have to remember that only the main content area is scrollable. The banner and the status bar are always on the screen. And I’m not sure that that’s what I want. In my code, I have stuff like this a lot:

if (isTallDisplay()) {
} else {

If the display is tall (which I define as greater than 400px) then I assign the footer to the status field. Otherwise, I append it to the scrollable main area.

And, frankly, my code has a lot of little checks like this. I’m constantly looking at the width or height of the device and tweaking my layout in an attempt to support the many diverse devices out there.

The Main Buttons

At one level, the main button area seems relatively straight-forward. I have six buttons, each of which activates a different app feature.

It probably doesn’t take a lot of guesswork to realize that each “button” is, in fact, a graphic image. The Blackberry has a component called a BitmapField for showing images. But it’s not a very good component.

In particular, it doesn’t really emulate the behaviour of a button. One of the important concepts on the Blackberry is the concept of “focus” — what widget on the screen has focus? This notion of focus is rooted in the Blackberry’s original trackball-based interface. As you wheel around the trackball, you need to be able to see what thing on the screen has been brought into focus.

In the case of our buttons, each image actually has two representations: a focused and an unfocused version (you can see the white outline on the focused button).

Conveniently, many people have created components that provide this behaviour: show one image when the field is not in focus; when it is in focus, show a second image. There’s even an implementation of this kind of field in the set of advanced components that I mentioned earlier — the BitmapButtonField.

So: with a good set of images, we should be golden, no? Well, I still had one problem: the text part of the buttons. Now, one solution could simply be to add the text to the image, itself. Unfortunately, I had a requirement for multi-language support, and it was going to be easier for me, in the long term, to pull the text part from a localizable source. So I ended up creating a subclass of the BitmapButtonFieldthat paints text on top of the image.

There is one other complexity: once again, I have to care about the screen width. These images are just over 100px wide, and this layout is optimized for a 360px-wide screen. I don’t try to resize them — if I’m on a wider display, I put more space between the buttons. If I’m on a narrower display, I only render images two-across, rather than three-across.

More Focus Considerations

Now, the top portion of the screen is the marketing collateral. In simple terms, it displays marketing graphics that are downloaded from a web service. We support multiple marketing images that the user can cycle through. And if users “click” on an image, they’re taken to a web page associated with that image’s marketing campaign.

That all sounds straight-forward. But, once again, what does it mean to “click” on the marketing image? On non-touch Blackberry devices, that means that we need to move the focus to the image, and click the Blackberry button.

But what does it look like when we move the focus to the marketing image? Remember, above, I had an alternative image that showed the “focused” state. Here, I have no control over the images — they’re being served up by a web service that I invoke. So, I haven’t been able to get the web service to give me more than one version.

Fortunately, the standard Blackberry BitmapField supports focus by highlighting the background. It’s just that, for most images, you can’t see it — the image, itself, covers up the highlighting. If, however, your image has some transparency, you can see the focus highlighting through the transparent portion of the image. That’s not my favourite user experience in the world, but it was the most straight-forward solution given the number of different parties involved in serving those images.

One aspect of this solution that I didn’t like, though, is that there’s no straight-forward way to alter the color of the highlighing. You can subclass the BitmapField and provide your own implementation of the drawFocus(Graphics g, boolean on)method. That does not thrill me, but it gets the job done.

Of course, screen size plays a role here once again.

Pretty Formatting

Some times, information on certain screens needs to be organized and rendered in a way that’s meaningful and attractive. Unfortunately, rendering blocks of text and data attractively is fairly hard, especially if you want to intersperse little bits of functionality. Consider this example: the contact page includes clickable areas that can initiate a phone call or email session.

Coloured Labels

To use a simple example of why rendering is hard, consider the coloured labels on the screen. The standard Blackberry components don’t provide a simple way to change the text colour on a label. That feels, to me, like a gross oversight.

Once again, you can accomplish this with just a simple matter of code. Subclass the LabelField and override the paint method. Can’t say I’m thrilled with that.

Blackberry and the Box Model

One of the most basic ways of chunks of data more attractive is to introduce a bit of whitespace. Use spacing to provide structure, and also to avoid overwhelming the user with too much information. And, on the Blackberry, you can often accomplish this using padding and margins. If you’re familiar with HTML/CSS, the notion of padding and margins should be immediately recognizable. Blackberry uses a “box model” very similar to HTML.

In this simple example, here, I’m using both a margin and padding (as well as a border) to make the display of this information a bit easier.

What is frustrating, however, is that if you try to set a background on a standard component, the background never fills in the padding. In the example you see, above, I’ve created a custom component — there’s a grey background to the screen, and my information “box” has a white background and a dark blue border. If I hadn’t created my own component, the white background would appear behind the text, but would not extend to the border. Words cannot express how annoying this is. That’s not true; words can express that, but management doesn’t allow us to use those words on i-Proving.

Labels with Image Background

In yet another example of death-by-paper-cuts, the top banner on most of the screens includes a screen heading with an image background. In Blackberry terms, you can create a label, assign the heading text, and then assign a background image. Here’s the drawback: you can’t force a particular height on a label. So if I want to ensure that the entire background image of the label is visible, I have to, once again, subclass and tweak the layout logic.

Why Not HTML?

People who are familiar with tools like PhoneGap must be wondering: why don’t you just render this fancy-formatting using HTML? Doesn’t HTML do a perfectly-acceptable job of rendering text in attractive ways? In fact, the answer is, “yes, it does!”

But here’s an important part of the answer: to render HTML, you almost-certainly want to use something called the BrowserField component — it’s the Blackberry equivalent of the UIWebView. The thin
g is, the BrowserField component is really broken on Blackberry 5.0, such that if you include it on any screen that has other buttons, or anything that’ll steal the focus, you’ll suddenly find yourself getting a lot of Java IllegalArgumentExceptions. It’s a known problem and Blackberry has done nothing to fix it. Their solution: upgrade to 6.0. Except, unlike with the iPhone, people aren’t good about updating the OS on their Blackberry devices.

Custom Buttons

Here’s a fairly basic example of how beautification of the functionality makes a big difference in the overall experience. “Find a nearby location” is a pretty common feature of many retail and banking applications, and it’s a pretty common component in our toolbox. But providing the functionality is one thing; making it attractive is another.

Because of the specific needs of this client, we adapted our store locator component to provide two different ways of locating branches: one is GPS-based (finding all locations near the device’s current location) and the other was criteria based (e.g. “I’m looking for branches — not just ATMS — in Kitchener-Waterloo”) When users select the “Find Us” option, we present a screen that asks if they want the GPS-based version, or the criteria version.

Here’s the most basic rendering of a simple screen with two buttons.

There’s a lot that’s butt-ugly about this screen. There’s also a lot of research that talks the relationship between size of a UI component and relative priority of the actions that those components give access to. Here, it seems like the second one is favoured (because it consumes more real-estate on the screen) whereas, in truth, the first option is probably more applicable for general use.

At the very least, a comparable iPhone app would almost automatically make the buttons the same width. That turns out to be kinda hard using the standard Blackberry components. Returning, once again, to our set of better Blackberry components, there’s a layout manager called the VerticalButtonFieldSet — it’s ideally designed for exactly this kind of problem. So long as you tell the manager to use all the width, like so:

VerticalButtonFieldSet manager = new VerticalButtonFieldSet(USE_ALL_WIDTH);

you can add buttons to the manager and get a somewhat better result:

This example expands the buttons to consume that entire width of the layout manager. I’ve been careful about margins and padding, so that the buttons don’t scrape up against the edges of the screen, and this is probably perfectly acceptable for many applications.

But… that blue colour isn’t quite the same blue as our application’s palette. And that’s not always happy-making. Something that kinda shocks me is that it’s really hard to change the colour of a button in a Blackberry app. If you Google this problem, you can probably find a number of examples of code solutions for this problem. The most common solutions involve subclassing the ButtonField class and changing the paint or paintBackgroundmethod. And after some trial and error, you’ll probably discover that none of those components play nice with the VerticalButtonFieldSet component. Awkward!

In the end, I went back to the BitmapButtonField approach: create two attractive button backgrounds (one for the focused state, and one for the unfocused state), but I still had to introduce a subclass to add some text on top of the button images.

I also had to deal, once again, with the problem that the screen width varies. As with the splash screen, I maintain the background button image in a number of different sizes, and choose the most appropriate size based on the actual width of the display.

This solution allowed me to render the screen as follows:

I confess that I look at this screen and wrestle with the question of which button has focus. It turns out that the darker-coloured one is the focus image. To make it a bit more clear, I tweaked my code to grey out the text on the unfocused button:

Fancy Lists

As a last example, we’re all familiar with the UITableView in the iPhone — the iPhone uses it extensively. It’s so popular, that some of the advanced controls I mentioned earlier emulate its behaviour. The ListStyleButtonFields and the ListStyleButtonFieldSets are direct ripoffshomages to the UITableView. And they can certainly spice up a Blackberry screen.

Some times, though, you need more elaborate layouts, such as in this location list:

Here, I need to render a variety of things:

  1. A main icon on the left
  2. An arrow icon on the right
  3. A title
  4. A details line
  5. An indication of the distance

The ListStyleButtonFieldwasn’t capable of that. To be fair, even the iPhone’s UITableViewCell needs extra love in this instance.

So, once again, it’s off to the land of subclassing components. One of the complexities of this requirement involved the actual text labels. On the iPhone, if the text is too long to fit in its designated space, the iPhone automatically truncates the text and appends “…” to the end. On the Blackberry, because different screen sizes have long been part of the landscape, labels tend to wrap automatically. So if you want the iPhone “feel” of having a list of items of fixed size, you need to write some code to trim the labels that are too long. Annoyingly, this kind of code is a bit tricksy. But the end result definitely seems worth it.


Clearly, it’s possible to create attractive Blackberry apps. I just wish it was a bit easier.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply