Up until very recently distributing test versions of an app had a limitation of up to 100 devices. This was great in theory but those 100 devices were over the course of a whole year and surprisingly we’d already used about 20 of those device tokens just on our own internal testing. Reaching that 100 mark wouldn’t take much.

Of course the other important factor was making the process of having a visitor test our app quick and easy. Distributing a test app to someone’s device was a several step process. We were using TestFlight internally for distribution of our app which requires a tester to create a TestFlight account and ask to join our app distribution list. This then registers their device UUID—used to uniquely identify an Apple device. But it doesn’t end there, each time a new device is added to a distribution list a new version of the app and various other Apple certificates need to generated…painful at best.

So to try and circumvent the process we made the decision to use our own devices and hand them out to visitors to test with. This seemed like the easiest approach. We’d no longer have to worry about hitting that 100 device limit and we’d totally bypass the pain of installing the app on a new device. This also gave us full control over our testing environment. We’d know what iOS version was being run and set any device settings accordingly—turning notifications on etc…

Our stock of iPod Touch devices ready to go for user testing.

We had seven iPod Touches (5th generation) left over from the very first test. We thought we’d created a perfect testing environment…

That’s when we starting learning about the limitations of an iPod Touch. In our first round of internal testing we had some of our team using their own devices (mainly iPhones) and various other team members using the iPod Touches. Interestingly, we noticed that the Bluetooth signal kept dropping out on the iPod Touches, but not once did that happen on the iPhones. This was a key feature of our app to detect visitor location using Bluetooth LE and iBeacon technology. It wasn’t acceptable to have the Bluetooth connection drop out intermittently during member testing. In addition we also saw that the wifi signal dropped out on occasion which we rarely saw with the iPhones. Again this was problematic—no wifi meant no notifications arriving to tell a visitor the question was answered. In fact questions couldn’t be asked in the first place as no means of network connectivity could be established without wifi on the iPod Touches.

We realized at this point that there was a fundamental problem testing our app with the iPod Touches. With an iPhone if the device auto locks (this is usually managed in settings with a default of five minutes) notifications will still arrive but with an iPod Touch if the device auto locks the wifi drops out and notifications will never arrive.

So controlling the environment needed a little more control. We had to set the iPod Touches to never auto lock which would keep a steady-ish wifi signal. We also had to add code to start and restart the iBeacon detection manager in an effort to keep Bluetooth enabled. We were working around the problems, but it was starting to feel a little too far from a real world scenario. We were forcing behaviors that didn’t mimic those used by real app users.

The iPod Touch doesn’t have a vibration mechanism making notifications in a museum a tricky thing.

One final interesting point about the iPod Touches was also around receiving a notification. After a couple of rounds of member testing we had feedback asking for a vibration when a response to their question arrived on the device, this way they wouldn’t keep looking at the device to see if a response had arrived. Sure no problem—and thats when we found out that an iPod Touch doesn’t have a vibration mechanism—who knew! Yes we could add a subtle sound (and for testing purposes we did) but long term that sort of interruption in a museum setting is never desirable and a vibration is definitely preferred.

Along comes September 2014—Apple Worldwide Developers Conference (WWDC). During that conference Apple announced that they were partnering with TestFlight to allow even easier distribution of test apps. We’d now have up to a 1000 device limit for testing and the process of installing the test version on someone’s device was greatly streamlined. At the end of October 2014 Apple had officially integrated with TestFlight. We quickly made a decision that to really be testing our app we needed to have our visitors install it on their device. In a couple of weeks we are going to invite visitors to do just that and are excited to see more real world results!

Today, we are launching BklynMuse, a gallery guide that is designed to complement the more structured museum experience.  In its most basic form, it’s a community-powered recommendation system for the objects that are on display here.  As visitors move through the galleries, they can recommend objects to other visitors.  Based on the  recommendations you give it, this muse will crunch the collective data and present other suggestions for you as you move from room to room.  The guide does other stuff too—it gives access to our cell-phone audio stops, our YouTube videos—but the real power in the device comes from visitors sharing their own takes in our galleries.

This is one of a series of things we are implementing to bridge both the online experience with the in-person visit.  In the case of BklynMuse, Posse members get their recommendations saved to their profiles for future reference—think of it as bookmarking your favs on the go in the gallery and then being able to access them later.  Even more than that, Posse members can create sets of objects on our website and annotate them and, if you choose to sign into your Posse account on BklynMuse, your sets will be right there waiting for you to follow in the gallery.  Those same sets can be shared and featured for other visitors to see, so your voice…your notes…your selections…may be highlighted, in all their Posse glory, for all to see.

For those of you reading the blog, you know I’ve been on a bit of a failure kick lately—cautious observations of visitors glued to screens and kiosks that drive me slightly bonkers—you may be wondering how this could possibly be different.   We designed this interface as more like a scavenger hunt than a multimedia guide.  It’s something that can guide you to objects and something you can use to help guide others, but it’s not meant to replicate the actual experience of really looking at the work, so I’m hoping this reduces the screen glue. As with everything, only time will really tell the outcome, but it’s worth a try.

