Mobile Usability

“Investigating Usability Issues in WAP Applications” Page 1 of 67
A research conducted for MSc Dissertation.
“Investigating Usability Issues in WAP

Applications”
Author:
Dhaval Vyas, (MSc Computer Science)
Contact:
d.vyas@lancaster.ac.uk
dhaval_vyas@yahoo.com (always)
Date: 23/09/2002
MSc DISSERTATION for Advanced MSc in Distributed Interactive Systems, Lancaster University.
Abstract:
This research is aimed to generate different usability issues and guidelines for WAP
Applications. It starts with problem findings in WAP applications from different sources and
then we analysed all those problems and generated usability guidelines and issues,
concentrating on user interface issues. To evaluate the research we have performed an
experiment with some participants and also evaluated the applicability for these guidelines.
Table of contents
Author: ..............................................................................................1
Dhaval Vyas, (MSc Computer Science)............................................1
Table of Figures:.................................................................................7
Figure-1...............................................................................................8
Mobile devices.....................................................................................8
Figure-2...............................................................................................8
Structure of the research...................................................................8
Figure-3...............................................................................................8
Model for efficient WAP-browsing...................................................8
Figure-4...............................................................................................8
Flexibility in Navigation.....................................................................8
Figure-5...............................................................................................8
An example proxy mechanism..........................................................8
Figure-7...............................................................................................8
An example of wizard........................................................................8
Figure-8...............................................................................................8
An Example of Links..........................................................................8
Figure-9...............................................................................................8
An Example of Discoverability..........................................................8
Figure-10.............................................................................................8
An example of Vertical scrolling.......................................................8

Figure-11..............................................................................................8
An example of Accredited Information...........................................8
Figure-12.............................................................................................8
An example of Design of Evaluation.................................................8
Figure-13.............................................................................................8
An Example for visibility...................................................................8
Chapter 1: Introduction.....................................................................8
1.1 OVERVIEW OF USABILITY:....................................................................................................................................9
1.2 OVERVIEW OF MOBILE DEVICES AND THEIR USABILITY:...........................................................................................10
1.3 APPROACH USED IN THE RESEARCH......................................................................................................................11
Chapter 2: - Problem Gathering in WAP.......................................12

2.1 INTRODUCTION:................................................................................................................................................13
2.2 EXECUTIVE SUMMERY:......................................................................................................................................13
2.3 PROBLEMS IN WAP:.........................................................................................................................................13
2.3.1 User Personal Problem........................................................................................................................14
2.3.2 General Usability Problems.................................................................................................................14
2.3.3 Interface Problems................................................................................................................................15
2.3.4 Application Specific Problems..............................................................................................................17
Chapter 3: Usability Guidelines & Issues......................................17

SECTION 1: GENERAL USABILITY.............................................................................................................................18
3.1.1 Introduction:.........................................................................................................................................18
3.1.2 User-oriented issues:............................................................................................................................18
3.1.2.1 Know the user concerns: .......................................................................................................................... .....18
Speech Recognition.......................................................................................................................................20
Scrolling.........................................................................................................................................................20
Entering Numbers..........................................................................................................................................20
Entering Text..................................................................................................................................................20
3.1.2.2 User Tasks: .................................................................................................................................. .................20
3.1.2.2.1 Identify user activities:............................................................................................................. ..............21
3.1.2.2.2Classify activities:.................................................................................................................... ...............21
3.1.2.3 Design interface according to user activities:.............................................................................................. ...22
3.1.2.3 Other usability support:....................................................................................................................23
3.1.2.3.1 Minimise the user's memory load............................................................................................. ..................23
3.1.2.3.2 Consistency........................................................................................................................... .....................23
3.1.2.3.3 Feedback.................................................................................................................................................... .24
3.1.2.3.4 Internationalisation:........................................................................................................................ ............24
3.1.3 System-oriented issues:........................................................................................................................25
3.1.3.1 Iterative design and usability testing:......................................................................................................... ....25
3.1.3.2 Compatibility Issue:.................................................................................................................................... ...25
3.1.3.3 System Architecture Issue:............................................................................................................................. 26
SECTION 2: DESIGN CONSIDERATION:........................................................................................................................27

3.2.1 Input Layout..........................................................................................................................................27
3.2.2. Output Layout:.....................................................................................................................................28
3.2.2.1 Getting relevant information:....................................................................................................................... ..29
3.2.2.2 Information Presentation:.......................................................................................................... ....................29
3.2.2.2.1 Links: .................................................................................................................................... ................29
Figure: 7 Example of Links................................................................................................................ ........30
3.2.2.2.2 Page Layout:..................................................................................................................... .....................30
3.2.2.2.3 Writing & Naming:................................................................................................................................ .30
3.2.2.2.4 Graphics:..................................................................................................................................... ...........31
3.2.2.2.5 Fonts: ............................................................................................................................... .....................31
3.2.2.2.6 Main Card........................................................................................................................... ...................32
3.2.2.2.7 Menu Design:................................................................................................................................ .........33
3.2.2.2.8 Scrolling:.......................................................................................................................................... ......34
Figure: 9 Scrolling...................................................................................................................... .....................35
SECTION 3: NAVIGATION.........................................................................................................................................36
3.3.1 Architectural Issues:.............................................................................................................................36
3.3.2 Presentation Issues:..............................................................................................................................37
............................................................................................................................................................. ...........37
Figure: 10 Contextual Information................................................................................................................ ........37
.................................................................................................................................................................37
3.3.3 Back Button:.........................................................................................................................................37
SECTION 4: PERFORMANCE & RELIABILITY................................................................................................................38
3.4.1 System Response:..................................................................................................................................38
3.4.2 Error Prevention & Recovery: ............................................................................................................40
3.4.3 Domain-Specific Application:..............................................................................................................41
3.4.3.1 Payment Issue:........................................................................................................................................... ....41
3.4.3.2 Timeliness Issue:...................................................................................................................... .....................42
3.4.3.3 Accredited Information.......................................................................................................................... ........42
Yahoo! News......................................................................................43
FIGURE: 11 ACCREDITED INFORMATION ................................................................................................................43
SECTION 5: SUPPORT SERVICES................................................................................................................................43
3.5.1 Online Help Service:............................................................................................................................43
3.5.2 Bookmark:............................................................................................................................................44
3.5.3 Searching:.............................................................................................................................................44
3.5.4 Customer Groups:................................................................................................................................45
SECTION 6: DEVICE USABILITY................................................................................................................................48
3.6.1 Challenges to Device Usability:...........................................................................................................49
3.6.2 Contextual Design and Task Analysis:.................................................................................................49
3.6.2.1 Contextual Design:......................................................................................................................... ...............49
3.6.2.2 Task Analysis:............................................................................................................................................ ....49
3.6.3 Input-output issues:..............................................................................................................................50
3.6.3.1 Output issues:................................................................................................................................ ................50
3.6.3.2 Input issues:............................................................................................................................................ .......50
3.6.4 Flexibility & Customisability:..............................................................................................................52
Chapter 4: Evaluation......................................................................52
4.1 INTRODUCTION:................................................................................................................................................52
4.2 METHODOLOGY:...............................................................................................................................................53
4.3 DESIGN OF EVALUATION:....................................................................................................................................53
Initial Interview................................................................................................................................................ .........53
User Tasks.................................................................................................................................................... .............53
Final Interview.......................................................................................................................................... ................53
4.3.1 Initial Interview:...................................................................................................................................54
4.3.2 User Tasks:...........................................................................................................................................54
4.3.3 Final Interview:....................................................................................................................................54

4.4 ANALYSIS:.......................................................................................................................................................54
4.4.1 Visibility of system status......................................................................................................................54
................................................................................................................................................................ ..........55
Figure: 13 Example for visibility....................................................................................................... ...................55
4.4.2 Match between system and the real world............................................................................................55
4.4.3 User Control and freedom....................................................................................................................55
4.4.4 Consistency and standards...................................................................................................................56
4.4.5 Error prevention...................................................................................................................................56
4.4.6 Recognition rather then recall..............................................................................................................56
4.4.7 Flexibility and efficiency of use............................................................................................................57
4.4.8 Aesthetic minimalist design..................................................................................................................57
4.4.9 Help users recognise, diagnose and recover from errors.....................................................................58
4.4.10 Help and documentation.....................................................................................................................58
Chapter 5: Final Discussion & Conclusion:...................................58

Bibliography:....................................................................................60
Appendix A: Personal Information................................................65
Appendix B: User Tasks & Results.................................................65
Occupation or Work ........................................................................66
LESS THEN A YEAR 1-2 YEAR 3-4 YEAR MORE THEN 5 YEARS...............................................................66
Which of the following area services you use more?.....................66

How long have you been using the Mobile phone?.......................66
Less then 1 2-3 years more then 4 years.....................................66
Have you used any WAP phones before?.......................................66
YES NO...............................................................................................................................................................66
Do you have any knowledge about HCI or Usability studies?.....66

Not heard Just heard Familiar.................................................................................................................66
Table of Figures:
Figure-1 Mobile devices
Figure-2 Structure of the research
Figure-3 Model for efficient WAP-browsing
Figure-4 Flexibility in Navigation
Figure-5 An example proxy mechanism
Figure-7 An example of wizard
Figure-8 An Example of Links
Figure-9 An Example of Discoverability
Figure-10 An example of Vertical scrolling
Figure-11 An example of Accredited Information
Figure-12 An example of Design of Evaluation
Figure-13 An Example for visibility
Chapter 1: Introduction
This dissertation is an Integrative Research on investigating different usability issues in WAP

headsets. Many people have witnessed the failure of the initial version of WAP, in 2000. This
dissertation is aimed to investigate different human computer interaction (HCI) issues in
WAP to make it usable. Our research will generate set of usability guidelines and some
important issues about HCI. Throughout this research we have used lots of different usability
principles to generate guidelines.
1.1 Overview of usability:
Most researchers have found out lots of usability problems in WAP phones from their
experiments. Here, we would like to introduce usability principles. Many usability experts
have described usability in different way but mostly all those usability principles are very
similar to each other.
Jakob Nielsen describes, in [Nielsen 93], usability as combination of Learnability, Errors,

Satisfaction and Memorability. Learnability measures novices' ability to reach reasonable
level of performance. Errors refer to error-rate, error recovery and number of catastrophic
errors in a system. Satisfaction refers to the pleasant usage of the system. Memorability refers
to the ability of casual user to remember how to use the system properly.
In [Dix 98], the usability is described as a combination of Learnability, Flexibility and

Robustness.
Learnability is further divided into Predictability, Synthesizability, Familiarity,
Generalizability and Consistency. Here, predictability is the ability of the user to determine
the future effect, synthesizability is the ability to assess the past activities in current state,
familiarity refers to how familiar the system is for the users having their real-world
experience, generalizability refers to the generic view of the system that can be used by user
from all other systems, consistency refers to the similarity in input-output behaviour in
similar situations.
Flexibility is further divided into Dialog-initiative, Multi-threading, Task

migratibility, Subtitutivity, Customisability. Here, dialog-initiative refers to the pre-
emptiveness of system constraints, multi-threading means allow the user to accomplish
symultaneous tasks, task migratibility refers to the ability to pass on a task between user and
system, subtitutivity refers to allowing equivalent values of input-output to be arbitrarily
substituted for each other and customizability refers to modifiability of the interface by the
user.
Robustness is further divided into Observability, Recoverability, Responciveness,

Task conformance. Here, observability refers to user's ability to evaluate the states of the
system from its presentation, recoverability refers to the ability to correct one's action after
recognising the error, responciveness refers to how the user perceives the rate of
communication from system and task conformance is the degree to which the system
provides all services that user expects.
Depending on system's requirement and behaviour, these usability principles should be

applied.
1.2 Overview of mobile devices and their usability:
There are lots of different types of mobile devices currently available in market. Some of
them are shown in figure 1. But, in our research we have mostly talked about cellular phones.
Figure 1: Mobile Devices

Courtesy of [RedWhale]
Mobile devices are basically used for personalised and on the move access to different
services and data. But there are lots of challenges in mobile computing compared to desktop
systems, as mentioned in [Satyanarayanan 95]. Briefly, mobile systems are resource poor,
inherently hazardous, having less energy source and having very slow and unreliable
communication. Coming to mobile phones, poor resources mean- a very small display (i.e.
text of 5-10 lines with less resolution, depending on phones), limited input capacity (e.g.
push-button), slow processor, low memory, small battery and dynamic contexts (e.g. passing
through tunnel).
Considering the given limitation, there are lots of other HCI challenges to overcome as
described in [Kuutti 2002]. First, “develop better ways to provide good user interface”. A
‘painful’ interface will not make users to visit that site again. Present the information in a
way that user can perform tasks well and they also feel good about the interface. Second,
“develop better ways of interaction”. Having to change the focus to a new interactive
system, from static systems, can be very difficult for users. Interface must require ‘minimal
attention’ from the user, considering different contexts [Jesper 2002]. And third, “develop
important and interesting services that can be compared to desktop systems”.
To consider the usability of a WAP headset, one has to consider three conceptual interfaces
namely- Service Interface, User Interface and Device Interface [Pekka 2001]. Here,
external/device interface is the interface that is provided by WAP phones and its accessories,
user interface is the interface that is provided by WAP browser (e.g. Nokia browser,
Openwave browser) and service interface is the interface that is provided by the WAP sites.
1.3 Approach used in the research
To limit the scope of the research, we have only discussed usability issues about User
Interface and Service Interface. We have discussed Device Usability issues very briefly at the
end of the report since it is as important as the other two.
There has been lots of work done to improve WAP usability. We have used different WAP
usability reports and research papers to generate guidelines. Lots of work has been done in
past and still going on, to make the Web more usable. It would not be possible to apply all of
the Web-Usability guidelines to WAP, but we believe that the people that use Web sites and
WAP sites are Humans, and they all have got relatively same perceptions and similar
expectations, as a whole, from a service. So, in this report at some times we have tried to
apply Web site's usability guidelines to WAP applications and also generated WAP specific
guidelines.
Figure 2 shows the design of this research, which is divided, in three parts.
Problem Guidelines &

Issues for Evaluation
Domain
WAP-
Usability
Figure 2: Design of the research
In Problem Domain, we have investigated different usability problems in WAP applications.

