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
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
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
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
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
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
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
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
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
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.
To The November 2003 Table Of Contents ]