These screenshots show the content of the app purchase screen in one of the older releases of Android Market (before rebranding to Google Play). The screen combines billing information along with the list of all app permissions and various terms & conditions. If the specific application requests a non-trivial number of permissions the user can scroll down to view them all. An earlier entry on this blog has talked about the technical aspects of synchronized scrolling, whereas some content stays fixed (summary), some scrolls to snap (buy button) and some fully scrolls (billing table and permissions).

This screen is consistent with the system UI for showing application permissions. Permissions are grouped, you can tap on each group to view more detailed description, and by default we only show the dangerous permissions. The “See all” toggler allows expanding the normal permissions, following – once again – the system UI. I’ve been working on this screen on and off for quite some time (you can compare these screenshots with the earlier iterations to see slightly different styling of each permission group and vertical spacing around the buy button, for example). The next group of screenshots shows what happens when you tap on the “See all” toggler:

When the “See all” toggler row is clicked, it changes the arrow orientation to indicate that there is now more content below it that can be swiped up – as shown in the last two screens. This behavior was obvious to me because I know all the technical details behind the implementation and has been through these motions countless times during the original development and subsequent bug fixes and styling enhancements.

Which is why I was quite surprised to get an internal bug report that this behavior is not very usable. And indeed, if you compare the last screen in the first trio with the first screen in the last trio, the only user-facing difference is the direction of the arrow icon. That’s it. Nothing more. In fact, since we don’t want the arrow icon to be too heavy, you can even say that nothing changed as a result of user tapping this row. Which is bad. Quite bad. In fact, multiple subsequent taps on this row do nothing (user-facing) expect toggling the icon. Which means that if you tap this row in the rough vicinity of the “See all” label, your finger has most likely been obscuring the icon all along. This is a sure recipe to make your users angry.

It took me some time to understand why I didn’t see this as a big issue. I’ve been spending so much time on this screen, both as a developer and as a user, that I was going through the motions automatically. I know – as the developer behind this screen – what happens when I – as the user – tap that row. I stopped looking at the icon, just knowing that additional permission rows will be shown after the tap, and all I needed to do to see them was to swipe up. In fact, I’ve never looked at this screen as a first-time user.

Alex Faaborg talks about this in the “Advanced Design For Developers” session at Google I/O 2012 (starts around 4:40, with the quote at 8:30 mark):

I would argue that even though it’s really useful to have access to user research facilities, you don’t have to have them. You can just start running user tests in your head, basically short term amnesia. What you have to do is to encapsulate your mind, to forget the things that you know about your interface, to try to look at it with fresh eyes. Try to think about it as “OK, I’ve never seen this thing before.” If you can do that, if you can look at it with fresh eyes, try to let all the assumption that you’ve built up to fall away, then you’re able to do that kind of user test, just on yourself. And if you’re regularly doing that, it’s going to quickly improve your applications.

Here is how the interaction with the “See all” toggler looks in the latest version of the Play Store application:

The first screen shows the default state, where only dangerous permissions are shown and the toggler shows a downward arrow. When “See all” is tapped, we do two things:

• The label changes from “See all” to “Hide”. This follows the system UI and highlights the change in the visibility of normal permissions.
• We also scroll up the newly added content using the ScrollView.smoothScrollTo() API.

While the label change elevates the arrow direction toggle to a somewhat more visible degree, it is the smooth scrolling that shows the user not only that we have processed his tap, but that we’ve also added the relevant content (normal permissions). By scrolling the new content into the view we indicate that it’s there, and it’s ready to be read and consumed.

As you can see in the second screen, we limit the actual scrolling so that the “See all” / “Hide” toggler stays within the visible content area. For applications with few normal permissions (such as in the third screen) this means that we’ll scroll the content all the way to show all the normal permissions. For applications with more normal permissions the smooth scrolling will ensure that the user sees as many of them as we can fit, while not getting “bumped” down all the way to the bottom of that long list.

And so, be mindful of what you “know” about your application. The more you know, the less you see.