What do museums get out of using these instead of, say, QR codes for visitors to get informations on exhibits? Do these require users to install a custom application?
Having used them for a number of different applications, I can tell you that they are way better than QR codes from a 'just works' perspective to the user. Now, the dev/site team knows darn well that the hardest part of using beacons is getting the distances/interference measured and dealt with, but at the end of the day the user shouldn't have to do anything other than walk around and have your app installed on their phone.
That is key, they have to have your app installed (and allow the correct OS permissions). After that you can (on iOS at least) pop up alerts, passively track how people are moving through your space, see what the most popular spaces are, change your app context to show them details about where they're standing, give them directions, etc.
I don't know how accurate beacons are but I recently visited the Greenwich museum in Greenwich, the Museum of Musical Instruments in Brussels, In Flanders Fields Museum in Ypres, and Casa Mila in Barcelona. All of which had audio tours using numbers (punch the number on some device they hand you) and all of them were fairly crowded and dense. If they were using beacons and the beacons had a range or more than about 1 to 1.5 meters I'd imagine a lot of conflicting inputs. I suppose good UX design could mitigate that showing all the options from all nearby beacons. I guess it just has me wondering is this a solution in search of a problem.
Reading the article it also sounds like lots of poorly designed software. The author complained about pairing being a chore but it seems like with some good software you'd just put up any beacon, scan it, then pick what it corresponds to. If that beacon disappears or breaks just pick any beacon out of sack of beacons, place, scan, pick what it corresponds to. That seems like it should be a trivial 5 second operation. Am I missing something? I shouldn't care what the id is. I only care that it's unique to every other beacon (which the software can tell me the moment I scan it). I don't care about major or minor numbers. Just put any beacon anywhere, scan, pick what it corresponds to. Done.
Note that for school kids, a significant user of museum services, my kid's school issued ipads can scan any QR code and they use that in class, in fact its the only time I've seen someone "in the wild" actually using QR codes, but getting an app installed requires an impressive level of government bureaucracy and leadtime (basically once a year at curriculum review time you could get a new app added to next year's standard system if there's storage space and the review board approves, etc).
They rolled out unlocked, which led to nothing but playing games, then went thru a phase of blacklisting but there's too much whack a mole to list everything to block, now they're pretty well locked down.
Museum folks are pretty primitive in a way. Unlike websites, in a museum it's really hard to know which exhibits or parts of exhibits are popular, and which are not. Maybe you have 100 paintings, but people ignore 90 of them? Or maybe you'd like to automatically play some audio commentary as a visitor approaches a display? Or something a little fancier?
Or maybe you've got a REALLY BUSY museum (think Louvre). It would be really nice to have a heat map of where everyone is. Too many people in that area? Let's direct new visitors elsewhere.
There's a lot of demand for things like this. iBeacons are reasonably horrible, but they're less horrible than trying to use GPS indoors or relying on wifi for location detection.
While I believe you, it seems weird, since they're in the business of purchasing multi-million dollar objects. So there's money coming through, although maybe they can't use it for that? It's too bad, though... Selling off one or two pieces, in order to make the user experience a whole lot better for all of the visitors, would probably be a net gain for the museum's goals.
People Counting[1] is a pretty big market and has plenty of solutions already. If small retail stores can afford it, I don't see why it would blow the budget for a museum.
This is a standard feature for a number of CCTV platforms. Retailers are big users of it, but I'm sure many museums are also on board. It would be much more accurate than the small number of people who happen to have your app.
You may be able to get that heat map of "where everyone is" from your air conditioning system. More humans in a room = more heat = more power usage for your air conditioning system.
The major sticking points were around museums wanting to control the content themselves - even if their websites weren't mobile friendly or translated - and educating people into installing a QR reader (admittedly, no more difficult than getting them to install your museum's app).
The project is still in use with a number of zoos, galleries, and museums - but the QR stickers do occasionally fall off the exhibits
Also the fact that "Ok google, wikipedia foo" is far far easier than using (and possibly installing) a QR reader app.
Maybe if camera apps also functioned as QR readers automatically they might have gained some traction. But Google never enabled that functionality for some reason.
I do have to say that some of their pains could be alleviated by choosing the right vendor(s). We started with a few Estimote beacons (they are fantastic for small site/Dev work and really are a great company), but we met with and found many solutions to management, security, etc. Estimote beacons are VERY simple. Choosing another vendor allows remote management, health monitoring, rolling identifiers, a whole host of other solutions to the problem.
We even went to a Meetup where Nordic Semiconductor wound up sending us some of their Dev kits and WE created our own beacon OS. There are so many more options available for really big installs.
I hope you're right about the vendors. I've come across two now, and both times thought we did our diligence but part way into the campaign continued to get surprised by different issues that really just ended up coming down to a lack of appreciation for the app owner wanting to control the communication to the end user, and serious software quality issues (like the vendors SDK causing unavoidable crashes)
Yeah the Nordic chips are really great. I've created a device that is both an iBeacon and a normal BLE device, and another that is as many iBeacons as you want in one.
I did try spamming hundreds of random iBeacons to see if it would crash any phones (apparently that used to crash old Android phones) but it didn't really do anything.
We get some bad experience with estimote too. They are not mean to sell. For large scale deployment we end up using em micro [1] ones, cheaper, better, stronger and ability to reprogram the beacon OS.
Personally my experiences with iBeacons have been horrible. For an app of any real scale, you want to control your own messaging, but most of the vendors in this space want you to use their messaging platform (otherwise, what would be the point in partnering with them?). Unless you go all in and do it yourself, you're potentially setting yourself up for a very fragmented user experience and fruitless campaign.
Additionally, for iBeacons to work you basically need the stars to align (or for you to have some of the most trusting users in the world). You need:
* the user to have a data connection (likely and reasonable)
* always on location permission (depends on your app, possibly difficult to justify)
* the users bluetooth to be on (somewhat likely)
* access to send the user a push notification (in most cases, without this beacons are fairly useless as you're using them to message the user in response to their location)
In my experience, getting a few of these isn't hard, but getting them all requires a lot of story telling and justification (and rightly so!)
This is much worse on iOS than it is on Android, but with Android 6.0 you're going to see the same issues for iBeacons are you now need to ask permissions as opposed to simply getting them as part of the installation process.
Essentially, in my limited experience with two different beacon installations, beacons are great in concept, but in practice difficult to turn a profit on.
Yeah I agree that is reasonable, but the other non-requirement based requirements still exist, which add to the level of success you're going to have when executing a project using beacons.
Absolutely true! It might come across as an ad, but our solution is especially created to remedy these problems. We're using SLAM from robotics to get beyond basic triangulation. And we have them behind power outlets to get rid of battery and management issues. See http://crownstone.rocks.
"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."
I found this collision between thousands of year old tech vs modern tech intriguing. In the business world, it never fails that no matter how high tech an individual product is, it always relies on paper and pencil and human operated accounting at some point.
Batteries: an unfortunate weakness of ibeacons. I would recommend a six month schedule of preventative battery replacement. Someone at AnDevCon recently showed how to replace Estimote batteries though it might be less work to just go with Sticknfind or another maker that allows battery replacement.
Range: use the SDK to set power to a lower value, to avoid overlap.
Installation: maybe install small (white) plastic boxes to the wall with screws, then can easily place or remove beacons. Color becomes less of an issue as well.
There's a product "BluFi" or something like that, plugs into a wall socket and utilizes both ble and WiFi. Might solve several problems in one blow. I have no experience with this however.
Android prior to KitKat has some problems with BLE including inability to clear the device table without wiping and reinstalling the OS.
I agree that BLE doesn't scale that well. Currently it's something of a solution in search of a problem, but future potential is good.
Mainly my goal was to remind people there are some realistic use cases where audio beacons >> BLE beacons. For some reason audio beacons seem to be often forgotten about as a viable alternative.
31 comments
[ 3.7 ms ] story [ 81.5 ms ] threadThat is key, they have to have your app installed (and allow the correct OS permissions). After that you can (on iOS at least) pop up alerts, passively track how people are moving through your space, see what the most popular spaces are, change your app context to show them details about where they're standing, give them directions, etc.
Reading the article it also sounds like lots of poorly designed software. The author complained about pairing being a chore but it seems like with some good software you'd just put up any beacon, scan it, then pick what it corresponds to. If that beacon disappears or breaks just pick any beacon out of sack of beacons, place, scan, pick what it corresponds to. That seems like it should be a trivial 5 second operation. Am I missing something? I shouldn't care what the id is. I only care that it's unique to every other beacon (which the software can tell me the moment I scan it). I don't care about major or minor numbers. Just put any beacon anywhere, scan, pick what it corresponds to. Done.
Note that for school kids, a significant user of museum services, my kid's school issued ipads can scan any QR code and they use that in class, in fact its the only time I've seen someone "in the wild" actually using QR codes, but getting an app installed requires an impressive level of government bureaucracy and leadtime (basically once a year at curriculum review time you could get a new app added to next year's standard system if there's storage space and the review board approves, etc).
They rolled out unlocked, which led to nothing but playing games, then went thru a phase of blacklisting but there's too much whack a mole to list everything to block, now they're pretty well locked down.
Museum folks are pretty primitive in a way. Unlike websites, in a museum it's really hard to know which exhibits or parts of exhibits are popular, and which are not. Maybe you have 100 paintings, but people ignore 90 of them? Or maybe you'd like to automatically play some audio commentary as a visitor approaches a display? Or something a little fancier?
Or maybe you've got a REALLY BUSY museum (think Louvre). It would be really nice to have a heat map of where everyone is. Too many people in that area? Let's direct new visitors elsewhere.
There's a lot of demand for things like this. iBeacons are reasonably horrible, but they're less horrible than trying to use GPS indoors or relying on wifi for location detection.
Do you know how much money museums have? Let me quote you a nice, round number: 0.
[1] https://en.wikipedia.org/wiki/People_counter
The major sticking points were around museums wanting to control the content themselves - even if their websites weren't mobile friendly or translated - and educating people into installing a QR reader (admittedly, no more difficult than getting them to install your museum's app).
The project is still in use with a number of zoos, galleries, and museums - but the QR stickers do occasionally fall off the exhibits
Maybe if camera apps also functioned as QR readers automatically they might have gained some traction. But Google never enabled that functionality for some reason.
(I'm assuming its wordpress and a static blog at this point.)
There's a google cache
We even went to a Meetup where Nordic Semiconductor wound up sending us some of their Dev kits and WE created our own beacon OS. There are so many more options available for really big installs.
I did try spamming hundreds of random iBeacons to see if it would crash any phones (apparently that used to crash old Android phones) but it didn't really do anything.
[1] https://www.emdeveloper.com/downloads/embeacon/CoinStandardA...
Additionally, for iBeacons to work you basically need the stars to align (or for you to have some of the most trusting users in the world). You need:
* the user to have a data connection (likely and reasonable)
* always on location permission (depends on your app, possibly difficult to justify)
* the users bluetooth to be on (somewhat likely)
* access to send the user a push notification (in most cases, without this beacons are fairly useless as you're using them to message the user in response to their location)
In my experience, getting a few of these isn't hard, but getting them all requires a lot of story telling and justification (and rightly so!)
This is much worse on iOS than it is on Android, but with Android 6.0 you're going to see the same issues for iBeacons are you now need to ask permissions as opposed to simply getting them as part of the installation process.
Essentially, in my limited experience with two different beacon installations, beacons are great in concept, but in practice difficult to turn a profit on.
I found this collision between thousands of year old tech vs modern tech intriguing. In the business world, it never fails that no matter how high tech an individual product is, it always relies on paper and pencil and human operated accounting at some point.
I think from context the author means something closer to "hack" than "sneaker-net". Sneakernet has a useful and more precise meaning.
Range: use the SDK to set power to a lower value, to avoid overlap.
Installation: maybe install small (white) plastic boxes to the wall with screws, then can easily place or remove beacons. Color becomes less of an issue as well.
There's a product "BluFi" or something like that, plugs into a wall socket and utilizes both ble and WiFi. Might solve several problems in one blow. I have no experience with this however.
Android prior to KitKat has some problems with BLE including inability to clear the device table without wiping and reinstalling the OS.
I agree that BLE doesn't scale that well. Currently it's something of a solution in search of a problem, but future potential is good.
It's great to see this article getting attention. I also shared it two days ago in a comment on a story about audio beacons (https://news.ycombinator.com/item?id=10563134).
Mainly my goal was to remind people there are some realistic use cases where audio beacons >> BLE beacons. For some reason audio beacons seem to be often forgotten about as a viable alternative.