User testing sessions are a critical part of the process.

Android development is tricky. There are a lot of devices all running different system versions in various states of updates with hardware manufactured by different parties, distributed independently or by various carriers. By comparison, iOS is a fairly controlled environment; we knew we could develop the iOS version of the app in house, but it was clear to us that an external team would need to tackle Android and we contracted with HappyFunCorp.

In the beginning of our Android development process we looked at our Google Analytics to figure out which devices/systems were in our majority and this became our supported device list. Simply put, there are too many devices running too many systems to be able to support all of them, so you have to pick your battles. We settled on a combination of support for devices running at least Android 4.3 and with Samsung Galaxy 4S (and higher) and Nexus 5 (and higher) hardware.

As with our iOS release, we did a number of invited user testing sessions onsite at the Museum. Many of these sessions were attended with just a few users giving us their time. Each session helped us surface bugs, but it was difficult to get a critical mass. One thing we started to see, however, is that at each session we had users show up with hardware that was not on our supported list and, inevitably, we saw a lot of bugs on these devices. It was the very well attended session with Bloomberg employees that helped us identify a trend, come to terms, and make a critical decision that will affect all Android users (for the better).

Bloomberg employees helped us test both our iOS and Android app prior to launch.

Most of the bugs we found on unsupported devices came down to problems with beacon ranging. We could reliably require Bluetooth on supported devices, but on others we’d see two problems. First, if a device didn’t have bluetooth support the user couldn’t use the app at all. This requirement on iOS devices made sense because of the near ubiquity of Bluetooth on current hardware, but was more difficult on the plethora of Android hardware situations. Second, if users were on an unsupported device beacon ranging was hit or miss often causing problems like device sluggishness or outright device crashes.

It was during the Bloomberg testing session when we could see a number of users all having the same problems that issue became really clear.

We had three options. Option one would be to not allow the download on unsupported devices, but this would mean some users could find it in Google Play and other users wouldn’t see it at all. This presented a nightmare for messaging—”We have an Android app….sort of…”  Option two allowed the download, but many users would experience bugs and it would be difficult to communicate why.  Option three would be to turn off bluetooth/beacon ranging for all unsupported devices, but this would mean the ASK team would not see a user’s location.

When an unsupported device is in use, a “no bluetooth” icon appears on the ASK team dashboard alerting them to the situation.

In the end, we went with option three and decided to turn off beacon ranging for all unsupported devices. This means ASK will work on most Android devices, but on devices where we’ve disabled beacon ranging, the ASK team will be flying blind with “no location found.” They can chat with users, but the object information won’t be at their fingertips so readily in what we hope are users who represent the very edge case.

When thinking about Android expansion we had to re-evaluate how we were staffing mobile. In our first year it was invaluable to have someone on the internal team dedicated to iOS mobile development because the process at that time was more iterative. We were developing features and testing with users as we went along—having someone on staff to make changes as we discovered them was critical. Moving beyond that stage we had to reconsider the most efficient way of working and the best route forward would be to shift from staffing internally to hiring a firm. We contracted HappyFunCorp (HFC) to develop the ASK app for Android using our iOS app as a model. HFC is also handling our ongoing iOS maintenance allowing us to shift away from staffing internally in full.

The Android version of the app will function the same as iOS and in a future post I’ll talk about some of the changes that make ASK feel more appropriate for this platform and one of the bigger challenges we hit. Mostly, though, the transition to Android has been straightforward and, luckily for us, that meant we could concentrate on more vexing issues like how the app detects beacons and sends locations back to the ASK team. What follows is a lengthy post that details how our code works and the adjustments we’ve made. We are also taking this opportunity to release all of our code related to beacons in both iOS and Android regardless of the state it’s in—read on. 

In Android, permissions are granted in a one-step process at initial run. iOS, by contrast, stages permission actions as a user needs them. This delay in granting access to bluetooth may be causing “no location found” on start messages because we can’t range for beacons and build our array quickly enough.