In areas like The Dinner Party and Luce Visible Storage, suddenly you have a whole kiosk’s worth of information at your fingertips…right there in the space when you need, it in an unobtrusive way.

There’s even more after the jump if you are curious.

Logistics:

Why a web app?  We wanted to develop something that could be utilized on as many devices as possible.  Now, that means we can’t do some fancy bells and whistles…like integration with iPhone cams, etc., but we believe accessibility is paramount.

Why room codes?  We went with short codes instead of something like QR codes because I pine for the day that QR codes become truly easy to use.  Different cell phone cameras trying to capture QR codes in low light = one heck of a mess.  We are going for the most universal method, the simplest way to get visitors the information.

What’s to prevent a cascade? We’ve got lots of Wisdom of Crowds randomization built into the output to avoid it.

Why can’t I comment on objects and create sets on the fly during my visit?  That may be coming in version 2, but for now we wanted to be conscious that typing on these little device keyboards can be a frustrating and painful experience.  As it stands, the interface is almost all touch-and-go with as little typing needed as possible and the expectation is this will lowers the barrier to entry and allows the app to be more easily used.

Considerations:

At the moment, we are relying on visitors to bring their own hardware and we don’t how many of our visitors have these devices or want an experience like this. We will be watching usage closely, but also will be monitoring how many visitors come to the front desk to ask if we have units available.   For now, this is a starting point and as we learn more we will be considering if checkout at the front desk is necessary option that we need to provide.

What’s Next:

Eventually, the data gathered will power a recommendation system on our website.  This is something we’ve wanted to do for a while, but hesitated because objects present themselves so differently via the web.  We are hoping that data gathered in the gallery will be more true to the objects, so when we port this back to the website, the recommendations will be based on what visitors physically saw in the gallery rather than how objects are (mis)interpreted via the web.

As many readers know, we have an existing iPhone app that was developed using our API, so you might be wondering how these two things will co-exist.  Well, we think BklynMuse is something that works well in the building—everything is location specific, recommendations are something you give in the gallery while looking at objects.  The iPhone app works well outside of the building as a browser for our collection. Because the iPhone app is now open source, our internal team will be working to contribute code to combine the two things in the Fall. Ideally, when you download the iPhone app in the future, the home screen will present you with two choices “I’m in the building and want to explore.” or “I want to browse the collection away from the museum.” Based on the adventure you choose, the app will either bounce you to BklynMuse or you will be directed to the existing iPhone app.

Thank You:

For the first time since Click!, we did some extensive beta testing with some pretty amazing people willing to give their time to this project and this testing was essential.  We not only learned a lot from it, but it sparked some great ideas along the way and we wouldn’t be at this juncture without the help and dedication of: Mike, Rik, Lisa, Erin, MuseumNerd, Wesley, Mike, Matt & Kendall, Amy, Stephen, Ronnye & Fred, Farrah, Amy, Dave and Courtney.  Thank you for taking time out of your busy schedules to make this app even better.

If you got this far, you must want to give it a go?

We did extensive testing with mobile device browsers, but didn’t bother with desktop browsers, so you’ll have to humor us and use Firefox if you are testing via desktop instead of a mobile device.  Point your browser to m.brooklynmuseum.org and scale it down so the window is small.  If you need room codes you can find them on my Flickr (the codes are on labels in each gallery, I’m just giving you maps to be friendly).  If you are on the iPhone or iPod Touch, you can add the app to the homescreen after you hit it in mobile Safari.  Don’t forget to set your mood and have some fun!

Did everyone catch Michael Kimmelman’s article in the New York Times yesterday?  CultureGrrl adding her own take to museum sprinting was pretty amusing reading, too and the discussion reminded me of a similar one that David Pogue mentioned back in March about his “to film or not to film” a singular event like the Space Shuttle launch.  If you’ve ever been to the Louvre, what Kimmelman mentions is not much of a surprise.  I was there ten years ago, way before the proliferation of digital and cell phone cameras, but the people watching was much the same.  Photos or not, people were bolting for certain objects and ignoring everything in their path along the way.  What fascinated me was not the article—by 9AM yesterday, I discovered the NYT had enabled reader comments and I was riveted.  If you have not checked those out yet, it’s worth the time to peruse those comments.

As a technologist, I wanted to take the opportunity to look at those comments and discuss the topic of technology in museums, pointing to a recent example of ours.  I’ll warn you, I tend to find technology in museums (art museums) rather distracting and I’m not often a fan of what I see implemented.  We do a lot of experiments here and I often find myself torn with the results.  You may remember that last year, we produced a series of videos and put them on iPod Touches in the gallery.  One idea behind this experiment was to produce the videos as lo-fi as possible with the hope that very little production value would encourage visitors to look at the works of art instead of the screens.  Rather than just produce audio tracks, we felt like seeing the artist talking would provide a more intimate experience, but by eliminating video-fanciness we were hoping visitors would get started by watching and then shift their attention to the work as they continued to listen.

