Ubiquitous Enterprise Service Adaptations Based on Contextual User Behavior

Dan HongDepartment of Computer Science and Engineering, Hong Kong University of Science and Technology

csdhong@cs.ust.hk

Dickson K.W. ChiuDickson Computer Systems, 7A Victory Avenue, Kowloon, Hong Kong

(Contact author) email: dicksonchiu@ieee.org phone: +852 93572611 fax:+852 2712 6466

Vincent Y. Shen, S. C. CheungDepartment of Computer Science and Engineering, Hong Kong University of Science and Technology

{shen, scc}@cs.ust.hk

Eleanna KafezaDepartment of Marketing & Communications, Athens University of Economics & Business, Greece

kafeza@aueb.gr

A preliminary and short version of this paper appears in the Tenth IEEE International EDOC conference (EDOC 2006). The work was partially supported by a grant from the Research Grants Council of Hong Kong (Project No. HKUST6167/04E)

1

ABSTRACT

Recent advances in mobile technologies and infrastructures have created the demands for ubiquitous access to

enterprise services from mobile handheld devices. Further, with the invention of new interaction devices, the

context in which the services are being used becomes an integral part of the activity carried out with the system.

Traditional human-computer interface (HCI) theories are now inadequate for developing these context-aware

applications, as we believe that the notion of context should be extended to different categories: computing

contexts, user contexts, and physical contexts for ubiquitous computing. This demands a new paradigm for

system requirements elicitation and design in order to make good use of such extended context information

captured from mobile user behavior. Instead of redesigning or adapting existing enterprise services in an ad-hoc

manner, we introduce a methodology for the elicitation of context-aware adaptation requirements and the

matching of context-awareness features to the target context by capability matching. For the implementation of

such adaptations, we propose the use of three tiers of views: user interface views, data views, and process views.

This approach centers on a novel notion of process views to ubiquitous service adaptation, where mobile users

may execute a more concise version or modified procedures of the original process according to their behavior

under different contexts. The process view also serves as the key mechanism for integrating user interface views

and data views. Based on this model, we analyze the design and implementation issues of some common

ubiquitous access situations and show how to adapt them systematically into a context-aware application by

considering the requirements of a ubiquitous tourist information system.

Keywords

Context-aware application, context, process views, three-tier architecture, design issues, ubiquitous information

system, enterprise workforce management, HCI

2

1. IntroductionThe advancement and widespread use of mobile technologies has createdresulted in an increasing demand for the

extension of enterprise services to anytime and anywhere access. Although the computing power and bandwidth

of these mobile devices are improving, their capabilities are still significantly inferior to desktop computers over

the wired Internet. As most existing e-services are not designed to support users on mobile platforms, they have

to be adapted to accommodate these limitations.

With the widespread use of mobile devices and the need for ubiquitous computing, the issue of “context” now

becomes a hot topic in human computer interaction (HCI) research and development. There are several reasons

why context is important (Weiser, 1991). First, context reduces the input cost. Explicit input from users is

expensive. It interrupts the user’s thoughts and slows down the speed of the interaction. ABy analyzing users’

behavior, such as sensing the environment and interpreting explicit actions through mobile devices, could provide

a rich and implicit context. Context makes the communication between humans and computing devices much

more efficient. Second, context may provide an exciting user experience without much effort on the users’ part.

With the help of context, interactive services such as tourist guide support, message reminder service, and smart

home (such as those discussed in Section 2) are accessories that can make people’s lives easier. Third, users

benefit from context sharing. We may assume that users and their friends have similar preferences, which means

something that attracts one group member’s attention has a higher probability of being preferred by other

members. By sharing the context, the system could provide a better service. Therefore, this motivates us to

introduce the context concept in ubiquitous service adaptation. A detailed explanation of contexts will be given in

Section 2.

However, moving the interaction beyond the desktop presents many exciting and new challenges to HCI. First,

the interface is moving from humans vs. computers to humans vs. context-aware environments. With the

popularity of multimodal interactions, more varieties of input and output devices are now being used. A user may

have multiple devices, while a device may be shared by different people. Resolving the possibly conflicting input

of different cooperating devices becomes more crucial than before in the design process. Second, “knowledge in

the world” becomes more important (Dix et al., 2004). The goal of HCI design is creating a convenient user

experience. To better predict a user’s behavior, it is important to understand the subtleties of everyday activities.

Third, ubiquitous activities are not so task-centric while the majority of usability techniques are. It is not at all

clear how to apply task-centric techniques to informal everyday computing situations (Abowd & Mynatt, 2000).

To address these requirements of ubiquitous enterprise computing, we extend the notion of context, the

constantly changing environment, into three categories (Chen & Kotz, 2000; Schilit, Adams, & Want, 1994)

instead of the narrow perspective that just focuses on locations. Computing context refers to the hardware

3

configuration used, such as the processors available for a task, the devices accessible for user input and display,

and the bandwidth. User context represents all the human factors, such as the user’s profile, calendars, and

profiles. Physical context refers to the non-computing-related information provided by a real-world environment,

such as location, time, lighting, noise levels, traffic conditions, and temperature. The three categories are equally

crucial and they, as a whole, determine the appropriate and customized interaction between the user and the

service. Therefore, we propose to use this notion of extended context as a basis of the requirement elicitation for

ubiquitous service adaptations (Hong, Chiu, & Shen, 2005).

As for the implementation of these context-based adaptations, we consider the fact that most existing enterprise

services are developed with a three-tier architecture. Motivated by Chiu et al. (2003), we associate these context-

based adaptations through different views at all the three tiers, namely, user-interface views at the front-end tier,

process views at the application tier, and data views at the back end database tier. These views adapt services to

match the corresponding to the requirements of heterogeneous platforms under different contexts. We

demonstrate the applicability of our approach with a detailed case study of adapting a mobile workforce support

system (Chiu, Cheung, & Leung, 2005) of a telecommunication service enterprise into a context-aware

application, instead of a brief one on e-Government (Chiu et al., 2007).

The contribution of this paper are as follows: (i) propose a conceptual model and methodology for adapting

existing enterprise services into ubiquitous ones with context; (ii) explain how an extended notion of context help

requirement elicitation of such adaptations; (iii) propose the implementation of context-based adaptation with the

mechanism of three-tier views; (iv) demonstrate the applicability of our approach with a case study of a mobile

workforce support system. In the rest of this paper, section 2 reviews background and related work. Section 3

introduces our methodology and the conceptual model of our approach. Section 4 discusses some typical context-

aware requirements and design issues with reference to our model. Section 5 highlights how the adaptation

features are implemented with a three-tier view approach. Section 6 discusses the advantage of our approach

before concluding the paper in Section 7 with some directions of future research.

2. Background and Related WorkWeiser (1991) first proposed the idea of ubiquitous computing: specialized elements of hardware and software,

connected by wires, radio waves, and infrared, would become so ubiquitous that no one would notice their

presence. Different from virtual reality, ubiquitous computing techniques bring computing devices into everyday

life. This ubiquitous environment provides an opportunity, which permits human-computer interactions away

from any workstations. That is, the user may interact with multiple devices such as cell phones, Personal Digital

Assistants (PDAs), touch-sensitive screens, and notebook computers within a session which may be operating in

4

different environments. With the widespread use of mobile devices and the need for ubiquitous computing, the

issue of “context” now becomes a hot topic in human computer interaction (HCI) research and development.

What is context? By the definition of the Oxford Dictionary, context is a circumstance in which something

happens or in which something needs to be considered. Many researchers are not satisfied with such a general

definition so they have tried to come up with a more accurate one. Schilit, Adams, & Want (1994) claimed that

the three important aspects of context are: where you are, who you are with, and what resources are nearby. Chen

& Kotz (2000) redefine context as the set of environmental states and settings that either determines an

