Skip to content →

Best Practices for Connected Devices

Published 23 January 2018 by tigoe

I’m about to start a new semester teaching about networks and physical interaction, so in preparation, here’s a collection of best practices for network-connected devices that I’ve cobbled together over time. Much of this is derived from living and working with commercially available network products. Some is derived from conversations with many colleagues in this field. The rest is derived from my own practice building them and developing sample code and circuits for them. I’m not the first to publish such a list. Among others, Claire Rowlands and her co-authors have an excellent book called Designing Connected Products [1]. I’m eager to read those of others. If you’ve got one I haven’t read, email me.

First, I should lay my preferences on the table: I have a strong dislike for the Internet of Things as a concept [2]. I think it’s deeply flawed, mostly because it’s predicated on the idea of surveillance and information gathering rather than enabling human interaction through networked systems. Marc Weiser’s vision of calm technology [3] comes closer to my ideals, though it too has its flaws. Both the flaws and strengths of Weiser’s approach have been explored extensively over the past few decades. Genevieve Bell and Paul Dourish’s analysis of Weiser’s work [4] is a particularly good read. While the two assumptions, ubicomp and the Internet of Things, can live side-by-side in the same product or service, I prefer the latter.

Build projects (or products) not platforms

There’s a tendency among developers of connected products and services to think beyond one specific need in order to develop a platform that can serve many needs instead. This is related, I think, to a popular ideal in computer science, that it’s better to solve the general problem. When possible, replace specific numeric problems in a program with variables, we’re taught in programming classes; that way your code is more flexible.

While that flexibility is often valuable to a specific technical solution, it can weaken a product or service if taken too far. The more generic a platform is, the fewer problems it actually solves. On the other hand, the best platforms often grow from a specific need to address related problems. Bill Buxton wrote a great essay on this topic in 2001, “Less is More (More or Less)” [5]. In that essay, Buxton takes aim at the general purpose personal computer and advocates instead for specific use devices. If you’ve ever opted for a simple text editing tool like Apple’s TextEdit or Windows’ NotePad over a more full-featured word processing environment, you understand this notion. The simpler tool solves one problem, and it solves it reasonably well. Yet even these simple tools are prone to feature bloat.

In devices, feature bloat is an even more insidious problem than in software, because features require more money to make physical changes, or add complexity to an otherwise simple and functional device. With a limited (and inexpensive) display, you might have to page through several menus in order to get to the feature you want. Alternatively, a designer might opt for a higher resolution display, which costs more, requires more complex software, and more work on interface design. When you keep the feature set small, you can keep the operation simple, effective, and often more enjoyable.

Use Known Standards

Despite the best efforts of Apple, Google, GE, Samsung, and other hardware vendors, we don’t live in single-company households. My Sony TV needs to talk to my Bose amplifier and my AppleTV receiver. All of them need to speak to my Linksys router so that I can access content on the internet. They can only do it if they’re using interoperable standards. You’re going to buy products from other companies, and you expect the things you buy to be interoperable, whether one company made them all or not.

Hardware manufacturers generally want to control whose other devices you buy. Their resistance to interoperable standards waxes and wanes over time, but there is always some friction. Had TCP/IP and HTTP not emerged as standards for the internet and the worldwide web, we might be stuck in a world of competing telephony standards and features. Dave Isenberg wrote about this in 1998 in “The Dawn of the Stupid Network” [6]. The dynamics of competition from telephone network operators based on features that he described then parallel the competition from connected device manufacturers now. There are dozens of competing Internet of Things standards out there: Thread [7], Alljoyn [8], the Things Network [9], Apple’s HomeKit [10], Eddystone [11], and many more. Some are more open than others, and some include a larger collection of participating companies than others. Some might emerge as widespread standards. As a general rule, I am skeptical of any standard that’s dominated by one company, that’s not fully published, or that’s not yet seen adoption by at least two bitter rivals. While it’s good to watch emerging standards to see how they develop and who supports them, I think it’s best to be conservative in your application of them. More established professional associations and standards bodies, like the IEEE [12], ACM [13], ISOC [14], ITU [15], and ISO [16] are worth watching for which standards they support as well. Companies that insist on using only their own protocols, no matter how big, weaken the ecosystem of connected devices for all of us.

