Rule 1: Consistent User Interface
There is currently no shortage of mobile
data applications available to consumers, and more are being added every
day. Users are most likely to embrace
those applications which collectively meet there needs and interests. This suggests that one means to success in
the development of a new data application is to identify and exploit some
as-yet unmet need. That’s true, but
hardly useful. It’s kind of like saying
that one means to wealth is going about picking up hundred dollar bills that
people have dropped. Novelty of content
is pretty rare; a more reliable route to success is making the content as easy
as possible for the user to access. And
since most users will rely on a number of different data applications, ease of
use is largely dependent upon commonality of user interface. That means that
navigation, menu access and formats, image layout, data entry, command
selection and execution, and data display should all work pretty much the same
from one data application to the next.
Consistency of user interface is a critical
component of user comfort and familiarity, which in turn strongly impact the
user learning curve and user acceptance.
Of course, making the user interface natural and intuitive is also very
helpful, but I believe that consistency is even more important.
Rule 2: Simplified Data Entry
Many in the industry would like to pretend
that a wireless handset with Web access can deliver the same data services, in
the same way, as a personal computer connected to the Internet. This is patent nonsense. Even top-of-the-line smartphones like
Apple’s iPhone and Motorola’s Droid have far more rudimentary user interfaces
than those of even the most basic computers.
With simpler handset devices data entry can be agonizing. As I write this I am sitting at my desk
plunking away on a full-sized QWERTY keyboard and watching words I type appear
on a 21 inch flat panel display. Could
I do the same chore using the keyboard and display of my basic cellphone? I might start, but long before I finished
the first page I would probably get so frustrated that I would do something to
render the cellphone permanently out of service.
It is one thing for the wireless industry
to tell consumers that they can
access Internet data services from their cellphones just like they do from
their PCs, but it is quite another to design mobile data applications as if
this were actually true. In fact, mobile
data applications should be designed to limit and simplify user data entry as
much as possible. This is important
even for smartphone users, and absolutely critical for users of more common
Optimally, a wireless data application
should accommodate single-hand operation and should require a minimum of manual
“typing” for data entry. There are a
number of means by which this can be accomplished, including pick lists, scroll
lists, and radio button sequencing. And
of course the application should be able to “remember” commonly needed data
such as the user’s name and address.
Rule 3: Efficient Network Utilization
Another myth being perpetrated in the
wireless industry is that 3G data networks have abundant bandwidth for all
users. In fact, a radio channel which
can indeed provide impressive total data throughput is a resource which is
shared by all users using that channel at a given time. The more users, and the more throughput each
user demands, the lower the data rate available to each user. This trend can be offset to a point by
deploying additional 3G data channels in each base station and/or by deploying
more 3G base stations, but such “solutions” are costly. Furthermore, actual user data rates will be
negatively impacted by degraded radio channel quality. Emerging 4G networks will provide greater
bandwidths and correspondingly higher peak throughput rates, but the increased
capacity will likely be more than offset by growth in user demand.
Because of these and other factors, at any
given time and place a wireless data network may reliably provide to a given user only a fraction of the throughput
that it can deliver under pristine conditions.
Of course, providing a good overall MUE means doing so reliably, which
suggests that a mobile data application should use the data transport network
efficiently. Perceived delays in data
transfer, which will very quickly frustrate a user, can be minimized by
reducing to the extent possible the amount and frequency of data that needs to
be transmitted to and from the mobile device.
Rule 4: Off-line Functionality
One thing about mobile data users: they
tend to move around. And sometimes they
find themselves in locations (airplanes, subway systems, etc.) that even the
most ubiquitous wireless data networks cannot cover. However, lack of wireless data access does not mean that a data
application cannot provide useful functionality. In some cases a user may be able to anticipate the loss of
coverage and pre-load data for later use by an application program resident in
his or her mobile device.
Alternatively, a user temporarily outside of network coverage could set
up the application, including required data entry, so that required information
transfer can be executed immediately upon reacquiring service. In appropriate applications an optimal MUE
would require such “off-line” functionality, and in addition would require that
its operation, particularly in transitioning in and out of coverage, be as
intuitive as possible.
There is one additional requirement for
off-line functionality in order to make it usable aboard commercial
airliners. In order to comply with FAA
regulations, the user must be able to disable the transceiver of the host
mobile device while using the resident data application program.
Rule 5: Automated Data Sharing
Rule 1 suggests that wireless data
applications should have a consistent “look and feel”. Now Rule 5 suggests that they should also be
eager to share data among themselves. As
discussed in Rule 2, data entry on typical mobile devices can be a disagreeable
chore and should be minimized as much as possible. One way to do this is to automatically transfer data from one
application to another. This is pretty
obvious for “boilerplate” information such as user name and address, but there
are other instances where automated data sharing can be usefully employed. Example:
an application that provides diving directions from point A to point B
could port data to an application that shows locations of gas stations along
Rule 6: Dynamic Personalization
With the possible exception of identical
twins, no two people are alike.
Differences in tastes, needs, and technical sophistication extend to
selection and use of wireless data applications, of course, and successful
applications will allow for appropriate levels of user customization. But in order to deliver an optimal MUE
mobile data applications need to take personalization a step or two further. At the very least, the application should
automatically store such things as personal data, favorite websites, locations
of interest for weather reports, and stock ticker symbols on the basis of what
the user has done with the application in the past. Ideally, user interests and preferences could be predicted by
extrapolation from such stored information so that the information or option
most likely desired by the user could be the first one offered.
Such “dynamic personalization” of a mobile
data application can be very seductive when it seems to “magically” anticipate
what the user wants to do. However,
that seduction will quickly turn to frustration if anticipated preferences
cannot be not easily and intuitively overridden by the user when the program
Rule 7: Mobile Device Independence
Unlike the realm of personal computers, the
world of wireless data user devices encompasses a myriad of different
capabilities, user interfaces, and operating systems. To gain the broadest possible market opportunity, a mobile data
application must therefore operate over a wide range of environments. That alone is a difficult enough task for a
developer, but unfortunately it’s not sufficient to assure a good MUE. Because users change their mobile devices
with some regularity, a successful application will also need to operate in
those different devices in much the same manner.
Obviously, it will usually be impractical
if not impossible to design a given application so that it works identically in
mobile devices with vastly different user interfaces. I suspect that most users understand and accept this
reality. But a designer can seek to
minimize operational differences, and even more importantly can try to make
such differences as intuitive as possible.
One final note, as long as we are talking
about how users frequently change their mobile devices. It should be obvious that an optimal MUE
requires the ability to easily transfer personalized data applications from one
device to another.