So let’s take a look at the problem at hand. We’ve been seeing “no location found” on 15% of messages sent to the team with and high proportion of those on a user’s first message in a chat. We have a hunch this is likely because the beacon ranging starts too late. In iOS ranging only begins when a user turns bluetooth on and this prompt occurs very close to when a user would send that first message; turning on bluetooth is one of many things a user needs to enable and all of these prompts have been carefully staggered, so that users are not overwhelmed at the start. In Android, a user is asked for all permissions as a one step process up front and this means ranging for beacons starts right away. We think this change will help enormously, but we are still testing and this is to be determined. 

The other cause we’ve seen with “no location found” is attributed to the human error side of the equation. We have an admin tool that keeps track of our beacons and assigns them to museum locations. The beacon may be missing from that tool having been entered incorrectly (or not at all). To solve these issues the BKM web developer team enabled server-side logging; each time a beacon is sent to the dashboard that is not in the beacon database we’ve logged it in an admin tool so we can periodically use the data to chase down these problems.

Admin tool shows when we receive an invalid beacon ID likely the cause of a data entry error in our beacon tool.

The HFC team has also coded a debugger tool within the app which shows, in real time, all of the beacons in the application’s cache and the closest beacon the application would send with a message. This is helps us get visibility beyond the Estimote app because it shows what’s happening in our own application. Chris Wilson at HFC explains:

We now have a Chat/Beacon Log page that shows the list of messages sent since the list was reset. It has the beacons (with message optionally visible) showing the message timestamp, and the beacon’s major and minor ids. It uses live beacon data from the museum’s web api to determine if the beacons associated with these messages are valid, invalid, or if no beacon info was sent. The messages in the list are then color coded based on these designations. For easy visibility, messages with valid beacons are colored green, invalid designations are colored yellow, and messages sent with no beacon data are colored red. There are also total counts for each designation visible on the log screen.

Mobile side debugger tool developed by HFC to show beacons being ranged and which beacon would be sent with a message if a user were to hit send.

Our coding changes have not just been limited to the addition of debugging tools and as we discuss improvements it’s worth reviewing how the beacon code in our ASK app actually works. In a nut shell, as a user walks around the building the app ranges beacons as encountered by the device and builds an array with the associated beacon distance. When a user composes a message and hits send, we send the closest beacon to the user that is in the array. The following bulleted lists are coming direct from HFC:

Here’s the way the (newer) Android code works—

• On app start, the app begins ranging beacons using the Android Beacon Library.
• About every second the beacon ranging returns a list of beacons that have been seen.
• It cycles through each beacon and adds them to the cache, removing old copies of beacons that have been ranged with new distances.
• It removes beacons from the cache that have outlived the TTL (currently 2,500 ms – this is something we can try to tweak to improve accuracy).
• It then cycles through the list to determine which beacon is closest, replacing the closest beacon variable with this beacon. TTL on this is 3 minutes.
• The closest beacon variable is picked up and sent along to the chat server when the user hits the send button.

Here’s what we know about the way the (older) iOS code works—

• On app start, it the app starts the beacon ranging. However, the bluetooth check is only conducted when the user tries to send a message. Ranging requires bluetooth to be on, so this may be the source of “no location found” issues.
• When beacon ranging is run, an array of beacons, sorted by proximity is returned every second. If the proximity is unknown, the beacon is removed from the array. Only the first beacon (the one with closest proximity in the array) is used until the next ranging cycle. If the cache is empty, that beacon is added to the cache.
• If the cache is not empty, then the first beacon on this list (the one with closest proximity) is compared with the last beacon found with the last cache object. (1) If the major/minor ID of the beacon is the same AND the distance is less than the object, it adds the beacon to the list. If the major/minor ID of the beacon is the same and the distance is more, then it is not added to the cache. (2) If the major/minor ID of the beacon is different from the last object, it is added to the bottom of the cache.
• The last beacon in the cache array is grabbed along with the message when the user taps the “send” button in the chat message. If the beacon has been in the cache for more than 5 minutes, no beacon information will be sent.

So, what are the differences?

