Using Beacons at the Museum - Stage Three Update
For stage three of the museum beacon strategy we have developed an application with beacon interactions at the core.
As discussed in previous posts, at the museum we are using a staged strategy to implement beacon technology, with the aim of creating the most engaging experience for our audience. You can read more about the strategy - The Year of the Beacon and a staged strategy.
For stage three of the strategy we have developed an application with beacon interactions at the core. The interactions give visitors feedback about their location and what objects they are closest too, presenting them with rich content.
Designing & Optimising features
There were a number of basic UX features this stage had to achieve to allow us to evaluate the value beacons bring to our visitors experience.
The design and information architecture had to enable visitors to find things quickly and seamlessly. BeaconMaker (BM) brought learnings from a number of previous mobile projects, establishing a design that followed best practice and aimed to create a focused and intuitive experience.
The app contained supporting features, that were included to shape a useful experience of the museum. This version of the app included:
- Whats On Calendar
- About Us section
- User profile/account
A significant amount of testing and iterations of these supporting features took place as we were very conscious they needed to be intuitive to allow us to effectively evaluate the integration of beacons to the experience.
The current aspect of the app that includes beacon interactions to enhance the experience are the tours of the galleries, these include rich content around specific objects & sections. The design of this aspect inherited all the learnings we gathered from the supporting features.
The team spent a significant amount of time working on the design and interaction of the beacons. From our previous stage, Aztecs Audio Guide, it was clear that not all those using the app were using the beacon notifications to interact with the content. As a result the design of the beacon notification was updated.
Previously a user could close a notification and not be notified again unless they re-entered the broadcast zone of that beacon. With this version the BM team designed the notifications to either be maximised or minimised. Meaning when a user triggered a beacon, if they didn't want to interact with the notification they could simply minimise the view and it would continue to update subtly at the bottom of the interface.
Our intention with this update was to increase the use of the beacon notifications when navigating spaces within the museum.
As part of testing we wanted to review how the beacons would work when objects/stops were very close to each other and how accurate beacons were at indicating proximity.
This test highlighted another design requirement and inspirited BM to come up with the idea of a carousel of beacons/stops. Meaning that when a users device saw more than one beacon/stop, it would filter which stop it was closest to and show that object first, then displayed the remaining stops in order or proximity. This also solved some “jumpy” interface changes that occurred between beacon notifications.
Our intension with this update was to increase a users knowledge of their position in the gallery and also indicate to them what objects/stops were closest to them.
In addition as experienced in the previous stage, beacons should be positioned at the same height across the gallery for the most consistence beacon signial.
Soft launch of the app
The app had its soft launch on 10/4/2015 with the intension to only be publicised for testing purposes. We would then iterate changes based on user testing sessions with the museums audiences. The app would then be properly launched alongside the opening of our new Wild Planet Gallery.
We are in the process of gathering initial feedback to implement some minor bug fixes and UX changes, we will then be performing more structured testing sessions to evaluate the progress and KPIs of the app.
We will have more to share in the next month or so as progress is made on this stage of the project.
A Practical consideration for Beacon projects
A point to consider when defining your beacon project, Apple only allows monitoring of twenty regions (areas of detecting a user’s entry and exit) per app. So when planning your app make sure you have a clear idea of how to manage this, your development team should be able to guide you to a solution.
For the museum BM created the following solution to avoid this being an issue, John outlines below:
This will not be a problem for the museum. A 'region' by Apple's definition can be either a single UUID, UUID + Major combination, UUID + Major + Minor combination or lat/lng geographical coordinates. More information on Region Monitoring.
In the museum's case, we are always just monitoring for one 'region' which is the common UUID used for all beacons museum wide, and then performing constant ranging to get the attributes of all beacons in the area.
Also, if it ever becomes an issue, there are ways around it - Apple only allows monitoring of 20 regions 'simultaneously'. To overcome this, we can reset the regions to monitor when the user enters a specific area/sees a beacon, enabling us to continuously update the 20 simultaneous regions to monitor for, giving us unlimited permutations.
The Hitchhikers Guide to iBeacon Hardware: A Comprehensive Report by Aislelabs (2015)