marco:

Why I went to great lengths to implement this tiny feature.

This article is a great example of the things that software developers and designers must go through to make a really good app. The devil is always in the details, and it really goes to show when someone cares about what they are producing. Now, to try and resolve the issue at hand:

There are only 2 possible scenarios that should catch 95% of the interaction:

1. I was reading something, I accidentally tapped the top of the screen and now I’ve lost my place. Crap!

USER INTENT: This was a mistake, I want to reverse it.
SOLUTION: Tap “Return to Position”

2. I was reading something and I tapped the top of the screen to go to the beginning of the article.

USER INTENT: This is what I wanted to do.
SOLUTION: Ignore the “Return to Position” popup, and go about your business (re-read the article, click on a link, etc.)

By adding a “Cancel” button, you are introducing 2 more possible, but more obscure scenarios:

3. I was reading something, I accidentally tapped the top of the screen and now I’ve lost my place.

USER INTENT: This was a mistake. I want to reverse it.
SOLUTION: Hit “Cancel”, and nothing happens. I’ve lost my place.

4. I was reading something and I tapped the top of the screen to go to the beginning of the article.

USER INTENT: This is what I wanted to do.
SOLUTION: Hit “Cancel” so that I can go about my business (use the Instapaper menu that the “Return to Position” prompt replaced)

Scenarios 3 and 4 are deviations of intended use, and they are not necessary for this interaction to work properly. Scenario 3 is a mistake, and even though there is a button that’s clearly labeled “Return to Position”, by introducing another option you automatically introduce a chance for user error (no matter how small).

Scenario 4 occurs with an intended action, but you are putting the user (that could be considered an “expert” for using the tap-the-top feature) through another interaction to justify what they wanted to do.

Chances are that any action that the user wanted to perform if they tapped the top of the screen has nothing to do with Instapaper’s menu bar that resides at the bottom of the screen. Therefore, when the user taps the status bar and the Instapaper menu turns into the “Return to position” bar, chances are that the user did not need/want to interact with the menu at the bottom of the screen. The theory here is that If the user wanted to interact with any of the 5 actions at the bottom, they would have done so at the position where they were currently reading. I am guessing that this was the justification in temporarily replacing the Instapaper menu.

This justification brings about the core problem of this interaction. What if the user wanted to scroll to the top, but then immediately interact with the Instapaper menu at the bottom of the screen? The “Cancel” button is confusing, and the 5 second delay is too long to sit around and wait for the menu to turn back to it’s orginial state.

What if I accidentally tapped the top menu bar, lost my place, and mashed the first button I saw (Cancel) but as soon as I tapped it I glanced over to the other side of the screen to see the button that I really should have tapped to begin with! Dad-gummit!

The design decision of replacing the Instapaper menu with the “Return to Position” prompt makes sense aesthetically, but it’s the point at where you limit your user’s interactions. It also creates the need to have a “Cancel” button that just gives the user another place to screw up.

Marco, I know that you like symmetry and the consistency in the application. Therefore, here is the solution that I propose:

Show an additional bar at the bottom of the screen, but above the Instapaper menu that states: “Touch to return to positon”. Example:

You hit it right on the nose when you said that: “[The interaction] differs from systemwide behavior, which is usually the wrong choice.” except that the iPhone utilizes this same concept when you navigate away from the active phone call screen! Conceptually, both interactions are just buttons that takes you back where you need to be if you navigated away by accident.

The caveat here is that you let the user know how long this little pop-up will be active for. This way, they can choose to disregard it completely without worry that it’s going to affect them in any way. The timer effectively removes the need to have a cancel button that could lead to a mistake, since the only 2 options are to tap or wait for the popup to disappear. We can also remember the fact that this screen will only be unfamiliar once, and the reinforcement that comes with repetition will only make it easier to use.

Not replacing the Instapaper menu also allows those expert users to interact with those items without penalty. The only thing we have to take into consideration is the new Tap Zones for pagination that were just introduced! It would make sense to keep the size of the zones the same, but just displace the bottom zone upwards by the width of the new bar to allow the user to scroll down. If the user decides to scroll (or tap to scroll), the popup should remain just in case they decide to go back to their original place. This simplifies the interaction (as well as the code) by always ending the interaction in the same manner, which is by the timer running out.

This solution is more unobtrusive in terms of the functionality of the interface, but IS heavier visually. I think that the benefits outweigh the potential drawbacks, and that can only be confirmed by your mention of the customer emails you have received with complaints. As designers and developers, we ALWAYS want to err on the safe side when it comes to “data loss”, but always to a sensible and realistic level. I had a lot of fun thinking this one through, and it only goes to show how the simplest applications just have so many interesting and difficult caveats to solve!

LESS is one of those things that just should have been there from the start. CSS variables, class mixins, and more make this just awesome. On top of that, throw in an automatic compiler for OS X, and this night just got much much better.