application’s behavior or in which an application event occurs and is interesting to the user. Moreover, Dey et al.

(2001) define it as any information that can be used to characterize the situation of entities (i.e., whether a person,

place, or object) that are considered relevant to the interaction between a user and an application, including the

user and the application themselves. Contexts are typically locations, identities and states of people, groups, and

computational and physical objects.

A system is context-aware if it can extract, interpret, and use context information and adapt its functionality to

the current context of use (Korkea-aho, 2000). The challenge for such a system lies in the complexity of

capturing, accessing, and processing contextual data. To capture context information some additional sensors

and/or programs are generally required. Context can be acquired several ways. Location information, which is the

most popular user context, is easily obtained by sensors (e.g., the Global Positioning System (GPS) in an outdoor

environment). Moreover, sensors could detectsense the temperature, humidity, sound, or even movement in both

outdoor and indoor environments. Portable mobile devices such as cell phones, PDAs, and notebooks also

provide context by collecting and interpreting user’s interaction responses. Abundant context could propagate

through wireless cellular networks, wireless LAN networks, wireless Personal Area Networks (PAN), wireless

Body Area Networks (BAN), and wired networks (Chen & Kotz, 2000). Sensing techniques and wireless network

technology together bring context-aware computing into our everyday livesfe. Context is not only used in an

application, but is also shared among different applications. In order forthat context information to beis accessible

among different applications, the context needs to be represented in a common format and properly categorized

(Ciavarella & Paternò, 2004). In addition to being able to obtain context-information, applications need to have

some “intelligent” component which functions as a predictor of a user’s intentions. Developers can intelligently

use context information in four primary ways (Shafer, Brumitt, & Cadiz, 2001): 1) resolving references, 2)

tailoring lists of options, 3) triggering automatic behaviors, and 4) tagging information for later retrieval. Thus,

our extended notion of context serves as a legitimate basis of the requirements elicitation for ubiquitous

applications.

There are many context-aware applications available for mobile devices with features like proximate selection,

automatic contextual reconfiguration, contextual information and commands, and context-triggered actions

5

(Schilit, Adams, & Want, 1994). Such applications usually present information to a user, automatically execute a

service for the user, and tag the context to information to support later retrieval (Dey & Abowd, 1999). However,

most of these applications are concerned mainly with physical contexts. Here are some examples.

One of the application areas with the most context-aware software are tourist information systems. Cyberguide is

a mobile context-aware tour guide system for visitors in a tour of the Graphics, Visualization and Usability

(GVU) Center Laboratory during open hours (Abowd et al., 1997). It moves all the information into a hand-held,

location-aware unit. By using context information such as location, the direction of movement, and the user’s

previous locations, the system could suggest some places of interest according to the user’s preference. The long-

term goal is not only to know location information but also what the user is looking at. With this context the

system can predict and answer questions, and provide the ability to interact with other people in the vicinity and

the environment. The GUIDE system (Cheverst et al., 2000) integrates the use of personal computing

technologies, wireless communications, context-awareness, and adaptive hypermedia to support the information

and navigation needs of visitors to the city of Lancaster. The context such as the visitor’s interests, current

location, and any refreshment preferences may affect the interface of the system. The Mobile Location-Aware

Handheld Event is an event planner (Fithian et al., 2003) that provides a tourist guide service based on GPS

location acquisition. Users may also use this system to send or receive emails. The system also allows the user to

set up event reminders. Moreover, the system takes the privacy issue into account. A user could set the visibility

based on the persons or groups, which could help to control who can see whom. AccesSights is a multimodal user

interface to support different user groups (Klante, Krösche, & Boll, 2004). Its main objective is to support both

blind users and sighted users at the same time with the same tourist content but for each user group in their

preferred modality. Not only providing suggestions during the tour, tThe system not only provides suggestions

during the tour, it also warns by vocal output when some obstacles are in the way, which especially benefits blind

visitors.

As for office and meeting tools, the Active Badge Location System (Want et al., 1992) by Olivetti Research

Laboratory in the 1990’s is the first context-aware application. System users wear badges that transmit signals

providing information about their locations to a centralized location service through a network of sensors. The

purpose of the system is to provide a human receptionist with useful information in order to direct calls to the

nearest phone. Later experiments have been conducted for automatic phone call forwarding. The PARCTAB

System (Want et al., 1995) integrates a palm-sized mobile computer into an office network. The context used in

this system is location, the presence of other mobile devices, the inferred presence of people, time, nearby non-

mobile machines, and even the state of the network file system. The communicator, calendar manager, and

locator system work together to provide a more convenient information access and communication device based

on location information. Moreover, the system enhances collaboration by supporting group annotations and

6

voting. Conference Assistant (Dey, Abowd, & Salber, 2001) assists conference attendees by automatically

displaying the conference schedule and showing multiple tracks, which may help the attendees find their own

tracks of interest. The system directs the attendee to the room, where the track of interest is being held. When the

user enters the room, the system not only shows the name and title of the presentation but also offers help on

recording the presentation. Conference Assistant allows users to create notes of their own to attach to a certain

slide or Web page. After the conference, users could use a retrieval application, running on a desktop computer,

to retrieve the information about a particular presentation and share it among colleagues. Office Assistant is an

agent that interacts with visitors at the office door and manages the office owner’s schedule (Yan & Selker,

2000). Based on information such as the owner’s working status and available time slots, whether there is a

visitor arriving or leaving, and the interaction history, the system could assist users in changing their interaction

behaviors. Examples are interactions with other visitors, advising them on their appointments, and updating

calendar entries to reflect recent appointments.

As for message reminders, ComMotion is a location-aware computing environment, which links personal

information to locations in its user’s life (Marmasse & Schmandt, 2000). Once a reminder message’s attributes,

such as the time and location, match a delivery condition, it is sent out. The application is quite suitable when

users are driving since the system provides a speech interface and uses GPS as an outdoor sensing tool.

CybreMinder is a context-aware prototype implemented by the Georgia Institute of Technology. It supports users

in sending and receiving reminders involving rich context, such as time, place, and working status (Dey &

Abowd, 2000). The reminder could be delivered via Short Message Service (SMS) on a cell phone, email, or a

nearby display screen.

For smart-home applications, Easy Living (Brumitt et al., 2000; Shafer et al., 1998) is an intelligent system

environment of Microsoft Research. It focuses on applications that can make computers easier to use and able to

perform more tasks than traditional desktop computers. The system has information about the state of the world,

such as locations of people, places, things, and other devices in space. The context, which could be interpreted by

the system, helps users directly access all available devices, control some devices remotely, and control media

players according to user preference. eHome or the Smart Home Usability and Living Experience project

(Koskela & Väänänen-Vainio-Mattila, 2004; Koskela, Väänänen-Vainio-Mattila, & Lehti, 2004) was carried out

from May 2002 to March 2003 at the Institute of Software Systems at the Tampere University of Technology ,

Finland. The system supports users in controlling everyday “smart objects” such as moving curtains and status-

aware pot plants through three user-interface devices: a personal computer, a media terminal (i.e., the television),

and a mobile phone. In the system, the personal computer acts as the central control unit. A mobile phone is a

suitable remote controller when users are away from home.

7

Context-aware applications are not limited to research prototypes. There are already some commercial products in

the market. Up to eight profiles have been designed for users to select and adapt to different environments in the

Sony Ericsson K700i mobile phone: normal, meeting, in car, outdoors, portable, hands-free, home, office, and

terminal accessory. Microsoft Direct Watch (2004) is a new, specialized wireless service that delivers

personalized information through watches that combine style and technology. Services include news, weather,

stock quotes, appointment reminders, and personal messages. However, both of these two applications require

users to set them up manually since there is no other equipment (i.e., sensors) that will cooperate with them to

