More Back Button Confusion

In December I wrote about iOS Back Button Confusion, outlining how having multiple back buttons on the same screen in iOS creates user mistakes or slowdowns as they determine which button they should use. I recently noticed the same issue with my RSS reader of choice, NetNewsWire (which is an outstanding app for reading RSS feeds on the desktop).

In similar fashion to the iOS apps, NetNewsWire has an embedded browser for viewing links. Thus, it also requires having two back buttons: one to exit the browser and one for going backwards in the browser history.

With NetNewsWire, as with iOS, I find myself exiting the embedded browser when I intended to go backwards in the browser history. This causes a small amount of frustration which adds up to a poor user experience over time.

My proposed solution still stands, as the dynamics of the problem have not changed between touch screen and pointer input methods: provide a way for the user to “undo” the act of closing the browser. For a deeper explanation of not only the solution, but the problem, take a look at the previous post.

iOS Back Button Confusion

Since I purchased my iPhone in September, I’ve had a consistent issue that is prevalent in many iOS apps. While small, it is a source of frustration nonetheless. My issue: back button confusion with embedded, in-app browsers.

Let me explain what I mean.

When a link is opened, many apps utilize an embedded web browser to display the web page instead of exiting to Safari (e.g. tapping a link in a tweet in the Twitter app). Upon opening, a traditional “app” back button is placed in the top left (let’s call this the “app back button”) which exits the browser to the screen where the link was tapped. The browser also gets it’s own back button for going backwards in the web browsing history (let’s call this the “browser back button”) placed at the bottom of the screen. This results in two back buttons on the same screen.

While this design is functional, having multiple back buttons on the same screen means I have to choose which one to use: do I want to go back in the app or browser history. While this is a simple decision that makes sense after conscious thought, it doesn’t feel natural. Since I wasn’t in a browser to begin with (remember, I tapped a link in an app), the website feels like an extension of that app and therefore I instinctually reach for the app back button, regardless of whether I wanted to go back in the app or the browser history. If I wanted to go back in the browser history, then I’ve made a mistake. This results in the browsing history being lost with no way to easily undo it; the only way to get back to the last web page is following all of the links again which is both annoying and takes time.

I’ve thought of two possible solutions to this problem (though I know there are far more out there) which I believe would fit nicely with the existing UI paradigms in iOS, and solve the problem explained above.

1. A single back button
2. The ability to undo exiting the browser

A Single Back Button

This solution would remove the confusion by having the app back button as the only back button; the browser back button wouldn’t exist. This button would go back through your web history until the first web page, then exit the browser back to the app. There is a major flaw, though; repeatedly tapping the back button could take too long if you’ve built up a history larger than a few pages in that browsing session (not unusual, especially for power users).

The Ability to Undo

This option would give the user a method to undo their action of exiting the browser, returning them to where they were before they tapped the wrong button.

To accomplish this, I propose that tapping the original link in the app immediately after exiting the browser would return the user to the same web page, with the browsing history restored. If, however, you tap another link or change screens in the app, that browsing session would be lost.

An example scenario for this solution would consist of the following steps:

1. Tap a link to an article in a tweet
2. Embedded browser opens the link in-app
3. Tap a link in that article to read supporting information
4. Want to return to the original article to continue reading, but accidentally tap app back button
5. Returned to the tweet and realizing the mistake, quickly tap again on the link to the article
6. Embedded browser opens to the supporting information, not the article, with the browsing history restored
7. Tap on the back button for browser history to return to the original article and continue reading

I believe this behaviour would feel very natural to users and is similar in concept to fast app switching since state is being restored.

Apple Forgot About Fitts' Law

I have this quirk when I’m reading something on my computer (website, PDF document, etc) that I want to keep my mouse pointer visible so I easily know where it is when I want it, but I don’t want it in the content area itself obscuring what I’m trying to read. The margin of the content is the perfect place for this and that is generally where I leave my mouse when reading.

The other day I opened 5 PDF documents in the same Preview window to read, putting that window into Lion’s handy full-screen mode.

When I went to place my pointer in the left margin of this preview window, however, it wound up hitting the left edge of the screen causing a nifty navigation pane to slide out. I thought to myself “Cool!” and took a mental note for later when I had to switch between the PDF’s.

I was then putting my pointer back in the left margin, being cautious not to hit the edge, when the pane appeared again. This had me very confused and after a few seconds of experimenting I found out that a 40 pixel column along the left edge of the screen (give or take a few pixels) is the trigger area for the pane — not the edge of the screen itself.

This design goes directly against Fitts’ Law. If you don’t know what Fitts’ Law is, I recommend taking a look at the Wikipedia entry (Success and Implications section) for a quick summary. I want to draw attention to one point in particular from there:

Edges and corners of the computer monitor (e.g., the location of the Start button in Microsoft Windows and the menus and Dock of Mac OS X) are particularly easy to acquire with a mouse, touchpad or trackball because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width.

This means making the trigger extend inside the edge of the window is unnecessary due to the infinite depth this pane comes out of. This is due to the fact that once I know the left side of the screen activates this pane, I am not going to carefully place my pointer there, I’m going to “throw” it left, letting it hit the edge (as I do now). This is a similar action to a person showing a hidden Task Bar (Windows) or Dock (Mac OS).

The only reason I can think of for Apple extending the trigger area into the content is to increase discoverability — a person might be more likely to move their pointer near the edge of the screen than actually hit it. Also, unlike the Windows Task Bar and Mac OS Dock which are visible by default, there is no indication that this pane even exists until you activate it. However, this design comes with a major consequence beyond the annoyance for my quirky mouse-placement ways: if there is ever content under that trigger area, it is inaccessible for annotation or selection (despite the margin being prime real estate for annotations)¹.

I have high respect for Apple’s design and execution in their software and hardware, but I believe something was overlooked here, or I am not seeing a use-case that this design is the solution for.