Sunday, September 23, 2018

Location Based Services Part 3: Chromewalker’s Four Cardinal Points of Location

October 12, 2008 by · 102 Comments 

Chromewalker's Cardinal Points
(click to enlarge)

A component of success in the LBS application space, I believe, is finding the right balance between what I call the four cardinal points. If a service doesn’t find the right balance between these, I believe it becomes inherently difficult for the service to go mass market. The easiest way to begin looking at the cardinal points is by contrasting the poles. Let’s start with how people interact with a service.

Wap Site vs Mobile Client:

When a service/app developer is considering the mobile client route, either an iPhone app, Symbian app, WinMo app, Java app etc, they are essentially drawn to all of the functionality you gain by having an app that has some or open access to the phone’s native apps (address book) or hardware (GPS). This allows developers to create rich applications with beautiful UIs. However, this route usually requires multiple device testing and can reduce user adoption since client installation is a typical interest drop off point for many would-be customers.

The iPhone App store has revolutionized this to some extent, and now the other majors are following suit, but until the mass market has a smartphone and overcomes the discomfort of installing an app, this will continue to be an issue. Additional issues that continue to plague the mass market are concerns about costs associated with downloads, but as of early this year, most carriers (at least in the UK) have some sort of data bundled in for cheap, and these concerns should fade away with time. With a WAP site, however, user access is pretty straight forward, particularly if the application manages to get itself onto the mobile operator’s front page. People that just want to blow a few minutes of their time, will usually not think twice about following a few links to see where they take you. In addition, the concept of browsing to a site even if by typing a URL isn’t too foreign and most people feel more comfortable about it not incurring a huge download cost.

Recent phones, also have pretty powerful browsers built in. Nokia’s E & N series phones with Flash lite can render some pretty complex pages meant for the web, and some of Sony Ericsson’s new phones even have Opera’s Mini browser built in (an excellent browser by the way). With non-smartphones the options go down a bit, but most phones these days can do far more with WAP than the early days of the Ericsson R520m. In other words, don’t quickly discount the web app!

Insofar as location services are concerned, either on wap or app, consider applications such as Dopplr, Flirtomatic, Plazes, and Fireagle. They all allow you to state where you are by typing a component of your location. A zip/post code, a town name, etc. Once that is done, you are ‘located’, and this can be done  pretty easily over the mobile web, and doesn’t require GPS or even triangulation (although it would be  nice in order to reduce text input). The point is, you can do location without requiring the typical hardware and software components typically associated with location.

In the future, I think we’ll start seeing app/wap combinations for services with fire eagle type location updates as part of the posting parameters. Many web-only apps are now starting to allow this via APIs to location updaters, but in the future, particularly for mobile apps, I see apps being developed around location and not just as an add-on. An example of an app/wapp hybrid would be having an application that can message something from a phone app (whatever the service does) to a web app user and have the experience be almost identical.

To explore this in more detail, say a service gets my location via GPS/Triangulation/Text-entry on my mobile client app as part of composing a location aware message. Upon wanting to send the message, I then select a contact within my address book (sourced within the mobile client) and hit send. In the background, the service actually takes all of the information from your message, determines whether the recipient has a mobile client installed (both people are recognized user IDs of the service), and if so, delivers it natively, if not, it formats a wap page with the content as the author intended it to be viewed, and then sends the recipient an SMS with a WAP link that upon click, launches the default mobile browser and renders an experience almost similar to that of the original app. This concept is not new, this is how CDMA phones used to do SMS receive before SMS was part of the typical service offering of CDMA handsets. I’m just surprised by the low number of services that don’t do a hybrid approach such as this one.

In the end, there is no perfect solution that will cover 100% of handsets, but by approaching a service with a more hybrid architecture from the start, a service can more easily secure a beach head amongst the mass market.

User Generated vs Trusted Sources:

The other two poles of the cardinal points is user generated content vs. trusted sources. Take one of my  favorite apps of all time, Vindigo. I used Vindigo on my Palm Treo way back when I lived in NYC, and it allowed me to find restaurants near me and to read reviews done by professional food critics. I knew that if it was ranked 4 stars, I was unlikely to be disappointed with the quality of the food, and I knew that if it was ranked $$$$ it was bound to be expensive, even for those with deep pockets. In summary, I trusted the information, and I used Vindigo as a quick go-to reference.

On the other end of things are application such as Plazes and Rummble where users contribute places that they find are interesting. They don’t have to be actual proper locations per se, they can be a room within a location, and a block or neighborhood can also have various tagged places of the same type or name if different people tag them. In other words, it becomes very difficult to sort and find what you are looking for, and when you do find it, do you trust it?

This brings me to the ‘glue’ of the cardinal points: Trust.

In my previous post on privacy and permissions, we covered the issue of trust in the service, but how about trusting the data ON the service? If you consider the one pole, trusted licensed data, such as from Zagat or Moviefone you trust the data as coming from experts, but you and those experts don’t always agree. I, for example, like cheezy sci fi movies, Ebert may rank a movie as poor, but I may like it… I don’t trust his opinion on all matters sci fi. My friends, however, may share my same tastes, so if they tag a movie they like, I’m more likely to trust them. The problem with this is my friends are lazy, so they don’t frequently tag interesting movies or if they do tag a movie, they may not give me enough information as to why they liked it for me to know if I’ll share the same reason. This is the problem with the user generated content on LBS sites.

So how do you overcome this? Well, when designing a location based service, it is important to balance the two. If the service you are creating is one where you are looking for restaurants in your local area, for example, you could create a user interface that steal a design element from Photoshop: layering. Say you were to have the base map clear of anything. First, through some sort of location placer, you’d say where you were. The map would then center you. Then, you would have the choice of selecting various layers to overlay on top of the map. For example,

Select your layers:

Critic’s choice-
-Michelin Rated
-Zagat Rated
-TimeOut Rated

Community choice (public user contributed group)-
-Indian Lovers
-Thai Lovers
-Ethiopian Lovers

Friends choice-
-My friends
-Friend A
-Friend B
-Friend X
-My friend’s friends
-Friend AsubA
-Friend AsubB
-Friend Asubx

Once you selected the layers you wanted, you’d see a bunch of pins on the map, each with their respective address and contact data and relevant comments, tags, and reviews. From there, if you wanted to further refine your search, you could integrate things like expected cost, wait time, seating capacity, children area, etc.

Further intelligence could be built into the system to tie the two things together. Say you wanted to explore places that others tagged or created, but you were new to the service and didn’t have any friends or anyone whose opinion you could trust. Well, the service provider can have a service to bridge you between the yellow pages listings and stranger’s suggestions. If you’ve ever used Amazon, you know that when you buy something, you can see what other people have also bought. When you use iTunes, they music you’ve purchased in the past helps the engine give you recommendations. So, a location service of restaurants, for example, could vault you into the community’s tagged locations by first allowing you to choose those locations that you already know you like, and then correlate those with those that others found interesting. Once this finished, you’d have an intelligent recommendation engine, based on a trusted list, but with data points from user generated locations.

Nothing I’m saying here is ‘new’ it’s just that I do see many new applications that have a hard time finding the right balance between the two polar extremes. If you are a new user to a trusted data provider pole, for example, your interaction will be brief, for you will treat the service like a yellow pages and not ‘engage’ any further. If you are a new user to a user generated location based service pole, you will most likely have no basis by which to judge other people’s recommendations or favorite places since you don’t know them or know if you share their opinion, and therefore quickly tire of the service. There needs to be a balance between the two to make a useful and captivating service.

An application/service, therefore needs to consider not only how functional the service is on a device, but how easily people can trust the data and use it. In conclusion, I think the age of location based services is here. It is only a matter of time before we realize how much more value we can get from sharing our location as part of products or services we use day to day, and that we can control our privacy concerns, but still gain value from localized services. The market (financial crisis aside) is still poised for growth as an ever increasing number of phones have the hardware and software necessary to render compelling services, and as operators increasingly make data tariffs more affordable for everyone.

Reblog this post [with Zemanta]

Comments are closed.