provide context. Though these techniques are not mature currently, it reveals that the context-aware world is

coming.

In order to facilitate the implementation of context-aware software, the Context Toolkit developed by the Georgia

Institute of Technology infers the pieces of context automatically from sensors in a physical environment (Dey,

Abowd, & Salber, 2001). It separates the acquisition and representation of context from the delivery and response

to context by a context-aware application. It aims at the rapid prototyping of a rich space of context-aware

applications. However, one of the disadvantages is that the relationship between a widget and a sensor is one-to-

one mapping; that is, it cannot support sensors to work together in order to get a data item. Furthermore, one

application could not reuse the code of another application due to its way of handling the context interpretation

and aggregation. Burrell et al. (2000) summarize some previous context-aware applications systems and propose

the Semaphore, a context aware collaborate tool used in wireless networked environments at campus. Lei et al.

(2002) provide a middleware infrastructure for the design of context-aware applications and try to address the

extensibility and privacy issues at the same time. Baradram (2004) presents the design of a context-aware pill

container and a context-aware hospital bed, both of which react and adapt according to the context in its special

domain, a hospital. Kim et al. (2004) categorize context-awareness into only non-computational contextual

design, non-computational context-aware design, and computational context-aware design. Based on these

categories, they analyze how to design context-sensitive appliances.

However, all these designers have not explicitly provided a methodology for the requirements elicitation for the

design of context-aware applications in a ubiquitous environment based on our extended notion of context.

3. Methodology Overview and Conceptual ModelAs the knowledge from traditional HCI research is inadequate to capture user behavior for ubiquitous enterprise

service adaptation, we address this problem with context as the central artifact by attempting to answer the

following research questions by studying a case of adapting a mobile workforce support system (Chiu, Cheung,

& Leung, 2005) of a telecommunication service enterprise:

8

1. Can context help capture user behavior to address their requirements in a ubiquitous computing

environment? In particular:

a) Are the above-mentioned different categories of context useful for such purpose?

b) What are the typical considerations under such context categories for ubiquitous application

adaptations?

2. How can implementations of context-aware enterprise service adaptations be facilitated under current typical

software development and deployment environment?

Fig. 1 Three-Tier system architecture for the realization of three tier views in context-sensitive enterprise service adaptations

To address the first research question, we have to consider the two ultimate goals of Interaction Design (Preece,

Rogers, & Sharp, 2002). One is the usability goal. An interactive system needs to provide effective and efficient

services as well as making it easy for the user to learn how to use the system and to remember how to use it.

Another is user experience goals. In order to attract people to use interactive products, they must be designed to

be fun, enjoyable, pleasurable, and aesthetically pleasing to use. The services provided by the context-aware

applications need to satisfy users’ goals. So understanding the users’ expectations becomes crucial in the design

process. In order for the system interactions to match the users’ common usage, the behaviors of users have to be

studied too. The relationship between the environment and users and that among users themselves could be

considered as context. The obvious elements for ubiquitous computing are the computing facilities, the human

9

user, and the environment. This is the main reason we extend the notion of context to three main context

categories: computing contexts, user contexts, and physical contexts. We detail our analysis in Section 4.

To address the second research question, we note that Internet applications are generally developed with a three-

tier architecture comprising front ends, application servers, and back end databases. Each of these tiers hosts a set

of views as shown in Fig. 1, which also depicts our system architecture. Views help balance trust and security,

that is, only information necessary for the process enactment, enforcement, and monitoring of the service is made

available to the concerned user, in a fully controlcontrollable and understandable manner. At the front-end tier,

user interface views provide mobile users with alternative presentations and interfaces to interact with the process

views hosted at the application servers tier. At the logical tier, a process view is a projection of an e-service

process that adapts to a user’s behavior under certain contexts in a ubiquitous computing environment. Process

views are synchronized and enacted by application servers. At the backend, a data view consists of multiple

tables that collectively represent a projection of data that are required in the enactment of an e-service, according

to the user‘s ubiquitous contextual requirements. We detail our approach in Section 5.

To illustrate the fundamental concepts of our approach, Fig. 2 presents a conceptual model of capturing

contextual behavior for ubiquitous e-service adaptation, based on the implementation with the three-tier views.

User interface, process, and data views are associated with many-to-many relations. In other words, a user

interface view may provide the interface to multiple process views, each of which may in turn supports multiple

user interface views. We choose process views as the central mechanism to associate users in different contexts to

process views for service enactment as explained in the subsequent sections. However, it should be noted that the

three categories of contexts and the three views are orthogonal, as explained in later sections.

The scenario of extending and adapting an existing web-based application to support mobile users is usually more

typical than designing a context-aware service from scratch. In addition, the following discussion is also

applicable to phased enterprise projects, in which usually standard web-based application are developed as the

first phase, and supporting mobile users as subsequent phases. We propose the service adaptation process to be

carried out in the following major steps:

1. Determine the different target groups of users that the service is focusing on.

2. Identify the different types of the actions required for the service

3. For each action, observe different types of typical user behavior in carrying out the action.

4. For each type of user behavior, identify under what contexts they usually happen.

5. For each type of user behavior, enlist the requirements specific to the context.

6. Enlist the relevant features supported under different context. Pay attention to how different contextual

behavior may impact on its interactions and therefore determine the required context-aware features to adapt to

such contexts.

10

7. For each context-aware feature, detail the desired context-aware capabilities.

8. Make sure that the context-aware capabilities match and satisfy all the requirements elicited from step 5.

Otherwise, it would mean that some required context-aware features are missing and we should re-iterate from

step 6 to handle those unaddressed requirements.

9. Design process views that capture typical sets of context-aware features for adaptation.

10. Design data views for each of the data sources based on the requirements of the process views and

context-aware capabilities.

11. Design user interface views based on platform dependent restrictions.

12. Perform validation of view consistency.

Fig. 2 A conceptual model for context-aware enterprise service adaptation

By adopting this approach, our conceptual model further provides a basis for the system to select the required

context-aware features at run-time according to the user’s contextual behavior, so that the system uses the same

criteria (matching of context requirements with context capabilities) to provide the most appropriate service

adaptations.

4. Typical Context-aware Requirements and Adaptation Considerations Based on the methodology presented in the previous section, we proceed to analyze some typical context-aware

requirements and some adaptation considerations under the three main context categories: computing contexts,

user contexts, and physical contexts by considering the requirements of a ubiquitous tourist application. Table 1

classifies some typical contexts relevant to ubiquitous computing into these three context categories.

User Interface View

User Context

Physical Context

Computing Context

Context Requirement

Context-aware Capability

match

useData View

use

Process View

User

Action

Behavior

exhibit

Contextsituated at

Ubiquitous Service

interact with

Context-aware Feature

adapt to

implement

+Adaptation

11

Computing Contexts User Contexts Physical Contexts

Available devices

CPU

Memory

Screen size

Energy

Bandwidth

Preference

Purpose

User calendar

Personal information

Facilities

Disability

Location

Time

Destination

Traffic condition

Physical limitations

Weather

Table 1 Classification of Some Typical Contexts into Categories

4.1 Computing ContextsIn order to design a good interactive application, we must understand the characteristics of the new computing

environment. This involves a lot of new input and output devices that may lead to new interactive styles.

One important feature of context-aware applications is that users may use many mobile devices at the same time.

Which devices should be used in the interaction becomes very important. Users prefer a device with multiple

functions. The system needs to be integrated into the existing equipment (i.e., mobile phones or PDAs) and a

heavy device is not acceptable (Sumi et al., 1998). In this sense, tourist guide should run easily on any device that

is available to a user. Further, one significant difference to the traditional HCI is that multiple devices may be

available to a user in a specific situation in ubiquitous computing. Gesture recognition devices, handwriting

devices, and embedded cameras together provide more opportunities for users to interact with the environment

