Location Services On

skyhookSkyhook has a recent article and infographic based on a Research Now survey into consumer attitudes into keeping location services on. 50% of users are concerned about privacy, 23% don’t see the value of location data and 19% think that location services drains their battery.

locationon

Skyhook recommend developers concentrate on the First Time User Experience (FTUX) to tell users what data is being collected, why and the value in keeping it turned on.

Also don’t forget that on Android, as of Marshmallow, Bluetooth LE beacons (iBeacon and Eddystone) also need coarse location permission and location ON to detect in background. This is actually a functional regression in Android as older previously working apps now fail to detect Bluetooth LE beacons in background on Marshmallow phones without this permission and location ON.

App Retention Linked to Contextual Content

mobileworldliveThere’s an article at Mobile World Live (by the GSMA) titled Personalisation Key to App Stickiness. We all know user retention is just, if not more, important as user acquisition so how do we achieve this?

The survey by Localytics found that mobile users will start a new app on average 4.5 times before potentially stop using it.

The key is…

“Personalied app content and marketing messages, tailored to their specific behaviour, location and intentions.”

Hence, it’s crucial we use the first app launches to discover context for displaying the appropriate content in those and future app launches. For example, if the app continues to show ’empty’ states then it’s unlikely to be used again. However, what if the app shows nothing because it’s driven by external events such as location, iBeacons or notifications? It’s important to allow the user to initially populate the data somehow, perhaps via browsing limited content or via injected dummy events. That way, the user will get to see how the app can provide value.

MoMo London – Mobile, Maps and Geolocation

mobilemondaylondon.gifLast night I was at Mobile Monday London where the theme was Mobile, Maps and Geolocation – so much more than "Where am I?". It was a panel event with Gary Gale from Nokia, Christopher Osborne from AlertMe and founder and organiser of GeoMob, Ian Holt, Head of Developer Outreach at Ordnance Survey, Jeni Tennison, Technical Director at the Open Data Institute and member of the W3C TAG and Harry Wood of placr.co.uk who is also an OpenStreetMap volunteer.

momojune13panel.png 

I thought the event started very woolly with lots of vague statements that seemed obvious and probably even obvious to the layperson. It’s when the audience got involved that things became a lot more interesting. I came to the event expecting discussion on such things as privacy, implementation practicalities and comparisons of map providers but came away with probably, more valuable, insights into where Mobile, Maps and Geolocation might be heading in the future. Here are some of my notes…

  • There was discussion on whether we will always have or need maps. For example, navigation doesn’t need maps and Foursquare is centred around POIs rather than maps. I think the consensus was that these are additional uses for map data that probably won’t ever replace 2D maps.
  • There will probably be more innovations and required standardisation for indoor mapping.
  • There will be more use of map data with other contextual data and historical data so that problems can be solved such as "What will the traffic be like when I set out and hence what route should I take".
  • As with previous MoMo events on GPS and location, it was observed that location ‘where I am going’ is often more interesting then the current location. Again, historical and contextual information can provide for more useful services.
  • Some solutions will require access to raw vector data that’s currently unavailable from most providers (I suppose at least easily available and at reasonable cost).
  • There are opportunities for transactional apps based on where you are or where you are going. The current Taxi apps are early innovators in this area.
  • There was a view that OpenStreetMap needs to somehow sort out its licensing so that it can be used for apps that generate revenue. The current Share alike licensing is putting off a lot of potential commercial users.
  • Telecom operators, who are best placed to collect and use location data, continue to be (too) slow to innovate. They have large opportunities in areas that use aggregated anonymous data such as government traffic management and business intelligence.
  • Medical, particularly the security (location) of expensive medical assets is a growing and viable area.
  • There are opportunities to use location data to perform queries that don’t just rely on distance. For example, you might do a query that shows POIs of certain type based on time to reach as opposed to distance.
  • There was discussion on the UK PAF (Postcode) database that’s currently controlled by the Royal Mail. The Royal Mail probably needs to open this data otherwise it will eventually be replicated via open/crowdsourced methods.

Shared vs Private Location

mblox.pngLast week I posted about Teens and Mobile Data and concluded that their increased use of data has opened up new opportunities. Looking at the next age group up, a different report from mBlox shows that 89% of consumers aged 18-24 spend between 1 and 5 hours per day on their mobile device.

If you are creating a new app, the report reveals some interesting things that users will and won’t put up with. The conclusions of the report are best absorbed via a new infographic at mashable.com. Most of the insights from the report are obvious. However the following one is more involved…

mbloxlocation.png

This means that there’s scope for apps to distinguish, to the user, between using location just on the device and hence keeping it private vs sending it to a server. Blindly asking for permission to use location might not be enough.

Obviously, apps that rely on sending location to a server to filter returned data can’t do anything about this problem. However, other apps that, for example, just use location to show it on a map or use it to filter a data set on the device might gain more users (or lose less users) if they can tell the user their location isn’t being shared.

5o9 Location

509.gifMobile developers may be interested that 5o9 has developed a solution that allows BlackBerry and Windows Mobile device location to be made available to web sites without any native software development. A browser plugin provides location to web sites as well as allowing for customisation of browser menus to make navigation easier.

I contacted 5o9 to learn a bit more on how it works. Location is only sent when the browser is active and information is sent to web sites using http headers. There’s a data sheet showing the data exposed by the headers that includes device, owner and browser information as well as cellid and GPS position.

I happen to be working on a location application at the moment. I have been testing old and new phones side by side and I am surprised how much better newer devices are at getting location, especially indoors. Improved GPS with the newer, more affordable GPS devices means that the market for GPS applications might be reaching a tipping point.

Google Gears Geolocation API

google.gifAt the July MoMo London, Google told us about the new Gears Geolocation API. Well, today they released the first incarnation for Windows Mobile (5 and higher). The Google Mobile Help Center  lists the compatible devices.

The API allows web apps run in the mobile version of Internet Explorer to access location information based on the device’s GPS location or cellid. As mentioned previously, an application (actually Google Gears plugin for Windows Mobile) has to be installed on the phone to allow the browser to access the new APIs.

It would be great to see the location API opened up further (via http) so that any kind of application (c, c++, Java ME), not just web applications, on any platform could get location information based on cellid. Now that would be truly useful.

Enabling Location in Applications

momlondon.pngThe theme for last night’s Mobile Monday London was ‘Enabling Location in Applications’. The presenters included Ted Morgan, CEO of Skyhook Wireless, Ben Ward from Yahoo! Fire Eagle, Charles Wiles from Google (Gears), Andrew Scott from Rummble, Justin Davis from Buddy Ping, Mark White from Locatrix and Matt Womer from W3C.

Here’s what I took away from the event (my personal thoughts in italic)…

iPhone 3G actually uses Skyhook. This aggregates cellid, WiFi and GPS information to provide location where GPS alone might not work (indoors, height urban areas). Skyhook already have 50 million wireless access points (16 million in Europe) mapped by driving around various countries. While Skyhook uses cellids, it does not obtain any information from network operators.

If it does all this, I can’t help but wonder why my iPhone 3G is so slow at getting a fix. The maximum time to get a rough fix should be the time to get the cellid (negligible) and do a http or ip based lookup to a server somewhere. This should take seconds not minutes. Also, WiFi and cells change over time – how will this information be kept up to date?

Skyhook also have a ‘loki’ iPhone app that can invoke a request that includes location, to a web site through the web browser. This allows remote web sites to know the user location. It’s a clunky workaround as it requires the user to start an application to invoke the browser in this way.

Yahoo’s FireEagle is essentially a database or broker for current and past locations. Anyone can either provide or consume locations according to end-user defined privacy criteria.

I came a across FireEagle a few weeks ago. I must admit I was sceptical. Why would anyone want to trust Yahoo with their location? What’s in it for Yahoo? Having thought about it some more, an aggregated location information makes sense. The alternative, having lots of applications each providing and consuming locations drains battery. There must be some savings from aggregating this stuff. Also, there are classes of applications (proof of concepts, mashups, hobby) where people don’t really want or need to create their own database of locations.

Google told us ‘the web is the platform’. Interesting given they are championing Android. Anyway, the new Geolocation API will provide a Google Gears interface for mobile web browser based applications. There’s a synchronous getCurrentPosition() call as well an asynchronous watchCurrentPosition() that will allow for more battery friendly applications. The actual location can come from a variety of providers – Skyhook, Vodafone, Google etc. There will be implementations (plug-ins) for Windows Mobile, Android, PC and one other platform by the end of the year.

I am still wondering about this merits of this. I presume the the plug-ins themselves will require the installation of a download which is effectively an application (Ok, a DLL in most cases) and the supported mobile platforms won’t be that pervasive.

The W3C has just started to look into providing a standard location API for web browsers.

It seems to me that many organisations are all doing the same thing (trying to get the browser to support location) but in different ways. Let’s hope they converge otherwise we will have yet another set of fragmented APIs.

Rummble gave an interesting presentation and proclaimed ‘Mobile Internet will be the Internet’. Given enough time, people might use their mobile devices as their main device and hook it up to a monitor at home in place of today’s PC. Interesting. Andrew explained how their first iteration ‘Play txt’ failed because users ‘didn’t get it’. I actually see this a lot – tech people such as us can get too embroiled in things that the (lazy) mass market care little about and projects can go off the rails when mildly complex features detract uptake.

Locatrix’s presentation (and the Q&A) made me think more about privacy. There seems to be contention between allowing the user to control their location privacy and ease of use. The more control you give, the more annoying prompts and options need to be tolerated. Another aspect Mark touched on was white label branding. If you are a startup, consider this as it makes your idea much more sellable.

The most interesting part of the Q&A was when someone asked about the need to know other peoples’ locations without them having to push this information or use power hungry GPS, and the importance of cellid in this respect. The iPhone was briefly mentioned in particular it’s inability to run background 3rd party applications. There was also disagreement as to whether cellid on its own is good enough to determine location.

UPDATE: Interesting read from Nokia Conversations, ‘Location based services still do not measure up? Or do they?’

Navizon Cellid Based Location

navizon.gifThinking of adding location to your mobile application? Need a cellid based solution like Google maps cellid location? The problem is that you have to somehow generate (over time) a database of cellids vs GPS positions.

Navizon solves this problem by providing a collaborative database of not only cellids but also WiFi access points. What makes Navizon especially useful to developers are the iPhone, Windows Mobile, Symbian (S60) SDKs that allow you to plug Navizon software based location into your application. (Java ME is coming soon).

If you take a look at the white paper, it explains how Navizon works. It triangulates WiFi access points and uses cell signal strength to interpolate positions.

Navizon also provides some end-user tools to map your position, map your buddies or provide email alerts when a phone enters a particular area. You can even get paid via Paypal for contributing GPS fixes to the database. However, their points system vs payout is particularly low and you are not going to get rich very quickly.