I spent a lot of time watching people in the galleries and, in a very informal way, found that 80% of the time visitors were totally glued to those screens:

…by contrast, 20% of the time they were starting with the video, then shifting their attention to the work of art the artist was speaking about:

I’ve not blogged about this observation before now because I’ve had conflicted feelings about it.  On one hand, I wish I had seen more visitors engaging directly with the works, but on the other…I have to recognize that everyone will engage in different ways and that should be welcome.

I will say as we are getting ready to launch a new project, this idea of how to implement technology, so it promotes art viewing instead of TV watching has weighed heavily in my mind.  I’ll talk a bit more about this particular project in a few weeks as we get closer to release, but in the mean time, I’d love to know your thoughts on this issue.  For all the museum professionals and museum visitors who read this blog, there must be plenty of opinion out there?

Elaine Komorowski. Art Handlers, Brooklyn Museum, 2006. Oil on wood.

Many of our readers who’ve seen our behind the scenes sets of various exhibitions loading in have come to catch a glimpse of our fabulous team of Art Handlers and the type of work they do here on a daily basis.  The handlers are always out and about working in the galleries and the storerooms to ensure that art is moved safely throughout the building. In contrast to other staffers at the museum, they don’t have stationary desks with workstations, so we really needed to provide a solution for their computing needs that was more appropriate to their situation.

Elaine and Jason looking over their new work tool, the iPod Touch with Artsee.

ArtSee is a web app formatted for the iPod Touch 3″ screen and it runs a mobile version of our collection management system that we designed specifically for the needs of our Art Handlers.  Each member of the art handling staff has been given an iPod Touch so they can go into storage or the galleries and query an object’s location and other information. Lucky for us, Apple started supporting Exchange on these devices, so Art Handlers have easy access to Brooklyn Museum e-mail and are now in the pilot stages of e-mailing location reports back to the Collection Management team as objects are moved throughout the building.   In addition, Registrars are now using iPod Touches for web and e-mail access during courier trips and small things like currency conversion apps can sure make their life a bit easier on the road.  Registrars are also now utilizing mobile battery-operated printers to help them photograph objects and print records for condition reports as works arrive on site.

As it turns out, the solution came about from a confluence of events.  First, since 2002 we’ve had a wifi network running throughout the museum.  The wifi network was established for free public use, but we always had an eye toward utilizing it for staff and had wired up the storage spaces and the mechanical rooms at the same time we did the public galleries.  Second, the iPod Touch became pretty near to a fully-functional and affordable computing platform.  Last but not least, we put the collection online and that involved working with our database-driven business systems (such as our collections database, digital asset management system, etc.) to move various sets of data around, so it could form the foundation of web applications like the online collection and internal applications such as ArtSee.  For all the tech heads out there, Paul Beaudoin, the programmer in charge of making all this data play nicely together, has put together some nice documentation about how all this data moving works behind the scenes.  It’s in a wiki for the curious, so e-mail us for an invite.

We are still in the early stages, but are hearing good things so far.  You just can’t underestimate the smiling, giddy faces on the Tech team when someone says, “It changed the way I work for the better!”  Yay!

So, the idea was pretty simple: the curators of Burning Down the House: Building a Feminist Art Collection wanted our visitors to hear directly from the artists in the exhibition, so we set out to create a series of videos that would play on iPod Touches in the gallery. As most people reading this blog already know, we don’t have a lot of resources here (read: staff time) to produce video, so we needed a way to do this project without putting too much of a strain on the department. We purchased a bunch of Flip Video cameras and the curators set out to film short interviews with the artists—check these out. We were impressed with the quality of these cams, so if you are looking for a cheap and easy way shoot some video this may be a good answer for your needs—worked for us!

The iPod Touch part of the project turned out to be a bigger problem. Why iPods? Well, they are cheap and small. We are all conscious around here that too much technology can compete with the work on view and the Touches were a good fit. Small enough to be installed in a way that does not overpower the visitor experience, yet large enough screens to watch the movies and built-in touch screens to navigate a list of movie files.

iPod Touch installed in Burning Down the House seen here with Marriage Bed, 2001. Edwina Sandys (British, b. 1938). Mixed media. Brooklyn Museum, Gift of Henry Luce III and Leila Hadley Luce, 2004.29.

We were hoping to find a Museum Mode that would work for the Touch, but it doesn’t exist yet. I guess this makes sense, it took Apple a really long time to release Museum Mode the first time around and it looks like we may be waiting just as long for a version to run on this newer hardware. Best answer we could find was to use the API to create an app, but that doesn’t work either—the API won’t let you lock down the device in a kiosk-like way. No Museum Mode? No API? What’s a museum tech department to do? Our solution is not perfect, but it’s not difficult to accomplish and if you drop us a line we can point you to some existing documentation on the web that helped us.

Now that we’ve got them in the gallery, we will be watching usability closely. Apple is pretty good about providing easy-to-use interfaces, but it remains to be seen how it will translate in a situation like this one. We’ve got a fabulous team of security guards to help get feedback. I’ll be doing some of my own observation in the galleries and will report back with our findings.