For this we have used different sources of information currently available. In Guideline &
Issues for WAP-Usability, we have characterised different WAP problems, found in Problem
Domain, into different categories namely- General Usability, Design Considerations,
Navigation, Support Services and Performance & Reliability, as described in [Becker 2001].
We have also analysed each problem and try to found out different issues regarding those
problems and generated some usability guidelines. We have also found some research-papers
on a specific issue, which we have used, for our analysis. In Evaluation, we have used
heuristic evaluation method with four participants using different test-WAP-sites, to apply
and verify our guidelines. We have also found some new issues came across in our
evaluation.
Rest of the report is explained in following section.
Chapter 2 discusses some of the problems found form different usability experiments of WAP
applications.
Chapter 3 discusses different WAP-usability issues characterised in General Usability, Design

Considerations, Navigation, Performance & Reliability and Support Services. Here, we have
also described briefly issues of Device Usability.
Chapter 4 discusses the design methodology of evaluation carried out for the research. And
also some analysis of the results.
Chapter 5 discusses the overall discussion and conclusion of these guidelines and their
applicability on those test-WAP-sites.
Chapter 2: - Problem Gathering in WAP
2.1 Introduction:
In this section we will talk about the problems that users had faced in the initial version of
WAP. By this we will create a platform that will be helpful for us to gather usability and
design issues and guidelines for WAP applications. Here, we have tried to gather information
about WAP from currently available sources and some test-reports, rather then doing our own
experiment for finding out problems. These reports have described feedback from the users
who used the WAP mobile phones for certain amount of time. They have also addressed the
usability and design problems in WAP applications at that time. This section mainly uses the
material based on a report called “WAP Usability” [Nielsen 2000], produced by Nielsen-
Norman Group, but it also uses some other papers about WAP, which have been referred
separately. So, this chapter only talks about the problems that where found in these
experiments.
2.2 Executive Summery:
Apart from the problems caused by slow data transfer-rate and smaller size, problems found
in initial version of WAP can be described as following.
WAP usability failed miserably. To accomplish some simple tasks, the users were taking
much longer then expected, at the time of experiments. This was not only because failure in
the connection set-up but also WAP sites were designed pretty badly that users had to spend
lots of time while selection and navigation.
WAP phone providers had used built in portals to satisfy their monopoly. But these portals
were not designed well and there was also lack of usability resources available.
Spending money for good services will be the only concern of any user. But in WAP, users
were charged for the services which were not good and sometimes when users were not even
getting the proper services.
2.3 Problems in WAP:
The slow connection and higher download-time were very frustrating aspect of WAP. Many
times connections were failing before user can download data. While requesting any service,
most of the time, users were getting errors like e.g. "Internal Error", "Server Error", "No
access", "Connection Time-out", etc. Users couldn't understand what to do in those
situations. One of the reasons for this unreliable connection was the slow GSM connection.
We have divided the problems in following criteria:
1. User Personal Problem

2. General Usability Problems
3. Interface Problems
4. Application Specific Problems
2.3.1 User Personal Problem
Users were also annoyed because of the payment scheme used by WAP services. Users were
charged on the calling time-rate and as a result they had to pay, even if they didn’t connect
and had not been able to access any data. Being charged for something that doesn't work
seemed unfair and unacceptable to the users.
In some WAP sites, outdated content and incomplete services were major problems as
companies launched sites without the necessary commitment to maintenance or professional
editorial support. As a result of that users lost their confidence in those sites. Also, there were
no indications of trustworthiness of the WAP services. Users cannot simply rely on
information provided in the service.
In WAP, there was a lack of clear differentiation between services. Some services were
having similar kind of interfaces; e.g. newspaper sites were having similar kind of headings
and options and many of them didn’t use logos so it was very difficult to differentiate them.
2.3.2 General Usability Problems
After the period of experiment the impression of users was largely negative towards WAP.
Although there were some good WAP sites which provided comparatively better service to
the users but they were much less and those sites were not easy to find. As we have
mentioned above that connection time was very slow in almost all the applications and the
data quality was too variable. But still some users enjoyed using Internet on mobile phones
and other advantages having mobility.
In the usability experiment of WAP, described in [Nielsen 2000], the improvement in the
users' performance was very low compared to their initial knowledge. At the initial stage, it
may be acceptable if users were poor in performing their tasks as they were facing new
interface, and they had to learn it first. But in case of WAP, the users didn't perform well at
the end of the experiment even after having good use of the WAP phones. This clearly shows
that WAP provided very poor learnability.
Some WAP services were hard to use because of mismatch between their information
architecture and users' tasks. Desktop computers, which have more resources and better
interaction capabilities, still face the problem of poor “task analysis”; so a better task analysis
becomes inevitable in mobile systems, which is having fewer resources and smaller screen
then desktop computers.
WAP users, having small screen, don’t like to read all the text by scrolling down. And even,
the screen has poor typography and it becomes very difficult to scroll through pages of small
number of lines of information and try to piece them together in mind. They just want a very
precise content.
As we have mentioned earlier that all the WAP phones were having a built-in portal and in
which the developers had also provided on-line help. But a very few number of users could
find out that which simply indicates how bad these portals were. Even in the phone menuals
they have not described about the help.
While accessing WWW, users get the indication about whether the application is crashed, or
how much progress is made, or what is the status of the service (i.e. System Response); but in
WAP sites, users were not informed any of these things while they were waiting for service to
be downloaded. So, sometimes when users couldn’t connect, they ended up with just a waste
of time and money.
Even-though the screen size was a big limitation, for some users it was not the screen size,
which irritated them, but the contents that the service providers didn't re-purpose to work on
that screen size. E.g. in a newspaper site, if a story is
Device Usability: For users the experience with the Phone itself was OK. Here, one of the
problem faced by users was that in Ericsson Phone, the scrolling button was on top left edge
of the phone which was slightly awkward as users had to change the way that they hold the
phones.
2.3.3 Interface Problems
WAP designers used non-standard and invented language for labels and menu choices, which
user were not been able to recognise easily and as a result of that it caused delays in users'
navigation. The need for simple language is even stronger in WAP design, because there is no
room to explain non-standard terminology with effects or icons.
Initially, users were not aware of scrolling the pages, as there were no indications of page
layout. And even scrolling is not a good option in small devices for navigation.
Sometimes the phone is waiting for the user to input more information, but doesn't make this
clear to the user. Often, the reason is, the phone is waiting for the user to enter information
into text boxes but it can be only found by scrolling further down the page. And sometimes,
there were no indication that there is any more text to scroll down to.
Error Messages: The presentation of error-messages was itself a big issue. Users were very
annoyed with the quality of error-messages been shown on the screen. There were no
indications about these error messages or the meaning of these messages, in the handbook of
their phones. And as mentioned above there were no explanations given on the screen for the
errors. And as a result users could not understand what the problem was and what to do next.
E.g. after entering any site name, if user gets the error like, "Problems connecting the
Server", the uses had no idea on what to do. Should they try again or go for the alternative?
And in addition to it there were no indications about where the failure was, at the portal or by
the information provider. So, even the users wanted to complaint, they had no idea of where
should they go.
There was lots of instability in services, on some days users were able to access some sites
but not on other.
Some sites provided the reasons for the errors that were coming on the screen, like
"Upgraded and will be available soon." or "site temporarily unavailable". By this users could
even understand that what's wrong with it and what to do next. But this doesn't solve the
problem as users were charged for this.
One of the reasons for these problems was the incompatibility between the phone micro-
browsers, different networks, and portals. This was a very big usability problem and has to be
solved by all parties including site designers and engineers trying to agree to and then adhere
to tried and tested design principles.
Navigation Issues: Although there are lots of differences in designing mobile systems and
desktop systems, the basic usability principals are same to some extent. Navigation in WAP
mobile phones should follow the same principle as those are in the Internet. In WAP, user
navigation was restricted through only 3 provided mechanisms: Menu options, Search
engine, and Bookmark. This is to some extent acceptable as WAP was into its initial stages
and some constraints regarding their usage. But some of them are not working properly.
In the navigation point of view, NTT DoCoMo's I-mode provides users the flexibility to
customise their own menu so that their favourite sites or interests come up automatically.
While in WAP, they had planned this facility but it was not working at the time of the
experiment.
Labelling: Labelling was not proper and unclear in some portals, and as a result users didn't
understand the meanings from a given link or given menu. By this, sometimes user couldn't
find out the required services easily. WAP applications should follow the rules of the
labelling of the Internet. There should be some simple instructions like "click here" or "try
this", from which users can get even some ideas about what will happen after they click it.
Which was not there in the WAP sites. Telling people what will happen before they click
through to a new screen is a basic, long established principle of Internet design.
Back Button: At any point user may feel of going on wrong track and he has to come his
previous place and it is totally unacceptable if user has to connect to the server again and
download the page which he has just seen. In WAP, if a user wanted to go back then he had to
re-download the whole page again, which also mean that user is paying for the same thing
again. This will be a very big problem if you have to go long way back to the initial page.
Searching: Sometimes, it was difficult to find the desired site, as users were getting lots of
results and links with no level of relevance, as they had not designed the search-engine
properly.
Bookmarks: As we saw that searching for a desired page was not easy and labelling in the
menu option was also inefficient, this was the only reliable mechanism for navigation in the
sense that all user must have visited and used these book-marked pages. But, the phones have
provided less number of bookmarking capacities e.g. 15 to 30, which was not enough for all
users.
2.3.4 Application Specific Problems
WAP phones provided very less learnability as users had very less improvement in their
working speed even after one week of experience. Some sites were badly designed that more
screens were used for comparatively less number of informations. For a small-screen design,
it is more important to conserve screen space and present as much new information as
possible. Given the cumbersome and slow process for moving between WAP screens, it is
even more important for WAP design than for other small-screen designs to optimise the
communicative value of each screen. These were the common problem in all different type of
WAP sites.
One big problem that was common in most of the applications, supporting real-time
information e.g. sports, news, travel, whether, etc, was lack of regular maintenance or
updating. Users were getting out-dated information, so they found it very unreliable. Other
problem was the readability of contents provided by those sites. Users didn’t like to read bulk
of pages of information.
In the newspaper sites, they didn’t provide information with different level of details. The
users had to scroll through the bulk of pages if the story is long. And for each new page the
user had to wait until download completes. This was not only waste of time but was also hard
to continue on some interesting stories. In order to make the headlines precise, some of the
newspaper sites used same criteria and as a results newspaper sites were quite similar in look.
Users were not been able to differentiate between them. This way, some newspapers lost their
identity. As there was limitation on the screen of phones the users were not been able to view
pictures, and images. Some users preferred watching news on TV or reading it from the
newspaper for getting more interactions and more detail of the story. [Mobile 2000]
Some sites providing financial services like banking, stock exchange information, and other
related services, were not developed at the full-strength because these applications are very
crucial and require more secure and high-speed connection, which was not there in WAP. At
that time these sites were providing very simple services.
Some entertainment applications, such as movie listing, TV listings, music sites, had the
same problem of having out-dated information. The labelling was also not good and users
failed to understand its meanings, e.g. in one of the TV listing sites there was a label recorded
by a users called “Unmissable TV”, which doesn’t actually mean what was there in it. So, in
this way users had to waste some time. And in this type of applications e.g. movies, music,
TV listing, where long list of information could be there, there was no “home” link so the
users had to navigate all the way back to go to the first page by clicking on the back button.
Chapter 3: Usability Guidelines & Issues
This chapter will talk about different usability assessment issues, which are very useful to
consider the overall application usability of Wireless Internet [Becker 2001]. After analysing
these usability assessment issues, we have generated specific usability guidelines. This
chapter in divided in 6 sections.
Section 1: General Usability

Section 2: Design Consideration
Section 3: Navigation Issue
Section 4: Performance & Reliability
Section 5: Support Services
Section 6: Device Usability
Section 1: General Usability
3.1.1 Introduction:
To be successful for any technology or product, better user orientation in co-operation with a
good system design is necessary. This section is divided into two parts- “User-Oriented
Issues” and “System-Oriented Issues”.
3.1.2 User-oriented issues:
This is one of the most important aspects of usability that most developers should keep in
mind. "There is a widening customer experience gap online. Companies who bridge this gap
will win" [Hurst-Gellady 2000].
From a research it was found that approximately 70% of retailers lack a clearly articulated E-
commerce strategies in their online business applications [Spiegel 2000]. Of course, there are
lots distinctions between the WWW and WAP, but we believe that the basic usability will be
similar to some extent. In this section we will basically talk about user-orientation and other
related usability issues.
3.1.2.1 Know the user concerns:
Users are pretty much concerned about their money spent on the quality of service they get.
All they want is getting efficient, reliable and faster service. There is no way WAP developers
can satisfy all the requirements from different user group. At the same time, most common
requirements can be satisfied very easily.
A first time user should get a clear idea of the application’s usefulness in the first screen of
the application. Otherwise the chance is that he/she just might leave. This issue is more
important in WAP as there are some limitations:
- At present, using WAP is very expensive. Some users cannot let themselves to get
thorough experience of it and then get used to it.
- In Europe WAP is used more as problem solving service rather then a fun service. People
will not use it for surfing or to entertain themselves. Users will want to use it to
accomplish a task [Bergman 2000].
- The user might be distracted due to the fact that he/she could be in a demanding or
stressful environment.
- Users will definitely not like much browsing i.e. inputting and scrolling to get
information.
Analysis:
As we have maintained above that many users would use WAP phones as a problem-solving
unit, and they will definitely not like to do much browsing and/or inputting and scrolling.
Considering different WAP services, we can categorise these applications as “regular”,
“urgent” and “critical” depending on its usage.
Mostly, user will use mobile phones for getting quick information. E.g. consider a user with
three different situations. He might be travelling in his car and first, wants to check his mails
(as a regular activity); second, he wants to pay his bills (as a critical activity); and third, he
wants to check the traffic news on his way to the destination (as an urgent activity). Also in
the above example, while travelling in a car user is more concerned to looking at the road and
driving the car. So, for using the phone the user concentration will be divided into other
activities as well. In order to fulfil all this requirements, developers have to create contents
depending on these application as well as its situations. They should also provide effective
interaction styles, considering the criticality, urgency and frequency of usage of the
application.
In fact, in order to classify all different activities the developers have to do detailed “Task
Analysis”. It helps the designers to find out the critical tasks for the usage helps them to
consider these activities at the early stages and provide more support and efficiency to those
tasks. It also finds out frequency of use for tasks. Designers can assign priority to different
tasks by their level of criticality, frequency, user attention and time spent.
Users are not experts of the technology. Even some of the users don't like the complexity of
any system. It is not a good idea to put complex or technological information to the users.
The communication with users should focus primarily on the functionality and the benefits of
the systems instead of technology standards [Mobile 2000].
One other attribute of mobile user is they are always on the move and their concentration is
divided into few activities. In this situation their readability becomes very poor. So, the
information should verbally be very easy to read and contents should be very optimised in a
way that suits the users.
As described in the user concerns that users do not like to input and scroll in order to get
simple information. Scrolling in WAP phones can be only applied when all the menu options
are well-structured and most important options comes first in the list. A more detailed
analysis on scrolling and input issues is given in the section called Design Consideration.
In all of these situations information that is displayed on the screen should be essential and
intuitive. KISS- "Keep it simple and stupid" [Mobile 2000], is a well-known slogan to
support the easiness of the interactive applications.
Here, we have chosen a model, as shown in figure-3, which are different browsing styles and
can help develop efficient browsing in WAP phones. It shows different mechanisms, in
ascending order, to provide more efficiency and easiness to user. This can vary as new
technologies and its new mechanisms are coming to the market.
Speech Recognition
Scrolling
Clicking (Selection)
Entering Numbers
is less efficient
Entering Text
Figure 3 Model for efficient WAP-browsing
These are different WAP-browsing styles that developers should apply in

