Interface Design for Devices
- Common Interface Issues
- Special Considerations for Devices
- Creating Standard Components for Devices
- Optimizing Interfaces
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Topics covered in this chapter:
- Understanding common interface issues
- Special device considerations
- Creating standard components for devices
- Optimizing interfaces
It would be an understatement to say that designing good user interfaces is tough. It is, in fact, so difficult that there are numerous Ph.D. dissertations written every year on the subject. However, to summarize all the difficulties with good interface design, you could simply say that people are a problem.
Our attention span is short, our eyesight is in various stages of deterioration, and our hand-eye coordination varies greatly, just to name a few of our maladies. Toss into the mix that we are sometimes plain and simply dense, and you can see the formidable challenge posed to any interface designer.
In this chapter, you are going to learn about common interface issues, certain considerations you need to keep in mind when developing for devices, how to use some specially built interface components for devices, and how to optimize the code that makes up your user interfaces. This chapter won't make you an interface design guru, but it will help prevent you from making some of the most common interface mistakes, as well as give you some tools to help you create good user interfaces for devices.
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 (http://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.