Don’t Brick the Userbase
Building Consumer Devices for the Long Term
Some tech ages well, some tech doesn’t. When we were working on the Ubi in (a voice-based computer similar to the Echo) in 2012 and 2013, we had no consideration of how the devices would operate after being in use for many years. We didn’t have the means (or knowledge) to test for aging. There were so many moving parts that we also couldn’t account for what would happen if different services that the device relied on were sunset.
Looking back, there were many things that we could have done. For a device to last for the long term, there were at least three areas that needed to be addressed: software, connectivity, and the physical components.
Levels of Control
One of the first things that we had to develop was the ability to push over-the-air updates (now just updates) to the hardware. There were three levels of software that we were concerned with. One level was the online aspect — that was by far the easiest to control and update and we’d continuously make changes. The next level was the local software on the device that would control the user experience, such as the trigger word, the wake up tone, and offline experience. The lowest level was firmware. This controlled the watchdog for the device, speaker volume, microphone input, the button state machine, among other things. There was a lower version of code, the codec used to control input and output, but that required specialized knowledge.
Houston?
We likened the maintenance of the site to fixing a spacecraft after launch. Like the Socratic Oath, one of our first principles was to “First, do no harm” and not inadvertently brick everyone’s devices. After testing out a push update on our in house devices, we’d then slowly push updates out in batches, monitoring use. Did usage change? Did devices go offline? Did anyone report anything? We’d then slowly change everyone over to the newest version.
There was all sorts of infrastructure pieces that needed to be developed to support this. We needed the ability to know what version of code was running on a device, when it last connected, and any errors that it encountered. We needed the device to verify that it was receiving and sending requests properly. This was mostly done from scratch, where as today there are fully baked services available.
Your Glue Is Loose
All of these pieces are essential for enabling a device to last… at least from a software perspective. Devices are physical, after all, and that means they can be harmed by their environment. Connectivity is one of the most important and sensitive requirements. Antennae can become unglued after time and this will result in disconnections. What makes glue loose? Heat. Heat from processors or, you know, the sun can loosen glue and solder and break devices. We saw this happen with a few components in the Ubi.
Exposure to moisture and dust can also age devices prematurely. Mechanical components will fatigue over time and bend, snap, warp. Buttons have a finite number of uses before they stop working. Proper sealing while still controlling for heat will keep your little device neat.
Moving On
At some point, users move on to new device, as might you, and you’ll need to decide whether it makes sense to continue to support the devices and keep them online. If that’s the case, what’s the right warning period to let users know that their devices will become ornaments? The Voyager spacecraft maintained contact for decades (and still might for the next few years)
Is there an alternative use of the device as it drifts past Pluto?