descending order, in order to provide efficient browsing. However, this model
also depends
3.1.2.2 on different mobile devices and application needs.
User Tasks:
Depending on user group and application domain, users perform specific tasks. These tasks
are also performed at different frequencies. Developers should try to identify the main tasks
that the majority of user will perform. In order to generate design interface for different
application, the developers have to do a detailed Task Analysis. Task analysis is the study of
the way people performs tasks with existing systems [Dix 98]. There are many different ways
of doing Task Analysis, but we will follow the one that is described in [Openwave 99].
1. Identify user activities

2. Classify activities
3. Design interface according to activities
3.1.2.2.1 Identify user activities:
This is the first step to determine what tasks the user will perform with the application and in
what order. Here, developers should not create confusion between the user actives with the
application features. One of the best ways to find what task user performs for a specific
application is to conduct set of Inquiries. There are different methods for doing inquiries;
Contextual Inquiries [Beyer-Hugh 1997], Ethnographic Studies, Interviews, Cognitive
Walkthroughs etc. By this developers can make out set of scenarios. Based on these
scenarios, developers can conduct detailed task analysis by dividing the identified activities
into sub-activities and sub-goals. [Bergman 2000].
3.1.2.2.2Classify activities:
After the first step the developers can get the complete set of activities and tasks for an
application. Now all these activities will have different level of importance to the users as
well as the application itself. To classify them all the developers have to consider following
groups [Openwave 99].
3.1.2.2.2.1 Required Activities:
These are the compulsory activities for all users that all of the application users will have to
perform. These activities always compromise the user-friendliness of the systems and as a
result it degrades the overall usability. Some activities like logging-in or set-up activities
come in to this category. Developers should try and reduce these activities as fewer as
possible.
3.1.2.2.2.2 Main-path Activities:
These are the activities that are most frequently used. These activities should be as simple
and easier as possible, so the users don’t need to learn or spend much time over it. Even the
interaction and presentation styles should also be very easy.
3.1.2.2.2.3 Semi-main-path Activities:
These are the activities that have used by many users but not the majority of users. So, these
activities should be simple and intuitive, but users have to make sure that these activities
should not become an impediment for users who do not perform them.
3.1.2.2.2.4 Side-path Activities:
These are the activities that are used occasionally by most users when they use the
application e.g. 80% of users will use it 20% of time. Replying to e-mail is one such activity.
It makes sense to implement access to side-path activities in a menu that is not immediately
accessible.
3.1.2.2.2.5 Rare-path Activities:
These are the activities that are never used by majority of users. So, developers should try to
remove these types of activities. It would be better to have a simple system than one with a
lot of obscure options.
3.1.2.3 Design interface according to user activities:
Once all the activities are prioritised, they should be presented on the user screen in a way
that best suits the user needs and situation. E.g. Starting with the most important activities,
the user interface should be made assure that the higher priority activities are always
available with optimal user interaction and fewest user key-stokes. And also these activities
should be given better ‘presentation methods’. A more detailed analysis about how to present
information is described in Design Consideration section.
One other very important issue is to structure all these activities/tasks [Openwave 99].
E.g. consider wants to complete a task and in order to do that, he has to go through 2 sub
tasks to complete his goal. In this case structuring of tasks becomes very crucial. To explain
these in more detail consider following figure 4.
Sub-Task A
Sub-Task 1 Critical Line Sub-Task 2 GOAL
Sub-Task B
Figure 4: Flexibility in Navigation
To complete a goal user has to go through sub-task 1 and 2. Developers can provide
flexibility here by adding some subtask as A and B to provide more options to user [SAP
2002]. E.g. A user want to buy something from any online shop from his mobile. Now, there
are many different ways that user will buy that product. He may want to straightaway buy
that product if he has already got all information about that product or he may want to buy it
after getting some information about that product. The user should be given both the options
at the same time.
Another issue here is about the Critical Line. In Project Management studies there comes an
issue about ‘Milestones’ and ‘Deliverables’, in which the Critical Path to achieve that
Milestone should be as short as possible [Project Management]. That concept can also be
taken here to structure the tasks here. As we can see from the figure that goal should be
achievable through minimum amount of dependencies to provide more efficient navigation,
of course depending application type.
Here, developers have to "Balance" between flexibility and efficiency.
3.1.2.3 Other usability support:
3.1.2.3.1 Minimise the user's memory load
While using desktop computers, users have more time and fewer things to remember.
Whereas in handheld computers, users have small screen and they also have to remember
more information as the task that he will be performing is of very short-term. And also they
might be one the move for many times, so for hand-held users it would be difficult to face
lots of information considering the limited memory of humans [Telenor 2000].
In the conventional desktop systems, there is well known rule that “20% of the functionality
is used 80% of the time” [Bergman 2000]. By simplifying this, developer should cut out this
80% in order to reduce complexity and increase usability. So, the user interface should be as
precise and as simple as possible.
In order to navigate, user should always give some sort of selection criteria rather then input
field. Recognition is better then Recall [Nielsen 10].
In situations of choice the users should be asked to make simple decisions rather than
complex ones. Divide the problem if possible.
It would be helpful for the user if the WAP browser can remember some of the previous data
entered by user. This can be done by better cookie management [Telenor 2000].
3.1.2.3.2 Consistency
It is very important to provide an interface that uses same template or principles throughout
the application. It is also recommended to provided interface that is consistent with real
world.
Consistency can be provided in many other ways like labelling and positioning [Telenor
2000]. In naming, the function should be named from its functionality and the same functions
should have the same name. In positioning, same functions should be on the same position
throughout the site. Having consistence positioning can provide good recognition to users
and as a result they can work faster.
3.1.2.3.3 Feedback
Feedback is a confirmation of any user or system activity. For frequent and minor actions, the
feedback should be modest; but for some major and less frequent actions the feedback should
be substantial [Shneinderman 98]. E.g. as a low level feedback, when the user goes to a new
page, on that new page user should be informed about that new page by a header-name and
also, if possible, should also indicate the information about the previously visited page. This
will make user feel confident and comfortable with the new page. And this is a well-known
guideline for designing traditional web sites; to repeat the user's choice on the destination
page for confirmation of their task achievement [Nielsen 2000]. Feedback should both give
an indication of whether the input had a valid format as well as and the result of any
operation from user.
System should also give feedback about its progress and status. Some icons indicating
appropriate visual representation can be useful to provide system progress. System can also
provide user’s position in the site navigation hierarchy. This is described in Design
Considerations in more details.
3.1.2.3.4 Internationalisation:
Internationalisation refers to the process of designing a core application considering the

needs of foreign users [Brew 2002]. Designing an international user interface may or may
not include language conversion but should include special needs of other countries and
cultures [Nielsen 94]. This section will provide some important consideration for using
internationalisation as described in [Brew 2002, Nielsen 94].
Many countries have character sets that extend beyond A-Z of English and ASCII character
set. Some Asian languages have characters that extend 8-bit ASCII code. Some applications
have to use more then one language, which makes the representation more complicated.
Some languages use special characters ‘å’, ‘ø’, ‘ü’, etc. which have to be sorted by simple
characters, e.g. ‘ø’ with ‘o’.
The problem can also arise when presenting different currency-standards and time
measurement standards. In different currency standards the main problem is decimal point.
E.g. In US: $ 10,000.00

In India: 10,00,000 Rs.
Developers also have to review the application if it has to be made for international market
and also have to find out how different users will interact with it. After this developers can
change or accommodate some assumptions so that user can adapt to a variety of countries
and languages by minimal breaking of the application.
3.1.3 System-oriented issues:
3.1.3.1 Iterative design and usability testing:
Iterative design and usability testing are the issues that are not only applicable to the
development of WAP sites but all types of computer-based systems. These are very important
processes in systems development life cycle and also need some management. For this
research we cannot go into details of these issues, we can only give a very brief introduction
of their importance.
The developers cannot predict all the requirements of the system at the beginning of the
development, moreover in the development process these requirements tend to grow or
change. So, the better way to develop a product is to make a potential prototype of the system
and apply them to some users and get feedback on the prototype to make an improved
design. And by this evaluation, the final product can be improved. The definition of the this
iterative design is, as described in [Dix 98]:
“Iterative Design is a purposeful design process which tries to

overcome the inherent problems of incomplete requirement
specification by cycling through several designs, incrementally
improving upon the final product with each pass.”
Iterative Design in conjunction with Usability Testing can improve the system productivity.
Usability Testing is very important as it provides direct information about how the people use
computers and what their exact problems are with concrete interfaces being tested. [Nielsen
94].
3.1.3.2 Compatibility Issue:
Different mobile phones supported different browsers, e.g. Nokia and Ericsson used their
own browser; Motorola, Seimens support Phone.com browser (now Openwave). Now, all the
browsers support different WML structure, so it can be possible that an application running
well on a browser may not run so well on other. For example, Nokia assumes a "title" tag for
a WML 1.x card should be displayed at the top of the screen (but only one line); Openwave
assumes there will be content on the card describing the card and thus relegates the title for
use as the default bookmark title. [Little 2002]. All these mobile devices run on different
operating systems like, Palm OS, Windows CE, Symbian, etc
This issue has affected the mobile usability to the worst. We have already described different
problems caused by compatibility. Here we will describe some approaches to solve those
problems, as shown in.
Develop applications targeting a single device. Developers can readily write an application
that delivers an outstanding user experience for any small number of devices. It has,
however, drawback as it may only work for specific device group.
Develop application that can be used by all devices. By assessing all devices' implementation
of the platform, and selecting the subset that works effectively the same all devices,
developers can write only one application. Of course, this may be impossible for some
applications.
Use a “run anywhere” server. By this, server can translate the original application to the
format supported by the device. This can be very efficient approach and also is costly.
3.1.3.3 System Architecture Issue:
As we have mentioned in our introduction that usability in mobile device depends on three
interfaces namely: user interface, service interface and external interface [Pekka 2001].
Particularly in service interface, the usability can be enhanced by better network and
communication mechanisms.
In most simple scenario, developers manually build WAP sites by using WML. But there are
lots of other mechanisms currently available that can translate the HTML contents into WML
or other specific contents, at some third place. These mechanisms are called proxy. One of
the proxy mechanisms is shown here in figure 5.
Figure 5- an example proxy mechanism

Courtesy of [Arizona 2001]
There are lots of reasons that a proxy mechanism can improve the usability of mobile
devices. First, as we have mentioned in introduction about the problems with slow
connection in mobile technologies, having a proxy decreases the delays caused by wireless
communications. Second, it acts as Point of Presence (PoP), which causes the faster response
time (in terms of feedback and feedthrough), if it is near to the clients [Dix 99]. For more
information please see the section Performance and Reliability. Third, it can support
heterogeneous devices and can provide better quality of service by employing different
transcoding mechanisms. Transcoding mechanism is a very big issue within itself. Here, we
can only provide brief information about different transcoding mechanisms. WebExpress is
an example of this kind of proxy systems, which can employ different mechanisms
supporting compression, image conversions, caching, differencing, header reduction,
protocol reduction, etc. The efficient this mechanisms better usability in service can be
provided [WebExpress].
Section 2: Design Consideration:
In previous section, we have introduced user’s concerns. This section will describe usability
issues related to design layouts, information presentation, and interaction mechanisms.
3.2.1 Input Layout
Here, one important thing should be noted that in order to provide overall usable inputting-
process primary issue is to provide efficient input mechanisms (e.g. graffiti, T9, etc.), and the
input lay-out of the application becomes secondary. In this section we will describe different
input layout issues and guidelines for WAP enabled phones. As to follow simplicity in the
application developers should provide fewer fields for input so that it can save the time of the
users.
"In mobile phone interface design, every click loses half of your users".
-Nick Knowles
(Chief Technical Officer, KiZoom)
A research described in [SAP 2001], proved that error-rate in textual input is twice as higher
then in numerical input and the speed in textual input is also twice as slower. So, the
developers should prefer numerical input over textual. And if it becomes inevitable to use
textual input fields keep the input mechanism in mind by utilising the first letter of buttons.
And if possible developers should use selection of links more then inputting something, in
case of navigation.
In applications where more information from the users are needed, try to use fields that can
fit in only one page, as scrolling is supported by all browser. Also try to use input field like
check box, radio-buttons, so that users don't need to write much [SAP 2001].
It is also important for the developers to label those input fields in a way that prompts the
users to recognise whether it as a textual input field or numerical input field [Telenor 2001].
It is also important to have some default value in any field [SAP 2001].
In applications where more information from the users are needed, try to use field that can fit
in only one page, as scrolling is supported by all browser. Also try to use input field like
check box, radio-buttons, so that users don't need to write much [SAP 2001].
Developers can use wizards or forms for entering information. In [Openwave 10], they have
suggested the developers to use wizards instead of forms by saying that wizards give better
user experience especially for novice users. And up to some extent it is a good idea to use
wizards as there is less input needed on a page. But for expert users or returning users it is
not a good idea as they feel it as tedious. Other problem is that the back functionality doesn't
work well in wizards, as users have to navigate through all the wizard-pages that he/she has
visited to go back to the original place.
If developers are using wizards, they should use the page information on the screen as shown
in figure 6. And avoid having a separate "submit" card. The last OK of the wizard should in
fact be a submit option [Openwave 10].
XYZ Bank XYZ Bank
Payment Step 1 of 2 Payment Step 2 of 2
Credit card number: Expiration date:

