What The FITTS!

Lets assume for a moment that every button in the app is necessary (they aren’t, not a one). Who puts the navigation bar at the bottom of the screen, directly above Android’s standard OS navigation. It breaks every design trend in the book. Design trends Google has set!

If it’s location wasn’t bad enough, you went ahead and made the buttons 33% smaller than similar action bars on other apps, and even 17% smaller than the Android OS navigation bar. It’s like you want people to fail.

Button, Buttons, Everywhere, And Not A Use For One

No, you are not drunk; you do not have double vision. You are seeing that correctly. There is a back button, placed directly above the Android OS back button. I don’t…I…my head hurts.

What’s the icon next to it? It brings up a list of all the articles. You know, all the articles that you’re already looking at on the screen above you. Redundant? Redundant?

What’s that tiny button on the far bottom right? A next page button? You mean the ability to gesture across the entire screen to get to the next page wasn’t enough? What, you didn’t think the affordance to do so wasn’t emphasized enough with the pager displayed directly in the bottom middle? Even if you thought that this control was necessary, you don’t provide a back page button. Doesn’t it stand to reason if a user can’t figure out how to page forward via gesture, they won’t be able to figure out how to page back?

Not to mention that paging is utterly broken. Try to page to the left, past page one, and you get a bounce effect that it can’t be done. Try to page past the last page to the right, do you get the same bounce effect? No! You get an article. Who…I mean…I think blood is coming out of my nose.

Take a look at that share button as well. It does NOTHING! It’s available when you’re not viewing an article. Touch it, and you’ll share a link to a blank page. The only thing the page contains is a recursive link back to itself, and a link to get the application for your device. Wha…it…no!

Conclusion

I want to punch something. I want to punch something so hard that it hurts as badly as I do.

The first thing I did was make some assumptions. I assumed:

• That the Translate button would cause the text in the input box to be converted to the the appropriate language in the output box.
• That the Speak button would bring up the voice-to-text feature of Android phones for adding content to the input box.
• That the Listen button would read the text in the output box with the Android phone’s text-to-speach feature.

The next step was to isolate some of the problem areas of the current design. I came up with the following:

• The content in the labels is too impersonal. People using this app are human, not computers. The labels should read “From” and “To,” or be removed altogether.
• The Speak and Listen buttons are too far away from the components to which they’re supposed to control. It breaks their relationship, and they need to be moved closer.
• If there’s no content in the output box, then the Speak button should be deactivated, or not even present.
• The default Android style is ugly.

Having fully considered application, design, and it’s problems, I began the task redesigning it.

I started with the color scheme. Peter-W’s first redesign attempt used blue and orange. I thought this was a good choice, and stuck with that. Blue, being a corporate and trustworthy color, which meshed nicely with a translation app. Orange, being blue’s contrasting color, and a good way to make important elements pop.

The next thing I did was figure out how I could layout the UI in such a way that it would address all the problem areas.

The label remained at the top, but was made larger and more visible. Its important to have labels for your apps. Android is a multitasking OS, and often launches other apps while working within another (e.g. Gmail launching a PDF reader). The label provides a landmark to the user, letting them know where they are.

I then tried to figure out how I could simplify the UI. If I was seeking to translate something, the first thing on my mind would be, “from what language to what language?” By moving the language selection boxes to the top, and providing an arrow pointing from one to the other, the labels become superfluous.

The next logical step would be to enter some content. So, the next UI element was the input box. The Listen button was replaced with Android’s voice-input icon, and placed inside the input box. This provided a close relationship for it’s functionality. I also added a delete button to the top right. Android’s voice-to-text feature is pretty good, but far from perfect. Allowing a person quick access to a way of removing errors would certainly help speed up input.

The Translate button remained at the bottom. Even though the button is far away from it’s relationship with the input box, its color and size denotes it’s importance. It’s location would also move a person’s finger to out of the way, to see the result.

The result to the translation would show under the input box, creating it’s relationship. The text was made slightly larger and darker. This was to promote it’s importance, and also aid in it’s readability in an unfamiliar language. The Speak button was changed to Android’s sound icon, and placed next to the result. This would remove the button until there is something there to read, and create a better relationship.

That’s it!

This is the best I could do with just a couple of minutes work. From here, I would normally progress to some form of user testing. One thing I would want to find out is if the Translate button could be removed all together. That may help speed up the translation process, but may drastically slow things down if their were input errors. Again, only user testing would flesh that out.

Hope this snapshot of my work process helps some of you with your designs.

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

What I expected from the car dock:

• To hold and charge my phone
• To make and receive phone calls
• To act as a navigation device
• To play music on my car stereo

To Hold And Charge My Phone

More often then not, your phone is an after thought to driving. Your phone lives in your pocket or purse, and there it remains until it is required. Mounting your phone to the dock often happens after you’re already driving, and you suddenly need directions, or want to listen to music, or make a call. The ability to easily mount the phone to the dock is essential. Google simply was unable to get it right. The main problem is with the clip system that holds the phone in the dock.

