Backstepping on a mobile phone

This blogger has moved!

I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs

 

Mobile applications have two ways to use the Back function; As "History" or as "A Path Home". This blog post discusses those approaches and backstepping in general.

Back as history:

Say I am in the phonebook and I click an address. The map opens. In the map I do a search and the search result includes an email address. I click it, the email editor opens and I send an email.

I have jumped from "application" to "application" in the phone. How do I want the Back-function to work? I'd want to backstep from the email to the map to the phonebook. This is the behavior we are used to from Internet browsers.

Back as "A path home":

On most phones the Back-key does not step back through a history. It takes you back to the main menu or idle screen. The advantage is that users never get lost and can fairly quickly get back to known territory.

The Home key

A prerequisite for the history stack approach is that the phone has a "Home" key. You don't want the user to have to press Back 20 times to get to the main menu. In addition to WinMob, Android and the iPhone uses a hardware Home key. Btw: In version 6 Windows Mobile changed the back behavior from "A path home" to a history stack.

If you want to have a history function in your application (assuming your application is large and/or deep), and the phone does not have a hardware Home key, what are your options? Your only choice is to give the right softkey double or triple duty as Back + Home or Clear + Back + Home key. It is doable, but has to be thought out carefully and it may not be worth the trouble.

How Back works in Browsers

Current Internet browsers use a stack to implement the Back and Forward button behavior: the effect is that a person can use these buttons to move up and down the single hierarchical path captured by the stack, but cannot use it to revisit any pages that branched off that path as these are popped off the stack.

To illustrate this problem, let us take a person who starts at page A and visits page B. He then clicks the Back button to return to page A, then visits page C. This navigation path can be shown as A → B ï A → C. The contents of the Back menu will now be {A,C}. Page B has been pruned out of the menu entirely. (source)

This behavior corresponds poorly to the mental model of most people. Most people are incorrectly thinking that the Back button models a history list of all pages visited. It may seem that this system is confusing and frustrating, but research reveals no major problems with stack based navigation! An advantage of Back navigation is that it represents a very light cognitive load. People tend to use a simple "click until the desired page is recognized" strategy, and are happy to trade "true back navigation" for this simple model.

Techniques more sophisticated than the stack could be employed, but the simplicity and the effect of conditioning from a decade of browser use, dictates that the Back navigation functionality should mimic the one seen in Internet web browsers.

Don't store everything

The following states in the UI should not be included in the history stack:

• Notifications 
• Confirmation dialogs 
• Login or password screens

The Back key

The right softkey is default back navigation. The ultimate Back (from the application perspective) is an exit to the idle state, (closing of the application). In this case the right softkey is labeled Exit instead of Back.

Many Sony Ericsson phones have a hardware Back key. Some phones have a Clear key that does double duty as Clear and Back key. The preferred behavior is that the control keys work the same way in the application as they do in the phone OS.

And note: Back navigation cannot be used as an Undo function. After backstepping to the previous page, the screen should look the same as before. The focus must be returned to the same items, and items  kept in the same positions on the screen. However, any data that is committed will not and should not be undone by "Back". An Undo function must be labeled "Undo" and must be UI widget-oriented and not page-oriented.

Back behavior in mBricks

We are contemplating this mBricks history stack behavior:

1. Navigation to a page pushes a page to the stack top. This is done by a call to historyPush(). historyPush() stores the page and the appearance of the page (focus, highlight and scroll). 
2. Using historyBack() or historyForward() moves the stack pointer down and up the stack respectively, displaying the page at that stack location. The actual stack contents are not altered when navigating with these functions. 
3. When navigating to a new page, any entries on the stack above the current position are popped off the stack, and the new page is added. Pages popped off the stack cannot be revisited using the historyBack() or historyForward() functions.

The mBricks history stack is page oriented. Populating the stack is controlled by the developer. All page visits are pushed to the history stack by default and the history stack has a 20 item limit.

Comments

[Steven Hoober]

As promised months ago, I have repurposed this post (slightly) and added it to the wiki:
http://patterns.littlespringsdesign.com/index.php/Back

Anyone is free to go there and edit-away, if you have more info or a different opinion.

[Barbara Ballard]

Over here in the backwaters, Nokia is not in any way a dominant player. After all, 2 of our top 3 operators are CDMA and they pretty much abandoned CDMA for a while. We can't get the N95 without ordering from overseas, etc.

So a LOT of devices here have hardware back buttons, as you mention. The End key is pretty much a Home key. So for many of my projects, I use those as assumptions, and can have secondary navigation on the softkeys. It is really nice to have two or three softkeys, and not have one of them dedicated to backwards navigation.

The trick becomes handing "back" behavior from one application back to the device OS, and whether the device can support such a thing. Certainly Java doesn't particularly support it.

For devices that don't give us hardware back buttons (boo, hiss) we have to make a more difficult to use application, with extra button presses to accomplish pretty much anything.

When I work on device OS, usually I have to wrestle with the engineers to do this right. The engineers normally want Back to mean "go up one level in the hierarchy", and I usually want back-as-history-navigation. We can spend many many days going back and forth on this one.