• Beacons aren’t removed from the cache in the iOS app, so duplicate beacons with different distances are added.
• Rather than comparing all new beacons found to all cache beacons and updating existing beacons and adding new ones as in the Android app, the iOS app compares only the last beacon found to see if it is closer than the last cache array beacon.
• There is a TTL of 5 minutes in the cache in the iOS app, whereas the TTL on beacons in the cache in the Android app is 2.5 seconds, and the TTL of the closest beacon if no new beacons have been ranged is 3 minutes.
• In the Android app, in addition to the short lived cache of beacons, there is also a closest beacon variable set in case there are no ranged beacons for a period of time. This beacons is then sent with messages if it has been more than 2.5 seconds but less than 3 minutes. In the iOS app there is no concept of a closest beacon variable.

We are now going to begin the process of testing Android with users to see if these changes have helped and, if so, we’ll start to port these lessons learned back into the iOS code after April. In the meantime, given how many people are working (and struggling) with beacon deploys, we’ve decided to release both sets of code in the state they are currently in along with the mobile side debugging tools. Having a fresh set of eyes from HFC looking at the code has help a bunch and we hope having many more eyes on this code will only help everyone.

Lastly, I’d be remiss if I didn’t take this opportunity to talk a bit about our funders as related to this post in particular. ASK Brooklyn Museum is supported by Bloomberg Philanthropies and one reason we are releasing this code today is the amount of encouragement and enthusiasm that has come from the Bloomberg team toward information sharing in all states of a project’s progress. This blog, our lessons, and our code are published in the largest part due to their support; we are honored to be as open as we are because of the standard they have set among their grantees.

We started to look deeper into our beacon difficulties roughly six months ago because the project had been on the floor long enough to give us patterns in the data. The timing was critical, too, because we were about to begin Android development; working to solve the problems now would help make that deploy more straightforward. To get going quickly, we implemented a manual tracking system using Survey Monkey. The ASK team would log each time they ran into an issue with the location information in an ASK chat. This was not an easy thing to juggle because mid-chat they’d need to fill out a long and detailed form about what was happening and where, but it showed us two very clear trends. Problem messages were either coming in with “no location found” or nearby signal bleed was causing an incorrect location to be sent to the team.

If you thought the manual tracking system was labor intensive what comes next may boggle your mind. As we started to troubleshoot beacon issues, we wanted a clean slate. This meant updating the firmware on all the beacons, checking the battery life, and turning off the advanced power settings that Estimote provides. This was a painstakingly manual process where I’d have to go and update each unit one-by-one. In some cases, I’d use Estimote’s cloud tool to pre-select certain actions, but I’d still have to walk to each unit to execute the changes and use of the tool hardly made things faster. More frustrating was the process to update a unit’s firmware because the phone has to be in close physical proximity to the beacon you are trying to update; this meant carting a ladder around all day in the galleries because all of our beacons are installed high on the wall.

Using a selfie stick to update Estimote beacon firmware in the galleries.

Our solve for this—and I can’t claim credit for coming up with this one because it was our Head of IT, Christina, who drummed this up—was to use a selfie stick to circumvent the need for a ladder. In the end, it took 11 staff hours to make the needed updates/changes to the roughly 150 beacons installed in the Museum. There is some good news. After a year on the floor, the batteries are still holding strong with most units reporting 36+ months of battery life remaining.

With two clear issues on the table, we started down a technical path toward solving them. The web development team pulled data to see if we could quantify how big these issues were. Turns out, “no location found” was overwhelming larger than the “incorrect location” problem; roughly 15% of messages coming into ASK didn’t have a location. This was puzzling because if you walked around with the Estimote app ranging for beacons, it would show that the chance for a dead spot was unlikely; if anything we have too many beacons creating too much noise (as evidenced by the incorrect location problem). Diving in a bit more, the data was showing us that within the 15% of messages with no location data, 26% had no location on a user’s first message in a chat. This pointed to a problem with the beacon detection code in our ASK app.