When you try and put the phone into the dock, the clip gets caught on the seam between the battery cover and the phone casing. The first few days of use, no amount of reasonable pressure could be applied to clip the phone in using one hand. Mounting the phone was a two hand job. It took me a few days to figure out out how to hold the phone to the mount, while simultaneously pushing on the clip.

Two handed mounting of a phone to a car dock is simply unacceptable (you’re driving remember). The ability to mount the phone with one hand is a learned process. This issue detracts from the initial experience with the dock, making it feel clumsy.

To Make And Receive Phone Calls

Sending and receiving calls while driving is risky business. Distracted driving accidents are on the rise, and many states are passing laws for banning hand held cell phone calls. In order for this car dock to succeed, it should make the process of making and receiving call easier. Again, I simply didn’t experience it.

Mainly, the speakers on the car dock are simply not able to produce audio loud enough to hear. I talked with my mom for over an hour while on the road last Friday. Over that time, I continuously fidgeted with the sound volume and positioning of the dock, but could never achieve the voice clarity I expected. The voice seemed to fade in and out of clarity, and couldn’t compete with the road noise. This problem is due to how volume works when mounted on the dock.

There are two things that are controlling volume; there’s the phone volume, and the device volume. The phone volume decides how loud it’s going to push out the sound to the device. The device volume is how loud your device is going to interpret the sound it’s being pushed. So, if you’re call volume (or navigation voice) isn’t set to max before mounting the phone, the dock won’t play louder, even if you turn your device to max. You have to unmount the phone from the dock in order to increase volume, since the dock obscures the Nexus One’s volume rocker, then remount the phone.

The docks speakers themselves, are simply inadequate. Because they face away from the driver, the sound has to reflect off your windshield and come back to you. Even at full power volume, on the phone and dock, I simply couldn’t clearly hear my calls over the sound of the road. What Google could have done is make the dock speakers full volume, left the Nexus One volume rocker open, and provided a stereo jack to send sound to your car’s speakers.

One last peeve is the “slide to answer” feature of the Nexus One. While the phone is docked, it becomes difficult to accurately slide your thumb vertically across the screen. My right hand thumb keeps wanting to go up, and to the right. This continuously makes me drop the button. I find myself watching the device, instead of the road, so that I accurately complete this gesture. A large and in charge dedicated answer button on the dock would have been a welcome addition.

To Act As A Navigation Device

One of the popular features of the Nexus One is it’s out-of-the-box ability to be used as a turn-by-turn navigation device. Google marketed the dock as a way to enhance this feature, and it’s clear that they felt this was the dock’s main purpose (however short sighted). I’m sorry to say that the dock does nothing to enhance this experience.

To start, the dock does not allow the holder to be infinitely rotated to the left or right. The cords running up through the inside of the mount, delivering power from the base, would eventually break if they allowed a full 360 degree turn. This creates an portrait/landscape issue when the phone is mounted on your dashboard. Right rotation is prevented by the stopper. So, rather than a simply 90 degree turn to the right, a full 270 degree turn to the left is required. Flipping between landscape and portrait views is cumbersome, and unforgiving. A different positioning of the stopper would have solved this.

Second, navigating to places with the dock is actually harder to do while docked. One of the great features of the Nexus One Navigator was the ability to create destination shortcuts on my home screen. All I had to do is tap the icon, and up launches the navigator and routes me to where I want to go. The dock buries my shortcuts behind another layer, the car dock home screen. Some customization, like favorites, to the car dock home screen is need.

Last, like the in call volume issues I described earlier, Google’s navigator suffers from the same volume issues as in call volume while docked. It still stands that obstructing the volume rocker, and not providing a stereo connection was a mistake.

To Play Music Over My Car Stereo

I commute a distance from home to work, my ability to play music, podcasts, and audiobooks while I drive is important to me. It’s clear that playing music while the phone is docked was never thought of by Google as a use case. Shocking!

What I expected was for the dock to have a 3.5 stereo jack, and to pass music audio to it via the Bluetooth Advanced Audio Device Protocol (A2DP). A reasonable expectation since that’s how they did it with the Desktop Dock. They don’t. If fact, it almost appears like they made no effort at all to think about the audio experience of the Nexus One while docked.

What you have to do instead, is insert your car’s auxiliary audio cable into the 3.5 stereo jack on the Nexus One phone itself. While this will send music to your car’s stereo, you can’t control the volume, since the volume rocker is covered up (as I stated earlier). Also, since the sound is coming in as analog, instead of digitally via Bluetooth, you get a whine and ticking noise from your car’s alternator as it charges your phone. Had they provided the stereo jack on the dock itself, it’s conceivable they could have added in some hardware to properly dampen the feedback, and provided a superior sound.

Last, there is no shortcut in the Car Dock Home Screen to the audio player. A media button would have been nice. Sometime to easily bring you to the music player, or Listen, or Pandora.

In Conclusion

Google’s Nexus One Car Dock only provided me with a kludgy and frustrating experience. Other than it’s ability to hold the device in a visible position, it doesn’t offer a single enhancement to the phone, and only serves to hinder it’s use. Even a few hours of use case testing would have discovered most of these issues. Chalk it up to more Developer Underpants from Google.

Video Illustration

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 come 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 remain a shocking usability blunder made by Google.

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.