How List Jumping Currently Works

In order jump further down the list, you must first start by scrolling. This is done by placing the finger on the list, and moving it up the screen. Logically this feels backwards, moving your finger up to scroll down, but it makes for a pleasurable experience because you appear to be moving a physical object. When you start scrolling, a little tab pops up somewhere on the right side of the list based on how far down you’ve scrolled. To skip to list items that start say, with the letter ‘G,’ stop scrolling and place your finger on the jump tab and start dragging down. As you do, a letter will appear in the center of the screen, defining what letter items in the list currently begin with. When you have reached your letter, you let go, and can go back to scrolling normally.

Why The Current System Is Flawed

Having used the current list jump method for some time now, I have noticed several flaws with the solution’s interaction.

1. There is no way of initiating a jump without first needlessly scrolling.
2. There is a half second pause in your brain every time you use it, because it changes the interaction from “moving finder up,” to “moving finger down” in order to scroll.
3. It is wildly inaccurate. There is no standard iteration of distance to find the next letter. Instead, it bases the distance you need to scroll on the number of items in that list that start with a specific letter. So, if you have a long list of ‘G’s, a short list of ‘H’s, and a long list of ‘I’s, it will be incredibly difficult to land on the ‘H.’
4. It is time sensitive. The UI control for list jumping is not always on the screen. It comes and goes based on the amount you have scrolled, and how long you have stopped. The control may vanish before you can find it with your finger.

One Way To Fix The Experience

In order to list jump with this interaction, a user would first pinch the list. This is the same interaction used for zooming out on images and maps. Next, a new view will appear, overlaid on the list, showing all the different letters of the alphabet. The user then selects a letter they wish to jump to, the view will vanish, and the list will jump to the first item that starts with the selected letter. At this point, normal scrolling can resume.

Why This Fix May Be Better

Only usability testing will define which implementation is better, but their are indicators of how this may be an improved experience.

1. It makes use of a widely used gesture (zoom) which maps well with the interaction.
2. It does not attempt to change the already established interaction of scrolling.
3. It is potentially more accurate and affords kinesthesia. The consistent position and spacing of each letter allows a user to master the interaction.
4. It is more obvious that the list does not contain items that start with certain letters.
5. It can be initiated without having to borrow from another interaction.
6. Fitt’s Law: The hit area for this gesture enormous in comparison to the current method, which will potentially make it a more reliable interaction.

Demonstration

How You Can Help Make This A Reality

If you would like to see this interaction come to your Android powered phone, let Google know! Find my feature request ticket, and ask Google to add this feature.

Try It Out Yourself

As requested by commenter Zach, I’m providing a download link to the AIR mock-up APK (requires the Adobe AIR Pre-release). Pinch the list to get the alphabet list, ‘J’ is the only letter you can tap, tap the list again to reset the list to ‘A.’

Download list_jump_1.0.0.apk

Recently, someone on YouTube posted a video of how your hand effects the signal strength on the Nexus One (via Engadget article). Based on the comments that came out of the article, I don’t think it illustrated just how terrible of an issue this is.

As my video illustrates, all it takes to lose two bars worth of 3G service on the Nexus One is for you to simply hold your phone. In low coverage areas, this can spell the difference between not having 3G, and having it. On top of which, a simple shift of the hand can cause drastic changes, like dropping a call or important data transfer.

I think this continues to show how much Google is lacking any kind of effective usability testing within their Android department. Sure, HTC put the phone through the ropes, but it boggles the mind to think how something this severe would have made it through.

Update (2/18):

I got a email from Google today about the problem. This is what they stated.

Thanks for your note. There are a variety of factors which feed into the quality of 3G connectivity on mobile phones, a number of which are dependent on the environment rather than the phone itself. For instance, a software update can’t address the experience of users on the edge or outside of 3G coverage areas.

We have taken note of your feedback and we are already working on this.

I really don’t see a software solution to this problem. It has everything to do with an extremely poor placement of the antenna. I empathize with the difficulty of where to put such things. They have to pay attention to growing concerns over radiation from these devices while holding them up to your ear. Which, is why they’ve started to place them at the bottom. It’s just, that phones should be single hand devices. In using them as such, people tend to cradle the bottom of the device with their palm, in order to free up their thumb to type on the screen. The default positioning of the hand on this device completely covers the antenna area.

