Recent Blog Posts

As I've written in the past, one of the wonderful aspects of mobile devices is the availability of alternate input devices such as voice and camera. A recent News.com article on camera phone search technology describes several companies using the camera as web input.

Mobot does exclusively marketing, but they also have a more general image recognition technology. They target things like allowing users to take pictures of movie posters to get movie info or tickets, brand logos, CD covers, or any sort of printed advertisement to get information or purchase related merchandise (such as ringtones). I expect that the biggest issue with their vision of taking a picture of something like a movie poster rather than a special bar code is that not every movie poster would be in the database, leading to needing to put an extra message on the movie poster - or user frustration and eventual product abandonment.

Neven Vision appears to have a technology that is similar to, but slightly more generalized than, PaperClick (who specializes in bar codes). Neven Vision's marketing tool, iScout, uses visual hyperlinks to indicate "clickable" (pict-able?) items. They also have a more generalized product allowing users to take a picture of any product or picture of a product (such as TV or a print ad) that would allow the user to go to an internet site that has the product for sale. Again, until the majority of products are in the database this is likely to result in user frustration and abandonment of the product.

If the above technologies are possible, then it certainly should be possible for some travel and location based technologies to use the camera as an input. Imagine a visitor's bureau uploading pictures of their entire tourist region. A tourist could then take a picture of anything in the area, get directions, or further information on any location. This would be more accurate than most current GPS systems, with the additional benefit that it could work indoors (like in shopping malls).

The W3C's Best Practices Working Group has published a working draft of its Mobile Web Best Practices document.

Alas, both the group and the document are mis-named. They do not target "mobile web best practices", but "best practices if you have already made the limiting decision to write one web site that will work on desktop and mobile devices".

The recommendations in the document are general and only somewhat useful. For example, consider:

The service should be designed with a broadly balanced navigation tree where numbers of links on pages is balanced against depth of navigation.

Is this possible in a situation where you do not know how many links are on the page because it is dynamically generated based on device capability?

Or: "Group related links, identify the group and provide a way to bypass the group". This is great if you assume that browsers treat within-page links consistently. They do not. You could have a "skip" link that does nothing, causing major user confusion.

Or: "Do not create periodically auto-refreshing pages". That's exactly what I'd do if I had an email application or a stock tracking application. I might provide a way to turn off the auto-refresh, but when it is important that content be up to date, the content should be up to date.

Or: "Do not embed objects or script in pages unless you know the device supports them" This one makes sense, except that it should instead exhort designers to ensure that the page works with and without the script.

There is a lot of stuff in the document with which I agree. For hints on what those are, look at my basic style guide recommendations. There is quite a bit of overlap. Of course, I haven't updated my web style guide in a couple years, so some of these recommendations are out of date in a world where people are downloading songs and television shows. And my style guide is even referenced as the last item on the page, so that is pretty nice (an actual link would be better, as that would enhance my search engine results, but I'm not going to be picky).

Oh yeah - on top of that, the authors oversimplify what makes a site usable or not on a mobile device. Sure, as they point out, browser, site, and device usability all play a role - but equally important are the interactions between the user interfaces of the three as well as how well the site maches user goals in a mobile environment.

A site could be extremely easy to use on a small device, as long as the user completes the desired task before doing something else (like answering a call, receiving a text message, or getting off the train) but completely unusable when other things interfere. Factors affecting this difference include cookie use, transaction lengths, browser design (whether the last viewed page is available when re-starting the browser), screen design, and site information architecture.

A relatively standard configuration of buttons has emerged for scroll-and-select phone design. On most scroll-and-select phones, including Windows Mobile SmartPhone, many newer Nokia devices, any Sprint Nextel non-OS device (not Palm, RIM), and a wide variety of other devices you will find:

• Talk, End
• Back or Clear
• 4-way navigation
• Select or OK (the 5th way in so-called "5-way navigation")
• 2 softkeys

We'll leave the discussion of how we arrived at this point and whether it is a good design for a different day. For now, device designers are somewhat stuck with this arrangement due to requirements from carriers, OS manufacturers, and to some extent application environments like J2ME's KVM for MIDP.

What is a designer to do with a select key and 2 softkeys?

If your development environment includes inline controls like edit fields, date pickers, links, and checkboxes, then it is clear that the select key controls the widget. This behavior is the responsibility of the environment and not necessarily the application; an application designer can assume it works.

The softkeys for a widget-rich environment should have dynamic controls for either a specific widget or the whole screen. Be nice and follow the conventions and recommendations for your target platform. Try to limit yourself to a popup menu on at most one key (the secondary one) although there are times to violate this rule.

If your environment or situation instead is merely a set of menus whose items are displayed on the main screen, you have a plethora of options that can quickly lead you to a usability trap. You may find yourself inclined to use the select/OK button for navigation, and the softkeys to actually perform an action. Your users, unfortunately, will not understand your elegant distinction between navigating to a menu item (branch) and activating a menu item (leaf).

I recently had the experience of navigating through a menu structure, finally getting to exactly the menu item I wanted to use. I pushed the OK button again. Nothing happened. I backed up a level and tried again. Same result. The proper action was to use the now-labeled softkey to activate my target item, but it completely broke my flow and left me with the firm belief that my action was not actually possible, that the software was broken. The extra label for the softkey is nice confirmation, but make sure the OK button either replicates the softkey or launches a dialog box to confirm.

If you instead find yourself designing the core interaction behavior for a device and find yourself stuck with the keyset above, design different widgets for navigation menu items and action menu items. You now have different font sizes on the phone, graphical constructs, and some extra space. Use softkeys on action items to alter the behavior of the action, to allow quick binary settings, or to provide some type of shortcut. The OK/Select key can then be used for the default behavior, which may bring up a confirmation or other dialog with further information. But please - always have the select button select!