than with each of them alone. Handwriting devices, voice recognition devices, and GPS systems enable users

(especially disabled and elderly people) to input their location parameter in a convenient way in different

situations. Moreover, with the help of eye-tracking devices, such systems could benefit those with disabilities

since they help automatically choose a target device from a device set.

Another difference between a context-aware environment and a desktop-based scenario is the dynamic nature of

the available devices supporting the user’s interactions (Shafer et al., 2001). In particular, the devices of mobile

workforces are often moving dynamically, especially where there are wireless connections among the devices.

How to efficiently send the changing context back to the application has attracted a lot of researchers’ attention.

Much work has been done in ad-hoc networks and sensor networks. The dynamics of devices challenges the

routing of information. Furthermore, the dynamic changes to the devices should be transparent to the users. They

should not be asked to manually change the selection of devices.

In a desktop scenario, it is reasonable to assume that a user sees every message displayed on the screen or hears a

notification played through the speakers since the user is focusing on the computer. In the working environment

12

of mobile workforces, there may not be a focal point for a user to fully concentrate on (Shafer et al. 1998). It is

common for a user to miss a phone call in a noisy environment since the ring tone is not loud enough to be heard.

Moreover, users may no longer be static in an environment. It is also important that users maintain continuous

interactions without noticing the changes in the device.

Mobile devices have a limited computing (CPU) power. Even the most advanced PDA could not compete with

common desktop computers. The limited CPU power challenges the application installed on mobile devices. For

example, the CPU of a mobile device not only has to compute the user’s location information, but also to render

a map. Therefore, most of the computation is preferred to be done at the server side. Memory is another important

computing context during the interaction, since it is used to store the user profile and the context-ware

applications as well as to provisionally keep some application data. In a mobile workforce support system,

memory is very important and this will directly affect how big a map the device can maintain on the client side.

In traditional interactions, who is currently using the system is usually not an issue because there is often only

one user or the identity can be easily found from the login information. In a context-aware environment, it is

often possible that many users are interacting with different devices concurrently on either independent or

cooperative tasks. Each user may have multiple devices interacting and each device may be shared by multiple

users. Detailed information provided by the system may not satisfy a user’s needs (Kaasinen, 2003). The database

must maintain enough detailed information to suit the needs of diverse users. For example, in a route-finding sub-

system, the database might contain all small paths in the city and provide customized maps to users according to

their individual contexts. Moreover, it would be helpful if the sub-system could work with other databases (such

as a client location database) in order to provide other extended services.

Monitors and big screens are no longer the only display devices available. The screens on mobile phones or

PDAs are more convenient when a user moves around. However, the screens on mobile devices are usually much

smaller. Avoiding too much scrolling requirements of the mobile user interface would require careful design.

A main feature of mobile devices that concerns most users is the duration of battery power. No one wants to buy

a mobile phone which can only be used for a short while. Context-aware applications suffer the same problem. It

is important for mobile device users to select a reasonable protocol to communicate with the service providers in

order to save energy. Moreover, in the design process, developers might take the energy savings during system

idle times into consideration because to displaying a map on a colorful screen is very battery power consumes a

great deal of battery power.ing.

In a ubiquitous environment, devices communicate by wireless LAN, Bluetooth, or infra-red. The bandwidth is

limited compared with the wired networks. Therefore, to develop a context-aware application, we should not

13

assume a broad bandwidth for every user. When updating the map ion the screen of a user’s mobile device, we

also need to consider the network delay and bandwidth limitation.

4.2 User ContextsUsers usually have their own preferences that determine their choices (Shneiderman and Plainsant, 2005). For

example, some users might be interested in driving themselves, while others prefer taking a train. It is very useful

for applications to make use of such preference information. Further, if the system knows the user’s purpose of an

activity, wrong recommendations or interactions can be avoided. For example, if the user’s purpose for a trip is to

meet a tight scheduled time in a busy city center, recommending a subway is probably more appropriate as

compared with driving.

In some scenarios, the system goes beyond the users’ needs. For example, in a museum, users may prefer to

browse without a mental plan. A system that guides the visitor along a predefined route is not expected

(Kaasinen, 2003). The guide system should work as an assistant instead of a master. Users do not appreciate

being given commands for where to go next. Similarly, professional staff working on ad hoc problems with

clients should not be over-guided by the support system.

Context-aware applications may collect some personal data to deduce the interaction between the user and

ubiquitous environment. The system may want to know a user’s previous travel and duty history or other

demographic data to make better recommendations. A list of the user’s colleagues and clients enables the portal

to give them interesting surprises by arranging for them to meet at some spots and thus help relationship

management. However, how to protect privacy information becomes an important design issue for future

research.

In addition, mobile devices are not the only facilities that a user has: other facilities might also play a role in the

system’s response. For example, when the system recommends a path from source to destination, it needs to

consider if the user has an umbrella when it rains outside and should avoid as much as possible an uncovered

path across the rainy area. Due to similar considerations, the system should have special concerns for the

disabled. For example, a path without stair steps and a lift with a disability assistant button should be chosen for

those in wheelchairs.

4.3 Physical ContextsPhysical contexts refer to non-computing-related information provided by a real-world environment. These are

best explored by other existing ubiquitous applications and therefore we try to keep the discussion brief in this

paper. Among them, the user’s current location is the most important context, especially for mobile workforces.

Not only is this information critical to most interactions, it is also the key to many other system functions,

14

decisions, and recommendations. Further, the user’s destination (i.e., the location where the user wants to go)

together with the current location are the major determinant to the route of the user. In determining a route, traffic

conditions such as information about traffic jams and road repair projects help users to avoid these problematic

locations. Further, weather (sunny, cloudy, or rainy) and temperature impact on the recommendation of some

activities such as outdoor work.

In general, users need topical information (Kaasinen, 2003). When users are traveling, context-sensitive

information such as weather reports, transportation information, and local news may become invalid and need to

be updated in a timely fashion. For example, when a driver navigates across a country border, such information

should be updated in his portable device.

5. Three-tier View-based Implementation of Context-based AdaptationsIn this section, we first present a scenario of a next-generation mobile workforce support system, in which the

appointment service is a simple but key service for many interactive and collaborative enterprise information

systems. We illustrate how the requirements for context-aware service adaptations can be elicited based on our

proposed methodology (see Section 3). Then, we discuss the implementation such adaptations with views in a

three-tier architecture. In the next section, we discuss the applicability of our methodology introduced in this

paper together with some open issues.

5.1 Requirements ElicitationLet us consider a scenario in a next-generation mobile workforce support system. Imagine a normal day in 2010.

Alice is on a business trip. She wakes up at 7:00am and orders breakfast room service through a voice recognition

device in a hotel room. While waiting and watching the television, the screen reminds her to take an umbrella and

close all the windows as there will be a rainstorm. Without her login action, a high-resolution television screen

automatically pops up Alice’s trip schedule of the day from her PDA phone as her voice has already been

recognized. The only meeting in the morning has just been cancelled, but the schedule is too tight in the

afternoon. So, Alice wants to reschedule asome meeting that she has with Bob in the afternoon to the morning.

Alice enters such preferences through her PDA phone. So, Alice’s personal support system (PSS) interacts with

those of the people to be metBob’s PSS and seeto see if any rescheduling is possible. After some automatic

negotiation among the PSSs, the meeting with Bob is rescheduled at 11:00am, but it is now still too early. So,

Alice goes to a restaurant to havetake her breakfast and read some documents in the meantime. At 10:30am,

Bob’s PSS sends an SMS message to reconfirm his meeting with Alice about Bob’s meeting at his office.

Unfortunately, Alice loses her way and it is raining heavily. Her PSS provides directions based on her current

location and her schedule, which has the destination. Even with such help, she is likely to be late. So, Alice’s

