Desktops aren’t GPS-enabled but don’t let that stop you from providing hyperlocal information to all your fans.
IMAGE from macmillan buzzword dictionary
Two people are sitting in an Internet-enabled café. Let’s call the café Starbucks. One of them is using an iPhone or iPad while having a Hoffachino to find out what’s going on in the area. One of them is using a laptop to do the same. One of these two people is likely to get more accurate responses with less work. Which one is it?
Yeah, the Apple fanbois. To be fair, it could be a Blackberry fanbois or other GPS-enabled smart phone user. The point is that it’s much easier to hyperlocalize applications targeting smart phones because of their innate location-awareness supplied by built-in GPS.
But why restrict your hyperlocal application to just mobile devices? For developers the answer is simple – because the data required to hyperlocalize an application, i.e. the location of the user, is simply easier to get from a mobile device like the iPhone or iPad or Blackberry than it is from a desktop browser. Seriously. The API calls for the application are simple and adding them to either the request or shoving into HTTP headers is just as simple.
Google Gears offers an implementation compliant with the W3C GeoLocation API specification that provides one solution, though obtaining accurate coordinates without a GPS-enabled endpoint may be trickier for the developer.
While GeoLocation is an integral component of mobile device SDKs, there’s no complement on the desktop that provides this data. The result is that either desktop users are treated as second-class Internet citizens (how’s that for irony?) and are not provided with a hyperlocalized interface to the application or they can jump through a series of hoops to get to the same data that is offered up to mobile users automagically.
DYNAMIC INFRASTRUCTURE to the RESCUE
One of the key characteristics of dynamic infrastructure is in its ability to integrate and collaborate with other infrastructure components, both at provision and run-time. Part of those dynamic, run-time capabilities includes the means to intercept, inspect, and if desired modify the requests and responses that traverse the entirety of the application or service delivery chain.
Coupling the ability to perform such a task with the ability to grab location-based data gleaned from the client IP address and suddenly you have the information necessary to hyperlocalize all applications; not just those coming from a GPS-enabled smart phone or device.
There are a number of ways in which such a technique could be applied. For example, if applications are hyperlocalized already based on region, one could redirect users to the appropriate hyperlocalized location using a simple network-side script like iRules: