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.

A few days ago I saw on Mashable, a notification bar pop up with a Google+ call to action. It was a great little addition to their site, not overly intrusive, that I really wanted to add to my own. So, I built out the Google+ bar, and added it to my own blog.

I also packaged up all the files you need in order to add this feature to your own site. I had to use Google’s Catull font, which is not included in the ZIP file for copyright reasons.

Download The Google Plus Bar Example (google-plus-bar.zip)

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.

I hope to find or recreate the missing images from my posts soon. At least the content is back. To everyone reading this, take the time to backup your blog!

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

While this experience has worked great for the user that visits a site by computer, it fails when visiting a site by phone. You can’t point your phone’s camera at your phone’s screen. That’s why I propose a new standard for using QR Codes on websites.

When posting a QR Code on your site, always:

• Make your QR Code at least 100×100 pixels for easy scanning.
• Put the link in the alt and title parameters of the QR Code image
• Encase your QR Code image in a link tag that has the same link as your code.

By doing this, you will ensure that you are maximizing a person’s ability to make use of your QR Code. Those users that are visiting your website via their phone’s browser, will be able to click on the code with the same result as if they scanned it. Users that visit your site via browser, can still scan the code, and will be able to see what the QR Code is providing by hovering their mouse over the image.

Here is an example:

<a href=”market://details?id=com.android.flashLight”><img src=”http://flash-the-brain.com/wp-content/uploads/2010/07/qrcode.png” style=”border: none;” alt=”market://details?id=com.android.flashLight” title=”market://details?id=com.android.flashLight”/></a>

A very thought provoking image appeared on Astronomy Picture Of The Day yesterday. The boys at NSF ran the sun’s light through a spectrum to see what visible light the sun produces. As you can see from the image, there are swatches of color our sun doesn’t make.

This understanding might have a practical application in the Usability space. We as humans have evolved over the years to see color. But, humans may have difficulty discerning certain colors due to their rarity in nature. This may be something to take into account when trying to decide on the use and application of certain colors in the products we create.

Food for thought at least…

I myself still feel quite the novice to Interaction Design. My background is in Computer Science. While this has helped bridge the gap between design process and development process in a corporate environment, it hasn’t helped much with cognitive psychology or design research. For that, I ravenously devour books on the subject, and make it a point to design every day.

Designing every day doesn’t require a lot of time. In most cases, it’s just a few seconds. My popular tapestry is the office kitchen, since it’s in a constant state of disarray, and problems surface easily. Take for instance the milk for coffee.

Here we see the creamer cartons as someone placed them into the refrigerator. Which of these is the open one? It can be hard to tell. They’re all facing the same way, some are in front, others are in back, colors differ. In a few seconds, I can redesign this space to make it clear as to which of these cartons is the open one to be used.

If you truly love Interaction Design and it’s something you want to be, seek out small design projects throughout your day. Constantly analyse the world around you. Look for areas of difficulty or confusion no matter how small and trivial. Seek to make a space more functional when you leave, than it was when you entered it. Practice makes perfect.

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

There is nothing that I can write about this video that will do it justice. My mind is swimming with excitement and possibilities.

(via Engadget)