I see no way of fixing this other than by moving the location of the antenna.

The key draw of the Nexus One Desktop Dock is it’s ability to receive stereo audio over Bluetooth. If you were to connect the dock to your stereo system, you could transmit and control music from your phone without wires. A very exciting prospect. Unfortunately, Google utterly fails with it’s execution.

Who Reads Manuals, Honestly?

You don’t need to be a rocket scientist to setup the Nexus One Desktop Dock. I mean, there’s only one cord for power, and another cord that’s for audio. Those cords can only plug into the port with the respective shape. Also, the phone is only going to fit into the device one way, standing up and facing forward. So, who’s going to read a manual? Nobody.

If history has shown us anything, it’s that people do not read manuals. They blunder along as far as they can go, then consult the manual when they hit a bump. And, herein lies Google’s Usability FAIL. When you first dock your phone, you are presented with the following screen.

This is the setting box you need to check in order to send audio via Bluetooth to the dock. Yet, the language for this setting makes no mention of this. This selection also sounds scary, and that by checking it you’ll silence your phone. There’s one more key point, the “Remeber setting” checkbox is pre-checked! If you do any of the following, this settings box will go away, and never comes back:

• If you press, “OK.”
• If you hit the, “Back” button on your phone.
• If you remove the phone from the dock.

So, you’ve done one of the above and you played a bit with the Clock application. Now, you want to try the Bluetooth audio streaming. You can’t find the dock when scanning for it in your Bluetooth settings because it’s not currently turned on. Suddenly you realize what that pop-up setting box was for. How do you bring it back? There’s nothing in the Clock application, that which appeared when you docked your phone, that will display the setting. Removing the phone from the dock, and pouring through the phone settings will not reveal a way to make it reappear either. And, guess what? It’s not in the documentation or support forum for the dock either.

As far as the user is concerned, they blew their only opportunity to get their dock to work.

So What’s Missing?

It turns out that there actually is an option in your settings to re-enable the dock’s audio. In order to find it, you have to have your phone docked, then you navigate to Home > Settings > Sound & Display > Dock audio.

This is something the average person would have no way of stumbling upon. It’s also a key component, completely overlooked, in order to use the dock.

They could have fixed this by:

• Not having “Remember setting” automatically checked.
• Provided some feedback as to where the dock settings could be found after you choose your setting.
• Documented how to find the setting in the manual.
• Provided a shortcut to the setting in the Clock application’s menu.

Until this happens, it remains a shocking usability blunder made by Google.

Update: April 8, 2010

It looks like Google has addressed this issue in great detail.

They removed the dock settings from the “Sound & display settings” area all together.

They added a “Dock settings” button to the Clock application’s menu. This is the application that launches when you dock the phone.

Last, they removed the scary “silences phone” language from the setting.

Good job Google. High fives all around. I’m going to assume that you’ve also fixed the documentation that ships with the phone as well.

Corporate Underpants was a great idea for looking at how website content is organized. Basically, whenever you see content of a site organized in such a way that it reflects the internal structure of a company, you’re seeing the company’s “Corporate Underpants.” No one cares about your “Products Division,” “Service Division,” or “Human Resources.” They want to “buy a product,” “get help”, or “get a job.” Tamara argues, that a site’s content should be organized as to reflect the goals of your audience. Applying Tamara’s concepts to application, we can start thinking of user interfaces in the form of, Developer Underpants.

Developers are inherently lazy when it comes to the user interface design. It’s not their fault, their goals are just different. Developers live and breath logic and algorithms, they deal with absolutes. Developers don’t care where a button needs to go. If a button is needed, they make a button. Where do they put it, wherever there is space. In the end, applications become confusing, bloated with UI elements, and inconsistent experiences. They show their Developer Underpants.

I’m going continually add posts to this category discussing bad UI decisions. I’ll deal with Mobile Platforms. Mainly because I find it the most fun, and mainly because I think this fledgling landscape is ripe with abuse! We have the iPhone, Android, Windows Mobile, Palm WebOS, and Blackberry all competing to become king. As developers scramble to get their applications out to the greatest audience, they will be porting programs from one platform to another with disastrous results.

Time will tell what kind of trouble this category will bring.