|Future Scope – The Post-PC Era|
|SAP Style Guide for PDA Applications|
|SAP Style Guide for Blue-Collar Worker PDAs|
Location awareness: What is it for?
You might already know location systems like the GPS system from hiking or the navigation system in your car. Usually their main task is to locate and direct a user to a certain location. This article describes a different approach of using location to improve the usability of mobile enterprise applications.
As of today a lot of workflows especially for the employees on the road are still paper-based and therefore lack in automated processing and backend integration. With new small, lightweight and inexpensive mobile devices and the increased coverage of wireless data networks, mobile solutions have become applicable for a broad usage. Real-time access to enterprise data and applications for the mobile workforce, such as sales representatives or service technicians, will become a crucial factor for enterprises.
A location-aware application makes use of a user's location. A user's location might be based on a global coordinate system and expressed by coordinates, such as latitude and longitude. Such information is called a Physical Location. Semantic Location specifies the position within a larger context. The context information is stored locally in the context and queried by an application. An example of such a context is a conference room where a PDA might use Bluetooth to connect to the environment and query where the user actually is.
Our current implementation uses Semantic Locations from the shop's infrastructure, but we plan to consider also Physical Location in the future.
The business scenario described here is a real customer process for recording sales orders that we were asked to improve and automate. In their current process sales representatives fill paper forms for customer orders. The forms are collected and sent to a secretarial service once a week, where the data is manually entered and transferred to the backend system during a weekly batch job. Obviously, this process is time consuming, error-prone and expensive. In addition, any acknowledgement for the customer - such as delivery dates - is delayed until the sales orders are processed up to a week later.
To achieve an evolution of the customer's business processes towards a context aware mobile business solution we proposed a browser-based mobile application with an online connection to the SAP based backend system. We realized a Sales Order Entry and an Availability Check application as first implementation.
User interface design is very important for mobile applications. Due to the limited user interface in terms of data in/output, applications should be simple and focused to a user's task. This is especially true for data input. While developing the applications described above, we found that the objective of context-awareness should be improving the usability of mobile applications.
To figure the necessity let me explain the development process a little more
detailed. We implemented the first applications using WAP-phones. The restricted
user interface of the phone forces the application development to reduce the
set of input parameters compared to the paper based approach. The missing parameters
have been replaced with default values.
Figure 1: Sales Order Entry on WAP phone
The user interface of the sales order application (shown in Figure 1) consists of a 6-digit customer number, a 6-digit products number and the quantity that is usually about two digits. The average amount of digits for a single sales order is 13.5 digits.
Due to our findings described in the Designing
for Small User Interfaces article the average time for entering a number
on a WAP phone is 1,48 seconds. The overall time for entering an order using
the UI in Figure 1 is about 21 seconds on a usual WAP phone.
Figure 2: Context aware Sales Order Entry
Usability found this too time consuming and inconvenient, so the improved approach shown in Figure 2 uses contextual information to reduce the manual input. It uses the current user location in combination with customer addresses stored the backend to compute the customer number that is erased from the UI. The location information is derived from infrared transmitters placed at the customer's site, but could also be derived from various other sources, such as GPS in future versions.
Furthermore, contextual information is used to replace the product number input field by a selection list (see Figure 2). These product lists are usually too large for displaying them on a mobile phone. The contextual information allows reducing these lists based on context information as customer data stored in the backend (such as a CRM system containing customers preferences) or from the customer's context itself (such as the customer demand for certain products).
The system was implemented using a mySAP solution as backend enterprise software and SAP's Web Technology as middleware to connect the backend with the mobile devices. The Web Technology part was extended with some special WML templates to support the mobile devices.
In our implementation we are using small infrared transmitters to retrieve location information. These so called beacons broadcast a short message that contains an ID identifying the customer. They have to be installed at the customer's site. A directory service, called Resolver, maps the ID to a URL that points to a XML document containing a corresponding virtual customer description. The URL is send to the Sales Backend application that generates an adapted web page (Sales Application) using the information stored in the XML document in combination with information from the backend as the customer addresses. The application is displayed in the device browser to the sales representative.
For receiving the beacons the approach relies on a small footprint installed on the device. These footprint - the Contextual Information Module - resolves all incoming IDs and transmits the resulting URLs to the backend.
Figure 3: Architectural Overview
The indirect mapping of IDs and URLs, incorporating a directory service, allows for changing the location technology without much effort. For GPS coordinates simply another Resolver would used to translate GPS coordinates into the URL. The Resolver is also very valuable for the pre-processing and may direct to an appropriate XML document based on further contextual information. For instance, a user has a different role and other needs when entering a shop to buy a watch compared of his business role of selling them. The Resolvers allows integrating other contextual information to influence the application that is presented to the user.
Figure 4: Prototype Evolution
Figure 4 summarizes the evolution from paper forms towards a context aware mobile solution. (1) illustrates the initial paper based process that required the full amount of user interaction. The first mobile application illustrated in (2) decreases the necessary interaction by reducing the user interface and defaulting some values by backend data. The utilization of contextual data is illustrated in (3). The necessary user interaction is decreased and input is replaced with contextual and backend information. Defaulted input from step (2) may also be optimized in a similar way to the current context of use.
Based on our prototype, we figured that adding context information to enterprise applications is not generic. Different enterprise applications need different kinds of context information or at least a different interpretation. For instance, context information for a Sales Representative and for a customer has to be interpreted in a different way since their goals are completely different (one selling while the other is buying products). The trick is to find the best combinations for reducing the UI. Therefore context, process, and UI specialists should work jointly on that.
In our future work we will also investigate the usage of physical location technologies such as GSM-based location services to achieve a zero footprint on the device. Based on these experiences we will integrate location information into other typical mobile enterprise applications (such as service management) and additional usability tests will improve our current approach.
Comments or any other kinds of feedback on location-based systems and applications are greatly appreciated!