While this is about the last thing I wanted to hear, it was a darn good time to figure it out. With Android development on the horizon, we decided to evaluate the iOS code to try and figure out why this was happening, but fix the issue in the Android code. Then we could go back after learning those lessons to refactor how the iOS code is working. I’m going to expand on this at length—code release included—in my next post.

For now, let’s move on to the issue not affected by code—the incorrect location problem. Beacon placement in a situation like this one is challenging—we’ve got an older and complicated building with walls of all different material types, special exhibitions that change the physical spaces constantly, object cases that affect signal, and even things like attendance can cause fluctuations in signal that are not expected. To get a handle on signal bleed, we needed two things: a way quantify where we had problems and a way the ASK team could work around them because, no matter what, things may get better with bleed, but that problem is always going to be there with this technology.

The ASK team can toggle next/previous to show objects in adjacent locations if a incorrect beacon location is delivered.

The solve for the incorrect location problem gives the ASK team a tool to work around the issue while leveraging crowdsourcing to diagnose where we have the problem. In the ASK dashboard, the ASK team has a way to toggle the location. If it’s clear that an incorrect location has been sent, they can use the next/previous arrows to see the objects in adjacent locations; I have the ability to set the adjacencies in an admin tool. As an example, I can define that beacon group 59 (European) is adjacent to beacon group 34 (Assyrian) and 29 (Egyptian); if a message gets sent from European, but the visitor is clearly asking about an Egyptian object, the team can use the toggle to get to the adjacent Egyptian objects.

Admin tool showing which beacon group is returned and how many times the ASK team has clicked to a different location using the previous/next toggle in the dashboard.

The toggle helps the ASK team work around the bleed in the most immediate sense, but the toggle is also helping us discover our pain points. The web development team is now tracking clicks on the toggle and a report in our admin tool displays toggle clicks and where they land. This then helps me go into the galleries and adjust the transmit rates and/or placement of beacons to lessen the instances of the problem.

Speaking of, when I go into the galleries and adjust the transmit rates here are the general rules of thumb that I’m using; keep in mind, for ASK all we care about is knowing the room a visitor is standing in and we don’t need more granularity. Larger, cavernous spaces with fixed boundaries and little chance of bleed—our lobby and west wing special exhibition galleries—get fewer beacons with higher transmit rates for better coverage. Smaller galleries closer together—most of our permanent collections—tend to get more beacons with lower transmit rates; this helps us get the coverage we need while keeping the bleed at a minimum.

At the time we started our technical implementation—almost a year ago—iBeacon was new and it presented a good option for us. We’re following agile methodology and in a project where iteration is the norm, you don’t want a ton of technical overhead; a lightweight location aware system using beacons made sense.  We could implement location aware inexpensively, see how it would work for the app, and change it (to something else) or dump it if it didn’t work for our needs.

In trying to install beacons throughout our building we’ve faced many challenges.  While the solution remains lightweight and flexible, there’s a lot of overhead to deal with.  In a larger organization, you might throw money at this problem—there are plenty of third party management systems for beacons—or, even, staff time to help develop those solutions internally.  In our case, we’ve devoted some resources to coding internal tools needed, but we’ve also spent a lot of staff time (…my own) installing without the use of third party tools.  This is just how we roll over here; if we can possibly avoid coding, we’re going to do it.  If we can sneaker-net a problem, we’re going to go that route before throwing a lot of money or code at it, especially in the early days when we need to determine if the technology is a workable solution. Here’s our iBeacon install story…

We are using beacons from Estimote; we selected these units because the developer community is strong and we received consistently good customer service and communication from the Estimote team. Estimote has a standout SDK, too, which means we can develop tools to help us—the ability to create our own tools and fully integrate into ASK was critical.  In a market with many players, what we gained in these regards is unparalleled and we’d make the same choice today—both vendor and technology—even knowing the headaches we’ve been facing.

Installing beacons with the help of Matthew Yokobosky, our Chief Designer. White beacons have made all the difference.