PSS sends an urgent SMS message to request a delay of the meeting for an estimated 15 minutes. Indeed, Alice

15

arrives at Bob’s office 11:15am. The PDA phone automatically turns on the “vibration” mode during the

meeting. As the business meeting has progresses, so they plan to meet again within while Alice’s stay is still inn

the city. When Alice inserts a new appointment item into her PSS, all the schedules on her other devices

(especially the server for backing up her schedule) are synchronized via wireless networks. The PDA phone turns

off the vibration mode after the meeting. After the long meeting, Alice takes a break in the shopping mall. In the

mall, the PDA phone rings loudly to give her an exciting message that another colleague Cindy, whom Alice has

not seen for a long time, is also nearby. Alice is very excited to see Cindy. Based on the favorite food

information on Alice’s and Cindy’s PSSs, a suitable restaurant nearby is recommended. Alice happily invites

Cindy to dinner.

Let us concentrate on the appointment service of the PSSs, which is a very commonly used one in even a current

real-life situations. We will illustrate how we arrive at the key requirements of context-aware service adaptations

by following the first several steps of our methodology.

First, we identify the target groups of users that the information system is focusing on, which include users

internal and external to the organization. This mainly impacts the security and privacy concern (e.g., in accessing

the calendars of others), which is in our continuing research agenda. Now, as all users in this application are

considered to be mobile, let us concentrate the adaptation based on other contexts instead of user categories.

Second, we identify different types of the actions required for the appointment service, which includes meeting

cancellation, meeting scheduling (and rescheduling), minor meeting delay, etc. In particular, meeting scheduling

is the most interesting one as it is basically a negotiation process, which involves many different types of user

behavior.

Third, for meeting scheduling, we identify that users typically specify their options in three types of behavior

(i.e., modes), namely, passive mode, counter-offer mode, and constraint mode. In the passive mode, the user just

selects the acceptable alternatives from the options list. However, in the counter-offer mode, the user actively

suggests other counter-options through simple form-filling. In the advanced constraint mode, the user specifies

constraints representing his/her preferences through complex form-filling or by using a constraint editor.

Fourth, let us consider under what contexts typically users typically exhibit the above different types of behavior.

The passive mode is simple enough for any browsers including those for Personal Digital Assistant (PDA) with

wireless connections as well as mobiles phone supporting the Wireless Application Protocol (WAP). For the

counter-option mode, a PDA is fine, but entering options through forms in a WAP phone is quite inconvenient

and is therefore not recommended. For the constraint mode, a desktop computer is normally required because of

the process complexity and the required screen size. Further considering the message based communication

16

pattern of a mobile phone using SMS, entering a request together with its options saves one additional message

and is therefore more appropriate.

Fifth, for each of such behavior, we enlist the requirements specific for the context in Table 2. Sixth, we enlist the

relevant features supported under different contexts as shown in Table 3. Seventh, for each context feature, we

detail the desired context-aware capabilities in Table 4. The context-aware capabilities match and satisfy all the

requirements elicited above and therefore validate the requirements elicited.

BehaviorContextRequirements

Passive Mode Counter-offer Mode Constraint Mode

Authentication required Required RequiredMessage handling not required not required not required

Message confirmation required not required not requiredConstraint editor not required not required Required

Real-time response not required Required not required

Table 2 Capabilities required by various behaviour of the appointment service – adapted from Chiu et al. (2003)

Context Context Feature Supported PDA WAP SMS

Deployment of User applications yes No noClient-side SSL certification no No noForm handling yes Yes noMessage Reception yes Yes yesMessage Authoring yes Yes yesMessage Transmission yes Yes yesReal-time interactions yes Yes noMessage size medium small very small

Table 3 Example features supported under different Context - adapted from Chiu et al. (2003)

FeatureSet Context-Aware Capability

{Deployment of User applications} Constraint editor{Client-side SSL certification, real-time interactions} Authentication

{real-time interactions} Authentication

{real-time interactions} Real-time response{Form handling, real-time interactions} Formatted data handling

{Message Reception} Message handling{Message Authoring, Message Transmission} Message confirmation…

Table 4 Realization table matching feature sets against capabilities - adapted from Chiu et al. (2003)

17

5.2 Process Views Motivated by views in federated object databases, we propose the use of process views as a fundamental

mechanism for flexible ubiquitous service adaptation. A process view is a structurally correct subset of a process

definition, as defined by Chiu et al. (2003). The concept of process views enables different users (under different

contexts) to access different customized version of the same service. Process views are also useful for security

applications, such as access restriction (like the use of views in databases). Thus, process views serve as the

centric mechanism in our approach, that is, process views represent customized service processes that integrate

with data views and user interface views.

Fig. 3 Meeting scheduling process and process views for different adaptations.

Fig. 3 illustrates some process views of our example meeting scheduling process, in the Unified Modeling

Language (UML). Upon successful authentication to a service request, users may specify their options in three

modes, namely, passive mode, counter-offer mode, and constraint mode, as discussed in the previous sub-section.

Base on the presented requirements, we can arrive at the adapted view design as depicted in Fig. 3(b)-(d),

respectively. It should be noted that the task Show Options is not customized at the process tier, but at the user

interface tier instead. This is because just the appearance of the screens and input are different while they are

referring to the same set of information items, as explained in the section on user interface view.

In order to capture the requirements for users of a mobile platform, a commonly adopted approach from object-

oriented design is to carry out use-case analysis. We should concentrate on the difference of the requirements for

the mobile users from those under standard browsers. These differences are compared with the standard processes

18

to formulate views. We should identify similar or identical tasks to maximize reuse, and in particular, consider

the possibility of customizing them with data views and user interface views instead of rewriting them.

Usually, a complete detailed service process is too complicated for a mobile environment. Therefore, typical

adaptations are simplification of the process, reordering of work steps, task delegation to other personal or to a

software agent. For example, a user with SMS support can only make very simple decisions or feedback. As this

kind of operating environment is often error-prone and may have security problems, we suggest not allowing

critical options in these process views.

It should be noted that the views just discussed serve as templates only. User platform is just one of the context

types. It is often difficult to tell if a user can tolerate a complex process just because of the device. It could be due

to the user’s operating environment, preferences, or even due to the user’s mood. For example, when Alice and

Bob both sit in a restaurant, it is reasonable to use a more complex interaction mode. However, when Alice is

walking in the rain, the interaction mode should be more concise and easier to operate, if not fully automatic.

Therefore, it is always a good idea to consider more context types and information to determine the required and

preferred adaptation.

5.3 Data Views A data view is a set of tables comprising a projection of the enterprise data required for the enactment of some

process views. Note that a data table corresponds to either a class or an association. Table columns are

represented by the class attributes. With a process view defined, we can proceed to analyze its data requirement.

Usually, only part of the application data is required for a process and part of them in turn are required for a

process view. Each work step requires data from the database in some form. In particular, we should identify

mandatory fields, optional fields, and fields that are to be skipped in the view, in order to cope with the

simplification required for mobile users. However, additional fields those have to bemay have to be computed for

summarizing information and knowledge may be required. In case that the mobile user cannot provide mandatory

information or input them information effectively, we may need to modify the process so that the mandatory

information can be provided later or by someone else. Therefore, like designing software, the process is not a

linear one. In addition, security requirements should also be considered. Sensitive information may have to be

restricted to users within the office or to those of pre-approved locations. Data views may also be employed to

hide less important data fields or to show alternate summary columns.

In this example, the main tables related to the meeting scheduling process are schedules, options, and constraints.

For each specific type of service, the tables and their rows required are only a subset. For each user’s context, we

can further define specific data views to restrict such access and for the purpose of customization. In particular,

the WAP platform often has restrictions and needs summaries while the SMS platform always needs this (as

19

shown in Fig. 4). Moreover, even if integration with the user calendar is implemented, only the relevant part

