November 2003

The Three Golden Rules Of LBS Integration

BY CHERYL QUIRON

Location-based services (LBS) -- once touted as the �next big thing� in wireless during the days of the Internet hype -- are finally making a comeback here in the United States. In the glory days -- prior to the bursting of the Internet bubble -- everyone talked about how wireless carriers were going to make big bucks offering subscribers innovative location-based applications. The potential money-making services ranged from distributing a coupon via a wireless phone as a subscriber passed a particular fast food restaurant to basic navigational aids.

But then the dot-bomb hit. And plans to offer LBS (like many innovations in wireless) got put on hold as operators tightened their belts and rode out the economic storm that lasted the past few years. Today, however, LBS is making a comeback. It is one of several enhanced services that carriers are offering to squeeze additional revenue out of their wireless subscribers.

What does today�s LBS market look like?
� The average usage across all subscribers is 1.9 times per month.
� The average for minutes of use per session is 1.98.
� User numbers increase by 10 percent to 15 percent monthly with promotion.

The key statistic to focus on above is the growth that LBS applications are experiencing. That�s because many factors are coming together to drive increased usage, including improvements such as high-resolution color screens and faster wireless connections.

But there�s another factor that is even more important to the ultimate success of LBS, and that can be summed up in one word: Integration. Carriers that have been successful in LBS overseas have turned to LBS middleware platforms that follow the �Three Golden Rules of LBS Integration:�

1) Use Data to Drive Applications.
2) Make Application Development Easy.
3) Develop Superior User Interfaces.

The Benefits of Data-driven Applications
LBS applications generally deal with two types of data: dynamic data and �static� data. Typically, users update dynamic data as they navigate their way through the application. Saving, deleting, or editing addresses, maps or routes is inherently dynamic. LBS applications also use so-called �static� data, which are typically data sources that are updated at regular intervals by the service provider. These data include such information as Yellow Pages, restaurant listings, and ATM content, as well as the standard cartographic data (routing, mapping data) from which spatial calculations are derived. These sources are �static� in the sense that they cannot be augmented directly by the user.

Good LBS applications use all available data sources to drive the application functionality and presentation of information to the user. Using data to drive the application and ultimately presentation to the user is critical for maintainability and extensibility of the applications. Standardized application programming interfaces (API) and database structures and protocols streamline data retrieval and presentation. Having standard protocols to deal with data categories and entries enables the applications to populate menus and generate results lists for many different types of data. For example, the same core code can be used to present ATM or restaurant data.

Dynamic data makes LBS applications more useful to end consumers and greatly enhances overall usability. For example, if users have stored addresses, these should be presented to them for selection when calculating routes. The ability to save and reuse pre-entered information greatly reduces �time to result.� This enhanced usability is a powerful driver for LBS application adoption and increased usage.

In reality, subscriber information has many facets. The information can be entered by the user or generated automatically by the application (and associated with specific user requests and actions). The tracking and storage of this data greatly enhances the user experience by limiting the time required to enter (or re-enter) information during subsequent uses of the application. Typical subscriber data includes:

� Relatively static information, such as demographic information and application preferences. These are typically name-value pairs and information that is traditionally considered part of a subscriber profile.
� �Bookmarks,� or named sets of entities, such as �My Favorite Routes,� or �My Maps.� Users have control over what objects they choose to save.
� Histories, or sets of entities, which have special behavior; namely, they are ordered by timestamp, and users cannot add or modify the histories directly.

Histories collect information about the recent entities the user has interacted with, such as recent locations, recent maps, and recent routes. An application can add to the history and read from it via the application programming interface.

Easing Application Development
In addition to data source structure and access, a well-designed LBS platform has two other key elements: the business logic that runs the application (we�ll call these the parts); and the display layer (we�ll call these the widgets). In well-integrated LBS applications, the business logic extracts data from the database, performs specific business-level functions to it, and then hands the information to the presentation layer, which then delivers this information to the user.

In many location-based applications, there is a great deal of commonality in the sorts of requests that are made (the business logic). This logic can be handled via �parts,� which are components that encapsulate one or more sets of functions. For example, a finder part would know how to search the database for the nearest data items of a given category from a given address (or other position). This can be further abstracted to build parts of specific category types such as restaurants, ATMs, etc. Parts encapsulate the fundamental elements necessary to carry out searches, validate an address or calculate directions. They are also built to be adaptable to specific deployment requirements -- using data to drive the functions and configuration parameters to specify implementation specifics (such as which database instance to use). This means that many different location-based applications can use basic, �plug-and-play� business logic elements to build very different, complex applications.