Respect Privacy

Authorization (allowing me to use a thing) doesn’t have to depend on authentication (verifying my identity). This principle is seldom honored among makers of connected devices these days. For consumers, authentication can be an extra unnecessary step, and off-putting.Don’t ask me to log in to your site or create an account to use a product that I just paid you for. Allow me to choose whether I want to give you anything other than my money. For example, in deciding between Philips Hue system and LIFX’ WiFi lightbulbs, I prefer the former. Although there are a number of reasons for my choice, Philips’ respect for my privacy has been one of the most important.  There’s a second, related reason I like them:

Keep Communications Local

The Philips Hue system is remarkable among Ethernet- or Wifi-connected products in that the Hue hub doesn’t send traffic outside my network. I watch the traffic on my network pretty regularly, and unlike, say Nest or Amazon’s Alexa products, the Philips hug don’t send updates to the manufacturer about my activities. The Hue hub lives on my local network, and handles all communications with my lights. There’s no need for an external service.  More recent versions of their Android and iPhone apps are less respectful, unfortunately. But that’s okay, because the hub’s API [17] is accessible, and based on a known standard: HTTP and REST. You can make your own app [18] if you prefer, and many have. 

Ask for Permission to Go Outside the Local Network

Connected devices work for the consumer, not the other way around. Therefore, if your connected devices want to leave your house, they should ask for permission. If Google wants to know what I do with my lights, and their app asks for my activity data, I can decide whether I want to give it or not. This should be the default. Any other choice prioritizes the manufacturer or third party over the consumer.

Listen More Than You Speak

Connected devices listen. They listen to their sensors for input, and they listen on the network for instructions from applications and other devices. Because they exist to meet our needs (and not the other way around), listening well is critical to their success. However, when students first learn to program devices, they’re taught to make the devices speak first. “Hello World!” is the first program in most every computer languages. For microcontrollers, blinking an LED is the “Hello World!” equivalent. Students quickly learn about consoles and debug terminals and serial monitors as tools to make the computer speak, and they use them liberally. It’s a good way to learn. But once you’ve got the basics, it’s important to learn when to speak and when not to. A good rule of thumb is to speak only when a significant event occurs, like when a user pushes a pushbutton to change its state; or when you’re spoken to, like when an app requests your device’s status. Devices that send messages all the time clog the network and prevent other devices and services that use the network from working well.

Don’t Listen All the Time

Just as it’s important to know how to listen well, it’s equally important to know when not to listen. Devices which listen for activity all the time [19] seem more like spies than tools. Voice interfaces are particularly prone to over-listening [20], because their convenience derives from not requiring any other physical interaction: “Alexa, turn on the lights!” In order to achieve that convenience, your Amazon Echo or Dot has to be listening all the time, for you to say “Alexa”. For a company that wants to know about your habits, that’s a strong temptation. If we’re listening for one word, why not listen for another? Like “soap”, or “shoes” or “Netflix”? Do you really want that level of monitoring? While there are stories of listening devices calling 911 to prevent domestic abuse, or being used as evidence in murder trials [21], not all cases are so benign. Even if having a listening device is benign, it should be the consumer’s choice whether or not to have that benefit in the home. Kudos to Google’s AIY Voice Kit for adding a pushbutton to their voice interface to enable the user to turn it on or off. Too bad the vision kit doesn’t seem to have the same feature.

Inform Me When You’re Listening

Nobody likes an eavesdropper. Humans have developed etiquette around unintended listening from which device manufacturers can learn. Just the presence of a third person in a room will change the tone of a private conversation, but when we’re not seen, we have ways to indicate our presence in order to help others save face. We clear our throats, move to make ourselves visible, or speak up to announce our presence and our ability to overhear. Devices need to do this as well.

