Suppose you want to create a location-sensitive application, to be triggered at various contact points using (depending on the end-users device and inclination) NFC taps, QR code scans, iBeacon vicinity or plain old key-in-a-printed-URL.

There are many, many valuable use-cases for this scenario (think of a contact point as a web bookmark).

To understand the issues arising in creating such applications, let's consider a feedback survey to be deployed in this way.

  1. First construct an online survey using your favourite survey platform; this survey will have a URL for the end-user to visit to activate it.
  2. For (say) 100 locations, you generate a QR code for the URL and make 100 printed copies to deploy at the locations. That's not hard or time-consuming.
  3. If you want to support NFC, you need to program 100 NFC tags with the URL and attach them to the carrier of the QR code. That's getting more tedious, though you can get the NFC supplier to pre-program them for you and even to incorporate them into a printed label with the QR code.
  4. If you want to support iBeacons you need to persuade visitors to install a specific iBeacon app, program the platform associated with the app to direct visitors of the beacons to your URL, and make the platform aware of the unique identities of the beacons you will deploy. This is not so straightforward at all.
  5. Finally you need to install all the contact points you have prepared and be prepared to deal with support issues arising locally, e.g. if a contact point is removed or damaged.

You might be happy to do all these yourself, just once or even on a regular basis. However, this is only the simplest case where you provide an identical user experience at each location. In practice, there are several complications.

Customisability

Engaging applications need to customise what happens depending on which contact point is being used. For instance, at a supermarket check-out you don't want the user to have to enter which supermarket they are at. You may want to vary the questions asked depending on whether the supermarket is of out-of-town, mid-size or convenience format. Etcetera.

This implies that you need a different URL for each contact point, so that the application is given the location-specific information. If you reconsider the steps above where each of the 100 contact points requires different material, it has suddenly got a lot harder.

URL restrictions

This is a technical but important consideration. QR code URLs need to be very short, so the location-specific information cannot be carried entirely in the QRcode.

This can be addressed with URL shorteners like bit.ly or tinyurl but this only extends the limit from around 30 to around 1000 characters. If you want a lot of custom information the survey application will need to be invoked with an HTTP POST request, not a GET, and something more sophisticated will be needed. In any case, some front-end system is needed in addition to the survey platform.

Permanence

The contact points have some endurance, while a survey and its URL are a "here today, gone tomorrow" thing. So you don't want users triggering the URL after it has expired. This again implies some front-end system that allows you to manage the content delivered to the user over time. This system needs to be aware of your inventory of contact points so that you don't need to do operations point by point.

Our solution

InABl.ink have considered all of these issues and provide a solution that minimises the work you have to do to create, deploy and maintain your location-based application. We support you whether you want user content delivered and feedback collected by your own application, by a third-party application, or entirely by our platform. For details of how InABl.ink can work for your application, read on here. InABl.ink is a service of X-MR.