13 March 2007
Location on the web
Posted by Ryan Sarver under: Business; Locationaware; Mobile; Technology .
Since I have started at Skyhook I haven’t had much time to do any personal blogging. It’s not a knock on my job at all — in fact its a great thing that I have been staying really busy with work that I love and being surrounded by good people. But I felt the current topic was good enough to finally carve some time out and make a point to start writing about it.
The topic is the standardization of geolocation on the web. One of the main reasons I wanted to join Skyhook and have believed in the technology from the outset is the value of location in applications, and that really starts with web applications and eventually will carry into mobiles and the desktop.
After spending the first few months getting acclimated, releasing a few versions of Loki and understanding the landscape more, I thought it was time to push forward on helping make location aware browsing a reality. Really the effort has three facets to it…
First is how the browser, or User Agent, determines where it is located geographically. This can be done through various technologies including GPS, WiFi triangulation, IP Geocoding and even user input. Each technology has their pros and cons and an ideal system takes each of them into account and intelligently switches between them or gives the user control over their priority in the system. NMEA makes for a great standard to start with, but has its drawbacks as a final specification for many reasons — its a one-way protocol, its geared specifically to GPS use-cases and only deals with latitude and longitude. To deliver a full solution, APIs will need to be developed that allow different locative technologies to become providers to the system.
Second is how the exposing of this information is controlled. Privacy concerns are a major piece of the puzzle and the management of the privacy policy needs to be handled in a way that is intuitive and granular without being cumbersome. This is a more difficult task than it may seem. The browser must act as a broker of information between the user and the domain requesting the information. Unlike something a simple as a popup blocker, where the black/white list can be binary, we are dealing with a set of data that is less binary and more gradient in nature. Maybe the user is OK exposing their zipcode, but the site is requesting their latitude/longitude. How does this get conveyed in a user interface, how do you give user the controls to manage this and how do you expose this to the website. All good questions that will need to be tackled.
Finally, we have to standardize the way in which web developers can access this information. Not only in terms of the object name in the DOM, but also how it is requested, how it returns errors, and how the developer specifies what level of information they need for the use case.
With the ubiquity of free mapping systems like Google and Yahoo maps, location-based services and content have exploded on the web and on mobiles. Now we just need a way to deliver location as a context to make these applications and content more meaningful and useful for the consumer and the developer.
I will be writing more on the topic soon, so stay tuned and let me know your thoughts…