should be exchanged because of privacy reasons.

Further, contextual information also serves as input to services. For example, more obvious contextual

information includes the user’s current time, location, destination, and user calendar. For more advanced and

flexible determination of a meeting venue, weather, traffic condition, and user preferences should also be

considered.

5.4 User Interface Views

(a) (b)

Fig. 4 Screens of the Show Options task for (a) PDA users and (b) WAP users

As illustrated in the example, contextual information helps select the appropriate device (especially the user has

multiple devices) as well as the user interface view. User interface views provide users with appropriate interfaces

to interact with process views within the capabilities of front end devices. This means the user interface views for

a web user is different from that for a WAP user. As shown in Fig. 2, we use eXtended Markup Language (XML)

Style-sheet Language (XSL) technology (Lin and Chlamtec, 2000) for the implementation of user interface

views. Fig. 4 presents two possible user interface views that support the Show Options task in the process views

for PDA users and WAP users, respectively. Information to be presented at a user interface view is structured as

XML document objects by a process view. Both Fig. 4 (a) and (b) correspond to the same XML document object

but are rendered by two different XSL style sheets. For example, the presentation objects for a WAP user

interface view are decks and cards in the Wireless Markup Language (WML) while a PDA browser interface still

uses Hypertext Markup Language (HTML).

We usually need to remove graphics or reduce the resolution, provide panning and zooming, shorten or

summarize fields or provide summarized ones instead, or break one web page into several screens, etc. Due to

device limitations, multimedia contents, such as pictures, animations and videos, are omitted from the screens in

the user interface view for WAP users. For user input, we should consider the difficulties in entering data

(especially typing) on mobile devices, and provide menu selections as far often as possible. For PDA interface,

20

the main problem is just a smaller screen, some of which may be black-and-white. If the original full-function

user interface is too complicated (e.g., too many unnecessary features or high resolution screen layout), another

simplified user interface view is probably required. Pictures and documents may be required to be shown in

lower resolution, and documents may be outlined and level-structured. Panning and zooming (supported by most

browsers) should also help. For users on a WAP interface connecting to the application server via a WAP

gateway, the screen is extremely small. A user interface view is mandatory to map the original one into WML.

It should be noted that other than devices, context such as the user’s eye-sight, lighting, environment, and

preference also have an impact on the user view selection.

6. Discussion As demonstrated in this case study, adaptation of enterprise services to mobile and ubiquitous ones is more than

merely patching user front-ends: adaptation of the processes is essential to cope with different user contextual

behavior. We have proposed the use of a view-based mechanism at all the tiers of a three-tier architecture

(namely, process view, user interface view, and data view) to implement such adaptations, driven by the process

view mechanism. Our approach provides the basic artifacts for ubiquitous service adaptation all the way from

requirements elicitation to implementation and deployment, tackling the complex problem by breaking it down

and considering the adaptation of components. This is also a pragmatic approach to the problem because most

existing enterprise services have been developed with a three-tier architecture. Moreover, the scenario of

extending and adapting an existing web-based application to support mobile users as an extension phase is

usually more typical than designing a context-ware service from scratch.

As the specification of process views is based on the standard artifact of UML activity diagrams while the three-

tier architecture and contemporary XML are widely employed, the techniques presented in this paper areis readily

applicable to other types of systems. Through our approach of incremental and systematic adaptation of e-

services, fast deployment as well as reduction in development and maintenance cost can be facilitated. Thus,

ubiquitous service provision can be streamlined.

Further enhancement of ubiquitous services could possibly deal with handling exception and alternatives due to

the unavailability of the required personnel, network delay, interrupts, disconnections, and so on. In the worst

case when a process is aborted, the system should consider additional requirements for compensation processes

(for example, a clean up process for a service cancellation) under a mobile environment. We admit that some

existing enterprise services have to be adapted or optimized for the introduction of new service parameters and

information involved after the introduction of user mobility. Though this cannot be solely addressed by the three-

tier view architecture, our approach still helps identify these extra adaptations and keeps changes systematic and

reusable. Our approach provides a practical guideline to analyze the requirements of the enterprise services

21

against that of the target contextual behavior, and then select among the alternative viable adaptations. The

consistency of such adaptations can be verified against its definition based on process algebra and automata

theory (Chiu et al., 2003). In this way, we can also identify similar or identical views at each of the tiers to

maximize possible reuse of the original services as well as various adaptations under different contexts.

As for limitations, we identify the following issues, but they are mainly rooted from ubiquitous technologies and

context resolution instead of our proposed approach. First, users desire natural interfaces that facilitate a richer

variety of communication capabilities between humans and machines (Abowd and Mynatt, 2000). By selecting a

natural interface, a user does not need to change the current interaction behavior. The natural interfaces requires

the development of both new software and hardware. In the example scenario, the time estimation to arrive at the

appointment venue requires many different context inputs such as user location, weather, transportation type,

traffic condition, etc. Right now, the context interaction may need some manually explicit input. Such interfaces

are not natural enough and need more research effort.

Second, the various contexts need a good representation model and a good reasoning model to enhance the

system and work efficiency by matching users’ intentions. Most current applications only take advantage of the

user’s location and identity. However, in real-world interactions, more context information is essential for better

personalized decisions. Take the restaurant recommendation activity in our scenario as an example. The system

provides information via users’ location (where Alice is and where nearby restaurants are), users’ preference

(what are Alice and her friends favorite foods), users’ tolerance (if the distance and price of the food are

acceptable), and the environment (if it is a noisy or quiet place, and if Alice and her friends need to wait for a

table). There remain challenges in the standard representations of context, which helps context sharing between

different enterprise applications. In this scenario, Alice could not know whether her colleague is nearby if her

colleague’s location context is not readable by Alice’s devices. Context is a great help to understand a user’s

needs. However, a derivative intention from multiple contexts is hard to achieve. Simple logic reasoning does not

work well since the context relationship is too complex. An accurate predictive model, which is easy to compute,

is useful in both the design and evaluation processes.

Another challenge in design is the privacy problem and many researchers are attempting to address it. In the

above scenario, whether Alice’s colleague allows Alice to know her presence needs to be considered. It would be

awkward if this colleague does not want to be seen by Alice. So, it is necessary to protect the privacy of the

users. But the privacy requirements may change from situation to situation. So a context-aware privacy

mechanism needs to be designed. A possible solution is an extension of P3P (Platform for Privacy Protection by

W3C, 2005), which is used to address the privacy problem in websites. Users need a simple and friendly interface

to initialize and edit their privacy statements.

22

Finally, evaluation techniques may not be applicable in all context-aware applications. Formative and summative

evaluations of ubiquitous systems are difficult and represent a real challenge for the ubiquitous computing

community (Abowd et al., 2002). Deeper empirical evaluation results cannot be obtained through controlled

studies in a traditional, contained usability laboratory. The traditional task-centric evaluation is not appropriate

for the non-task centric interaction behaviors any more. For example, a moving professional or salesperson may

have to react to the einquiries of many clients and colleagues. It is not at all clear how to apply task-centric

evaluation techniques to informal everyday computing situations (Abowd and Mynatt, 2000). Moreover, this kind

of user participation evaluation is very expensive since many users are involved in many context environments

over a long period. A new qualitative or quantitative evaluation technology, which is cheap and not time-

consuming, is very desirable.

7. ConclusionIn this paper, we attempt to address the research questions concerning requirement elicitation and implementation

of ubiquitous enterprise service adaptation based on contextual user behavior. We propose using the notion of

extended context as a basis of capturing user’s mobile behavior and eliciting the associated requirements for

ubiquitous service adaptation. We have presented a conceptual model and methodology for achieving this

purpose, by reconciling user requirements under different contextual behaviors with context awareness