The first and most obvious issue we faced had to do with lack of beacon color choices.  We started with only three options available, light blue, dark purple, and seafoam green; all of zero matched any colors used on our walls. We knew this would be a problem going in and Estimote said a white beacon would release by the end of the year, so we started working with light blue (no matter how much it clashed) during our testing period last fall. As promised and on time, the white beacons were available in December.  This was great news, but we had to repurchase and replace the blue beacons we had installed on our testing floor and we now have a lot of unusable blue beacons from the early install just going to waste.  Additionally, we need black and grey options and we hope to see those in a few months…at which point, we will have the same issue.  We’ll have to go through and replace in areas where we used a less optimal color and then we’ll be swimming in purple units that we used as an early stopgap.

A beacon on the floor; an all too common sight in our galleries during this install process.

As if this wasn’t enough, we’ve had a lot of problems actually getting these to stay put on the walls. It’s no secret we have a tough production environment here; we use different types of paint (gloss, flat, semi) and our walls vary in surface (plaster, glass, sheetrock, cement). No matter what we do, we’ve found beacons are constantly falling off walls…constantly. The “gecko” adhesive on the back of the beacon just won’t stick (for long) on our surfacing. These particular beacons with their rubberized covers are on the heavy side; this doesn’t help at all.  Sometimes adding Scotch adhesive squares work and other times they make the situation worse, so we can’t always rely on this as a solution.  The folks at Estimote have sent us some custom sticky backs which is helping alleviate the problem.  For obvious reasons, we are installing far from works of art; when beacons fall visitors pick them up, our security guards find them, or they disappear likely swept up in cleaning. The rubberized covers also attract dirt and once they fall (and often bounce) we have to clean up the cases quite a bit prior to getting them back on walls.

When I’m lucky, I come into my office and find fallen beacons on my desk with notes likes these. (This is a real note!)

Once they fall, we’ve got bigger issues.  You have to figure out where you installed that beacon and replace the now missing unit.  Beacons don’t have serial numbers written on the casing, so you have to use an app to scan the beacon and figure out its assigned major and minor number.  The major tells me which beacon group this is in (essentially a room in our galleries) and the minor shows me where in that gallery, but this means during installation I have to keep a map of every beacon we install and its corresponding major/minor number so I can track it down later.  During replacement, you can’t just reassign a missing beacon’s minor value and rehang the unit because minor numbers in any major group have to be unique.  This means you have to change the minor value to a unique value and then go back and update the number on your map.  Imagine what this means when you have to go through and swap colors.  What should be an easy and quick process is a mess of pencil erasing on a floor plan combined with trying to track changed numbers.

Estimote is a startup and just like we are experimenting with our app and working with agile process, they are likely doing so as well.  In one recent shipment of white beacons, I went through and spent all day replacing units in the gallery for better color matching only to find that two days later almost every unit had fallen off walls.  Most were missing, some were recovered, all needed super sleuthing to figure out where they needed to go back.  As I was standing in the gallery frustrated beyond all capacity of lost time and money, our head of conservation happened by and asked how my day was going.  She took a look and realized that the backs of the beacons had changed slightly from one shipment to the other. What was likely a simple manufacturing change (something Estimote is now looking into) turned what should have been a color swap into an all out nightmare of several install days gone.  The folks at Estimote have responded in full by replacing all these missing beacons and overnighted sticky backs; this is one big reason we went with this company in the first place—a direct line and a responsive team have helped us in a lot of ways.

What an art conservator can tell you…there’s something different about the adhesive of these two beacons.

In the end beacons are stand alone, battery operated units—this is great because those features afford you flexibility in installation because there’s no need for power or a hard wired internet connection.  The unfortunate part of this means unlike a hard wired system (like a wireless access point) there’s no reliable central management tool for beacons. Beyond actually going into the galleries and taking a look to see if units are still there and/or working with a scanner app, we have no way to know what’s happening on the floor. You can imagine, I’m sure, the terror I feel every time I walk into a beacon installed space days and weeks later, rounding corners and wondering if the beacons are still hanging, if I’ll find them, if I can figure out where they were to replace them, and if my mobile battery will last long enough in the process.

