Read an Excerpt
Chapter 3: The User Interface
We have looked at the application-design process as a list of general dos and
don'ts, so now we will look at the specifics of a user interface for a WAP device.
This consists of screen layout and menu design considerations primarily, but
we will touch on other aspects as well.
User Interface Basics
A
user interface can be roughly defined as the set of routines and procedures that a user has to
follow when working with a device, whatever it is, in order to use that device as intended.
User interfaces do not only apply to computer software. Anything that is used in
some way has a way of being used. This is commonly called design or style. It's all part and
parcel of the same thing, however. Even vegetable peelers differ between brands. The one
that feels comfortable when you are actually using it is probably the one that has had the
most investment in terms of design, or user interface.
Any user interface has to be learned by the user. Most people in the developed world
can operate a television and any associated remote control fairly easily, and it is pretty
much taken for granted that this is so. However, working a device like a radio or a TV still
requires a basic set of experiential reference points. If the reception isn't good, we know
that we need to adjust the aerial or complain to the cable company, depending on how
you receive the transmissions. Even adjusting the aerial requires an understanding that
the aerial needs to be positioned properly to catch these invisible signals.
Now, hands up if you can program your VCR easily. I still have trouble with mine,
and I have had the same machine for over five years. In fact, the VCR is almost the archetypal
example of a badly designed mechanical user interface.
So, if the user always has to learn an interface, we need to try and make the learning
curve as easy as it can possibly be.
When people are using a mobile phone, they are working on the basis of their previous
experience with telephones. It doesn't matter that the phone can access the Internet or
act as a calculator, alarm clock, or whatever. If it looks like a mobile phone and acts like a
mobile phone, then the laws of association say that I, and most users, will regard it as a
mobile phone, and not as a mobile computer or anything else.
This is probably why there is some difficulty in working out an interface strategy for
WAP devices in general. The brain says the device is a web microbrowser, but the eyes
say it's a telephone (or a PDA, or a refrigerator, or whatever else it might be). This means
that any user interface that will be used on a mobile phone must be designed for users
who are primarily thinking of the device as a mobile phone.
To show how important some of the design considerations of a user interface are, here
is an example from the car industry. Lotus Cars developed the "active suspension" system
now commonplace on many modern cars. The original design goal was to be able to drive
over a brick at 60 miles per hour and have the driver think that he had missed it completely.
This goal was actually achieved—there was only one problem. Because the ride was so
smooth and comfortable, drivers would take any road surface at the same high speeds, and driver and passenger safety became a major issue. Dirt roads, potholes, it didn't matter.
The ride was smooth, so the tendency was to drive faster than was safe. The suspension
had to be "detuned" so that it was not only comfortable, but also safe to use.
Similarly, Lotus built a vehicle that was controlled entirely by a joystick. Push forward
to accelerate, pull back to brake, push left or right to steer. Again, the system
worked just fine, but the test drivers hated it. When they wanted to slow the vehicle, they
wanted to be able to push against something solid so they could feel in control. They were
not comfortable with the idea of trusting their lives to a flimsy joystick. They preferred
mechanical linkages and real tactile feedback.
The point is that it doesn't matter how new and innovative an interface is. If the user is
not comfortable with it, it is a "bad" interface. The more comfortable the user, the "better"
the interface.
Whether you prefer the Macintosh or Windows platform, there can be no doubt that
everybody has truly benefited from the idea that applications should share the same interface.
Once you have learned the basics of using one application, then you will always
know where to go and what to do to perform any of the basic functions that are common
to any application.
If you are developing for the Windows platform, then you know that the interface
that you create has to be consistent with the "standard" interface. If it isn't, then your application
will not find acceptance with the broad user public. It doesn't matter if it is the
greatest application ever written. Users will find it cumbersome and unintuitive. It will
make them feel clumsy, and they will avoid it. Once a workable interface has been established,
people will feel uncomfortable with anything that does not conform to it.
Most users are quite obliging and will go through the most tortuous procedures for
you. But only once. If the process is too painful, they just won't do it again, or they may
even abandon the process in the middle. This is called "voting with your feet." If consumers
don't like your application, they will simply walk away and not come back.
If this kind of thing happens with your applications, you will gain fame as a developer,
but not the kind of fame that you will want to brag about. Usability is important for
any user device, but this is especially true for WAP devices, where the inherent physical
constraints make it harder than usual for the user to interact with.
Users already tend to get "lost" in applications, but this is especially true of a WAP
application. It can be hard to provide all the data that users want, as well as all of the necessary
visual cues to let them know exactly where in the application they are, where they
have come from, what steps they have completed so far, and what the next step might be.
On top of that, users of mobile devices are often likely to be distracted by something
happening in external environment, and this makes the developer's job tougher.
WAP is a totally different medium from a normal computer interface, and new rules
need to be developed to help the user get from point A to point B without becoming frustrated,
confused, or overwhelmed. Phone.com in the United States has been established
for some time, and they have an extensive knowledge base gained from intensive usability
testing. Here is a list of the basic constraints of any mobile device for you to think
about, so that you can create an interface that the mobile consumer will readily accept. As 4 well as going over each of the interface constraints of WAP devices, and the ways that we
can overcome some of the problems, I will also go over some of the things that can and
should be done to help the user.
Low Bandwidth
Time is money, and in the case of WAP, this is literally true. The user is paying for the
time spent on your application. You shouldn't ever forget this fact, because the user certainly
won't. (This, of course, comes down to the perceived value of the application. If the
user gets excellent perceived value for the time and effort spent online, then they will be
happy. However, if it takes ten minutes to get a weather report that they could have gotten
for free by turning on the radio, they will not be happy.)
Even when the technology advances to the point where connection time is not an issue,
and only the amount of data transferred is paid for (when GPRS technology comes
online), there will still be people using WAP devices that use the cheaper low-bandwidth
solutions currently in use. You will find yourself developing low-bandwidth applications
for some time to come.
One point that separates the professionals from the amateurs is the naming of
files and directories in URLs. Large URLs embedded in your code, like http://
www.webdesignsinteractive.co.uk/wapforprofessionals/chapterone/introduction/
default.wml, simply increase download time and fill the cache that much more quickly.
As the user won't see the URL anyway, it would make the application more usable if you
named the files and directories with as few characters as possible (while still maintaining
readability, of course).
Small Screen Size
The small screen size is the probably the most obvious limitation of a WAP phone. You
should never develop your applications for use on anything larger than a display averaging
4 lines by 12 characters. Larger displays obviously will exist in the future, and some
do now, but the majority of phones will have small displays. Applications developed for
smaller displays work fine on larger displays, but the reverse is definitely not true.
As well as making your data readable, you have to make your menus navigable. If
you have a menu that is 20 items long, and the most lines you can get on the screen is four,
users will have to click the down scroll button 16 times to reach the last item. I don't have
to tell you that the user is not going to do this many times before giving up on the application
altogether.
Therefore, you should try to keep your menu sizes as small as possible, and use specific
titles wherever possible. If you find that you have some general categories, you
should put them at the end of the menu.
To illustrate, let's say you are a user looking for the local weather report. You are
scrolling down the main menu on your WAPphone, and you reach an item called "Information"
before you come to anything called "Weather...."