capabilities of the available features. Based on this conceptual model, we have analyzed some typical context

categories (namely, computing context, user context, and physical context) and some key adaptation

considerations based on a pragmatic three-tier view architecture.

The emergence of ubiquitous computing brings context as part of implicit input , which effectively improves the

interaction between human and enterprise information systems. We have illustrated through a case study of a

mobile workforce support information system how contexts serve as the basic artifact for ubiquitous service

adaptation all the way from requirements elicitation to implementation and deployment. We have further

discussed the advantages and limitations of our approach.

Users’ positive attitude towards context-aware application encourages continuous research. Though a lot of

research has addressed context-aware human-computer interactions, there are still many challenges for future

studies, such as natural interface, context reasoning, and new evaluation methodologies. In particular, our

research direction focuses on the requirements elicitation for context-aware applications, especially on how

composite context information and their requirements could be effectively elicited with the consideration of

possible conflicts and implications. We are also interested in evaluation metrics for the selection among viable

adaptations. We are especially interested in applications for ubiquitous collaboration and agent-based computing

under this emerging information system frontier.

23

REFERENCESAbowd, G. D., Atkeson, C. G., Hong, J., Long, S.,  Kooper, R., & Pinkerton, M. (1997). Cyberguide: A mobile

context-aware tour guide. Wireless Networks, 3(5), 421–433.Abowd, G. D., & Mynatt, E. D. (2000). Charting past, present, and future research in ubiquitous computing.

ACM Transactions on Computer-Human Interaction, 7(1), 29–58.Abowd, G. D., Mynatt, E. D., & Rodden, T. (2002). The human experience. Pervasive Computing, 1(1), 48–57.Bardram, J. E. (2004). Applications of context-aware computing in hospital work: examples and design

principles. Proceedings of the 2004 ACM Symposium on Applied Computing, 1574–1579, Nicosia, Cyprus.

Brumitt, B., Meyers, B., Krumm, J., Kern, A., & Shafer, S. (2000). Technologies for intelligent environments. Proceedings of the Second International Symposium on Handheld and Ubiquitous Computing (HUC2000), 12–29, Bristol, UK: Springer-Verlag publications.

Burrell, J., Treadwell, P., & Gay. G. K. (2000). Designing for context: usability in a ubiquitous environment. Proceedings of the Conference on Universal Usability, 80–84, Virginia, US: ACM publications.

Chen, G., & Kotz, D. (2000). A survey of context-aware mobile computing research. Technical Report TR2000-381, Department of Computer Science, Dartmouth College, Hanover, USA.

Cheverst, K., Davies, N., Mitchell, K., Friday, A., & Efstratiou, C. (2000). Developing a context-aware electronic tourist guide: Some issues and experiences. Proceedings of the Conference on Human factors in computing systems (CHI), 17–24, The Hague, The Netherlands: ACM publications.

Chiu, D. K. W., Cheung, S. C., Kafeza, E., & Leung, H.-F. (2003) A Three-Tier View Methodology for adapting M-services, IEEE Transactions on Systems, Man and Cybernetics, Part A, 33(6), 725-741.

Chiu, D. K. W., Cheung, S. C., & Leung, H.-F. (2005). A Multi-Agent Infrastructure for Mobile Workforce Management in a Service Oriented Enterprise. Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS), CDROM, 10 pages.

Chiu, D.K.W., Hong, D., Cheung, S.C., & Kafeza, E. (2007) Adapting Ubiquitous Government Services with Context and Views in a Three-Tier Architecture, Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS), CDROM, 10 pages.

Chiu, D. K. W., & Leung, H.-F. (2005). Towards ubiquitous tourist service coordination and integration: a multi-agent and semantic web approach. Proceedings of the 7th International Conference on Electronic Commerce (ICEC), 574-581. Xi’an, China: ACM publications.

Ciavarella, C., & Paternò, F. (2004). The design of a handheld, location-aware guide for indoor environments. Personal Ubiquitous Computing, 8, 82–91.

Dey, A. K., & Abowd, G. D. (1999). Towards a better understanding of context and context-awareness. Technical Report GIT-GVU-99-22, Georgia Institute of Technology, Atlanta, Georgia.

Dey, A. K., & Abowd, G. D. (2000). Cybreminder: A context-aware system for supporting reminders. Proceedings of the Second International Symposium on Handheld and Ubiquitous Computing (HUC), 157–171, Bristol, UK: Springer-Verlag publications.

Dey, A. K., Abowd, G. D., & Salber, D. (2001). A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human-Computer Interaction, 16, 97–166.

Dix, A., Finlay, J., Abowd, G. D., & Beale, R. (2004). Human-Computer Interaction. Harlow, England: Prentice Hall, third edition.

Fithian, R., Iachello, G., Moghazy, J., Pousman, Z., & Stasko, J. (2003). The design and evaluation of a mobile location-aware handheld event planner. Proceedings of the 5th International Symposium Human-

24

Computer Interaction with Mobile Devices and Services (MobileHCI ), 145–160, Udine, Italy: Springer-Verlag publications.

Hong, D., Chiu, D.K.W., & Shen, V. Y. (2005). Requirements Elicitation for the Design of Context-aware Applications in a Ubiquitous Environment, Proceedings of the 7th International Conference on Electronic Commerce (ICEC), 590-596. Xi’an, China: ACM publications.

Kaasinen, E. (2003). User needs for location-aware mobile services. Personal Ubiquitous Computing, 7, 70–79.Kim, S. W., Park, S. H., Lee, J., Jin, Y. K., Park, H.-M., Chung, A., Choi, S., & Choi W. S. (2004). Sensible

appliances: applying context-awareness to appliance design. Personal Ubiquitous Computing, 8(3-4), 184–191.

Klante, P., Krösche, J., & Boll, S. (2004). Accessights – a multimodal location-aware mobile tourist information system. Proceedings of the International Conference on Computers Helping People with Special Needs (ICCHP), 187–294, Paris, France: Springer-Verlag publications.

Korkea-aho, M. (2000). Context-aware application surveys. Retrieved June 10, 2007 from: http://users.tkk.fi/~mkorkeaa/doc/context-aware.html

Koskela T., &  Väänänen-Vainio-Mattila, K. (2004). Evolution towards smart home environments: empirical evaluation of three user interfaces. Personal Ubiquitous Computing, 8, 234–240.

Koskela, K.,  Väänänen-Vainio-Mattila, K., & Lehti, L. (2004). Home is where your phone is: Usability evaluation of mobile phone UI for a smart home. Proceedings of the 6th International Symposium Human-Computer Interaction with Mobile Devices and Services (MobileHCI ), 74–85, Glasgow, UK: Springer-Verlag publications.

Lei, H., Sow, D. M., Davis, J. S., Banavar, G., & Ebling, M. R. (2002). The design and applications of a context service. SIGMOBILE Mobile Computing and Communications Review, 6(4), 45-55.

Lin, Y.-B., & Chlamtac, I. (2000). Wireless and Mobile Network Architectures. New York, NY: John Wiley & Sons.

Marmasse, N., &  Schmandt, C. (2000). Location-aware information delivery with commotion. Proceedings of the Second International Symposium on Handheld and Ubiquitous Computing (HUC), 157–171, Bristol, UK: Springer-Verlag publications.

Microsoft (2004). Microsoft direct. Retrieved June 10, 2007 from: http://direct.msn.com/Preece, J., Rogers, Y., & Sharp, H. (2002). Interaction Design: Beyong Human-Computer Interation. New York,

NY: John Wiley and Sons.Schilit, B. N., Adams, N., & Want, R. (1994). Context-aware computing applications. Proceedings of the IEEE

Workshop on Mobile Computing Systems and Applications, 85-90, Santa Cruz, CA: IEEE publications.Shafer, S., Krumm, J., Brumitt, B., Meyers, B., Czerwinski, M., & Robbins, D. (1998). The new easyliving