These �reusable components� make building an application much simpler for developers -- and make it much easier to customize applications for wireless carriers. For instance, one carrier might want to offer only a list of restaurants to users, while another carrier may wish to incorporate restaurant reviews. The same basic functionality is used for both applications, meaning that the second application only requires the application to be slightly reconfigured � not entirely recoded. This not only speeds the development process, it also reduces software glitches and streamlines the process of upgrading applications.

The emergence of open standards and the move to a Web services model in the LBS arena has also made writing applications much easier for developers. For instance, the standard OpenLS defines the kind of geospatial information that users can request and the format in which it can be delivered. Basically, it is a standard way to determine what type of functionality that an LBS platform can support, which can change significantly from platform to platform. This means that developers no longer have to make sure that their applications can talk to each platform. OpenLS performs that function for them.

Superior UI = High ARPU
Another critical part of effective LBS integration is delivering information in a logical manner -- and that�s where the display layer, or what we call �widgets,� play a key role. As discussed above, in its most basic terms, a well-integrated LBS application uses business logic elements to extract and manipulate data using application specific logic. It then hands this data off to the presentation layer, which displays this information to the user in the format that is most appropriate for the device that subscriber is using.

Widgets manage the layout and presentation of the information using device specific information. The widget device manager handles idiosyncrasies of specific WAP, PDA, iMode, and Web devices. This device manager contains information on device specific problems and implementation of tested workarounds for known device presentation issues. This approach ensures the creation of markup that has been validated on the requesting device, ensuring a consistent user experience (and minimizing potential errors). Implementing a presentation layer between the user and the business logic information allows displays of data such as maps, search results, and others to be optimized when the device falls short on a particular task, such as list delivery.

Another key to improving the user interface is making applications work together to create a continuous user experience. In other words, well-designed applications allow users to logically jump from one application to the other. With this capability, an application can essentially ask the question, �I have this ____. What can I do next?� This is often referred to a �context� within the application. What you can do next is dependent upon the information that you currently have on hand.

An Action manager can be employed to track which operations can be performed on system primitives (most of which are geospatial in nature). For example, if you have a position (latitude, longitude) what functions can be performed on this? The Action Manager can track operations available within the App Framework that can make use of a position. These may include operations such as �map,� �get directions to,� �get directions from,� �find address of,� etc. The available actions (functions) must also be easily configured to match specific deployment requirements. In reality, carriers have different requirements and may not want to make all actions available.

Let�s take the example of a restaurant application. After a user finds a restaurant listing, the application can use the API and ask, �I have a restaurant entity (which by default has a position associated with it). What can I do next?� Based on rules that can be defined in the LBS platform, the Action Manager returns a list of possible applications that can accept that restaurant data as input, such as a directions application, a restaurant reviews application, or a Yellow Pages application. If a user selects �get directions to,� the directions application will be invoked, with the destination location already populated with the location of the selected restaurant. This enables a continuous user experience, giving a seamless transition from one application to the next. Equally important is the fact that it also minimizes keypad entry by the user, which is critical for LBS application uptake.
In addition, after using autolocation to find the nearest restaurant or to get directions to that restaurant, well-designed applications make it easy to share this information. Well-designed LBS applications enable users to send an SMS to one or more friends inviting them to the newly found restaurant. The SMS (or e-mail or MMS) can also contain step-by-step directions that tell how to get there. With MMS, richer content such as maps, photos, and reviews can be forwarded as well. This not only improves the user experience, it also serves as a catalyst for the viral adoption of LBS applications and drives revenues for carrier data services.

An Integrated Approach
Like all good software designs, LBS must use sound principles to deliver industrial grade applications to the wireless world. The glue that binds all location-based services together is, of course, the location itself. Location defines context (and thereby available actions) and drives what data is retrieved, presented and saved by the user. In essence, the concept of location in itself provides a fundamental framework for building LBS middleware.
 
Additionally, using good software design principles (abstracting the data sources, business logic and presentation layer) provides a highly integrated and user-friendly approach to delivering LBS applications. Integrating these elements using open interfaces and powerful APIs results in an LBS platform that enables wireless carriers and applications developers to easily build powerful, interconnected location-based applications and extend them across a wide range of devices -- while also delivering a superior user experience to subscribers.

Cheryl Quirion is CTO at Webraska, a provider of advanced software solutions designed to support the development, integration, and deployment of location-based and telematics services. Webraska currently powers the LBS and telematics offering of service providers on four continents, including Bell Mobility, E-Plus, Sensis (Australia), Telecom Italia Mobile, O2, Vodafone Live! and Orange.

[ Return To The November 2003 Table Of Contents ]