Speaking of battery life, we are facing similar issues.  Battery life isn’t a problem yet because the batteries should last for a while (a year..or two ???…untested), but we’ll have to deal with this eventually and right now we have no centralized and fool-proof way to tell which units need to be replaced beyond a walk through with a handheld scanner. And once we have to replace them, because the batteries are not accessible in the current Estimote units, we’ve got that pesky major/minor unique number problem all over again.  What should be a simple reassign and put back up (watch for falling beacons) becomes a complicated mess of changing numbers and tracking everything through.

We could leverage the Estimote SDK more to help us.  In doing so, we could build into our app the ability to read the battery level as each beacon is used by a visitor, but there are issues there.  First, it ties us to a specific vendor (our app, for now, only uses Apple’s API) and we’d like to stay vendor agnostic as much as possible.  Second, the battery drain on the units (not to mention the phone) for this kind of overhead makes it a poor choice. However, in not using the SDK, we can’t take advantage of the features Estimote is releasing as they steer their own resources toward SDK development (and they are doing a lot of this right now). That’s okay for us right now—it’s better to keep things as simple as possible to see if beacons work for us first, but we may change our strategy on this take in the future.

Some issues we are facing are not vendor specific. Beacon signal, for instance, is disrupted by everything save air…walls, vitrines, objects, people, you name it. This problem is so bad, in fact, that I can be standing directly beside a beacon on the wall, and will find a stronger signal coming from one across the room.  Jennie has had to implement a ton of code gymnastics in our app to detect the beacon most likely where a person is standing.  As you can imagine, this problem is making for a complicated install process and ongoing maintenance; works of art move quite a bit more than you’d expect.  A simple object rotation in the galleries can throw things off and we do those regularly.

Jennie scans the beacon using the Estimote app so we can assign major/minor values. I’m there with the paper map and Pritika is manning her beacon tool.

We have coded and created solutions to help us when we really needed to do so. Pritika has developed a tool which allows me to add a beacon and pair it with gallery locations.  The tool lets me create beacon groups, so I can assign more than a single beacon to a specific location.  It also gives me a preview of the objects assigned to the location, so I can do a quick visual to ensure the beacon I’m installing is pairing with the correct group of artworks.

My hacked out beacon install cart complete with cookie tins.

We’ve also customized an install cart, which has been essential given the size of our building and the simple square footage of the install areas.  Take a look at the way Mike in our carpentry shop tricked out our cart so the ladder can roll with it. I’ve got my laptop with Pritika’s tool, my iPhone with the Estimote app, a floor plan, a pencil (it’s been a long time since I’ve used one of these), a ton of sticky options, and metal tins of beacons in each color.  The tins are normally used to hold Jodenkoeken cookies that our Head of IT brings back from her trips to the Netherlands.  These tins have become a vital part of the install because they block the signal of the unassigned beacons sitting inside, which can be its own confusing process to deal with. How’s that for a hack?

Our building is fairly large—roughly 500,000 square feet. When we are done, we’ll have about 150 beacons installed throughout the galleries with very little centrality beyond walking around and scanning with eyes and iPhones.  I think our size is pushing the limits here; I simply can’t image scaling this solution to larger organizations without a lot of custom software and overhead that totally defeats the purpose of a lightweight solution.

We are still happy we went this route, but the practicalities have been difficult. I have to tell you we’ll likely switch to Apple’s Indoor Positioning as fast as we can possibly do it; at least, I hope, before batteries in these beacons run out.

To achieve this we placed beacon hardware in the galleries so that when a visitor asks a question the app detects the closest beacon; the visitor’s location is then transmitted to our audience engagement team who will answer queries.  Each beacon has location information assigned to it so we know where the visitor is in the museum. We initially chose two beacon vendors to begin our beacon testing:  Estimote and Kontakt. Both are big players in the newly founded beacon vendor world. And so we set out ordering a handful of each and began our tests.