Surveillance camera manufacturers often do the right thing by including a recording indicator on the camera. Unfortunately it’s not as ubiquitous as it should be. Similarly. voice interfaces do this to a lesser extent (think of the Echo’s glowing ring), but they don’t often use all the means at their disposal. If I start a private conversation in a room where a voice interface is present, a glowing light may not be enough. Such devices are designed to blend in visually. Perhaps the device should clear its throat and say “Ahem. Alexa here. Can I help you?”

In security applications, this level of politeness may defeat the effectiveness of a device. There are cases where invisibility is a necessity in a surveillance device. But I believe that should be the exception rather than the rule. If something happens after a long period of inactivity and a device is listening, announcing that fact is good practice.

Put a Button On It

Sleek minimal physical interfaces may be all the rage, but they discourage active interaction. If you want me to do use your device, put a button on it. Physical affordances provide us cues to signal what we want from a device. Removing those affordances erodes our agency. Though some automation may be convenient, there is value and even pleasure in making some decisions for ourselves, and signaling those decisions through physical interaction.

Allow Everyone To Join the Conversation

If a device is controlling media, lights, temperature, or any aspect of the environment in a room full of people, then by default everyone in the room should be able to operate it. This runs counter to much software design. By default, we log into operating systems, banking systems, chat forums, and many other software services with which we interact daily. For private information, or any system that represents me or my identity, login makes sense. But for shared environments, it creates inconvenience, tension, and sometimes unsafe conditions. If you’re controlling shared resources, make sure everyone has control of them by default. An app won’t do unless there’s also a switch or a panel on the wall. In many situations, limited access may be desirable. For example, you may not want infants turning on the stove. In these cases, physical placement of controls is access control.

Admit to Vulnerability, and Use Encryption

The primary condition of participants in any network is vulnerability. In order to use any shared medium, we give up some control, some privacy, some autonomy. We have to trust the others on the network, at least a little bit. As a result, we have to manage our trust and our vulnerability. The larger the population of a network, the more basic safety is required. Even in the safest large cities, you lock your doors. Even with the most trusted courier services, you use envelopes. Likewise, basic encryption, authorization, and access control are necessary on any network.

Keep the Firmware Minimal. Don’t Activate Services You Don’t Need

With increasing processor power and the proliferation of embedded Linux systems, it’s common, and often convenient, to design a connected device around a full embedded operating system. Before you decide do to that, however, consider the minimum amount of software you need. If you’re making a connected speaker, do you need a full operating system? [22] If you do, did you make sure to disable any of the operating system’s default services that your device doesn’t need? Do you need to give the consumer the added step of having to establish a login for their refrigerator? Or could you do it with a single-program microprocessor, or a more stripped down version of the operating system? The more your firmware is capable of, the more vulnerabilities it has to attack.

Use Two-Factor Authentication

Two-factor authentication relies on the combination of something you have and something you know, or something you can physically do, in order to gain access to a device. For example, an increasing number of systems are accepting Yubikey [23] tokens or other physical tokens as the something you have, along with a password as the something you know. WiFi Protected Setup (WPS) works similarly, requiring the press of a pushbutton on the router in order to enable a wireless device to connect to the router. The Philips Hue bridge connection button works the same way, requiring something you can physically do (pressing the button) to enable something you have (an app on your mobile device). Two-factor physical protection is a convenient, though not perfect, way to enable access to connected devices without requiring a high-resolution screen.

Put an Off Switch On It

This seems obvious unless you’re primary concern is keeping the device on for monitoring. If I’m not using a device, why is it wasting energy by being on? Many device makers use the excuse that always-on minimizes startup time, but that can be addressed by better software and interaction design, rather than the lazier solution of leaving the device always on. Sleep modes for most processors and microcontrollers have gotten increasingly efficient, encouraging the tendency to omit the off switch. But you can do a lot to build a customer’s trust by letting them turn it off and enabling fast restart.

Allow for Graceful Aging

