Wearable hardware proving easy to use, but hard to maintain.
This is the first post in a series which will detail the lessons we are learning from our testing sessions with the wearable.
The wearable was tested on the floor for two weeks before the holidays to get a quick feel for the process and to surface initial challenges; tests will continue in January and February. With only a couple of weeks worth of data many things are still fuzzy, but there are some aspects about the hardware that we can report on right now.
We were initially concerned about accessibility of the hardware and we’ve been surprised by the ease of use.
97.44% of users found the text “very clear,” no one reported “very difficult,” and only 2.56% responded “somewhere in between.” 100% of users could see the image on the screen. On a scale of 0–100, users gave the wearable a 91 in ease of scrolling. 84.62% could feel the watch vibrate, but because we were having some problems with content delivery not firing in certain rooms we think this number is low and likely reflective of a technical bug; we expect to see this rise as we move through more testing. On a scale of 0–100, users gave the wearable an average of 85 in overall ease of use. Given the complexity of this hardware and that no one in our testing group had used anything like it before, those are some pretty great stats.
Most of the challenges have cropped up in a place we didn’t expect— the off-the-shelf hardware.
The iPod and iPad as touring devices have been around for a while and we’ve gotten so used to things like commercially available multi-dock charging stations and easy Apple-approved ways to deploy devices in kiosk mode. By comparison, trying to get wearables on the floor felt like the dark ages. Remember 2007 when we had devices with awesome potential, but getting them into the hands of visitors would take a lot of hacking while we waited on manufacturers to make it easier? I just relived it.
Android Wear let us build a kiosk mode, but system level variables still have to be set manually — joining wifi, setting power levels, all had to be done by hand on each device. Those things were annoying, but mostly expected.
There have been unexpected gotchas like the inexplicable times when wifi preferences would just revert for no reason causing the wearable to stop working. As a result of this unpredictability, we had to eliminate our wifi captive portal for our testing period, so there would be less friction getting these devices on the floor.
Another benefit to Android Wear? The device can act alone in a way that the Apple Watch cannot — the app you build can have wifi and bluetooth access without the need to broker through a phone — that was a big win for us, but there are still some things that need to be done with a paired phone. You’d think this wouldn’t be a big deal. I mean, if all we have to do with the paired phone is update the system every once in a while how bad could that be?
Part of it was our perspective. I have an Apple Watch and it is annoyingly cautious about updating the OS by asking me more than once, wanting the device plugged in, charged to a certain percentage, and demanding the phone be within a certain proximity of the watch before it does anything. By comparison, Android Wear is overly enthusiastic and wants to update your watch over the network and on a dime. There was this surprising moment when the paired phone was in the hands of a system administrator twenty miles away and an automatic update was sent to all the watches in a closet back at the Barnes. Luckily, the first time this happened was after hours, but the most astonishing thing is you can’t turn this overly enthusiastic update system off; the only recourse is to un-pair the phone. (!!)
Issues with lack of battery life are the single biggest issue we face. An Apple Watch will get you a full day of use, but the Sony Watch was giving us under three hours given the wifi and bluetooth needed by the application. We’ve been making it through an average visit, but we are also now testing alternative hardware to see if we can get better results from battery life. The good news is we have some choices —having developed on Android Wear means our app will likely work on other hardware.
And then there was this moment in my inbox, “I’m seriously worried about sourcing the watch because stock is running low everywhere.” Turns out the Sony Watch 3 went end of life just as we started deploy and that was before the Sony Watch 4 hit shelves. We were able to buy enough hardware at various stores to get us through our testing period, but it had me valuing predictable development cycles because, you know, predictability can help you get sleep at night.
In prototype testing where we are only dealing with 25 devices, we can make all of this work. In a production environment where we need 200+ devices, we’ve got to consider all of this very carefully.
The nice thing about working with a prototype is issues are surfaced early and it gives us time to see what our options are and how to solve for a future production environment. One thing is for certain. This process has made me value the flexibility of developing on Android Wear while longing for Apple’s hardware and, more specifically, the ease of use of a (hopefully not too distant) future when they play along with Apple Configurator.
The Barnes Foundation wearable digital prototype is funded by the Barra Foundation as part of their Catalyst Fund.
Want more info? Read more about the Barnes Wearable on Medium and follow the Barnes Foundation publication, where we’ve got multiple authors writing about our projects.
