What Is Mobile Computing?

(Cont.)
Mobile Computing:
Is an umbrella term used to describe
technologies that enable people to access
network services anyplace, anytime, and
anywhere.

3
 Comparison to Wired Net.
Wired Networks Mobile Networks
- high bandwidth - low bandwidth
- low bandwidth variability - high bandwidth variability
- can listen on wire - hidden terminal problem
- high power machines - low power machines
- high resource machines - low resource machines
- need physical access(sec. - need proximity
- low delay - higher delay
- connected operation - disconnected operation

4
 Why Go Mobile?
Enable anywhere/anytime connectivity
Bring computer communications to areas
without pre-existing infrastructure
Enable mobility
Enable new applications
An exciting new research area

5
Applications of Mobile Computing
(Cont.)

For Estate Agents

In courts
In companies
Stock Information Collection/Control
Credit Card Verification
Taxi/Truck Dispatch
Electronic Mail/Paging

6
 Challenges
Disconnection
Low bandwidth
High bandwidth variability
Low power and resources
Security risks
Wide variety terminals and devices with
different capabilities
Device attributes
Fit more functionality into single, smaller
device

7
Future of Mobile Computing

Use of Artificial Intelligence

Integrated Circuitry -> Compact Size
Increases in Computer Processor
speeds

8
 Features of Android
Android can run multiple apps at the Same Time
Also support optimized graphics VGA, 2D graphics and
3D graphics
Android has a better app market
Android lets you change your settings faster
It gives you more options to fit your budget
Android keeps information visible on your home screen.
Android also support Java applications.
 Conclusion
Mobile computing has severe limitations
- however, it is far from impossible, and
technology improves all the time
Lots of challenges
- some have (good) solutions, many
others are still waiting to be solved

10
WHAT IS ANDROID?
Android is an open mobile phone platform that was
developed by Google and later by Open Handset
Alliance. Google defines Android as a "software
stack" for mobile phones.

Software stack is made up of operating system(the

platform on which everything runs), the middleware
(the programming that allows applications to talk to
a network and to one another) and the applications
(the actual programs that phone will run)
APPLICATION COMPONENTS
Activity

●
Present a visual user interface for one focused endeavor the user can undertake
●
Example: a list of menu items users can choose from

Services

●
Run in the background for an indefinite period of time
●
Example: calculate and provide the result to activities that need it

Broadcast Receivers

●
Receive and react to broadcast announcements
●
Example: announcements that the time zone has changed

Content Providers

●
Store and retrieve data and make it accessible to all applications
●
Example: Android ships with a number of content providers for common

Intents

●
Hold the content of a message
●
Example: convey a request for an activity to present an image to the user or let the user edit some text
ACTIVITY
CYCLE
INSIDE AN ACTIVITY

public class CCSActivity extends Activity

{
@Override
public void onCreate(Bundle
savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
SERVICES
 Run in the background
 Can continue even if Activity that started it dies
 Should be used if something needs to be done while the
user is not interacting with application
 Otherwise, a thread is probably more applicable
 Should create a new thread in the service to do work in,
since the service runs in the main thread
 Can be bound to an application
 In which case will terminate when all applications bound to
it unbind
 Allows multiple applications to communicate with it via a
common interface
 Needs to be declared in manifest file
 Like Activities, has a structured life cycle
SERVICES
CYCLE
PROJECT COMPONENTS
SRC
The project source code

GEN
Auto generated code
Example: R.java

Included libraries

Resources
Drawables
Layout
Values like strings

Manifest File
A must have xml file. Contains essential information about the system to
the android system
R CLASS
 Auto-generated: YOUR SHOULD’NT EDIT IT!
 Contains IDs of the project resources
 Enforces good software engineering
 Use findViewById and Resources object to get
access to the resources
 Ex. Button b = (Button)findViewById(R.id.button1)
 Ex. getResources().getString(R.string.hello));
 Introduction
Because the greatest advances in mobile
communications originated in the military, it is no
surprise that one of the first applications of wireless
communication for mobile computing systems was in
displaying terrain maps of the battlefield. From this,
the global positioning system (GPS) evolved so that
soldiers could know their locations at any given time.
Portable military computers were provided to provide
calculations, graphics, and other data in the field of
battle. In recent years, wireless telephony has become
the major provider of a revenue stream that is being
invested into improving the infrastructure to support
higher bandwidth data communications.
51
 Wireless Mobile
Recently, computer networks have evolved by leaps and
bounds. These networks have begun to fundamentally change
the way we live. Today, it is difficult to imagine computing
without network connectivity. Networking and distributed
computing are two of the largest segments that are the focus of
current efforts in computing. Networks and computing devices
are becoming increasingly blended together. Most mobile
computing systems today, through wired or wireless
connections, can connect to the network. . Because of the
nature of mobile computing systems, network connectivity of
mobile systems is increasingly through wireless
communication systems rather than wired ones. And this is
quickly becoming somewhat of a nonmandatory distinguishing
element between mobile and stationary systems.
52
 Wireless Mobile
There are four pieces to the mobile problem: the
mobile user, the mobile device, the mobile application,
and the mobile network. We will distinguish the
mobile user from the stationary user by what we will
call the mobile condition The set of properties that
distinguishes the mobile user from the user of a
typical, stationary computing system. We will wrap the
differences between typical devices, applications, and
networks with mobile devices, applications, and
networks into a set of properties that we will call the
dimensions of mobility: the set of properties that
distinguishes the mobile computing system from the
stationary computing system.
53
 ADDED DIMENSIONS OF MOBILE COMPUTING
The dimensions of mobility (Figure 1.3) are as
follows:
1. location awareness,
2. network connectivity quality of service (QOS),
3. limited device capabilities (particularly storage
and CPU),
4. limited power supply,
5. support for a wide variety of user interfaces,
6. platform proliferation, and
7. active transactions
54
ADDED DIMENSIONS OF MOBILE COMPUTING

55
 Location
Location : There are two general categories: localization and
location sensitivity.
Localization is the mere ability of the architecture of the mobile
application to accommodate logic that allows the selection of
different business logic, level of work flow, and interfaces based on a
given set of location information commonly referred to as locales.
Localization is not exclusive to mobile applications but takes a much
more prominent role in mobile applications. Localization is often
required in stationary applications where users at different
geographical locations access a centralized system. For example,
some point-of-sale (POS) systems and e-commerce Web sites are able
to take into account the different taxation rules depending on the
locale of the sale and the location of the purchase. Whereas
localization is something that stationary applications can have,
location sensitivity s something fairly exclusive to mobile
applications.
56
 Location
The most well known location sensing system today is
GPS. GPS-enabled devices can obtain latitude and
longitude ‫ خـطـوط لاـطـول وـلاـعـرض‬with accuracy of about 1–5 m.
GPS has its roots in the military; until recently, the
military placed restrictions on the accuracy of GPS
available for public use. Most of these restrictions have
now been lifted.
GPS devices use triangulation techniques by triangulating
data points from the satellite constellation that covers the
entire surface of the earth. If a device does not have GPS
capabilities but uses a cellular network for wireless
connectivity, signal strength and triangulation or other
methods can be used to come up with some approximate
58
location information, depending on the cellular network.
 Quality of Service
Whether wired or wireless connectivity is used, mobility
means loss of network connectivity reliability. Moving from
one physical location to another creates physical barriers that
nearly guarantee some disconnected time from the network.
If a mobile application is used on a wired mobile system, the
mobile system must be disconnected between the times when
it is connected to the wired docking ports to be moved. Of
course, it is always a question whether a docking port is
available when required let alone the quality and type of the
available network connectivity at that docking port. In the
case of wireless network connectivity, physical conditions can
significantly affect the quality of service (QOS). For example,
bad weather, solar flares, and a variety of other climate-
related conditions can negatively affect the (QOS).
59
 Quality of Service
When it comes to taking into account the QOS in most
applications, certain functionality is expected of most
mobile applications. For example, almost all mobile
applications should know how to stop working when
the application suddenly disconnects from the network
and then resume working when it connects again.
Other functionality may be desired but not required.
For example, often QOS data are measured and
provided by the network operator. For example, the
real-time bandwidth available may be part of the data
provided and refreshed on some time interval. Such
data can be utilized to design applications that
dynamically adapt their features and functionality to
the available bandwidth. 60
 Limited Device Storage and CPU
No one wants to carry around a large device, so most useful
mobile devices are small. This physical size limitation imposes
boundaries on volatile storage, nonvolatile storage, and CPU on
mobile devices. Though solid-state engineers are working on
putting more and more processing power and storage into smaller
and smaller physical volumes, nevertheless, as most mobile
applications today are very rudimentary,‫ي‬ ‫بــ‬
‫ادـئـ‬ there will be more
and more that we will want to do with them.
Today’s mobile applications are resource-starved ‫لموارد‬
‫ مـتعطش لـ‬. So,
although the designers of modern applications designed to run on
personal computers (PCs) and servers continue to care less and
less about system resources such as memory and processing
power, it is a sure bet that memory limitations will be around for a
long time for mobile applications because when it comes to
mobile systems and devices, smaller is nearly always better
61
 Limited Device Storage and CPU
Limitations of storage and CPU of mobile devices put yet another
constraint on how we develop mobile applications. For example, a
mobile calendaring application may store some of its data on
another node on the network (a PC, server, etc.). The contacts
stored on the device may be available at any time. However,
the contact information that exists only on the network is not
available while the device is disconnected from the network. But,
because the amount of data that can be stored on each type of
device varies depending on the device type, it is not possible to
allocate this storage space statically. Also, some information may
be used more frequently than others; for example, the two weeks
surrounding the current time may be accessed more frequently in
the calendar application or there may be some contacts that are
used more frequently. Mobile applications must be designed to
optimize the use of data storage and processing power of the
device in terms of the application use by the user.
  62
 Limited Power Supply
We have already seen that the size constraints of the devices limit
their storage capabilities and that their physical mobility affects
network connectivity. For the same set of reasons that wireless is
the predominant method of network connectivity for mobile
devices, batteries are the primary power source for mobile
devices. Batteries are improving every day and it is tough to find
environments where suitable AC power is not available. Yet, often
the user is constantly moving and devices are consuming more and
more power with processors that have more and more transistors
packed into them. The desirability of using batteries instead of an
AC power source combined with the size constraints creates yet
another constraint, namely a limited power supply. This constraint
must be balanced with the processing power, storage, and size
constraints; the battery is typically the largest single source of
weight in the mobile. The power supply has a direct or an indirect
effect on everything in a mobile device .
63
 Extra DIMENSIONS OF MOBILE COMPUTING
Varying User Interfaces: Stationary users use nonmobile
applications while working on a PC or a similar device. The
keyboard, mouse, and monitor have proved to be fairly efficient
user interfaces for such applications. This is not at all true for
mobile applications.
Platform Proliferation: Because mobile devices are small and there
is much less hardware in them than in a PC, they are typically less
costly to assemble for a manufacturer. This means that more
manufacturers can compete in producing these devices.
Active Transactions: Most of today’s stationary applications have a
restriction that can reduce the benefits of a mobile application
system enormously: The user of the system must initiate all
interactions with the system. We call such systems passive systems
because they are in a passive state, waiting for some external
signal from the user to tell them to start doing some particular
thing.
64
 ARCHITECTURE OF MOBILE SOFTWARE APPLICATIONS
The first step in building a software application, after the
process of gathering requirements, is to lay down a high-
level plan of what the application will be like when it is
finished. Mobile applications, like any other software
application, require such a high-level plan . We call this
high-level plan of the mobile application a “mobile
software architecture.” Our approach to architecture in
this text will be bottom up: we will introduce a variety of
design patterns, application architectures, and processes
with each addressing some specific problem with mobile
applications (next Figure).

65
66
 Mobile Operating Systems and Virtual Machines
Although Java tries to solve the proliferation problem by making the
code portable between different platforms, there are other plausible
approaches. One of these approaches is to create tools that make the
applications native to one platform. Microsoft’s .NET framework
deploys such a strategy. The tools provided by the .NET framework
allow the programmer to develop the application in a variety of
languages supported by the framework. The individual applications are
then compiled to code that can be executed on the same platform.
Microsoft’s creation of the .NET platform is spurred by economic
reasons, namely to keep Windows as the dominant computer
operating system. However, this does not imply that the tools provided
by the .NET framework are either superior or inferior. It is simply
a different technical approach whose merit should be judged by the
implementing developers and the users of applications that use this
platform.
67
 Hardware-Specific Tools and Frameworks
One way to deal with device proliferation is to avoid it!
Device manufacturers can allow the application
programmers to develop code that directly takes advantage
of the device features and functionality. The notion of an
operating system, in such case, is much different than what
we typically think of as an operating system. The services
offered by the operating system are few and very low level.
The downside here is a tight coupling to a platform that, in
turn, can translate to heavy reliance on the manufacturer of
that platform. This is the approach that Qualcomm offers in
its BREW platform. It is a physical layer communication
protocol that offers very efficient use of the bandwidth
available in a segment of the spectrum.
68
 JAVA
Today, it is widely accepted that Java as a programming language offers the most
portable commercial environment for writing software applications. The success
of Java has been mostly in providing standard Application Program Interfaces
(APIs), a very thoughtfully designed infrastructure for OOP that prohibits many
bad design and implementation habits such as multiple inheritance. Standard and open APIs
offer a process of evolving a language that is open to many vendors. Furthermore, there exist
implementations of the virtual machine and the native dependencies of the APIs for most
popular operating systems. There are three major categories of Java APIs and virtual
machines, namely J2ME, J2SE, and J2EE. Java offers three distinct features as a mobile
application platform:
1. Java is an object oriented programming language. As any other programming
language, it can be used to write applications.
2. Java offers complete code mobility and weak mobile agent ability. Java allows
for platform-independent programming.
3. Java is a platform.
First, Java, as with any other programming language, is just that: a programming language. It
allows us to program a set of instructions. Perhaps just as importantly Java is somewhat of a
vendor-neutral language-based platform.” Java seems to have solved the problem that has
plagued many other programming languages in the past: the lack of standardizing libraries.

69
 BREW
• BREW (Binary Run-time Environment for Wireless) gives
application developers a new and different approach in
producing mobile applications.
• BREW is built directly into the hardware. It is offered as
an API to access the CDMA, GSM/GPRS, or UMTS chip
sets that provide the support for it. But, it is primarily
intended for the variations of CDMA, a technology
owned and licensed by Qualcomm.
• BREW applications can be written on a PC using the
BREW Software Development Kit (SDK).
• Once the application is developed, it must be tested,
and then deployed. Deployment of BREW applications is
a process done jointly by Qualcomm and
telecommunications carriers and not just the developer.70
 set of applications of BREW
1.BREW MIF Editor: Every BREW module, defined as the classes that
make up one or more BREW applications, has an associated
Module Information File (MIF).
2. BREW Device Configurator: This is a stand-alone application that
allows developers to make up their own handset by configuring a
vanilla mobile phone and specifying the behavior of the keys, the
look and feel of the screen, and other specifics of the device.
3. BREW Emulator: For those who have designed and implemented
any mobile application, it is obvious that one of the most difficult
steps in the development process is the incremental unit testing.
4. BREW Image Authoring Tool: There is an image authoring tool
that allows creation of images for BREW. This tool can use PNG or
BMP files.
5. BREW ARM Compiler:Many mobile devices are based on the ARM
or Strong- ARM hardware platform (registered trademarks of ARM 71
 set of applications of BREW
6. Image Converter: The tool set provides an image converter to convert 4-bit
bitmaps to 2-bit bitmaps as BREW only supports 2-bit bitmaps because of the
limited resources on mobile devices
7. BREW Resource Editor: If you have worked with Java or C++ to build GUI
client-side applications, then you are familiar with the concept of a resource
bundle. Resource files in BREW are a collection of images, strings, and dialog
look-and-feel components that allow changing the look and feel of the application
for internationalization and similar purposes without changing the code
base. The BREW Resource Editor gives the developers a GUI interface to manage
the resource files.
8. BREW Pure Voice Converter: This command line utility allows the developers
to convert wave files (audio) to Pure Voice files or vice versa.
9. BREW AppLoader: This tool allows the developer to deploy an application on
a handset through a PC connector. This is a testing and not a deployment tool.
10. BREW Grinder: The Grinder generates a variety of inputs and tests the
application.
72
11. BREW TestSig Generator and AppSigner: The TestSig tool provides the developer
 WINDOWS CE
An operating system is the master control program that enables the
hardware by abstracting it to the application via drivers
[Development tools for Mobile and Embedded Applications 2002].
Microsoft’s various products revolve around different versions of an
operating system. The versions that concern us, the mobile
application developers, most are Windows CE and Embedded
Windows XP. Windows CE has been around since 1997 and
Embedded Windows XP is being released at the time of authoring this
text. These two operating systems are designed for two different
purposes. There are different flavors of the Windows CE operating
systems, of course, depending on the hardware platform. Some of
these flavors are the Pocket PC,Windows CE .NET, and Pocket PC
2002. These flavors largely depend on the commercial bundling of
different feature sets and hardware platforms with which they are
shipped (such as Compaq’s IPAQ). Embedded Windows XP, in
contrast, is a subset of the desktop version ofWindows XP
components. Development for EmbeddedWindows XP is a bit more 73
 Microsoft provides tools to build applications for each
environment too. These are as follows
1. Embedded Visual C++:This is a tool set separate from Visual
Studio, the typical development environment for PC-based Windows
applications. It allows for authoring mobile applications in C++.
2. Embedded Visual Embedded Visual Basic: This tool provides the
ability to write applications using
Visual Basic.
3. Smart Device Extensions for .NETSmart Device Extensions for .NET:
The .NET application programming platform, the newest set of tools
for building Microsoft Windows-based applications, can be
complemented with a set of extensions that allow developers to
author .NET applications for mobile devices.
4. Microsoft Mobile Internet Toolkit: This is really a server-side frame
workWe will discuss it along with the other publishing tools later in
this chapter.
74
 WAP
• Wireless Application Protocol (WAP) is the single framework most used
in building mobile applications today. Despite all of its initial high
promises, its lack of meeting those promises, and being written off for
dead, WAP seems to have survived the critics and continues to improve.
• WAP, which was initially intended to be as pervasive for wireless and
mobile applications as HTTP has been for the Web, never achieved the
level of success initially expected. However, to date, WAP has the
largest install base of all open application development platforms
(second to NTT Docomo’s closed and proprietary i-mode system) on
mobile phones, meaning that WAP is installed on more mobile phones
than any other software.
• WAP shares some similarities to HTTP. From its inception to now, it has
become more and more like HTTP. WAP 1.x and WAP 2.x are
significantly different with WAP 1.x being the basis for nearly all the
current installations in the market today and WAP 2.x being the target
platform for WAP devices during 2003 and 2004. Let us go over some
basics about WAP.
75
 WAP
1. WAP is intended for thin clients. Much like HTTP, the designers of WAP 1.x
were thinking about a thin-client technology: a case where nearly all logic is
calculated on the server and very simple display instructions are bundled in
some mark up language to be displayed by the client.
2. WAP is built on its own lower level communication protocol. Whereas
HTTP assumes the existence of TCP/IP (which in turn provides persistent
connections), WAP is built on its own set of communication protocols that
wrap around TCP, UDP, or a variety of other possible protocol
implementations.
3. Typical deployment of WAP includes a proxy or a gateway. Wireless
carriers (also referred to as bearer networks) like to have control of every
single incoming and outgoing bit of data that travels on their network. This is
understandable as usage time is the typical mechanism for billing.
4. WAP is a complete framework for mobile applications. Whereas most
tools created for development of applications treat a part of the mobile
application chain, WAP treats, or at least attempts to treat, all parts of the
mobile equation. 76
Chapter 3 chapter 5
 Chapter3.XML: The Document and
Metadata Format for
Mobile Computing
The Extensible Markup Language—XML—is a
subset of the Standard GeneralizeMarkup
Language (SGML) specified in ISO standard 8879.
SGML was created to create and maintain
complex and portable documents to be used in
highly scalable systems in a non proprietary
manner to any particular vendor. XML has
become a key technology in the development of
content for the World Wide Web. Today, with the
birth of Web services, it is used for more than its
original purpose of representing documents. 78
 XML and Mobile Applications
1. Mobile applications should understand and be able to manipulate
XML content. As content on the Internet, and other networks,
moves into an XML format, it is very desirable that a given mobile
application can handle XML. How the XML is handled is of
particular interest. Although the task of parsing and interpreting
the XML can be done on the mobile device itself, or some proxy
such as an application server that processes all content for the
device, issues such as performance become of paramount concern
2. Mobile applications use XML to facilitate their implementations.
For example, XML documents can be used by mobile applications
to exchange data; configuration of a device or a server may be
encapsulated in an XML file; some protocols such as WAP use
XML as the means for presentation. There are countless places
where mobile applications and related frameworks can use XML
internally.

79
 XML WEB SERVICES
Web Services are a prime example of an organic, as opposed to a
synthetic, evolution in technology. They exist because the HTTP protocol
is ubiquitous: Just about everyone today has access to the Web. Web
services build on the HTTP protocol methods, mostly GET and POST, to
build an RPC (Remote Procedure Call) that allows two systems to
exchange messages over HTTP. But, why not use CORBA, COM, JINI, or
other distributed computing protocols? XML based Web services are not
efficient: They convert binary to text to convert it back to binary again.
This is a weak point of XML based Web services when it comes to dealing
with mobile applications. However, there are work-arounds Web services
are a text-based MMI (Machine-to-Machine Interface). However, they are
simple to build and they take advantage of the ubiquity of the Web.
Protocols such as CORBA have failed in becoming ubiquitous. Other
protocols such as COM are proprietary to a platform. The platform of Web
services is the Web. Regardless of level of efficiency, those two aspects
alone create an economic reason for Web services to exist. Another
consideration that accompanies the use of Web services (typically HTTP
based though they can be based on other protocols such as SMTP) is
security.
80
Web Services and Mobile Applications
1. Web Service Proxy: The infrastructure of mobile applications
can use Web services for messaging. For example, a given
system may allow mobile users to find someone’s phone
number through a directory service and subsequently get the
driving directions to that person’s place of residence. These
two functions, finding the phone number and the driving
directions, may be fulfilled by two different systems, each
implemented in a different environment. So, the back end for
our mobile system may use Web services to connect to each
one of these systems and retrieve the information we need to
return it to us. The interface between the back-end system and
the device remains consistent and can be implemented through
whatever communication protocol may be necessary. This is
the more likely scenario for most systems.

81
Web Services and Mobile Applications
2. Direct Connection to Web Services:
Mobile devices with more resources can
directly access the network through the
use of Web services (see Figure 3.4). Of
course, this requires a considerably
advanced mobile device as we have to
have very efficient XML parsing as well as
the ability to write substantial applications
that implement the application of XML that
supports the particular Web service to
which the mobile device must connect to.

82
 KEY XML TECHNOLOGIES FOR MOBILE
COMPUTING
Some standard applications of XML have been
specifically designed with mobile applications in mind.
Standardization of such applications of XML is required
to provide interoperability between disparate systems. As
we mentioned previously, mobile applications should be
able to handle XML content. This may mean parsing the
content to take some actions based on the content,
transforming the content for various user interfaces, or
using XML as the metadata for handling various types of
content. There are a set of standards by W3C and
proprietary recommendations by various vendors that
apply for these cases. We will focus on standards
recommended by W3C as they are typically more
encompassing than proprietary recommendations.

83
 XML-Based User Interface Technologies for
Mobile Applications
As we previously mentioned, one of the first markup languages
to be pervasively used was HTML. Most of the Web documents
today exist in HTML. HTML is an application of SGML, but it is not
very clean. XHTML is an attempt at cleaning up the HTML syntax
and providing a version of HTML that is an application of XML.
XHTML will replace HTML past version 4.01 and it is an approved
W3C standard. One of the biggest problems that HTML presented
was that it was not designed to be used by a wide variety of user
interface types. HTML was designed with minimum requirements
of a color screen of 640 × 480 pixels and the PC in mind. Though
some considerations were made for screens that did not display
graphics, not much else was available to the developer. Also,
HTML was not strict enough in enforcing syntax. So,
programmatic changes to HTML to make it fit various devices
was not possible without making assumptions (which in turn
create bugs).

84
 Chapt.5 Generic User Interface Development
such as issues related to human factors are not well defined. In
this text, we will use terminologies outlined by ECMA (European
Computer Manufacturer Association), W3C (World Wide Web
Consortium), or similar non-commercial standards bodies. It is
also important to note that user interface development for
mobile applications is a new field; therefore, there will be
occasions when these bodies have not decided on a standard
way of addressing these problems. In such cases, we will build
some logical vocabulary as built on top of the existing standards
and as decided by the author of this book. The first step in
moving forward is to ask ourselves, “Why do we want to build
generic user interfaces?” First, mobile applications are typically
used by a wider array of operating environments and systems
than a PC. Because there is such a wide array of end clients for
mobile applications, we need to be able to adapt the
application quickly, if not in real time, with very little or no
additional development effort.
85
 User Interface Development
A software application is started by a person, another
software application, a hardware application, or a
combination thereof. A demon program may invoke a
server application at a particular time; this is an
example of a software application being invoked by
another software application. The operating system
itself is an application that may be started by a
hardware/software driven application, turning the
computer on, providing power to the CPU, and allowing
the initialization software permanently stored on the
hardware to invoke an operating system. Excluding
artificially intelligent systems, all software applications,
at some point and perhaps through a long line of
succession, are either started or scheduled to start by a
person—a user. 86
 Human Factors

Dix et al. define human factors, often referred to as

ergonomics, as the study of
the physical characteristics of the interaction: how the
controls are designed, the physical environment in which
the interaction takes place, and the layout and physical
qualities of the screen [Dix et al. 1998].
For any typical application, we need to consider the
following as the elements of human factors consideration:
1. the look and feel of the application and how the users
“like” the user interface,
2. the ease of learning the interface well and becoming
efficient at using the user
interface, and
3. health issues in using the user interface.
87
Usability, Human Factors, and Other Considerations for Developing Stationary PC-Based User Interfaces

list some issues that the software engineering industry,

as a whole, deems to be important
1. Intuitiveness: User interfaces should be intuitive.
User interfaces should be intuitive. The first time a
user uses an application, he or she should be able to
navigate his or her way through without too much
trouble, assuming a reasonable amount of
familiarity with the application domain.
2. Consistency: Consistency: A software application
should present user interface components that are
consistent with each other and consistent with their
operating environments.
88
Usability, Human Factors, and Other Considerations for Developing Stationary PC-Based User Interfaces

3. Learnablility: The user should be able to

learn how to use the user interface within the
first few times of using it and remember how
to use it without having to refer to manuals.
This goes hand in hand with the user interface
being intuitive.
4. Nonintrusively Helpful: The user interface
and the underlying application should provide
help and hints. There can never be too much in
the way of help and hints on a user interface.
89
Usability, Human Factors, and Other Considerations for Developing Stationary PC-Based User Interfaces

5. Accommodating Expert Users: A good user

interface provides shortcuts for the expert users.
Applications should be efficient and fast to use for
expert users. As a user learns how to use the system
better, he or she should be able to access the
information and perform the tasks faster and faster.
6. Trustable: The user interface should be predictable,
trustable, and easily understood. There should be a
simple set of rules that are used in building the user
interface that allow the user to be able to guess what
the reaction of the user interface may be.
90
Usability, Human Factors, and Other Considerations for Developing Stationary PC-Based User Interfaces

7. Robustness [Dix et al. 1998]: A good user

interface should gracefully recover from user
errors (e.g., display the proper dialogue boxes
to guide the user when an error happens),
should convey the relation to the application
logic easily to the user (e.g., make sure that
the user knows which data are changing,
when transactions are committed, etc.), and
should be fast enough and let the user know
when there are long waits for responses.
91
 Example 5.1: User Interface Consistency Guidelines for a Mortgage Banking Application.

A) Guidelines by Domain:
a. Color: Use white, black, scales of gray, and scales of blue only. These are the
branding colors associated with ACME Mortgage corporation.
b. VUI Prompts: All prompts relating to gathering information for the financial
portions of the loan application should be recorded by a female voice talent. All
prompts relating to gathering information for the personal sections of the loan
applications should be recorded by a young male voice talent.
B) Guidelines by User Interface Components:
a. Color: Use blue for all of the buttons. Use white for all of the backgrounds. Use
black for all of the fonts. Use scales of gray for all other interface components.
b. VUI prompts: All informative prompts must be recorded by a female voice talent.
All warnings must be recorded by a male voice talent. When the user does not
understand one prompt pronounced by a given voice artist twice, the voice talent
should be dynamically changed to allow the user to understand the voice of
another voice talent.

92