Software and computer manufacturers are used to thinking in product cycles of less than a year. This runs head-on into conflict with appliance and infrastructure markets, which move in multi-year or even multi-decade cycles. Connected devices are moving from the personal to the architectural, and that requires that we think about how long we expect them to remain operable, useful, and interoperable with other systems.

In How Buildings Learn[24], Stewart Brand offers a useful model. He elaborated on Frank Duffy’s concept of shearing layers [25] to relate the various layers of architecture and technology in a building to time scales. Briefly, from Brand (1984):

  • Site – the geographical setting and location. “Site is eternal.
  • Structure – foundation and load-bearing elements. Thirty to three hundred years.
  • Skin – exterior surfaces. Twenty years.
  • Services – communications, electrical wiring, plumbing, HVAC, mechanical systems. Seven to fifteen years.
  • Space Plan – the interior layout. Commercial spaces change every three years or so; residential spaces might change every thirty years.
  • Stuff – furniture, appliances, lamps, etc. Some items change daily, while others might last a decade or more.

Which layers does the device your designing interoperate with? This should influence many of your choices.

Provide the Facts

Electrical and electronic devices already come with basic labeling indicating their power usage and requirements. The consumer lighting industry has taken a page from the food industry, thanks in part to the US Federal Trade Commission, and now provides a “Lighting Facts” [26] label on new light sources. Connected devices could provide something similar. For example, connected devices might indicate:

  • Basic functionality
  • Physical sensors (sound? voice? motion? light? gas?)
  • Network connection method (WiFi? Bluetooth? ZigBee? Ethernet?)
  • External requirements (mobile device? What OSes?)
  • Defaults:
    • network communications (Local? Manufacturer’s site? third party portal?)
    • external communications frequency (daily? weekly? monthly?
  • Standard protocols used (HTTP? DMX-512?)
  • Encryption used
  • Recycling directions

What else? This is subject matter for another essay.

Make it Recyclable

Given the increasingly short product cycle of electronic devices and the increasing observed effects of climate change, it’s imperative that we be able to recycle electronic devices. connected or not. Regulatory directives like the Waste Electrical & Electronic Equipment (WEEE) [28] directive encourage this, but device makers can do more. Make your devices able to be disassembled. Integration of batteries, circuit boards, and housings is increasingly tight, and has impacts on the cost and difficulty of recycling. Remember that the choices you make to reduce size and increase design coherence have environmental impacts. Even if your device is not meant to be opened by the consumer, you can still help the recycler. Publishing the disassembly instructions, or even just the materials used in a product, can potentially improve the recyclability of a device.

Conclusion

If it’s got a battery or a plug on it, the chances are good that it communicates with something else. Nowadays, communications between devices and interoperability with existing systems are as important to their design as physical form, affordances, and operations. Makers of these devices need to develop their own best practices, whether these or others, in order to maximize the useful life, graceful decline, and thorough disposal of the things we design. Though no designer can know everything, the principles outlined here are ones with which every product designer, regardless of training or discipline can and should be familiar.

References

  1. 1. Rowland, Claire, et al. Designing Connected Products UX for the Consumer Internet of Things. OReilly, 2015.
  2. Ashton, Kevin. “That ‘Internet of Things’ Thing.“ RFID Journal,  22 June 2009, www.rfidjournal.com/articles/view?4986. Accessed 8 Jan 2019
  3. Weiser, Mark and John Seely Brown. The Coming Age of Calm Technology, Xerox PARC, October 5, 1996. Accessed 8 Jan 2019
  4. Bell, Genevieve & Paul Dourish. Yesterday’s Tomorrows: Notes on Ubiquitous Computing’s Dominant Vision.  Springer-Verlag London 2006. https://www.ics.uci.edu/~jpd/ubicomp/BellDourish-YesterdaysTomorrows.pdf. Accessed 8 Jan 2019
  5. Buxton, W. (2001). “Less is More (More or Less)“, in P. Denning (Ed.), The Invisible Future: The seamless integration of technology in everyday life. New York: McGraw Hill, 145 – 179. Accessed 8 Jan 2019
  6. Isenberg, David S. “The Dawn of the Stupid Network” in ACM Networker 2.1, February/March 1998, pp. 24-31. Accessed 8 Jan 2019
  7. Thread Group. “What Is Thread“, www.threadgroup.org/. Accessed 8 Jan 2019
  8.  Open Connectivity Foundation (OCF).“AllJoyn.” openconnectivity.org/developer/reference-implementation/alljoyn. Accessed 8 Jan 2019
  9. The Things Network. “The Things Network“, www.thethingsnetwork.org/. Accessed 8 Jan 2019
  10. Apple Inc. “HomeKit.”  developer.apple.com/homekit/. Accessed 8 Jan 2019
  11. Google “Eddystone Format  |  Beacons”,  Google, developers.google.com/beacons/eddystone. Accessed 8 Jan 2019
  12. IEEE. “IEEE – The World’s Largest Technical Professional Organization Dedicated to Advancing Technology for the Benefit of Humanity.” IEEE – Advancing Technology for Humanity, www.ieee.org/. Accessed 8 Jan 2019
  13. Association for Computing Machinery. “Association for Computing Machinery.” www.acm.org/. Accessed 8 Jan 2019
  14. Internet Society. “Internet Society“, www.internetsociety.org. Accessed 8 Jan 2019
  15. International Telecommunication Union. Statistics, www.itu.int/en/Pages/default.aspx. Accessed 8 Jan 2019
  16. Naden, Clare. “International Organization for Standardization.” Developing Standards, 19 Dec. 2018, www.iso.org/home.html. Accessed 8 Jan 2019
  17. Philips. Philips Hue API , developers.meethue.com/. Accessed 8 Jan 2019
  18. Igoe, Tom. “Hue-Control.” GitHub, 30 May 2015, github.com/tigoe/hue-control. Accessed 8 Jan 2019
  19. AirBnB, Inc. “What are Airbnb’s rules about electronic surveillance devices in listings?” www.airbnb.com/help/article/887/what-are-airbnb-s-rules-about-electronic-surveillance-devices-in-listings.Accessed 8 Jan 2019
  20. Cooper, Alan. “Alexa, Please Kill Me Now ”.  Medium.com, 12 June 2017, medium.com/@MrAlanCooper/alexa-please-kill-me-now-eb693ce73258. Accessed 8 Jan 2019
  21. Chavez, Nicole. “Murder Charge Dropped in Amazon Echo Case.” CNN, Cable News Network, 2 Dec. 2017, www.cnn.com/2017/11/30/us/amazon-echo-arkansas-murder-case-dismissed/index.html. Accessed 8 Jan 2019
  22. Paganini, Pierluigi. “Hackers Can Remotely Control Thousands of Sonos and Bose Speakers.” Security Affairs, 1 Jan. 2018, securityaffairs.co/wordpress/67292/hacking/hacking-speakers.html. Accessed 8 Jan 2019
  23. Yubico, Inc. “YubiKey Strong Two Factor Authentication for Business and Individual Use.” 8 Jan. 2018, www.yubico.com/. Accessed 8 Jan 2019
  24. Brand, Stewart. How Buildings Learn: What Happens After They’re Built Phoenix Illustrated, 1 Oct 1995.
  25. Brand, 1995.
  26. “The FTC ‘Lighting Facts’ Label: Questions and Answers for Manufacturers.” Federal Trade Commission, 27 Dec. 2017, www.ftc.gov/tips-advice/business-center/guidance/ftc-lighting-facts-label-questions-answers-manufacturers. Accessed 8 Jan 2019
  27. European Commission. “Waste Electrical & Electronic Equipment (WEEE).”EU Environment Home, 10 Jan 2018. ec.europa.eu/environment/waste/weee/index_en.htm. Accessed 8 Jan 2019

Further References

Published in interaction design networks physical computing

Tagged in

Comments are closed.