The first round of testing ended with disappointing results. We experienced very erratic results…very, very erratic. We could be standing right on top of a beacon and it wouldn’t be detected—although strangely, it might detect the beacon on the other side of the room.

With test one behind us we started to look a little deeper and do our research into what was going on. Beacon technology wasn’t going to be as plug and play as we’d hoped. We referred to endless blog posts of experience working with beacons.  Stephen Elliott founder of Llama Digital had written an insightful post on beacon positioning for best detection results.  The article suggests using brackets to mount beacons in such a way as to achieve optimal signal strength. Because of the gallery layouts and general architecture we aren’t able to follow this approach so onward we went. We spoke with Jess Elder and Scott Newman over at the National Geographic Society. They’d recently added beacons into one of their installations. They found mounting beacons on the ceiling gave them more accurate results. Although they also cited similar frustrations with inconsistent beacon detection. Placing beacons on the ceiling wasn’t an option for us either—in many cases our ceilings are incredibly high and getting lifts through the galleries for placement, testing, and battery changing was not going to be practical over the short or long haul.

We performed various other tests, including changing power settings on the beacon which would in theory make the signal weaker or stronger. We tried adding and removing beacons in a room. None of these tests were giving us the consistency we’d hoped for. One gleaming limitation is of course the technology used to transmit beacons—Bluetooth low energy technology. Bluetooth technology is based on radio waves. Radio waves are inherently flaky because of interference. In our case interference might mean any work of art, vitrine, installation partitions, or even other visitors in the gallery! Ultimately each gallery has its fair share of radio wave blockers.

Installation of beacons has been informed both by accuracy and detection for our app as well as minimizing intrusiveness in the gallery as much as we can allow.

In the end we found that basic detection was not enough and so the app works a little harder to determine which beacon is the truly closest one. This involves caching beacon results and time of detection as well as using the accuracy metric from the Apple Core Location API. This metric gives the number of meters the Apple device is from the beacon…in theory.  The accuracy measure is at times wildly inaccurate but tracking that measure and averaging results helps give a more ‘accurate’ result. Beacon placement was very important to make sure we were getting decent coverage in the space we were attempting to identify. We placed the beacons roughly 7-8 feet high and 15-20 feet apart in each gallery. Having the beacons sit higher on the walls works well to remove the beacon from the general range of vision.

One thing we were certain on was that Estimote and Kontakt were both decent beacon vendors. We ultimately chose Estimote because we’d found their developer community to be sizable and very active. The Estimote forums discuss issues which Estimote then fix in a relatively timely manner. The SDK has had various releases as has the firmware. These releases have addressed some big improvements in battery life and security around the beacon.

‘Icy Marshmallow’ is the best choice for us for now as we await more color choices.

Of course the one big difference between the two beacons is the look. At the museum the aesthetics of each gallery are very important. A great deal of time is spent designing the galleries and adding beacons throughout was a sticking point for some. The Estimote beacons come in a limited number of colors and have a distinctive look. As a starting point we’ve chosen the least intrusive color ‘Icy Marshmallow’ and we are eagerly awaiting more color options which we understand are coming by the first quarter of 2015.  The decision around placement of the beacons has been informed both by accuracy and detection for our app as well as minimizing intrusiveness in the gallery as much as we can allow.

Adhesive was also a concern as objects in galleries are often changed and so might the beacon placement. We had to be sure the adhesive wouldn’t damage the wall and would be easily transferable to the next location. In most cases Estimote beacon adhesive seemed to work ok with several exceptions where we’ve doubled up with Scotch Removable Mounting Squares.

So all in all, it’s been a fantastic learning experience for our team—not only working with new technology and evolving software and hardware SDKs, but also how they can best interact and co-inhabit a delicate environment like the traditional museum gallery space. This is only one of many ways we are trying to merge the physical and digital experience, and look for a simple, elegant application of technology that is invisible to the visitor, yet enhances the experience.

What’s next for us? Our Beta test of the ASK app will be happening soon. We are hopeful this will reveal more insights into iBeacon technology and its best application for us.