Indoor Navigation is simple, right?
Last year, one of my very first projects at the Philadelphia Museum of Art, was a digital version of a beloved book, also created at the PMA, named “A is for Art Museum”. The book consists of 26 objects, you may have guessed it already, associated with a letter of the alphabet. We wanted to create a treasure hunt through our galleries, so families could explore the collection in a fun way. As a visitor approaches an object, it opens up on the screen and prompts the user to interact with the art itself. After finishing the activity, the letter “unlocks” and changes its state, engaging kids to start unlocking more and more letters as they explore the galleries.
As “the” developer in our team, I quickly became the lead for the project and the iBeacon planning, testing and rollout.
In order to create an engaging and fun interactive experience, we teamed up with a couple of different vendors to prototype our experience using iBeacons, which were supposed to get installed throughout most parts of the Main Building.
This prototyping phase was extremely helpful on so many different layers. We learned a whole lot about the beacon signal in the real space (vs. testing in our office space), the user experience of wayfinding indoors (drawing a specific path results in a heads-down experience vs. highlighting a general direction which results in a heads-up experience) and also about the different platforms, their strengths and weaknesses (not to mention the pool of different iBeacons in all different shapes and colors).
After evaluating existing platforms and solutions (most iBeacon-based solutions at that time focussed on push notifications for advertisement and good backends with good APIs were rare), it became clear that there was no existing platform out yet, that supported our idea, so we started folding up our sleeves and got to work, building it ourselves.
I quickly became the “beacon person” at the Museum, always running around the galleries with a notepad and an iPad connected to my computer, debugging the app and configuring beacons.
What began was endless walkthroughs through our X number of galleries, carefully evaluating ceiling height, possibilities to mount the beacons and taking notes if we needed to paint an beacon in order to hide it (yes, we now have beacons that perfectly match the color of the ceiling in a handful of galleries, we invite you to come and try to spot our beacons!)
We decided to install the beacons over head, ideally on existing light tracks, so the signal would not be absorbed by visitors standing in front of a beacon. To mount the beacons, we tested a few options and settled with power strips.
Since we already experienced issues with triangulating the beacon signal during our prototyping phase, it was clear that we could not rely on it. We agreed that knowing what gallery a visitor is in is the highest accuracy we could achieve, but we also found that this is good enough for our intended purpose.
In order to get a visitors location in a gallery, we installed the beacons close to doorways and entrance ways to galleries, which ranges from one beacon per gallery to up to four beacons per gallery, depending on the shape and the size of the space.
We were OK with loosing the beacon signal eventually while in a gallery, since we knew we would get a new reading entering the next space.
Alright, we have maps, we know where we want to place the beacons and we just put in an order for 300 beacons (we ended up with Kontakt.IO iBeacons, by the way), now how do we make sure we don’t end up in beacon-chaos?
I decided to go with a naming schema that reflects the galleries name and the position of the beacon in the gallery. Since I was mostly planning on my desk looking at the map, I decided to go with a “at desk” perspective, using left, right, top and bottom vs. North, South, East and West, which would make more sense in the actual space.
So for example, the beacons in gallery 161 are named: 161_T, 161_L, 161_R and 161_B whereas 174 has three vertically positioned beacons: 174_T, 174_M and 174_B
That was all good, until I reached the ground floor of the building, which hosts the cafeteria, education corridors, our restaurant Granite Hill and other spaces like coat check or our project room (which served as the Art Splash headquarters, where visitors would pick up and return their iPads). The ground floor does not have a consistent naming schema on any of our maps, so we had to come up with some names and even break up spaces into multiples to allow a visual flow on the map, which made it hard to keep it consistent.
It also triggered a series of questions on how the three shops in our building are actually named and learning about the difference between our two coat check locations near the west entrance. (It was a great experience to get to know the whole Museum inside out and meet a lot of colleagues along the way!)
To update the beacon names in the backend, I wrote a quick script that communicates with the Kontakt.IO API, to fetch a list of all beacons. That made it much easier to assign an alias name to the beacons and push the information back into the system, than running through the browser interface and manually editing every single beacon.
This JSON feed also served as the base for our app, but I will write more about that in the second part of this article.
Working with iBeacons turned out to be quite an adventure, and I can’t wait to talk about the software side of it, as we encountered a whole lot of quirks in the building and interesting results from our wayfinding algorithm.
Thanks for reading and please feel free to reach out or leave a comment!