[ ] (mm/yy): [ ]
Menu Next Menu Pay
Figure 6: An example wizard
To use any mobile phones, users have to enter pin first. This way the device itself provides
security by identifying them. Developers should only ask for username and password when
application requires more security e.g. applications like online shopping or online banking.
For other applications cookies can work fine to identify users.
3.2.2. Output Layout:
At first instance it can be said that having small user screen, the WAP usability is heavily
affected by amount of information that can be presented on the screen compared to a Web
page. However, it is very important to know how users uses and perceives information from
both web and WAP pages. While using web pages users don't read each and every word but
they just scan it [Neilson 99]. This is because they get lots of information at the same time
and some of them they don't want. However, in WAP applications users are on the move very
often, so the way they use and read the information is very different.
Researches showed that, in small display device (i.e. mobile phones), user's ability to read
and understand information is not adversely affected [Jones 99]. It is also said that user is
more active when he uses the small screen device then any desktop computer. So from all
this, it is reasonable to say that limited screen is not a disastrous for the usability and the
contents presentation is more important issue. Taking this concept in mind we will generate
some guidelines and issues to improve the output (or presentation) of WAP devices. This
issue is further divided into “Getting relevant information” and “Presenting information”.
3.2.2.1 Getting relevant information:
Building a WAP site often means transformation from its Web site. For this the developers
have to reduce its contents and have put only the relevant and most important contents in the
first place. Finding the most important information requires a firm grasp of the subject area
as well as an understanding of the users' needs and tasks - the development team has to
involve users throughout the design process [SAP-MiniApp]. There are some generic rules
described by Dr. Nielsen [Nielsen 99] to get the relevant information.
Aggregation: Showing single information that is a collection of other smaller ones.

Summarisation: Presenting a large amount of information in a smaller form without
compromising the quality.
Filtering: Eliminating some irrelevant information that users don’t care.
Elision: Showing everything with examples to provide practical understanding and to reduce
the words.
3.2.2.2 Information Presentation:
From researches it has proved that only 20% of display is used for 80% of time.[Bergman
2000]. And as we know in mobile device the user screens are very small, especially in mobile
phones, it becomes necessary to use the user display optimally. We have divided this issue in
different presentation and interaction issues.
3.2.2.2.1 Links:
Different browsers use different ways of presentation. E.g. Nokia browser uses only
underlined text to present links, as “Link”. In Phone.com browsers (now Openwave), they
present links as Link, [Link] and <Link>. By presenting the links as underlined text gives the
users the Familiarity of web sites enables users to discover the links very fast. Developers
should not use underlined text for any other purpose and do not put text within <> or []. This
might be mistaken as for a link.
The developers have to take into account the different WAP browsers supporting different
length of text in a line and wrapping as well. E.g. some phone.com browsers does not support
more than 16 characters, and Nokia browser does not support wrapping and allows only 18
characters in a line [Telenor 2000].
Another issue is about the words or the sentence contained by those links. Telling people
what will happen before they click through to a new screen is a basic, long-established
principle of Internet design, which can also work well for mobile applications [Nielsen
2000].
Use the smallest meaning words or abbreviations for links, because for some times if there a
longer word or phrase is used as a link then users may misunderstand that assuming it as two
different words. And even while selecting those links in some browser only one part of the
link will be selected, which may mislead the user.
Clicking a link can lead to some information contents or can lead to some more sub-links. It
will be a good idea to let users know what they can expect by clicking those links. There are
some important issues here that designers should consider [Telenor 2000].
Labelling - Link that leads to lists of topics should be distinguished from links that lead
directly to services or content. Naming them properly can do this. E.g. "NEWS" will lead to
different category of news like, sports, technology, latest news, etc.; and the link shown as
some breaking news can lead to contain straight away.
Information at different level - Link that lead to lists of topics and links that lead directly to
services or content can be shown at different level of link-structure in the portal.
By separating links - A page containing links to both lists of topics and links directly to
content or services can be shown separately by putting them in different groups see figure-7.
XYZ News
- America asks Iraq