project at Microsoft Research. Proceedings of the DARPA / NIST Smart Spaces Workshop, Gaithersburg, Maryland.

Shafer, S. A. N., Brumitt, B., & Cadiz, J. (2001). Interaction issues in context-aware intelligent environments. Human-Computer Interaction, 16, 363–378.

Shneiderman, B., & Plainsant, C. (2005). Designing the User Interface: Strategies for Effective Human-Computer Interaction. San Francisco, USA: Addison-Wesley, Fourth edition.

Sumi, Y., Etani, T., Felsyand, S., Simonetz, N., Kobayashix, K., & Mase, K. (1998). Cyberguide: A mobile context-aware tour guide. In: Community Computing and Support Systems (pages 137–154), Kyoto, Japan: Springer-Verlag publications.

W3C (2005). Platform for privacy preferences (p3p) project. Retrieved June 10, 2007 from: http://www.w3.org/P3P/.

25

Want, R., Hopper, A., Falcão, V., & Gibbons, J. (1992). The active badge location system. ACM Transactions on Information Systems, 10(1), 91–102.

Want, R., Schilit, B. N., Adams, N. I., Gold, R., Petersen, K., Goldberg, D., Ellis, J. R., & Weiser, M. (1995). An overview of the Parctab ubiquitous computing experiment. IEEE Personal Communications, 2(6), 28–43.

Weiser, M. (1991) The computer for the 21th century. Mobile Computing and Communications Review, 3(3), 94–104.

Yan, H., & Selker, T. (2000). Context-aware office assistant. Proceedings of the International Conference on Intelligent User Interfaces, 276-279, New Orleans: ACM publications.

26

Dan Hong received the bachelor degree in the department of computer science and technology of Xi'an Jiaotong University, China. Currently, she is a Ph.D. student in the department of computer science and engineering of the Hong Kong University of Science and Technology. Her research interests include context-aware applications in pervasive computing (especially privacy issues) and Web browsing with mobile devices.

Dickson K.W. Chiu received the B.Sc. (Hons.) degree in Computer Studies from the University of Hong Kong in 1987. He received the M.Sc. (1994) and the Ph.D. (2000) degrees in Computer Science from the Hong Kong University of Science and Technology, where he worked as a Visiting Assistant Lecturer after graduation. He also started his own computer company while studying part-time. From 2001 to 2003, he was an Assistant Professor at the Department of Computer Science, the Chinese University of Hong Kong. He was a Visiting Assistant Professor in 2006 at the Computing Department, Hong Kong Polytechnic University. His research interests are in information technologies, logistics and service management, as well as e-/m-business with a cross-disciplinary approach, involving Internet technologies, agents, workflows, software engineering, information system management, security, and databases. His research results have been published in over 100 papers in international journals and conference proceedings, including practical results of many master and final-year projects. He received a best paper award in the 37th Hawaii International Conference on System Sciences (HICSS) in 2004. He served in the program committees of many international conferences as well as workshop co-chairs. He is a Senior Member of the IEEE as well as a member of the ACM and the Hong Kong Computer Society.

Shing-Chi Cheung received the B.Sc. degree in the Electrical Engineering from the University of Hong Kong in 1984. He received the M.Sc. and Ph.D. degrees in Computing from the Imperial College London in 1988 and 1994, respectively. He is an Associate Professor of Computer Science andreceived the B.Sc. degree in Electrical Engineering from the University of Hong Kong in 1984. He received the M.Sc. and Ph.D. degrees in Computing from the Imperial College London in 1988 and 1994, respectively. He is an Associate Professor of Computer Science and Associate Director of CyberSpace Center at the Hong Kong University of Science and Technology. His research interests are in the areas of software testing, pervasive computing, RFID based systems. Associate Director of CyberSpace Center at the Hong Kong University of Science and Technology. Professor Cheung is an associate editor of the IEEE Transactions on Software Engineering, the Journal of Computer Science and Technology (JCST), and the International Journal of Patterns (IJOP). He participates actively into the program and organizing committees of many major international conferences on software engineering, distributed systems and web technologies, such as ICSE, FSE, ISSTA, ASE, ER,COMPSAC, APSEC, QSIC, EDOC, SCC and CEC. His research interests include software engineering, services computing, ubiquitous computing, and embedded software engineering. His work has been reported in more than 100 refereed articles at international journals and conferences, which include TOSEM, TSE, ASE, DSS, TR, IJCIS, ICSE, FSE, ESEC and ER. He is a Chartered Fellow of the British Computer Society and a senior member of the IEEE. He co-found the first International Workshop on Services Computing in 2005 and was the tutorials chair of ICSE 2006. He has co-edited special issues for the Computer Journal and the International Journal of Web Services Research (JWSR).

Vincent Y. Shen received the Ph.D. degree from Princeton University in 1969. He taught at the Computer Sciences Department of Purdue University (Indiana, USA) from 1969 to 1985. He also held visiting positions at Tsing Hua University (Taiwan, Republic of China) and IBM (California, USA) during that period. He joined the Micro-electronics and Computer Technology Corp. (MCC; Texas, USA), a research consortium supported by 20 major US computer companies, in 1985, to work on problems related to large-scale software systems development. He later directed the company's Software Technology Program, which had about 60 professionals

27

and support personnel. Then, he joined the Hong Kong University of Science and Technology (HKUST) in 1990 as Founding Head of the Computer Science Department and served in that position until 1995. He also served as Director of HKUST's Sino Software Research Center from 1992 to 1995, during which time he founded Hong Kong Supernet Limited, the first licensed commercial Internet service provider in Hong Kong. Supernet was the largest service provider in Hong Kong when it was sold in 1996 and became Pacific Internet. For this work and the influence it had on the development of Hong Kong's Internet industry he received the Fok Ying Tung Special Contribution Award in 1998. Professor Shen was appointed Associate Vice President for Academic Affairs at HKUST in 1996. He returned to teaching and research at the department in 1997. In 1999, he co-founded the Internet MPAS Limited (later renamed eCyberPay.com Limited) which developed a micro-payment technology to facilitate electronic commerce transactions of small amounts on the Web. The company was later acquired by the Vertex Group, a listed company in Hong Kong. From 2000 to 2003, Professor Shen was seconded by the Government of the Hong Kong Special Administrative Region to serve as Science Advisor, focusing on supporting the development of information technology and electronics industries in Hong Kong through the Innovation and Technology Commission. Professor Shen has served on the editorial boards of IEEE Software, IEEE Computer, and IEEE Transactions on Software Engineering. He served as a member of the Industry Department's Information Technology Committee from 1993 to 1998, and served on the Board of Directors of the Hong Kong Industrial Technology Centre Corporation from 1994 to 2000. He was appointed an Expert to assist the Commission of Inquiry on the New Airport in 1998 in their six-month investigation on the causes of the chaos when the new Hong Kong International Airport opened in July. Professor Shen established the World Wide Web Consortium (W3C) Office in Hong Kong, focusing on Web internationalization issues. He was General Co-Chairman of the Tenth International World Wide Web Conference (WWW10) which was held in Hong Kong in May, 2001. Professor Shen is a member of the International World Wide Web Conference Steering Committee (IW3C2, from 2000) and is now its Chairman, a member of the Board of Directors of Hong Kong Applied Science and Technology Research Institute (ASTRI, from 2004), and a member of ACM's Publications Board (from 2006). He is a founder of the Hong Kong Mandarin Bible Church (HKMBC) and has served as an Elder.

Eleanna Kafeza is a lecturer at Athens University of Economics and Business. She received the PhD from Hong Kong University of Science and Technology where she also held a visiting assistant lecturer position. Her research interests are in workflow management systems, legal issues in web contracting, web services and grid computing.

28