COMMON INTERFACE ISSUES

Designing an effective interface goes way beyond functionality. You have to be able to meet the needs and expectations of a wide range of users and you have to do it while juggling the limitations of the device for which you're designing. Some of the common interface issues you'll be facing as you design for devices include these:

• Designing for both haves and have nots

• Providing what users expect to find

• Figuring out how to help humans use what they already know

• Developing desktop functionality for device applications

Most computer-literate folks have, on their PCs, the icons reduced to next to nothing and the resolutions cranked up. Most people who are not computer-savvy have their desktop PCs set to whatever resolution, icon size, and color depth with which the computer came installed. Hence, the still lingering nastiness that is the web 216-color palette (which I hope we can soon regard as quaint, much in the same way that we regard 2400-baud modems these days).

An additional issue is that we interface designers are digitally "tuned-in," sometimes to our own detriment. A good example of this is the current trend of design-oriented web sites to use smaller fonts. Sure, it looks cool, but it is often just plain unreadable. Sometimes, the text written in that small size doesn't mean anything it's just there for design purposes. However, even then, the small size is detrimental because it's nearly impossible for a literate human being to look at text in this language and not try to read it.

This brings us to a very important point that interface designers can utilize; human beings are, for all intents and purposes, pattern-matching machines. We can pick out a single conversation from a crowded room and know instantly the face of friend we last saw 20 years ago. Our brains are wired to match patterns, so let's use that to our advantage.

A good example of this is what happened when I first started to use my Pocket PC. The interface looked and usually acted like the Windows I was used to, and because of this, I could quickly jump in and start working with it. However, years of working with Windows taught me certain patterns that at the time simply didn't exist in the Pocket PC world namely closing applications. I must have spent 30 minutes, on and off, looking for the little X to close Pocket Word when I was done writing. I knew and realized that the paradigm of using a Pocket PC was much different from a desktop one, but the continuation of my use patterns between the devices led me to look for a Close button when it just wasn't there.

Patterns are powerful things, and often, even though there might be a more efficient and usable way of creating an interface, it's best to stick with what people know. Yes, a Dvorak keyboard is better than a QWERTY one, but I sure can't come close to the 70wpm I'm currently typing on a Dvorak. You'll notice that this is the reason that the interface widgets that I talk about (and provide later in this chapter) aren't all that different from their desktop counterparts. It is important to know, though, that they are different so that they can deal with the restrictions of devices. Just plopping a regular desktop widget on a device will rarely work well; you almost always need to make some sort of modification.

Typing Made Tedious, or Why QWERTY Stinks

You might be wondering why our QWERTY keyboard is bad. It was actually designed specifically to slow us down! Early typewriters, being mechanical in nature, jammed easily when a typist got up to a decent rate. To avoid this jam-up, the standard keyboard was invented to keep commonly associated letters as far away from each other as needed to prevent the typewriter from jamming. Later, the Dvorak keyboard was invented to be much easier on our poor digits by placing commonly associated letters near each other. Alas, Dvorak has never really caught on, and unless you want to take the time to both find a Dvorak keyboard and learn how to use it, you are stuck typing with the parking brake on. It's also interesting to note that various other keyboard layouts have been designed especially for one finger or stylus-based typing. The best known of these, the Fitaly keyboard (www.fitaly.com) actually claims to enable users to type up to 80WPM using a single digit! The layout is based on both letter frequency in the English language and mnemonics. (The keyboard spells out various words, and by looking for words, it's easy to find letters.)

Many, if not all, of the modifications that were made to the widgets were in the name of simplicity. Even if we weren't talking about devices, simplicity would be the name of the game. However, simplicity is more important than ever when you are developing for devices (if for no other reason than that people use devices much differently from PCs). Devices need to be quick and simple to use or people won't use them. A good example of simplicity in interface design is the venerable Palm Pilot. It took Windows CE devices nearly three generations to begin to become even close to being as accepted as Palm-based devices. Anyone who has owned or used a Palm Pilot knows how simple the devices are to use. There is simply little to no learning curve. The fact of the matter is, if technology is going to try to replace a pen- and paper-based solution, it has to be just as easy, if not easier, to use than pen and paper.

A lot of what has been mentioned so far might have seemed like common sense to you. In fact, that's the point; a good deal of interface design is separating the "cool" from the "makes sense." Here's where a very important problem arises, though. As the person who has designed an interface, you know the program inside out and backward. It will nearly always seem usable to you! However, what you need to do is test your usability on a group of impartial, representative users as early as possible in your application development process. If your application will be used mostly by, say, middle-age housewives, have a group of them test the application rather than a group of hardcore UNIX sys-admins.

When you are doing your testing, watch your users closely. If they get hung up on a particular element, ask them what they were expecting and why. (You'll almost always get a good answer for the "what" part, but don't expect to get too much for the "why" part.) Look for patterns in your users where they get hung up, where they whiz through, and where they just seem confused. More than likely, you will be able to extrapolate from the results of such testing what needs to be done to your application.