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
In version 6 Windows Mobile changed the back behavior from “A path home” to a history stack. 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.
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 Back 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 is 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 looks the same as before. The focus is returned to the same items, and items are 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:
- 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).
- 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.
- 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.
“Colleagues and customers alike expect you to be up-to-date. In order to meet this demand, information must be accessible at any given time - on the mobile phone.”So says Bjørn Jarl, CEO of 