- Tony Blair supports
- Sports
- Local News
Menu Back
Figure: 7 Example of Links
3.2.2.2.2 Page Layout:
It is very annoying for the users to read any document having lack of continuation. The
designers should use the whole card for information presentation, otherwise users have to
wait for new card to be loaded. If the information is longer e.g. large articles or email, there
should be a link "MORE" shown at the very last of page. And this "MORE" link should be
easily discoverable and recognisable. For this designers have to show it with different size of
font with different type of color.
3.2.2.2.3 Writing & Naming:
In Naming and Writing, consistency and simplicity are the two most important characteristics
for any well designed system.
Use consistent grammars in menu and link items that are used in WWW e.g. don’t use Back
instead of Previous and Home instead of Main. Also within a site, use the same words
throughout, for the same functions [Shneiderman 98].
User uppercase and lowercase letters appropriately. As we know Upper-case words are
slower to read so they should be used for only important information, which needs more user
concentration [SAP 2002].
E.g. for a Flight-No: user Uppercase SQ203A and for general text use lower-case
words.
Space restrictions may necessitate the use of abbreviations in many situations: in dialog
boxes, for field names in the applications, for lines in the menu bar or pull down menus, and
for function key names. But do not use abbreviations if sufficient space is available [SAP
2002]. Use abbreviations only if you are sure that the user can easily understand them. Refer
to standard abbreviations such as listed in dictionaries. Designers can also use new
abbreviations, if there is no accepted abbreviation available and more information is
necessary. There are some rules defined for this in SAP design guide [SAP 2002], which we
have shown here, briefly.
- Right truncate words: Create abbreviation by omitting the end of words and use
period. E.g. "abbreviation" becomes "abb."
- Omit vowels: Vowels that do not influence the pronunciation of the word very much
can be left out. E.g. "group" becomes "grp".
- Create acronym: created new terms consisting of the first capitalised letters of the
word fragments or individual words. E.g. for "Human Resources" use "HR".
3.2.2.2.4 Graphics:
Normally, the most limiting factor in WAP phones is small screen. So, developers should use
graphics very carefully. They should only be used for Company-specific logos [SAP 2002]
(to provide the users the familiarity and recognition about that site), Navigational status of
the phone and as a part of content only if that is inevitable. As a consequence of the limited
screen, a good strategy to use graphics that are stretched horizontally.
3.2.2.2.5 Fonts:
Designer would want to provide as much information as possible, efficiently. And it would
also be logical to provide text with smaller fonts on small screen. Researches have shown
that the font size and its type have effects on the overall usability. [Legge 85] found that
reading speed improves with the increasing text size, but upto some critical point. [Tullis 95]
found that as the font becomes smaller the error rate increases. Still there is not much work
done on fonts of the small screen. Here, there are some guidelines most of which basically
derived from the desktop PCs but can also be applied to small screens.
Do not use capital letters for no reasons. It reduces the readability speed for the users. Only
use them where they are originally used or when it is very important to draw the user's
attention. Bold fonts should be only used for important information.
Use big fonts where there is need to show the status of phone and activity the phone is doing.
That is because it is very important to provide the feedback for the user's activity. Some
status messages like "Dialling", "Call Divert" are very important to be shown to users and as
we mentioned above that bigger fonts improves readability, it becomes essential to show
those messages in bigger fonts. Even some error messages should also be shown in bigger
fonts.
Some researches like [Tullis 95] has shown that even some font types are also very important
for usability. They have experimented with Arial, MS Serif and MS San Serif; and proved
that as the font size increases the reading time and the error rate decreases in Arial.
Some times fonts become very crucial when novice users are using the device. We have
already devoted a section to provide usability to novice users in Customer Support part.
Fonts can provide efficient discoverability. Discoverability means easiness to find things or
options from the screen [Openwave 99]. It would be easier for the novice users, if text
materials are presented with different font size and font style, and now a day considering the
available color screens different font colors will also be very helpful to the novice users. E.g.
in the following figure it is not only easy to discover different links but also it is good for the
user to recognise where they are in the navigation.
XYZ -NEWS
-Sports
-------Cricket
- Tendulkar on 100
- Dravid is the ….
MORE
Menu Back
Figure: 8 Example of Discoverability
3.2.2.2.6 Main Card
By main card we mean the first page of any WAP portal or WAP site. In WWW the first page
is called the home page, and it the starting point to find any service or application within the
site or portal. Now, it is very important for the developers in WWW to make the Home Page
as usable as possible so that any kind of user (specially novice users) get full and efficient
advantage of the services provided by the whole site. This theory can be applied to WAP sites
as well. Ideally, the main card should always have an option that matches as close as possible
to any user’s initial thought about what is the task and what is the best way to start with
[Movie 2001]. For this a proper Task Analysis is needed.
To improve the usability of the main card, all other issues of menus, labelling, list, fonts, etc,
all that we have described in this report are important, which is needless to mention here
again.
Increasing the length of main card incurs relatively small loss in usability while at the same
time can provide for a significant gain through the variety of options offered [Movie 2001]. A
greater number of options on cards indirectly increase the usability of application either by
allowing shorter time required to reach the target card or by increased level of satisfaction for
users who want to find out more details along their search path. Long card also mean more
scrolling, so the interface should be well structured. For this, options or links that are
presented there, should be most important and frequently used by most users.
Even in terms of marketing, the first card is very important e.g. in any commercial WAP site,
the first card is very important to attract user by providing efficient usability.
3.2.2.2.7 Menu Design:
WAP phones and other hand-held devices, usually, utilise hierarchical menu structure to
interact with users. Menus were originally designed to exploit the fact that humans are better
at recognising commands from list rather then recalling them from memory [Marsden 2001].
But the menus cannot be straight away translated from desktop PCs to hand-held devices, as
there are lots of limitations in handheld devices. And also because users don't have access to
all the available choices simultaneously on one screens, in the menu. To find some
improvements considering the limitation described above, we have described some
guidelines and issues here.
Developers should try to build a menu system with a uniform structure and make similar
parts of the application look and feel like consistency [Dix 98, Shneiderman 98]. To prevent
applications to behave differently in similar situations, the developers have to use well-
defined hierarchical structure [Ericsson 2001]. There are two approaches defined in
[Ericsson 2001]. First structure, as shown in figure (a), uses strict relation within menu, so
that uses can easily keep track of the location in the menu. But this approach some times
becomes tedious, as users have to navigate through the whole sequence back to go to the
different main menu options. Second structure, shown in figure (b), hyperlinks the menus
together so that they can be accessible in different ways. This approach gives shorter
interaction time while moving between different menus. But same time could be wasted, as
users can't keep track of the navigation, especially novice user. The developers have to use
one of the approaches depending on their application.
Figure (a) Figure (b)
Menus are part of navigation. The efficient the menus are presented the efficient and faster
the navigation can be. One of the best ways to improve the usability of menus is to have
better categorisations in the menu classification [Marsden 2001]. Considering the small
screen display the menu categorisation is also limited to few lines. Research [Swierenga 90]
says that handsets having 3-4 lines of options can perform similar to desktop computers.
There is also an important issue about the tree structure in menus. [Miller 81] conducted that
wide and shallow trees are more desirable then narrow and deep. Recent research [Norman
88] found out that "Concave menus are more efficient"- i.e. developers should give more
options (i.e. wide structure) at the root and leaves and less options at the intermediate links.
For more information about the tree structure see the Design Architecture section of chapter
Navigation.
In menu design if the developers can provide some extra information along with the options
then that would be very helpful for the users. E.g. In movie listing applications, the release
date along with the movie name or even the star-cast along the movie name can be very
useful.
There is also an issue about designing menus with small number of options. Of course this
contradict with the long main card that we described in previous section. But in short, it
totally depends on the developers to choose any of these options depending on the
application that they are developing. More justification about "number of menu options" is
described in following section of scrolling. Here, there are some more guidelines.
If you want to use more menu options in a card, keep the frequently used options appear first.
Much more importantly, let the users customise their own menu so that their favourite sites or
interests come up automatically [DoCoMo's I-mode].
Another method is to presents the list with numbers that act as accelerator shortcut keys,
allowing users to select an option by pressing the corresponding number on the keypad rather
than scrolling to it.
3.2.2.2.8 Scrolling:
To start with simple, scrolling is needed where there is more information to be presented
beyond the screen limitation. Generally, scrolling creates some problems as users sometimes
just scan the text and may forget to look further down. Scrolling also affects overall
readability of the screen, as user has to divert his concentration towards the scrolling.
Specially, where there is a huge limitation of screen size, the scrolling becomes very crucial.
There is a slight difficulty to provide the straightforward guidelines for scrolling in smaller
devices like mobile phones. The usability guru Nielsen, in his review of Web Usability since
1994, no longer sees scrolling as a "usability disaster". But he also suggests developers
should not to use scrolling in small screen devices like WebTv [WebTv 97]. In contrast,
some researchers from Middlesex University has provided different mechanisms to improve
scrolling in Mobile phone applications, acknowledging that scrolling in small displays can be
improved.
Considering Nielsen's arguments about scrolling, it would definitely be a good idea to have
only screen-sized pages (cards). By using small sized pages/cards not only scrolling can be
reduced, the error that are being made from using scrolling can also be reduced. E.g.
sometimes error can be made if a user may not scroll down to choose a particular option, as
he just scans the page. Also if users are not prompted to scroll they can miss some
information down-words by not scrolling [Nielsen 2000]. Also scrolling can reduce the
readability and diver the user's concentration. So, all this issues argue to support Nielsen.
Researchers from Middlesex University have done some experiments on different way to
employ the scrolling and enhance the overall usability [Buchanan 2001]. Among them the
best was Vertical scroll method, which displayed each menu option on a series of lines on the
display with the user scrolling down to see the full list of option as shown in figure 9.
Figure: 9 Scrolling
The main advantages of this method were it was easier to read from the screen with no
wrapping, the average time complete a task was very low and also the average number of
error were also low. The drawback of this method, considering Nielsen's comments [WebTv
97], was that user has to do some scrolling. But by providing increased length of pages can
gain significant advantage of variety of options offered on the screen [Movie 2001]. A
greater number of options on a page indirectly increase the usability of application either by
allowing shorter time required to reach the target service or page; or by increased level of
satisfaction for users who want to find out more details along their search path.
After considering both arguments about scrolling, if a developer can provide a mechanism in
which most important and primary options of links should be presented in the front and other
less frequently used options/links should be presented last on the page [Jones 99]. By this
way most of the users can choose their links with minimal scrolling from the screen. For this
developers have to do Task Analysis and have to rate the activities.
Other issue for scrolling is about the ergonomics of the scroll-button. In some mobile phones,
e.g. Nokia, newer types of scroll-buttons like Navi-roller and others are used, which are
actually very effective to use compared to other mobile phones like Ericsson, in which user
have to use the push-buttons. In navi-roller users just have to scroll the roller on the screen,
where in scroll-buttons user has to push up- and down buttons to scroll up and down, which
is sometimes tedious.
Section 3: Navigation
Navigation is the navigational schema in terms of breadth and depth of search path and
traversal mechanism [Becker 2001]. An efficient navigation depends on architectural issues
or the tree structure and effective presentation on the user screen. In this section we will talk
about both of the issues.
3.3.1 Architectural Issues:
In WAP application all pages are called Cards, which can be of any size depending on
application. When a request for a WAP site is made these cards are sent in a bunch, which is
called Deck. Now while users navigate through the site, the Deck should have sufficient
Cards for the use. If the requested page in not in the Deck a new request has to be send to the
server, which will take some time. So, it is recommended that a maximum navigation space
should be provided within one Deck to avoid reloading during the navigation [SAP 2001]. In
[Openwave 10] it is recommended to use decks of 500 bytes or less. They also say that
having larger deck space can increase download latency. They also suggest setting the deck's
expiration value high if the content is static.
The user can navigate through pages by using menu options, links from the menu or may be
from the back button. Now, all the cards/pages in a WAP application can be represented as a
tree structure. Issues about different tree structures are presented in Menu Design section.
Precisely, wide and shallow trees are more efficient then narrow and deep trees [Miller, Lee].
One of the reasons for this is wide and shallow tree mean more options or links are presented
on each of the screen. And as more options are presented on the screen, user can complete the
tasks faster, with less interaction time. And providing more options user has less memory
load, so this serve as recognition then recalling.
The navigation can also be utilised for efficiency and flexibility. From the figure-4 described
in General Usability section, flexibility can be provided by allowing users to navigate
through different paths, at the same time efficiency can be provided by providing user fast-
path [SAP 2002]. Developers should also use focused navigation by e.g. presenting list of
goals that they can achieve from the site straight away [Jones 99].
3.3.2 Presentation Issues:
Menus are the representation of the "card architecture" in all WAP applications, as whenever
the user selects any option from menu he will be shown a new card on the screen depending
on the selection. Now, user always wants confirmation about their task completion [Nielsen
2000]. Whenever they navigate by clicking a link on a page next page should describe some
information about the previously clicked link, means user should be given confirmation that
they have gone to the right page that they wanted to go. One of the solutions, as described in
[Marsden 2001, is to provide “visualisation” by giving the visual feedback on the screen.
Actually, visualisation is one of the wildly used mechanisms for PDAs. In [Marsden 2001]
they have used Iconic presentation and Contextual presentation.
In iconic presentation, they have suggested to use animated icons to represent actions or verb
as shown in figure. Here in addition to word-Call Divert, animation can add little
understanding about the role of that menu link. Some context icons can be used to highlight a
particular choice from the set of alternatives. It is also better to display full set of context
icons on the screen then single menu per screen.
In contextual representation, it will be better to give feedback to users about their position in
the navigation, especially for novice users. E.g. as shown in the figure 9, show the menu
number and its section number in the top-right corner.
1-7-2
Shows the navigation hierarchy
Memory
Status
Menu Back
Figure: 10 Contextual Information
3.3.3 Back Button:
It may happen at any time that user may find himself on wrong path and may want to go
back. So, developers should always provide back functionality. Different phones browsers
use different provision for back buttons. Some phones have separate back button and some
have back function in menu.
One of the problem in current back function in mobile phones is sometimes users cannot go
back in a site where timer is used. This type of pages often disables back function. In this
case the phone browser should ignore the timer function and allow the user to go back.
Some browser (e.g. Nokia browser), uses the same button for back function and clear
function [Nokia]. In this case when the users are dealing with wizards and they want to go
back then they have to clear all the fields first and navigate back to the page they want.
One of the best ways to provide intuitive back function is to set a "Back" link on the WAP
site. By having a back link, user will not be confused about the back buttons, as different
phones uses different ways for back function. Other important thing is to have a back
functionality, which takes the user back to first page or "Home". This can be done either
setting a Home function in menu or by putting a link on the site itself.
Section 4: Performance & Reliability
Up to now we have addressed different issues about presentation of layouts, different

interaction layouts, different user services, etc. However, the overall usability has lots of
influence over performance and reliability provided by the system. In general, there are no
specific guidelines to provide better system performance or reliability because different
applications have different levels of performance requirement. This section will apply the
general issues to improve the performance of WAP applications.
In web, performance can be measured in terms of consumer wait time and system response
time [Backer 2001] and reliability can be defined in terms of site crashes, downtime, error
messages, and consistent response time. We can apply the same concept for WAP. In this
section we have tried to discus them in following manner.
1. System response
2. Error prevention & recovery
3. Domain-Specific Application
3.4.1 System Response:
One of the most important issues about System Response is that it affects human behaviour
and productivity and as a result it affects the overall usability. E.g. It is obvious that a system,
which takes long time to respond, will annoy its users. A system with higher response time
will definitely please the users but it should not be much faster that its users don't even
understand what have happened. There have some research been made for a proper response
time while interacting with WWW, but none with WAP or other mobile applications.
In any computer system, response time is the number of seconds the system takes to perform
and satisfy that activity after the user initiates it. But in reality, to calculate the system
response, issues like -interaction complexity, technical feasibility, costs, task complexity, user
expectation, error rates, error handling procedure, have to be considered. The overall
productivity not only depends on speed of the response but also on rate of human errors and
how the system helps to recover them [Shneiderman 98].
So for our research here, we will try to find out what factors and issues to consider getting
optimal System Response from WAP applications. Looking at the previous usability studies
of WAP [Nielson 2000], system response was the most frustrating bit for the users. One of
the reasons for this was user's expectation about the WAP phone's response from their
previous experiences. Generally, user uses a mobile phone to make and receive calls, so
while using WAP enabled phones they can wait up to the same response time that they can
wait while making call from a simple mobile phone. Second thing, probably most of the
WAP phone users expect its response time similar to WWW as WWW is the main and widely
used source of Internet applications. So, a proper response time that user can tolerate from
any WAP service can be found from the two aspects that we have just mentioned. Of course,
we cannot provide any concert experimental evidence here but this can be very useful for
future research about WAP usability.
Other issue to improve the system response is about Point of Presence (PoP) as described in
[Dix 99]. WAP applications can have single-user interaction or multi-user interaction
depending on the applications. And as we know the slowness of mobile communication
causes delays in feedback (response from user's own action) and feedthrough (response from
other user's action), it becomes really important to consider the system architecture.
Architectural design has important effects on usability and notably the temporal properties.
In both cases, the PoP is the replication of server that has almost all the capability of server
for a particular application. PoP effectively form a third place where computation and data
may reside. The crucial point about PoP is that it can be very near to user (or client) and as it
can improve the speed of the response. E.g. a PoP can be a local cell's base station for mobile
phones or a it may be a desktop computer for PDA like devices.
Other issue to improve the system response is through better caching and cookie
management. Cache management is important for quick access for previously used cards and
to control the display of time-sensitive data and cookies are used to store data so that user can
be flexible to enter less input [GSM 2001]. Here are some common guidelines for both of
them.
- Do not store any time-sensitive data in cache.

- Set proper expiry value for the deck, so that old decks can't be used after certain
time.
Response time is also affected the underlying protocols and technologies used. In Europe, all
mobile phones uses GSM networks that are relatively slow then GPRS. DoCoMo's I-mode
technology (very similar to WAP) uses GPRS networks and has already gained lots of
advantages against WAP. This report will not look into these technologies but we can
definitely generate an issue that to improve system response better protocols and technology
are needed aseptically for WAP.
3.4.2 Error Prevention & Recovery:
Error prevention and its recovery are part of system response but as their importance in
usability we have separated them from system response. Even the experienced users are some
time makes error in operation computers [Card 1980, Brown-Gloud 1987]. One of the
better ways to reduce errors is to provide improved error messages. Improved error messages
can lead to lower error-rate, increased subjective satisfaction and repairing the errors
[Shneiderman 1982]. In particularly using WAP phones, when the user time is more critical
and users have less attention towards the system (compared to desktop systems), the error-
messages becomes more important.
Mobile devices use menus, options, lists, etc for the interaction and as a results the interface
becomes very complicated. So, developers should not use "modes" in interaction, as it
becomes impossible for users to reverse their actions [Norman 1983].
It is better to avoid the errors before they could occur. First we will see the error prevention.
One of the most frequent errors come from mismatch between the "user input" and the
"system input structure" [Shneiderman 98]. One of the ways to deal with this problem is to
use proper instructions on the screen for the users. Sometimes it would be helpful to use
selection as input. By this way, system can not only prevent the error but it can also make
faster progression, as there will be less input needed for the system. Sometimes user tries to
enter command that is not supported by application [Shneiderman 98]. In this case
developers should provide some default inputs [Dix 98]. Other way of preventing errors is to
foresight the applications and investigates if there are any resources available at the site. It is
far better to say, "service is unavailable" then allow the user to sign-in and then show them
the error [Nielsen 2000]. System can also guide the users through prompting them to
navigate on specific set of path to achieve their goal. Some help can be provided by the
different input mechanisms used by the device. E.g. some phones use T9 facility for input,
which remembers the previous user commands and provides list of pre-entered commands
that may be used again by the user. But this comes in device usability, which we are not
going to look in this report.
Users can sometimes make mistakes and may want to recover from that mistake.
Recoverability is the term used in [Dix 98], which means to clear or overcome the error of
interaction that has been recognised. The recoverability can be achieved by moving forward
or moving backward depending on application types.
Error messages are also one of the ways to recover from the errorsome interaction. Error
message works for different causes. It can serve as a feedback, to prompt the user about the
mistake and can also help recognise the mistake. Considering the complex interfaces of
mobile phones, it is really difficult to differentiate which fuctionalities are device specific
and which are application specific fuctionalities [Bergman 2000]. So, if an error occurs the
error message should explain if that is application specific or device specific. This helps the
users if they want to complaint about that error [Nielsen 2000]. There are some guidelines
about how to use error-messages [SAP 2001].
- Error message should contain the actual problem of the error and the reason for it, in a
language that a common user can understand.
- And if possible also provide some hint for solving that problem.
Here, language becomes very critical usability, as we know that user screen is very small and
the error message should also be informative and easily understandable. And any technical
information and cryptic errors should be avoided.
Like error messages, the success messages are also important. If the system has performed a
task successfully then the user should receive the confirmation for that [SAP 2001].
Especially in WAP phones, where there is limited screen space and most of the time users are
on the move and as a result they cannot provide 100% attention to the system, it becomes
necessary to provide confirmation for most of their tasks. By providing the success messages
systems can provide more satisfaction.
3.4.3 Domain-Specific Application:
Throughout in this report, we have presented guidelines and issues that concern most of the
application domains. In this section we will talk about some of the specific requirements for
domain-specific WAP applications. Domain-specific applications like News, Sports,
Shopping, Entertainment, Travel Information, Financial Information etc have their own
specific requirements like real-time support, accredited information, security, etc. This
section will provide some issues and guidelines for building domain-specific WAP sites.
3.4.3.1 Payment Issue:
As with all things involving money; security and reliability are critical. There are some WAP
sites that offers on-line shopping or other services that requires users to pay. In this section
we will provide good user-interface issues for payment service to get better usability from
[Allnet 1].
User should always be given information about the exact price (i.e. including VAT) of the
product on the same first page when he/she selects it, with proper currency and decimal
point. To provide secure navigation, the browser should disable the back function so that user
can’t go back to the original page and he cannot place another transaction from that page.
Now, the confirmation of the transaction is also very important. But it should also depend on
the level of the price of product. If a product is worth e.g. £1, then it is not necessary to
provide confirmation of that transaction. And as the amount increases the level of security
and feedback should be more effective. Developers should only ask for password or pin, if
the transaction is very important e.g. transaction of a big amount or if the service requires
more confidentiality. One of the reasons for this is because mobile phone, actually, asks for
initial pin-number when the user starts using it, so it would not be worth taking users time to
ask password if the transaction is not big. But for all the transactions, it should just give the
confirmation e.g. “Transaction Successful”. This gives the user good control and a feeling of
safety, which is an important competitive quality for an e-commerce WAP service.
If it becomes necessary to ask password from users, the developers should follow these tasks.
As we know that inputting from mobile headset is a tedious task. The browser should allow
numeric passwords, so it can be entered easily. Another issue about password is when user
types a password most browsers mask it and user cannot see if he/she has typed the write
word. This situation becomes worst when the user has to enter some letter, in which he/she
has to be very careful. E.g. to type ‘v’, user has to press 8 three times. So, there is a big
probability of getting password error, which can make user highly frustrated.
Another reason, while entering the password in “*****” format, there is a chance that user
might forget the typed letters and have re-type all over again. So, developers should not use
masking mechanism for password. One advantage of not masking the password is, mobile
phones are very personalised and whatever the user is doing cannot be easily seen by others
as most of the users use it at chest height or stomach height, by keeping the head down. So,
mostly the privacy of password cannot be breached.
3.4.3.2 Timeliness Issue:
Timeliness is necessary for almost all applications, mainly supporting News, Sports,
Whether, Stocks, etc. applications. And some times it is also important for Entertainment
applications e.g. in Movie listing, TV listing, etc. Users always want to see the newest
information and hates out-dated information. One of the simplest but the most important and
inevitable thing, to apply timeliness, would be to maintain or update sites more regularly.
Maintaining information along with efficient presentation can increase usability performance.
This section will talk about some guidelines to present real-time information.
For some application specific WAP site, it would be better that the first page should be about
the latest information about that site. E.g. for News site, the latest and most important news
should be on the main card and other news can be selected from different categories. For a
whether site the latest whether information for any specific place should be on the first page
rather then the whole menu.
Allow users to bookmark some categories so that they can straightaway go there rather then
from the first page. On the main page “alerts” should be given, when new information
arrives. These alerts should be easily discoverable with e.g. “New” logo or blinking texts.
3.4.3.3 Accredited Information
There is a big problem of accredited information in the Internet. However, it has been
reduced up to some extent by digital certificates and signatures, but mostly in some finance
and stock related applications. There has not been much development done in these
applications of WAP or other mobile applications. But, even in case of any other application
domains like e.g. News, Sports, etc, people need some kind of confidence in the given
information. But the application developers can put reference form where the information has
come. This can at least give some confidence to users. E.g. in the following figure 11 of
Yahoo-News WAP page, all the news links mention about its source “Reuters”.
Yahoo! News
- Terror alert on 'Alligator
Alley' (Reuters)
- Powell to push Iraq
- 14 killed when van goes
off Maine bridge
(Reuters)
MORE
Menu Back
Figure: 11 Accredited Information
Section 5: Support Services
By support services, we mean those services, which provides additional support to user-tasks.
The application-providers may provide these services in addition to and support their core
service. This section will gather guidelines for support services like "Online Help Service",
"Bookmark", and “Searching". It will also provide guidelines for specific user group and
issues of flexibility and reliability.
3.5.1 Online Help Service:
There may be a situation while using the WAP service, where user will need help from the
system. Help can be the application help or the device help. Here, we will only talk about the
application level help. Online help provides lots of advantages to developers as well as the
users. In general there can be several advantages like- there will be no need for any manuals,
the information can be easily updated, and the information can be easily available
[Shneiderman 98]. At application level, it can provide some facilities like- explanation of
errors, explanation of displayed questions, description of specific terms (or abbreviations),
different guidelines, examples etc.[Shneiderman 98]. Here, we have provided different
guidelines to create online help for WAP applications [Duffy, Keassley].
- Developers should anticipate the problems that the users may encounter.
This can be done by doing some experiments and reviews and then try to collect as many
problems as possible and prepare accurate solution for them each.
- Provide the help that can be easily accessible.
Nielsen found in his WAP usability experiment that out of 20, only 1 person was able to find
the help service from his mobile [Nielsen 2000]. It would not be sensible to provide help
service which users could not find. So place the help form the first page of the application. It
would also not be sensible to provide help for each and every page. Provide help for those
pages where users get more problems as explained in previous point.
Also provide all help pages/cards at one level, so that all pages can be available faster and no
need to get connected next time.
Provide help in a way so that user can proceed in their task. Also give stepwise guidance to
accomplish a particular goal. And considering the worst case, provide some alternative ways
to help users, if they cannot use online help. E.g. provide phone number or e-mail address of
that service
- Provide help with efficient presentation:
The user should get their help from a single page. They should not have to read many pages
to get answer of their help. So, each section should be self-contained. In the help contents
developers should provide examples, so that users can understand it easily. "A good example
can replace a thousand words".
Also organise the topic hierarchy according to the structure of the site. In topics organise
contents that the user can easily understand.
The language and contents becomes very critical for some user groups like novices. Use the
language that requires less verbal skills and should also be easy to understand. Avoid any
abbreviations or any technical words. The text should be in small readable fonts and contents
should be short but consistent considering the screen limitations.
3.5.2 Bookmark:
Bookmark (or favourites) has always been a very useful way to browse the Internet. And
considering the difficulties in mobile phones to enter the whole URL, the bookmark facility
becomes very critical part of usability. Bookmark is a device-specific facility and users can
bookmark only specific numbers of WAP sites. But the number of bookmarks available in
Nokia 7110e was 10 and in Ericsson R320s it was 25, which are very small [Nielsen 2000].
The only way to overcome this is to increase the bookmarking capacity in mobile phones.
3.5.3 Searching:
Usability studies showed that more then half of all users were search dominant [Nielsen
9707b]. While using WWW, they just go to search button and go and find their specific
information. But in WAP, the issue is not the same. Because of the screen limitations the
information is formatted differently in WAP sites so the searching service becomes slightly
less important in WAP sites that provide specific information. Some big WAP portals like
Yahoo!, Excite, etc., which provide lots of different services and have lots of pages of
information, should provide Searching service in their applications. Here, we have described
some issues and guidelines to employ searching in WAP sites.
The searching should very intuitive [Serco 2000]. And it is obvious that the users who will
use the search mechanism may not be very familiar with the system. As a starting point, use
scoped criteria so that user can select their own choice [Nielsen 9707b]. However, avoid
using long navigation to find particular information.
Provide flexibility of search. If possible allow user to type in search field for specific
information without being taken to another screen [Serco 2000]. Also use some default
criteria for users. It is recommended that users should be allowed to fill as fewer fields as
possible, but sometimes it becomes necessary to ask more information from user to provide
more sophisticated search result. In that case provide mandatory as well as the optional
fields.
The search result should also be very intuitive. The resulting list should be very short [Serco
2000], so that not much scrolling needed. If a search gets more result then the user should be
asked for further refinement by adding extra criteria.
The most probable result should appear on the top. Also provide some abstract descriptions
about that result and also provide the level of matching of that search result e.g. give the
relevance in percentage.
3.5.4 Customer Groups:
As the price of mobile phones is getting lesser, more and more people are using them. The
developers of WAP applications should consider different limitations and requirements, as
there will be lots of different user groups, which may use the WAP phones. The customer
groups can be divided into children, elderly people, novice users, less educated users, expert
users, disabled people etc. And even in the disabilities, developers have to consider different
disabilities like, color blind, deaf, mentally disabled, mobility disabled, etc. It is necessary to
consider all of the user groups and their requirements and limitations in the development of
WAP applications; however, to generate guidelines for all these user groups will be out side
the scope of this research.
Here we will provide guidelines for novice users. We believe that novice users are very
critical for any kind of applications. One of the reasons for this is that they have actually very
less or nil experience of the application and if they find the application very difficult then
they will definitely not come again to use the same one. And if the application they found
very easy to use then they will use it often and this will be profitable for application
developers and/or service providers. It is said that WAP application should be that easier for
new users that they should be able to use it without reading the manuals [Bergman 2000].
Novice users:
In order to develop WAP (or infect any) applications, the developers have to know their users
very well. Developers have to know their needs, liking and limitations [Galitz 93]. In general
we will call them user concern. The most common user concern we have described in section
General Usability.
To generate guidelines for novice users we will use the same approach.
As from the name, novice users are the one who are the first time users. Developers have to
design the application that can be easier to figure out and should be interpreted very easily by
novice users. If the application is poorly designed, novices may find themselves completely
stumped, unable to succeed, frustrated at wasting precious time without achieving a goal. On
the other hand, if experts find the interface redundant and the information repetitive, they
may quickly lose interest and move on to alternatives. So, balance between them is necessary
here.
Guidelines:
All the issues and guidelines that we have described throughout the report should be applied
to most user-groups. Here we have only gathered some typical and important guidelines that
relate to particularly novice users.
Novices require more familiarity:

It is not necessary that a novice WAP user must have used WWW before, but if the
WAP developers can provide similar sort of familiarity as in same WWW application then it
would be helpful to novice users. E.g. in Yahoo WAP site the developers can provide the
same logo as in its web site. This kind of familiarities can be provided considering other
factors as well. [Dix 98].
Consistency:
Consistency in interface design allows the user to build a mental model of the system, and as
we know this is badly needed for novice users. Developers of WAP site interfaces can be
consistence with Sequence of Tasks, Results of actions, Data across views, Functionality of
tasks, and navigational patterns. E.g. the link "home" should always lead to start or home
page.
Simple:
Even for any application and for any user group simplicity is the best policy. "KISS" (Keep It
Simple and Stupid!) is well known slogan for any interactive application [Mobile 2001].
• Developers should use simple verbal language for menu options or links.
• Because of the limited screen space, sometimes it becomes necessary to use
abbreviations. Abbreviations should be either most simple ones or should be defined in
the manuals. See Design Layout section for more information.
• Do not use highly technological information.
Predictable:
Predictability is closely coupled with Consistency, as consistency allows users to build the
mental model of the system, which lead to make the application more predictable. As we
have mentioned earlier that- telling people what will happen before they click through to a
new screen is a basic usability principle [Nielsen 2000]. This is can be done by labelling the
links with simple and most common meanings. Even while performing some task, the screen
should provide the information about the page hierarchy and also number of pages remaining
for a particular task. E.g. in wizards information like "2 of 7 page" on the top of the page.
Feedback:
Getting feedback from the action is also a very important and widely known principal for
usability [Dix 98]. Developers can use Iconic feedback or Contextual feedback as described
in Navigation section. Developers can also provide confirmation as a feedback. E.g. In some
online shopping WAP site, after the user places the order a page stating, "Your order has been
successfully placed" should be provided. * The error messages are also very important issue
for novice users. The error message should be very intuitive and easily understandable for
novice users.
Recognition:
As novice users are not familiar with the system, recognition becomes more important then
recall. This guideline in general applies to all kind of applications all user groups as well.
Recognition can also be achieved by some sort of synthesizability [Dix 98] e.g. some voice
effect on each button press can be helpful. User's attention is also achieved by different
presentation styles, e.g. different font size, different color on the screen, blinking texts or by
some special characters like '*'.
Less Input:
The number of input should be kept less to perform a task. First-time users should be able to
carryout simple task easily and successfully. The developers should follow the guideline of
input mechanisms described in Design Consideration section. In any WAP sites the
frequently used services or information should be the most easily accessible and should not
be deep in navigation hierarchy.
Use Wizards:
As we have earlier mentioned that wizards are more efficient then forms, especially in case
of novice user. Wizards reduce the memory load from the users as they have less information
to deal with and they also provide good contextual feedback to the user e.g. on the first line
"page 2 of 4". Of course wizards are relatively slow compared to forms but for novice users
they are more appropriate.
Discoverability:
The term discoverability has already been used in some [Openwave 99]. We came across this
term in our evaluation. We asked some users, who haven't used WAP before, to use the WAP
emulators. And we found that they were not been able to discover (or find) some links which
were presented on the screen, at first instance. E.g. the link "More", when there is more links
to be seen on next page. The main reason for this, we believed, was bad presentation of the
screen. These links were mixed up with other links and as a result they were not easily
discoverable. As a solution we suggest that for some information, which are different from
common text used on the screen, developers should use different presentation (e.g. different
fonts, color or size) and they should be separated from the common text. E.g. the scrolling
indicator icon on the phone should also be well designed so that user can understand it.
Error messages:
Novice users are highly likely to make errors while using the system, so the interface design
should be made to prevent the error then to recover it after it has occurred. More detailed
information about error-message is described in Performance & Reliability section. Here, for
novice users the error-messages become more critical. The language should be as simple and
as understandable as possible. The message should not be general; users need more specific
reason for errors [Shneiderman 98]. Developers can use more information on the page that
can be scrolled down, as more simple information will prompt novice user to solve the
problem.
Section 6: Device Usability
As we have mentioned earlier that all mobile head-set have three interfaces [Pekka 2001]
and due to mobile handset interaction and user interface design conventions it is sometimes
very difficult for the user to distinguish which part of the service is phone functionality and
which belongs to the service [Bergman 2000]. It would be out side the scope of our research,
to produce detailed guidelines for the mobile device. But one has to consider both the device
usability and UI usability while designing the mobile system.
This section will describe some issues and guidelines to improve device usability.
Considering all mobile devices like mobile phones, PDAs, communicators, etc. we think
mobile phones will have better future then the others. The following are the reasons for this:
Mobile phones are used since late 80s in Europe and now it's used in the day-to-day life of
most people in world. This shows that most of the people are more familiar with its use and
functionality. So, any added functionality to the mobile phones will be easily accepted by the
user groups then in any other mobile device [Bergman 2000 page 170-178].
Though having comparatively small screen interface then the other mobile devices, mobile
phones do have better ergonomics then others and phones can be operated by one hand only,
which is good considering some critical situations.
Mobile phones are much cheaper then the others.
3.6.1 Challenges to Device Usability:
There are some Basic Requirements to fulfil, which are inevitable while designing any usable
system.
At the user's part, the interaction is mainly carried out through sequences of button presses;
and the phone may give feedback through tactile feedback, abstract sounds, or
textual/animated effect on the user screen [Bergman 2000].
The mapping of user's key presses to the device's action is not always straightforward and
simple. We cannot match each button to any single function.
One of the ways to structure this phone functionality is a hierarchy of different factions.
Users move through this hierarchy by "up", "down", "back" etc buttons. But still user has to
make a mental model for this and he has to remember it.
3.6.2 Contextual Design and Task Analysis:
3.6.2.1 Contextual Design:
Context of use together with specified target user group-should always be starting point for
design process [Bergman 2000].
As from the name Mobile, it means variability, variability of all means. This variability, we
can describe as different context of use. The analysis of the context can find out the focus on
how and when the device should behave differently and offer different
interaction/presentation options depending on the context of use [Rodden 98]. Contextual-
design is a huge research area, so it would be out-side the scope of our research to go in
much detail.
3.6.2.2 Task Analysis:
One would have noticed form this report, that WAP phone’s usability is somewhat dependent
on WAP browser and WAP services (or sites). Actually, users perform their tasks on device
(i.e. WAP phone) according to the presentation that they get from the UI of service and
browser (i.e. WAP site). So, to consider Device Usability, one has to take into account
different user-tasks that users perform on the WAP site and browser, at the early stages of
design. These tasks can be ad hoc, time-critical, event driven, highly personal, short-term use,
less attention [Berman 2000].
Task analysis is a process of finding out the user behaviour towards the system. It is a Black
Art, and is often not given proper interest. Even the current Internet is having some problems
for not employing task analysis. Task Analysis helps making the complete design process. It
helps designer to find out the sequence of usage and scenarios of user's work format. From
these scenarios more detailed Task Analysis can be made [Berman 2000]. The user goals and
tasks can be divided into sub-goals and sub-tasks that all aims to a specific goal.
As we have mentioned in previous section, different device functionality and services are
mapped into the hierarchy and user has to go through this hierarchy by soft-keys and other
buttons. By using the task analysis, after finding out different priority-level of user-tasks, the
designer can set up easy button-navigation for most critical tasks and more traversal
navigation to less critical tasks.
Even some dedicated buttons can be set-up on the phone for a very important or extremely
critical task. E.g. for switching off the mobile phones a separate button on the top right on the
phone can be set-up. At the same time designer has to provide Familiar symbols and easily
Learnable and understandable icons for different tasks/services button on the phones.
3.6.3 Input-output issues:
3.6.3.1 Output issues:
Both the Mobile phone and PDA are having different layout and size. The user screen is
comparatively bigger in PDA then in phone, which means PDA can be optimised for more
information presentation by space utilisation. The user-screen is fixed in size and can only be
optimised at the application-level by improving the various interaction mechanisms. These
mechanisms are described in Design Consideration section. As there are limitations on the
size of the phone, the designers should try to provide less dedicated buttons on the phone.
Soft-key Issues:
Almost all mobile phones have 2 soft-keys. These soft-keys work as function-keys of the
calculators. They provide extra functions to use on the screen. There are some issues to
consider in these Soft-keys. Number of soft-keys affects the usability. If there are less then 2
soft-keys on the device, then there should be other alternative keys (dedicated keys) or some
mechanisms at the screen interface. But both of this will divert the user's focus, and will
affect the speed of navigation [Bergman 2000]. Even having more soft-keys will make
confusion while remembering them. It is reasonable to have at least 2 soft-keys.
As soft-key works as functional-key the overall performance of system can be optimised by

“number of soft-key pressed for a task”. Soft-keys also provide good recognition of functions
as they always appear on the bottom phone screen, which help the novice users.
3.6.3.2 Input issues:
World is becoming fast-paced and people having no time to press a key three times to enter a
single character. On the other hand, users also have ‘too little’ or ‘no’ time to train
themselves. Even inputting data using regular keypads gets confusing when users try to enter
special characters. As the number of cellular phone users are growing, low performance
times and high error rates will lead to frustration, unnecessary stress and will discourage
novice and elderly from taking advantage of the newer technologies. Users must therefore, be
able to enter text efficiently.
Compared to other mobile devices, input mechanisms in Mobile phones are slower then
others because button interface is much more difficult while navigating links. For effective
mobile phone usage there should be some alternative mechanisms for inputs. To provide high
usability, some of the mechanisms can be described as following.
Researches have proved that inputting numerical letters are much easier and faster then the
textual letters. Some of the experiments have also shown that textual input is approximately
twice as slow as numerical input and that the error rate is about twice as high [SAP 2001],
but this has to be dealt at application-level.
In the traditional Mobile phone 12-key pad is used for input. But it has some problems e.g. to
input a single letter user has to press 3 or 4 buttons at the extreme cases. There is one other
input method called T-9 [Nokia 2002], which uses a built-in dictionary and adds knowledge
to the system itself. It only requires one keystroke. For example, to enter "this", the user
enters 8-4-4-7. T9 then uses the combination of letters and compares it to the word
possibilities in its dictionary to then "guess" the intended word. This creates problems as
many multiple words may have the same key sequence. T9 then guesses the most common
word. Users can then press "*" to view the next possible word. The performances of the
novice and expert users are very different. The novice using T9 for the first time will have to
go through a training and practices session whereas expert users will already be adapt. Expert
users will already be familiar with the way T9 works.
Voice Interface: Recent advances in wireless communication and speech recognition have
made it possible to access the web from any place, at any time, by using only a phone. Some
possible applications are browsing the web, getting stock quotes, verifying flight schedules,
getting maps and directions, checking email, etc. Companies like IBM, Motorola, Lucent and
AT&T founded in 1999 the VoiceXML Forum to deal with speech technologies that make
Internet accessible [Voice 2002]. Speech technology contributes to universal design by
creating access mechanisms that appeal to both people with or without disabilities.
The other two major input entry methods are handwriting using Graffiti alphabet, which is a
hand stroke based handwriting recognition system; and tapping on a soft keyboard. These
two mechanisms are not used in Mobile phones for now but they are very effective in other
mobile devices like PDA. In the previous research of early 90s, the screen keyboard was said
to be faster then Graffiti; but as there are more improvements in handwriting recognition
software, now Graffiti has likely the same speed as the screen keyboard. However, Graffiti is
having some other advantages as well.
3.6.4 Flexibility & Customisability:
One of the best ways to provide the Usability in a system is to provide better flexibility and
customisability in the system. Users should be allowed to customise the interaction in their
own way, but up to some extent. User should not be forced to become designers of their
system. Functions that allow, but not force, users to change some aspects of their device can
significantly increase the subjective satisfaction with the device. E.g. let the users allow
placing their favourite application on a button, which is ergonomically good.
Chapter 4: Evaluation
4.1 Introduction:
In the case of any interactive system, the main goals of an evaluation will be to assess the
usability and functionality of the product and find out problems, if there are any. For our
research, the evaluation will be a critique of two different WAP sites currently available. Our
main aim will be to find out how usable the current WAP sites are.
For our evaluation we asked few people, each at a time, to perform set of tasks on Nokia
Mobile Internet Toolkit v3.1 -emulator and asked them some questions about usability of
those WAP sites and their suggestions about the sites. Obviously, evaluating from any WAP
emulator will not provide the same results, in terms of usability, as the original WAP enabled
phones. In the evaluation of WAP emulators, some issues like ergonomics, interaction styles,
input mechanisms, etc. will not be applicable as they are totally different in WAP enabled
phones. But here, our main concentration will be on the presentation and design layout of
these WAP sites.
The main reason for this evaluation is to apply the guidelines that we have generated in our
research and find out how the current WAP sites and portals apply those guidelines. We also
want to know what factors and issues would be important for users and where they might
have problems while using it. So, from the nature of the evaluation this would not be any
statistical experiment but would be a simple critique.
4.2 Methodology:
From the nature of our research, we cannot apply any field or laboratory studies to evaluate
these sites. For our evaluation a method, developed by Jacob Nielsen and Rolf Molich, called
heuristic evaluation will be the most appropriate. Of course, they had originally developed it
for desktop user interfaces but we can use it for handheld device interfaces as it uses the most
common principles. Heuristic evaluation luckily fits very well to our evaluation as it help to
find out usability problems in user interface design [Nielsen 10]. It would also be
advantageous to have some observers (or participants) for assessing the same sites as they all
could find out different usability problems [Nielsen 10]. In addition to the heuristic
evaluation, it would be helpful to use usability principles described in [Dix 98].
4.3 Design of evaluation:
We asked four people, 3 male and 1 female, in person, to use Nokia Mobile Internet Toolkit
v3.1 - emulator and perform three tasks on two different WAP sites each. We have
deliberately selected them as they all were familiar with mobile phones and none of them has
ever used WAP before. The test design is shown in the figure-12.
Initial Interview
User Tasks
Final Interview
Figure 12- Design of Evaluation
4.3.1 Initial Interview:
First, we asked our participants some general questions about their experiences in the Internet
usage, mobile phone usage, their personal interests, etc. The full list of questionnaire can be
found in Appendix-A. The main reason for these questions was to know their individual
experience and interests. We also showed the demonstration of that Nokia emulator and
taught them how to use it.
4.3.2 User Tasks:
Here, we asked our participants to use two WAP sites, first wap.yahoo.com and then
wap.hollywood.com and asked them to perform 3 tasks. The importance of this test was not
just the completion of the given tasks but how they completed them and what did they like
about the sites and what they didn't. Here, we have to interpret user's action in order to infer
how these actions are related to the usability issues in designing the interfaces. Initially, we
have also informed the users to speak, without hesitating, through out the test about the
problems they may face while using the site. That is because they might forget some issues
after the completion of the test. The more they say about the site the more it would help us to
criticise it. We also generated the result of the test, which is shown in Appendix B.
4.3.3 Final Interview:
After completion of those tasks we asked our participants to criticise and comment on the
issues about the design layout and presentation of those two sites.
4.4 Analysis:
It would be sensible to write a common critique from all four participants rather then their
individual ones because there were lots of common views we found in this evaluation. We
have divided our critique in 10 different parameters as described in [Nielsen 10] by Jakob
Nielsen and allocated our critique into it. We have also applied usability principles described
in [Dix 98] to make our critique more concrete.
As we have mentioned earlier that in some cases there is a very blurred distinction between
the user interface (provided by the WAP browser) and service interface (provided by the
WAP application). Hence, in our critique we shall mention both them in conjunction as they
complement each other in the overall usability. Here, we will use just Yahoo to address
Yahoo-WAP site and Just Hollywood for Hollywood-WAP site. The following are the main
points of our critique.
4.4.1 Visibility of system status
“The system should always keep users informed about what is going on, through
appropriate feedback within reasonable time.”
Whenever the system is processing some task, the browser provided by the Nokia emulator
shows a rotating icon every time. This is also important because it is shown on the same top-
right corner of the Internet-browsers such as the Internet Explorer. In both Yahoo and
Hollywood, on the top of each card there is one header showing the service-name or menu-
name. In Yahoo especially, the whole sequence of menu and sub-menu is also shown on the
top of card when the user is in the sub-menu.
E.g. Y! Sports
- Cricket
Live
News
Menu Back
Figure: 13 Example for visibility
This can give good indication of the navigational hierarchy as well as current card status. The
Hollywood shows only the current menu on the first line. In Yahoo, the visibility is given a
good importance as they also have shown a service with an indication as “X” (cross mark),
which was not available at that time.
4.4.2 Match between system and the real world
“The system should speak the users' language, with words, phrases and concepts
familiar to the user, rather than system-oriented terms. Follow real-world
conventions, making information appear in a natural and logical order.”
Both the sites have used very pleasing and unambiguous language in the links and in other
text, so that almost all type of users can understand it. The logo of the site can provide more
confidence to the user about their correctness and it can also provide better familiarity. Yahoo
provides the logo but not Hollywood. The order and summarisation of the links should also
be efficient, it should follow the rule of “most important links should come first”. Yahoo
doesn’t follow this rule well; one of the reasons is that it is a big portal and it would be
difficult to show all the important links. Hollywood is a very specific domain and it has done
good link usage.
4.4.3 User Control and freedom
“Users often choose system functions by mistake and will need a clearly marked
"emergency exit" to leave the unwanted state without having to go through an
extended dialogue. Support undo and redo.”
The browser supports back function by employing back soft-key on the screen, which works
well. Hollywood’s site has facility of back, by providing a “back” link, in some pages where
users might though to go back e.g. some leaf cards, where user has no further navigation. But
this is not there in higher level pages. It also had “more” link at the same time is the users
want to read more about that. But Yahoo didn’t have this facility. Hollywood site can be
called to be of a specific domain, and Yahoo is a portal. In big portals there should be a
search engine or help mechanism that can help user if they want to find some specific
information, but these are not there in Yahoo’s site.
4.4.4 Consistency and standards
“Users should not have to wonder whether different words, situations, or actions
mean the same thing. Follow platform conventions. “
The consistency can be applied in positioning the widgets (or similar as in Mobile phones)
and naming of links and options. In yahoo we observed that on some pages they have used
‘Back’ and in others ‘Prev’; this had actually caused problem for a participant working with
us. He though it might be used for ‘Preview’ instead of Previous. Yahoo has used the same
naming as it is in Yahoo web-site. There was also lack of consistency in Hollywood’s movie
‘Symptoms’, as some movies had long information and some had nothing written about
them.
4.4.5 Error prevention
“Even better than good error messages is a careful design which prevents a problem
from occurring in the first place.”
One of the main sources of errors, especially in mobile phones, is the input process. And here
we have used an emulator and we are only going to evaluate the user interface, so this issue
can not be applied here. In emulators most of the navigation is link-based so there is less
chance for making errors. But we think, in this browser they haven’t kept any default
selections, so user might just press a button but nothing works for him.
4.4.6 Recognition rather then recall
“Make objects, actions, and options visible. The user should not have to remember
information from one part of the dialogue to another. Instructions for use of the
system should be visible or easily retrievable whenever appropriate.“
One of the most interesting issues that we found in this evaluation is Discoverability. We
found that one user couldn’t find a link called “More”. This is used when there is more
information available on next page. And reason that he said was he couldn’t easily
distinguish that link from the other links. Here comes the concept of discoverability, we have
defined it as “how easily a user can distinguish (or discover) a link or other widgets from the
interface”. If that more links had a different color or different font size/style (i.e. a
mechanism that easily distinguishes a thing), the user would have easily found that link.
Scrolling is always an important issue for mobile devices. Here this emulator showed good
indications about the scrolling by adding an arrow at the bottom. Both of the sites have not
used any good alert mechanism (e.g. symbolic “New”), which can be used in newly arrived
news or new movie.
In yahoo, as we have mentioned above, they have used how navigation hierarchy in the
header, which gives good recognition of user’s task path. None of the sites have used any
voice-synthesises, which can be applied here.
4.4.7 Flexibility and efficiency of use
“Accelerators -- unseen by the novice user -- may often speed up the interaction for
the expert user such that the system can cater to both inexperienced and
experienced users. Allow users to tailor frequent actions.”
Hollywood gives two way to book a ticket, one can book the tickets from the first page and
for other users they can go and see the information about the movie and after they can book
the tickets.
In Yahoo, all long text is wrapped to next line and as a result it becomes difficult for user.
And even user selects a link, it becomes very confusing to them.
In Yahoo-News, one first screen a link, which just informs about that news in 1 or 2 lines and
after clicking it user gets the whole news. They should also provide a summery of news
because that news includes lots of scrolling to the user. But one good thing about it is, in each
of the news they had provided their references, mostly from Reuters. This gives good
confident in user as they have some evidence for those information.
In Hollywood, while browsing different area code users can’t go back straight to first page.
They have to re-navigate through the whole sequence again. In Yahoo TV-guide, in channel 4
schedule user saw the schedule always only up to 5pm, so there was less efficient updating.
4.4.8 Aesthetic minimalist design
“Dialogues should not contain information which is irrelevant or rarely needed. Every
extra unit of information in a dialogue competes with the relevant units of information
and diminishes their relative visibility.”
Both sites have followed this principle very well. There was not any decorative or fancy
thing on the screen. User can do their important task without scrolling.
4.4.9 Help users recognise, diagnose and recover from errors
“Error messages should be expressed in plain language (no codes), precisely

indicate the problem, and constructively suggest a solution.”
This browser uses “back” functionality automatically when the user goes to some unavailable
card or types a site that doesn’t exist. So, this way the browser prevents the confusion and
also helps the user by taking them to the previous page. This functionality, however, is really
good if it can be employed in the real WAP phones.
The only error-message that all user came across was accessing the Yahoo-Mail. The users
were getting error, but it was not well structured and didn’t prompt the users that well. The
only understandable thing about that error was that, it just said, “XYZ has been moved to
ABC. Go to new location”. For a normal user this can’t serve as a good reason or better way
of prompting him.
4.4.10 Help and documentation
“Even though it is better if the system can be used without documentation, it may be
necessary to provide help and documentation. Any such information should be easy
to search, focused on the user's task, list concrete steps to be carried out, and not
be too large.”
This principle may not be applicable to our evaluation as we are only dealing with the
usability of browser and WAP sites. However, it is important to provide help and
documentation separately and if possible on the sites as well. None of these sites have help
functionality.
Chapter 5: Final Discussion & Conclusion:
In this report we have described issues and guidelines to improve the usability of user-
interface and service-interface of WAP phones. Considering the different HCI-challenges for
mobile devices, as described in the introduction, one of the issues is to developer better
interfaces. In this research, we spent lots of time on providing better interface design. So,
here we will be able to comment on those issues.
We have discussed about input layout, and found out that inputting from small key-pad of
mobile phone is a difficult task so the developers have make the application accordingly. In
order to do that try to minimise the input fields in the application and if it becomes inevitable
to use, it then try to use the numerical input first. And at the worst case, ask for those letters
that can be easily pressed from the mobile phone (e.g. the first letters from the buttons). To
prevent errors, input fields should be labelled in a way so that user can clearly understand
what type of input is required, user default inputs and give proper examples to instruct users
while inputting. Developers should only ask for password when the application is very
critical, for otherwise there is no need for it.
We also saw different presentation mechanisms. Developers should provide the links in a
way that users can assume it’s destination. This can be done by better verbal usage. Getting
feedback from the work is also a well-known slogan in usability. Systems should always
provide feedback of its status and its progress. The feedback can be given by Iconic
presentation as well as Contextual presentation.
The contents that are provided on the screen should be very precise, because there is not
much space. So, better summarising technique should be used. Scrolling and page-size are
also very critical issues for presenting information. Scrolling will not be a bad idea if the
options presented on the screen are well structured. Also having long page (i.e. more
scrolling) can cause better page utilisation, as one can put more options on the screen and
user can have direct access to those information. And having fewer cards needed for the
navigation means there will be less reloading of new-pages each time. Here, menu
architecture also comes to attention. The shallower and broader the menu design the more
efficient navigation can be.
Colors can be used as for better Discoverability, a usability principle that we found during
our research. Better color presentation gives better recognition about the interface status.
Error messages are also important here. Error messages should provide clear reason for the
error and should also prompt user to overcome the error.
Here, we would also like to mention that we have tried to gather all the issues affecting the
WAP usability but some of them we have left out. E.g. context sensitivity is also important in
task analysis that we have not mentioned here. At the system architecture level we have just
talked about proxy mechanisms.
One other important thing we have observed here, form its current status, that WAP can have
good future in Entertainment, Sports, News, etc services as these services doesn’t need much
secured or accredited information; rather then in financial services like banking, stock
information or shopping. Even DoCoMo’s I-mode has gained more subscribers using
entertainment applications.
We can summarise the whole conclusion here in one sentence that “For better usability
provision, a good user-orientation with better systems resources is inevitable.”
Bibliography:
[Dix 98]
HUMAN-COMPUTER INTERACTION, second edition, Prentice hall © 1998
Alan Dix - Janet Finlay - Gregory Abowd - Russell Beale.

www.hcibook.com
[Nielsen 2000]:
WAP Usability - Déjà Vu: 1994 All Over Again, Report from a Field Study in
London, Fall 2000. By Marc Ramsay and Jakob Nielsen, Nielsen Norman Group,
December 2000.
[Bergman 2000]
Information Appliances and Beyond, Interaction Design for Consumer Products,
Eric Bergman (ed.), Morgan Kaufmann.
[Mobile 2000]
Mobile Usability. A report by Sabrina Duda, Michael Schiebl, Jan Michael Hess of
Mobile Economy.
[Hurst-Gellady 2000]
“Building a great customer experience to develop brand, increased loyalty and
grow revenues,” by Hurst, M and Gellady, E.
www.creativegood.com/creativegood-whilepaper.pdf
[Spiegel 2000]
“Report: 70 percent of retailers lack e-commerce strategy.” Ecommerce Times.
www.ecommercetimes.com/news/articles2000/000126-1shtml , Jan. 26
[Beyer-Hugh 1997]
“Contextual Design: A customer-centred approach to system designs”, 1997,
Morgan Kaufman Publishers, ISBN: 1558604111. By, Beyer, Huge and Holtzblatt,
Karen.
[Openwave 99]
Developing User Friendly Applications, Application Usability Guidelines from the
Phone.com Application Development Team. (August 1999).
[Project Management]
Essentials of Project Management. By Dick Billows.
[SAP 2002]
SAP Interaction Design Guide for WAP Applications, (Feb 2002)
http://www.sapdesignguild.org/resources/wap_guidelines/wap_guidelines.pdf
[Telenor 2000]
User Interface Design Guidelines for WAP Applications, Version 1.4, 1st of
October 2000. By Tone Grimstad, Harald Stegavik, and Erik Saastad. The Usability
Section, Telenor Mobile-Communications.
[Nielsen 10]
Ten Usability Heuristics. by Jakob Nielsen.
http://www.useit.com/papers/heuristic/heuristic_list.html
[Little 2002]
Mobile Style Guide – Sample, Little Springs Design, a division of Little Springs, Inc
http://www.littlespringsdesign.com/design/sampleguide.html
[Pekka 2001]
The Three Facets of Usability In Mobile Handsets. By Pekka Ketola & Mika
Röykkee. Nokia, Visiokatu 1, FIN-33720 Tampere, Finland.
[Brew 2002]
BREW User Interface Design Guidelines, 80-D4231-1 Rev. A. March 7, 2002.
http://www.qualcomm.com/brew/developer/developing/docs/80-D4231-1_A.pdf
[Nielsen 94]
Usability Engineering. Book by Jakob Nielsen, published by Morgan Kaufmann,
San Francisco. ISBN 0-12-518406-9 (paperback)
[Arizona 2001]
www.cs.arizona.edu/classes/cs630/fall01/ 630-1/presentations/proxy.PDF
[Dix 99]
“Places to stay on the move” Software architectures for mobile user interfaces.
By Alan Dix, Devina Ramduny, Tom Rodden, Nigel Davies.
www.hiraeth.com/alan/topics/mobile/
[WebExpress]
WebExpress: A System for Optimising Web browsing in a Wireless Environment.
By Barron C. Housel and David B. Lindquist.
[Rodden 98]
Exploiting context in HCI design for Mobile Systems. T. Rodden, K. Cheverst, N.
Davies and A. Dix (1998). Workshop on Human Computer Interaction with Mobile
Devices, Glasgow, 21st & 22nd May 1998.
[Nielsen 93]
Usability Engineering. Book by Jakob Nielsen, published by Morgan Kaufmann.
[Openwave 10]
“Top 10 Usability Guidelines for WAP Applications”
developer.openwave.com/resources/uiguide.html
[SAP 2001]
“WAP- Designing for small user interfaces”. By - Oliver Frick and Albrecht
Schmidt. www.sapdesignguild.org/innovation/artikel/wap-design1.html
(last accessed on 17/08/2002)
[Nokia 2002]
www.nokia.com
[Voice 2002]
www.voicexml.org/
[RedWhale]
“Adapting to Mobile Contexts with User-Interface Modelling”. By Jacob
Eisenstein, Jean Vanderdonckt, and Angel Puerta. RedWhale Software Corporation,
Town and Country Village Suite 273-277, Palo Alto, CA 94301.
[Bhagat 94]
Bhagwat, P. & Satish K. Tripathi (1994). Mobile Computing. In proceedings of
Networks’94, pp. 3 – 12.
[Satyanarayanan 95]
“Fundamental Challenges in Mobile Computing”. By M. Satyanarayanan School
of Computer Science Carnegie Mellon University
[Kuutti 2002]
“Challenge of Human-Computer Interfaces for mobile systems and services”
By, Prof. Kari Kuutti. Deprtment of Information Processing Science, University of
Oulu. http://www.ee.oulu.fi/~ato/ems2002/kuutti.pdf
[Jesper 2002]
“Just-in-Place” information for mobile device interfaces. By, Jesper Kjeldskov,
Department of Computer Science, Aalborg University, Denmark.
[Nielsen 9707b]
Jakob Nielsen's Alert box for July 15, 1997:
http://www.useit.com/alertbox/9707b.html
[Nielsen 99]
“User Interface Directions For The Web”. Communications Of The ACM. January
1999/Vol. 42, No. 1.
[SAP-MiniApp]
SAP MiniApp Guidelines.
http://www.sapdesignguild.org/resources/ma_guidelines/
[Becker 2001]
“A Usability Perspective on Wireless Internet Technology”. Shirley A. Becker
Computer Science & Software Engineering, Florida Institute of Technology, 150 West
University Blvd. Melbourne, Florida 32901.
[Jones 99]
“Improving Web Interaction on Small Displays”. By Matt Jones, Gary Marsden
Norliza Mohd-Nasir, Kevin Boone, George Buchanan. Interaction Design Centre
School of Computing Science, Middlesex University, UK.
[Legge 85]
Legge, G., Pelli, D., & Schleske, M. (1985). Psychophysics of Reading—1. Normal
Vision. Vision Research, 25, 239-252.
[Tulis 95]
Readability of Fonts in the Windows Environment. Tullis, Thomas, Boynton,
Jennifer, & Hersh, Harry.
http://www.acm.org/sigchi/chi95/proceedings/intpost/tst_bdy.htm
[ Duffy]
T.M. Duffy al et. "Online help: Design and Evaluation".
[Kearsley]
G. Kearsley "Online help systems: Design and Implementation".
[Marsden 2001]
“Ubiquitous Computing and Cellular Handset Interfaces – are menus
the best way forward?”. Gary Marsden a Matt Jones b
[Ericsson 2001]
http://www.nada.kth.se/~hehu/usability/WAPStudy_bw.pdf
[Miller 81]
The Depth/Breadth Tradeoff in Hierarchical Computer Menus. By Miller, D. P.
Proceedings of the Human Factors Society 25 the Annual Meeting pp. 296-300. 1981
[Norman 88]
The effect of tree structure on search in a hierarchical menu selection system. By
Norman, K. L., & Chin, J. P. Behaviour and Information Technology, 7, pp. 51-65.
1988
[DoCoMo's I-mode]
www.nttdocomo.com
[Movie 2001]
MIE 1404S: Movie Listing Service for the Mobile Phone
Group 8: Final Report
http://www.imedia.mie.utoronto.ca/people/takesh/html/MIE1404S/FinalReportE.htm
[WebTv 97]
WebTV Usability Review
Jakob Nielsen's Alertbox for February 1, 1997:
http://www.useit.com/alertbox/9702a.html
[Buchanan 2001]
Improving Mobile Internet Usability, by George Buchanan, Sarah Farrant, Matt
Jones Harold Thimbleby. May 2001.
[Allnet 1]
http://www.allnetdevices.com/developer/opinions/2001/08/27/usability_review.html
[Allnet 2]
http://www.allnetdevices.com/developer/opinions/2001/07/25/wireless_usability.html
[GSM 2001]
“GSM application style guide”
//developer.openwave.com/
[Shneiderman 1982]
“Designing Computer System Messages”. Communications of ACM 25, 1982.
[Norman 83]
“Design Rules Based On Analyses Of Human Errors”. Communications of ACM
26, 1983.
[Brown-Gloud 1987]
“Human Computer Interface Design Guidelines”. Albex, Norwood, NJ.
[Shneiderman 98]:
Designing the User Interface, Third Edition.
Addison-Wesley Publishing Company.
Appendix A: Personal Information

Appendix B: User Tasks & Results
Appendix A: Personal Information:
Name:
Sex:
Age:
Occupation or Work
How long have you been using Internet?
Less then a year 1-2 year 3-4 year more then 5 years
How many hours a day you work on Internet?
Less then 1 2-3 hours 4-5 hours more then 6 hours
Which of the following area services you use more?
Entertainment News Science Business Travel Sports Shop
Government Arts Education E-mail Computer related Chat
How long have you been using the Mobile phone?
Less then 1 2-3 years more then 4 years
Have you used any WAP phones before?
Yes No
Do you have any knowledge about HCI or Usability studies?
Not heard Just heard Familiar
In WAP phones which service you think will be most important to you? Why?
Appendix B: User Tasks & Results
User Tasks:
1) wap.yahoo.com
Task 1: Check the e-mail

Task-2: Check out news Top-stories
Task-3: Find out 8 o’ clock program on Channel 4
2) wap.hollywood.com
Task 1: Find the latest movie

Task-2: Find any theatre for that movie
Task 3: Check out movie news.
Results:
Participant wap.yahoo.com wap.hollywood.com

(No.)
Task-1 Task-2 Task-3 Task-1 Task-2 Task-3

Mobile Usability

Uploaded by

Copyright:

Available Formats

You might also like

Mobile Usability

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mobile Usability

Uploaded by

Copyright:

Available Formats

“Investigating Usability Issues in WAP Applications” Page 1 of 67

A research conducted for MSc Dissertation.

“Investigating Usability Issues in WAP

Dhaval Vyas, (MSc Computer Science)

An example of Vertical scrolling.......................................................8

Chapter 2: - Problem Gathering in WAP.......................................12

Chapter 3: Usability Guidelines & Issues......................................17

SECTION 2: DESIGN CONSIDERATION:........................................................................................................................27

4.3.3 Final Interview:....................................................................................................................................54

Chapter 5: Final Discussion & Conclusion:...................................58

Which of the following area services you use more?.....................66

Do you have any knowledge about HCI or Usability studies?.....66

Figure-1 Mobile devices

Figure-2 Structure of the research

Figure-3 Model for efficient WAP-browsing

Figure-4 Flexibility in Navigation

Figure-5 An example proxy mechanism

Figure-7 An example of wizard

Figure-8 An Example of Links

Figure-9 An Example of Discoverability

Figure-10 An example of Vertical scrolling

Figure-11 An example of Accredited Information

Figure-12 An example of Design of Evaluation

Figure-13 An Example for visibility

This dissertation is an Integrative Research on investigating different usability issues in WAP

1.1 Overview of usability:

Jakob Nielsen describes, in [Nielsen 93], usability as combination of Learnability, Errors,

In [Dix 98], the usability is described as a combination of Learnability, Flexibility and

Flexibility is further divided into Dialog-initiative, Multi-threading, Task

Robustness is further divided into Observability, Recoverability, Responciveness,

Depending on system's requirement and behaviour, these usability principles should be

1.2 Overview of mobile devices and their usability:

Figure 1: Mobile Devices

1.3 Approach used in the research

Problem Guidelines &

Figure 2: Design of the research

In Problem Domain, we have investigated different usability problems in WAP applications.

Rest of the report is explained in following section.

Chapter 3 discusses different WAP-usability issues characterised in General Usability, Design

Chapter 2: - Problem Gathering in WAP

2.2 Executive Summery:

2.3 Problems in WAP:

We have divided the problems in following criteria:

1. User Personal Problem

2.3.1 User Personal Problem

2.3.2 General Usability Problems

2.3.3 Interface Problems

2.3.4 Application Specific Problems

Chapter 3: Usability Guidelines & Issues

Section 1: General Usability

Section 1: General Usability

3.1.2 User-oriented issues:

3.1.2.1 Know the user concerns:

Figure 3 Model for efficient WAP-browsing

These are different WAP-browsing styles that developers should apply in

1. Identify user activities

3.1.2.2.1 Identify user activities: