Last week, while traveling for business, I ended up with a rental Hyundai Sonata. While slogging through LA freeway traffic, I adjusted the preprogrammed radio stations to my liking. I then checked to see if there were steering wheel mounted controls, so I could scan the stations and adjust volume without taking my eyes off the road.
Well, yes on one count. The Hyundai did have steering wheel mounted audio controls, but in a curious configuration:
What struck me as odd was that the volume controls were tucked away behind the main face of the steering wheel, while the station controls where on the front. I actually had to duck my head and peer behind the steering wheel to determine the placement and functions of the buttons. Once I sussed out where the buttons were located, I had to modify my grip on the steering wheel to reach them, extending my fingers out as if I was holding a phantom soda can in my left hand. This was uncomfortable and made me effectively steer one-handed.
Contrast this with the button placement on my wife's Honda minivan:
The buttons are all right up front, no neck craning or awkward peering necessary. Additionally, they can all be easily manipulated by my thumb while my left hand is in the normal '10 o'clock' steering grip position.
I can only imagine that the Hyundai designer was trying for something 'neat,' both in terms of visual presentation on the front of the wheel and in terms of functional gimmickry, trying to be different for the sake of being different. The end result is a lack of what I call contextual awareness for the controls.
If this were some trick looking iPod dock, meant to sit on a bookshelf or mantle and exude sleekness, I could forgive odd or non-standard button placement- once you learn where the buttons are, it's not that much more difficult to use it. However, the context of steering wheel mounted audio controls is completely different- not only is the user in a situation where their attention is probably more divided than usual, but they are actually impaired in their ability to perform one of the main functions of the vehicle- steering it clear of obstacles - while using the control. Taken to the absurd extreme, the Hyundai controls could actually contribute to your demise as you fumble and peer for the proper controls.
I highlight this real world example to draw a parallel with controls or input methods in online applications that similarly fail to understand the context of their use. Typically, non-context aware controls on the Web don't lead to a shower of glass shards and an airbag deployment, but they sure can put a dent in the enjoyment of your trip. You've experienced them- usually when you're undertaking some sort of task and you're stopped dead in your tracks, trying to figure out what the web page wants from you to continue.
Some common examples:
• Dropdowns to set data more easily entered as text, such as an event time in a calendar application, or worse- year of birth, with a dropdown listing years from 1945 to the present (I've seen that a few times, sadly). This is typically the result of a desire to limit the possibility for mistakes on data entry, but it shifts the burden to the user when errors could just as easily be checked and trapped in the background in many cases.
• Popups (such as calendars) that set data on the main page. Again, this strikes me as lazy programming - if you want to provide a piece of function that will take up an inordinate amount of space on the page when not being used, there's better ways to manage that than by banishing it to a popup. By moving a control function out of the flow of the page, you introduce ambiguity about what action to take next, and increase the possibility of errors.
• Unnecessarily deep drop-down menu trees. In a misguided attempt to mimic some desktop apps, I've seen web apps that offer three and four level deep dropdown menus for navigation. Typically, your mouse needs to follow an extremely narrow and precise path along those menus to prevent them from popping off and leaving you where you started. I invariably abandon the tightrope act and try and find another means to reach the subpage. In one case, I actually had to view the source of the javascript that generated the menus to pull out the URL I needed when I couldn't manage to thread the correct path.
These are just three of many similarly annoying web gadgets that fail to understand the context of most online applications: to allow you to complete a task or to obtain information as quickly and easily as possible. Forgetting, or worse, flouting that goal is what leads to high bail rates and low stickyness. Are those things worth showing off your neat Flash drag-and-drop skillz on your main site navigation? About as worth it as a car crash when you're trying to find a decent station while driving.
Tuesday, August 12, 2008
Thursday, August 7, 2008
Per iPhone: Google is a Verb
Although the Oxford English Dictionary has already decreed that the term Google is a verb, a more culturally relevant institution - the iPhone - has resoundingly confirmed it.
Here's the search screen from the iPhone's implementation of Safari:
Once you've entered your search term, you're invited (by the active, blue button on the lower right) to Google it.
I'm now searching the rest of the iPhone interface for definitive answers on energy independence, gay marriage, and the nature of free will - I will post those revelations as they emerge.
Here's the search screen from the iPhone's implementation of Safari:
Once you've entered your search term, you're invited (by the active, blue button on the lower right) to Google it.
I'm now searching the rest of the iPhone interface for definitive answers on energy independence, gay marriage, and the nature of free will - I will post those revelations as they emerge.
Subscribe to:
Posts (Atom)