iBeacons – Improve the Ranging Experience

FileMaker gave us the ability to integrate iBeacon technology with the release of FileMaker 15 last month. This is a great way to enhance existing apps with microlocation features as well as build entirely new apps to solve problems we couldn’t solve before.

Some potential app ideas that have been floating around in my head include:

• Time & Attendance Tracking: Combine iBeacons and TouchID to provide an entirely new, simple and streamlined “clocking into work” experience.
• Parks & Recreation: A resource scheduling solution that eliminates printing and posting event reservations each week for locations all over town.
• Professional Golf Tournaments: Stick an iBeacon in each player’s bag and provide an app for fans to find out who’s nearby, no matter where they are on the grounds.

 

Although I’m really excited for what iBeacons can do, there are two behaviors of the RangeBeacons function that I do not really care for.

1. The timeout is a static behavior, not an opportunistic behavior.
2. The “Searching for iBeacons…” dialog is intrusive to the user experience.

Allow me to explain further. Let’s look at the following example:

Two events will happen when this function runs:

1. The device running FileMaker Go will look for nearby iBeacons for 5 seconds, no matter what.
2. The user will see this dialog on the screen the entire time:

After seeing this behavior countless times I wanted to see if I could improve the experience and still get usable results. I think I have found a way to do just that. I had two goals:

1. Search for beacons for only as long as I had to. 5 seconds is a long pause in an app.
2. Get rid of the “Searching for iBeacons…” dialog.

It turns out if you specify a timeout of 1 second the dialog doesn’t happen. That’s fantastic! The problem is you potentially end up with a less accurate result (i.e., not finding any iBeacons). That’s not so fantastic…

So, the next step is to “mimic” longer searches with a loop. In my not-so-scientific testing I was able to get comparable results with 5 or less one second reads, compared with a single 5 second read. Now my code looks like this:

This small adjustment to how I leveraged the RangeBeacons function has addressed both app behavior issues:

1. Most of the time I was searching for less than 5 seconds. Yay for time savings!
2. The pesky “Searching for iBeacons…” dialog is gone. Yay for a simplified user experience!

I have yet to implement this technique in a real world app, but I’m excited for the opportunity. I believe this makes the iBeacon functionality in FileMaker 15 even more transparent to the user, which is a good thing in my book.