Designing Connected Products: UX for the Consumer Internet of Things (2015)
Chapter 2. Things: The Technology of Connected Devices
BY CLAIRE ROWLAND
This chapter looks at the technology needed to create the “things” in the Internet of Things (IoT). IoT is creating an explosion in the diversity of devices connected to the Internet. We’re seeing familiar objects gain connectivity and increased computational power, as well as new categories of device that can only exist as a result of the network. Sensors and actuators create new possibilities for bridging information and actions in the real and digital worlds. But many of these devices will have to make careful use of energy and computing power. These technical constraints are the root cause of some design challenges that UX designers will encounter when working with connected devices.
This chapter introduces:
§ The different types of IoT device, and the technology they contain (see Types of Connected Device)
§ How sensors and actuators bridge the physical and digital worlds (see Bridging Physical and Digital: Sensors and Actuators)
§ The challenge of powering IoT devices and how this shapes the technology (see The Challenge of Powering Devices)
This chapter addresses the following issues:
§ How the computer hardware and software technology inside specialized embedded devices—the novel devices of the Internet of Things—differs from multipurpose computers (see Embedded Devices)
§ How objects with no onboard computing power can nonetheless have an Internet presence (see Passively Trackable Objects)
§ How sensors can be used to gather data from the physical world (see Bridging Physical and Digital: Sensors and Actuators)
§ How actuators can be used to translate digital commands into real-world actions (see Actuators)
§ Why energy conservation is at the root of many UX design constraints in IoT (see The Challenge of Powering Devices)
The focus in this chapter is on the edge devices—the end points through which the digital service interacts with the real world. There are some other types of IoT device, such as Internet gateways, which are there to provide network infrastructure so that the edge devices can connect to the Internet. See Chapter 3 for more information on gateways.
Types of Connected Device
Connected devices can take a number of forms, and are typically one of the following:
§ Multipurpose computers
§ Specialized embedded devices
§ Connected sensors
§ Passively trackable objects
Most systems will be composed of multiple types. For example, a connected home system may have:
§ A control interface on a smartphone (multipurpose computer)
§ Heating/ventilation/air conditioning (HVAC) controller, remote control door locks, and blind controllers (specialized embedded devices)
§ Security sensors such as motion and contact sensors (connected sensors)
Table 2-1 summarizes the key differences between these, which are discussed in more detail in the following sections.
Table 2-1. Summary of connected device types
Specialized Embedded Data
Passively Trackable Object
Rich onboard interaction capabilities (e.g., through screens and keyboards)
May have limited inputs/outputs; advanced interactions handled via web/mobile apps
Via web/mobile apps
Via web/mobile apps
Generalized; can run wide range of applications
Specialized for specific functions
Powerful onboard processor
Onboard processor, with some functions provided by cloud service
Mostly in cloud service
In cloud service
These are powerful computers designed to perform a variety of computing tasks. They are no longer just PCs, but also smartphones, tablets, and now arguably connected TVs, set-top boxes, and game consoles. They have rich interaction capabilities, via screens, audio, touch input, keyboards, mice, and sometimes voice and gestural interfaces, too. They contain powerful microprocessors with external chips for memory and peripheral interfaces, such as networking. We don’t think of these as belonging to the category of IoT devices, but they are often used to handle user interactions for IoT services (or sometimes as Internet gateways to devices that don’t have a built-in Internet connection).
This book does not cover general design guidelines for PCs, smartphones, tablets, or other multipurpose computing devices. These are huge topics in their own right and many good reference books have been written about them.
The falling cost of technology means that a computer is now the cheapest, simplest way to implement even trivial tasks such as timing your tooth brushing. As a result, many more of the objects around us are starting to come with onboard computation and connectivity. This creates some of the most novel and iconic devices of the Internet of Things: the thermostats, bathroom scales, and even plastic rabbits. These are all embedded devices.
Specialized to perform particular tasks, embedded devices come in a wide range of form factors to suit the task and may have other mechanical parts (such as a washing machine) or even other embedded systems as well (such as a car).
Because embedded devices are specialized to do specific jobs, they can do those jobs more reliably and more efficiently than a general-purpose computer system despite having less power. For example, an embedded computer controlling your car brakes can guarantee that it would release and activate the brakes at exactly the right intervals needed to prevent you losing control (this is an example of a real-time system). A general-purpose computer running a general-purpose operating system could perform the same function, but with no guarantees as to how long it would take. The fact that it could also be used to watch YouTube videos is of no use to you when driving on an icy road.
Mobile phones were historically considered embedded devices, as they were highly specialized devices. Modern smartphones are more like general-purpose computers in terms of what they can do for the user, as there are so many ways to extend their functionality through apps.
Embedded systems may need to meet far more stringent operating criteria than general-purpose computers, especially if they are located in inaccessible places or controlling safety-critical systems. They may need to work in harsh environmental conditions (such as down an oil well), conserve electrical power very efficiently to run for years on a tiny battery (as in an environmental sensor), run for years without errors (as in anti-lock car brakes or a nuclear reactor), and potentially recover themselves from failures when human intervention isn’t possible (as in an undersea cable). They are also often devices that we expect to set up and largely forget about, such as home boilers/furnaces, which we don’t want to have to maintain or reboot regularly. Figure 2-1, Figure 2-2, and Figure 2-3 all show examples of embedded devices.
Figure 2-1. Nest’s thermostat learns how the home’s occupants set their heating manually, uses motion and light sensors to detect when the home is occupied, and uses this data to optimize the heating schedule and settings; controls are available on the device or via a smartphone app and web service (image: Nest)
Figure 2-2. The Withings Smart Body Analyzer bathroom scales transmit weight readings over WiFi to an Internet service for users to track their weight using a smartphone app (image: Withings)
In an IoT context, embedded devices are typically the parts of the system that interact with the physical world, gathering data from it through sensors (like a motion detector) and/or producing physical actions, like a connected door lock or light switch.
Figure 2-3. The Nabaztag—one of the earliest consumer IoT devices—was a rabbit-shaped ambient device that could read out email and information from Internet services (image: Rama)
Embedded devices may have onboard user interaction capabilities, such as the Nest thermostat, which has a screen, and a bezel that can be rotated to select/scroll and pressed to select. Users can make temperature adjustments and even set schedules on the device itself. But user interactions are often handled at least in part by other devices in the system. The Tado heating controller (see Figure 2-4) has very limited onboard user input/output capabilities: most interactions are handled by a smartphone app. (See Chapter 8 for more information on interface and interaction design for embedded devices.) Note that embedded devices with no input/output capabilities will have no way of providing feedback when they develop a problem, except for ceasing to function. If this is the case, you’ll need to ensure the system can use another device (such as a web or smartphone app or SMS) to tell the user there’s something wrong and guide them to fix it.
Embedded devices may connect directly to the Internet (as the Nest controller does, over WiFi). They may connect indirectly via a smartphone (as many wearables do; see Figure 2-5) or hub/gateway device (as many home automation systems do; see Figure 2-6). Gateways, and the different ways that devices can be connected, are discussed in more detail in Chapter 3.
Figure 2-4. The Tado heating controller has limited on-device user interaction capabilities: users control the device through a smartphone app (image: Tado)
Figure 2-5. The Pebble Smartwatch connects to a smartphone to display app notifications on the wrist; it can also run apps of its own, such as displaying Evernote notes (image: Pebble)
Figure 2-6. The Hive thermostat can be remotely controlled by mobile and web apps; it connects to the Internet via a dedicated gateway device (the small device in the center; image: British Gas)
An embedded system (the computing part of the embedded device) has some basic types of hardware components in common with a general-purpose computer, such as a central processor, memory, and peripherals (although these components may be integrated onto a single chip called a microcontroller, whereas in a multipurpose computer they would often be separate parts).
Microcontrollers typically have far less computing power than multipurpose computers (often just a few KB of memory and a processor clock speed in the low MHz range) but are optimized to perform specific tasks, such as controlling the anti-lock brakes on a car or the functioning of a sewing machine, and to do so with very limited budgets of cost, power, and perhaps space.
In IoT forums, you may often hear the names of some of the common microcontrollers/systems used in prototyping and building IoT devices, such as Arduino (see Figure 2-7), Beaglebone, Electric Imp, Raspberry Pi, and ARM mBed.
Figure 2-7. Arduino is a popular range of microcontrollers used in IoT prototyping and is designed to be accessible to newcomers to hardware prototyping; this image shows an Arduino Uno used to create a color-mixing lamp (image: Daniel Cortes)
Some of these are designed to be “open” systems: using open source software and hardware. You are given working examples to help you get going, but you can modify these right down to the bare metal if you want. Others (such as Electric Imp) are “closed”—they work out of the box but don’t give you access to their internal workings. They may be easier to use, but you can’t modify them.
Software for embedded systems is designed to make efficient use of limited resources. A simple device may have only a small, fixed-function program (firmware), just enough to make the system work. This is stored in nonvolatile memory (memory that is not lost when the device is not powered) such as Flash or ROM. If you want to change the way the device works, you need to overwrite the firmware (see Figure 2-8). (Flash can be overwritten but ROM cannot, so some devices may have firmware that cannot be upgraded.)
Figure 2-8. Some Whirlpool laundry appliances featured USB ports to enable users to upgrade the firmware and add new wash programs (image: Whirlpool)
A more complex device may have a specialist embedded operating system and be able to run multiple programs, as desktop operating systems are used to run applications. For example, an OS can manage access to system resources, like the processor or network, if different applications may require them at the same time. An OS also provides flexibility to change the functionality of the device without reinstalling all the software. Real-time operating systems, such as VxWorks, QNX, and RTLinux, are used where time-sensitive processing is needed. Many types of system may require real-time OSes, from spacecraft to robots to WiFi access points (see Figure 2-9). There are even versions of general operating systems specialized for embedded devices, such as Windows Embedded and various flavors of Linux. Operating systems generally require more CPU and electrical power to run than firmware.
Figure 2-9. NASA’s Mars Science Laboratory Curiosity Rover uses the VxWorks real-time operating system, as does Apple’s Airport Extreme (images: NASA/JPL-Caltech/Malin Space Science Systems, Apple)
Connected sensors are small embedded devices used for capturing data from the physical world, and passing this to a networked service. Although technically a class of embedded device, they tend to be used and experienced in a different way as part of the Internet of Things. They generally have no onboard user input or output capabilities. So there are no knobs or pushbuttons, and the only way to know what they are doing is via a display on another device, like a smartphone. Sensors tend to be quite low profile, so the devices themselves are often less visible and less salient parts of the experience. The focus of the UX is not on the devices, but on the data that is captured and the service that the data enables (see Figure 2-10).
Figure 2-10. The NetAtmo Weather Station sensors measure temperature, humidity, air quality, and atmospheric pressure; there are no onboard user interaction capabilities on the sensors, but data can be viewed via smartphone or web apps (image: NetAtmo)
They are often deployed in networks of multiple sensors (in which they may be called “sensor nodes”). A large-scale example such as a network of air quality sensors may have hundreds or thousands of nodes; a smaller-scale example might be a set of home alarm motion/contact sensors. Single sensors may also be practical in some circumstances, such as the Proteus in-body pill sensor (see the Proteus case study in between Chapter 3 and Chapter 4), which can be used to detect whether a patient is taking their medication. Bridging Physical and Digital: Sensors and Actuators discusses sensor types in more detail.
A connected sensor typically contains just enough onboard computing to gather data and transmit it over a network. This is likely to mean a very basic processing unit with very limited memory and computing power, a communication transceiver, and a battery or other power source (e.g., energy harvesting from the environment, such as solar or wind power). Communications may be a low-powered wireless local area network (WLAN) connection to a gateway, or a high-powered connection to the Internet via the cellular network. It will generally have no on-device user interface (a home alarm sensor might have an LED to indicate when it is functioning and/or connected to the network). It may be possible to pass simple instructions to the sensor over the network (e.g., to control how frequently readings are sent), or the sensor may only be capable of pushing data to the network and may not be able to receive instructions (see Figure 2-11).
Figure 2-11. The Proteus smart pill contains a tiny sensor—it has no battery, but is activated by contact with stomach acid, sending a small transmission to a Bluetooth-enabled skin patch, which in turn connects to a mobile phone and notifies relatives or doctors via an Internet service that a pill was taken (image: Proteus Health)
Energy is a particularly precious resource for most sensor nodes and must be conserved as much as possible (see The Challenge of Powering Devices later in this chapter for more detail).
Where sensors are deployed in networks, the networks are designed so that the whole network continues to function even if individual nodes fail, or lose connectivity, though data may be lost. A UX design for any IoT system must be able to cope with missing data points. For example, a system that uses sensors to monitor the movement of traffic on a road does not need every data point in order to calculate the speed at which traffic is moving. (See Chapter 13 for more on designing with data.)
Passively Trackable Objects
A “thing” can have a simple presence on the Internet without actually having an Internet connection. Passively trackable objects have a unique identity that is associated with information about them online, but are not themselves connected to the Internet.
RFID and NFC
Simple objects, which need not have any onboard computing at all, can be identified via radio-frequency identification (RFID) or a quick response (QR) code. This unique ID allows the user to access information about the object online.
In terms of data storage, there are two types of RFID:
Read-only RFID tags
These tags have just enough storage for a unique identifying number, which is associated with more detailed product information in a database, probably on the Internet. If you want to change any of the product information, you’ll have to do so in the database, as you can’t overwrite the data on the tag (see Figure 2-12).
These can be overwritten with changing information, so you don’t necessarily require Internet access to retrieve meaningful information from the tag.
RFID tags can operate on different radio frequencies. Higher-frequency tags are capable of transmitting over a longer range, lower-frequency tags transmit over a shorter range. A shorter range is preferable when the tag should be read as the result of an explicit user interaction, such as swiping a smart card or scanning a product label (see Figure 2-13). You don’t want to read the same tag twice, or accidentally read another nearby tag instead. A longer range might be more suited to tracking a number of items over a larger area.
RFID is commonly used in inventory management, to track stock levels in stores and at suppliers. For example, the UK department store Marks and Spencer was an early pioneer of RFID for inventory tracking, using it to keep track of the numbers of each item in each store with the aim of matching supply to customer demand.
Figure 2-12. A read-only RFID tag of the type used in pet ID chips (image: Wikipedia user Light_Warrior)
Figure 2-13. The London Oyster travelcard uses short-range read/write RFID to store local information about the cash or tickets stored on the card
RFID is also commonly used for contactless ticketing and payments, such as debit and credit cards. Disney theme parks issue RFID tickets and wristbands, which visitors swipe to gain access to attractions (see Figure 2-14). The tickets can store data about prebooked attractions and track the movement of visitors around the parks, helping Disney better understand visitor behavior.
Figure 2-14. The Disney MagicBand wristband, which provides access to attractions and can be used to pay for purchases in the park, helps Disney better understand visitor behavior (image: Ciara Taylor)
Near field communication (NFC) uses the same standard as some shorter-range RFID tags, but evolves it. An NFC-enabled device (e.g., a smartphone) can behave both like an RFID tag (and be read by a reader) or like a reader. RFID uses many different data formats, so different RFID devices cannot necessarily interoperate. A key advantage of NFC is that it provides a single common data format—the NFC Data Exchange Format, or NDEF—which can allow all kinds of NFC-enabled devices and tags to share data.
NFC-enabled smartphones are often used for contactless payments from mobile devices. NFC permits two-way communication between devices, and a potentially interesting application for IoT is in making it easier to set up network connections between other devices. Android Beam uses NFC to streamline the process of setting up a temporary Bluetooth connection between two devices to share data such as a photo or contact (see Figure 2-15). (See Chapter 12 for more details on this.)
Figure 2-15. Samsung S Beam uses NFC to establish WiFi connections between smartphones (image: Samsung)
QR codes are a very basic way to give a physical device a digital identity. These are two-dimensional barcodes, which can be read by any imaging device able to extract the data encoded in the image, such as a smartphone. Like read-only RFID tags, QR codes rely on the code being mapped to more extensive product information in a database.
An example of QR codes used in a consumer setting is the +More platform created by the UK agency Evrythng for the Diageo drinks company (see Figure 2-16). This assigns each bottle of spirits a unique identifier, which can be accessed by scanning a QR code printed on the label. A Father’s Day marketing campaign encouraged customers to buy whisky bottles as gifts, scanning the QR code to record a personalized video message, which the recipient could then in turn access by scanning the code.
Figure 2-16. The Diageo whisky gifting campaign allowed customers to send a personal video message with each bottle; each bottle is identified with a unique QR code, and scanning the code plays the video (image: EVRYTHING)
Beacons (such as Apple iBeacons) are another type of passively trackable object. They are used to provide very precise location information. Beacons use Bluetooth Low Energy to broadcast a unique ID that can be received by nearby Bluetooth-enabled devices, such as smartphones (Chapter 3 discusses Bluetooth in more detail). The phone looks up the beacon’s ID in an online database, which provides information such as who owns the beacon, and exactly where it is. The strength of the radio signal between the beacon and phone helps determine how far the phone is from the beacon. Beacon-enabled apps on the phone can then use that information to provide contextually relevant functions. For example, entering a favorite department store might trigger the loyalty app on your phone to notify you of a special offer or discount voucher (see Figure 2-17). Passing a beacon in the cleaning products aisle of the grocery store might trigger a shopping list app to remind you to pick up dishwasher detergent. Or a beacon in your car might trigger your phone to bring up the option to unlock the car. (More examples of beacon-enabled services are discussed in Chapter 4.)
A variant on the beacon concept is Google’s Physical Web project. Led by designer Scott Jenson, this experimental project aims to bring interaction on demand to the physical world, without requiring the user to have particular apps installed on their mobile device. Instead of broadcasting a simple ID that must be looked up, or needing to trigger an app, Physical Web beacons broadcast a web address. Users need not download a dedicated application but can just walk up to any device and interact with it via their phone’s browser. As the project’s web page cites, bus stops could share information about arrivals, parking meters and vending machines could all be paid for in the same way (see Figure 2-18), and rental cars could broadcast a sign-up page, allowing users to sign up and drive away quickly.
Figure 2-17. An Estimote beacon triggering a smartphone app to display a special offer (image: Estimote)
Figure 2-18. A Physical Web device broadcasts the web address through which the user can access its information or controls
Bridging Physical and Digital: Sensors and Actuators
Sensors and actuators are the device components that bridge the Internet and the physical world. Sensors convert energy readings from the physical environment into numeric values that can be transmitted digitally. Actuators convert digital instructions into mechanical actions. (See Figure 2-19.)
Sensors receive inputs from the physical world (e.g., motion, light, air quality, contact, location, proximity, humidity, orientation, etc.). They detect the presence of energy or changes in energy and quantify it, producing a numeric value. A digital thermometer usually converts heat energy to a voltage, and then quantifies the voltage as a temperature reading. Similarly, a photosensor might convert light energy to a voltage then output a numeric reading.
Figure 2-19. Sensors convert readings from the physical environment into digital information; actuators convert digital instructions into mechanical actions
Sensors can be active or passive. Active sensors inject energy into the environment to detect changes of some sort (see Figure 2-20); passive sensors detect energy that is already there. The motion detection systems used in stores (or to protect priceless museum exhibits in heist movies) use beams of light shone across a room at photosensors: when something (such as a robber) breaks the beam, the sensor measures the loss of light.
Figure 2-20. The Samsung Galaxy S5 has an active sensor that can be used to measure heart rate; it fires a red light through the user’s finger, using changes in light level to measure changes in blood flow that indicate a pulse (image: Samsung)
Motion detectors used in home security alarms (such as Figure 2-21) tend to be passive infrared sensors: human beings radiate infrared energy with a wavelength of around 9–10 micrometers, so alarm sensors are tuned to respond to rapid changes on this wavelength that indicate a person moving around. (Slower changes might simply mean that the room is warming up as the sun moves around.)
Figure 2-21. The Dropcam connected camera contains a passive infrared sensor to detect motion (image: Dropcam)
Some sensors measure the presence of chemicals. An air quality sensor might measure harmful volatile organic compounds (VOCs), such as benzene from car exhaust, by detecting changes in conductivity caused by the chemicals reacting with the surface of the sensor.
Location sensing is commonly used in applications for mobile devices. A GPS receiver calculates its position by timing transmissions received from GPS satellites (see Figure 2-22). The tiny compasses found in mobile phones use magnetic field sensing to tell which direction is north. Bluetooth beacons, described earlier, can be used to enable indoor location detection based on the proximity and signal strength of the beacons.
Figure 2-22. Tractive pet trackers track the location of your cat or dog using GPS (images: Tractive)
Accelerometers measure acceleration based on vibration (see Figure 2-23). They are often used in mobile phones and tablets to detect screen orientation and present the UI in landscape or portrait mode. Some alarm clocks use accelerometers to identify the best time to wake the user. The clock is placed on the mattress and detects differences in the sleeper’s movement during different sleep phases, waking them during light sleep. Gyroscopes measure angular acceleration (rotation around an axis), and can be used for more accurate movement measurement than an accelerometer alone.
Figure 2-23. The Wii Remote uses an accelerometer to detect rotation; the WiiMotionPlus (the attachment on the bottom) adds a gyroscope for more accurate movement detection—this is used in many sports games and for more “realistic” sword fighting in “The Legend of Zelda: Skyward Sword” (images: Nintendo and Evan Amos)
Sensors are increasingly found not just in networked embedded devices, but also in mobile devices. There are many applications (such as activity tracking) that formerly required a separate sensor but can now be achieved using a smartphone’s onboard sensors (see Figure 2-24). However, a dedicated sensor (such as a wearable tracker) may be more accurate or a better fit for the context of use (e.g., a phone carried in a handbag may move differently from a phone carried in a pocket as the user walks).
Figure 2-24. The Withings iPhone app can now track the user’s steps using the iPhone’s onboard accelerometer; however, Withings still makes dedicated activity trackers, such as the Activité (image: Withings)
Actuators provide the means for a digital system to act on the environment. They convert electrical energy into mechanical energy, producing movement in the real world. This might control a motor, or simply turn something on or off. Connected door locks (see Figure 2-25), ceiling fans, and window shade motors (see Figure 2-26) are all examples of consumer actuators. Even bubble machines have been used as actuators (see Figure 2-27).
Figure 2-25. The Danalock connected door lock allows users to lock and unlock a door from a smartphone (image: Danalock)
Figure 2-26. The Fortrezz water shutoff valve can be programmed and controlled remotely via a home automation app (image: Fortrezz)
Figure 2-27. The Bubblino Internet-connected bubble machine is a fun example of actuation: it watches Twitter and turns on the machine to blow bubbles when it sees a particular hashtag (which the user can define; image: Adrian McEwen)
The Challenge of Powering Devices
One of the key considerations in the technical design of a connected device is how it gets, and uses, power. This can have a fundamental impact on the functionality of the system and the user experience.
Conserving Battery Life
Many embedded devices and connected sensors run on batteries. This may be because:
§ They need to be portable
§ They need to work where mains power is not available (e.g., outdoors or underwater)
§ It makes them easier to install (avoiding the need to rip holes in your walls or call out an electrician)
§ It’s not safe to run mains power to their location (e.g., the device that takes readings from smart gas meters runs on a battery, as it’s not safe to run a power line near a gas pipe)
Many sensors are small, so will have only tiny batteries, capable of holding limited energy. As mentioned earlier, some devices may run on energy harvesting from the environment, such as solar or wind power, but this can be unreliable (it’s not always sunny or windy). A few may be able to generate enough power from a user interaction—for example, pressing a switch could generate a tiny amount of power from a piezo crystal that might be enough for a tiny data transmission (see Figure 2-28).
Figure 2-28. The Philips Hue Tap light switch is powered by kinetic energy generated when the switch is pressed (image: Philips)
Many embedded devices and sensors are background devices: things we want to set up and think about as little as possible. Some of them may be in hard-to-reach places, and if we have any number of them, we don’t want to be thinking about charging or battery changing any more often than we have to. If you have a battery-powered smoke alarm, you don’t want to be changing the battery more than once every year or two. In some cases, it may be extremely difficult to reach the device to change the battery, such as an internal pacemaker monitoring the vital signs of a patient with a chronic heart condition.
Processing data and connecting to networks drains energy, so devices that need to conserve energy need to do as little processing and as little talking to the network as possible. Embedded software is often programmed such that the device spends as much time as possible in a sleep or low power mode, waking up the processor only occasionally when it needs to do something (see Figure 2-29). For example, a radiation sensor might take readings in low power mode and wake up to send them at regular intervals, or it might wake up and connect to the network more frequently when the sensor reads over a certain threshold. Maintaining a constant connection uses a lot of power, so is best reserved for mains-powered devices.
This need for energy conservation is the main reason why many edge devices—embedded devices and sensors—are not directly connected to the Internet. Internet connectivity, such as cellular data and WiFi, requires a lot of power. Local, lower-bandwidth networks such as Bluetooth LE and ZigBee use much less. There are also a number of communication patterns and protocols that can be used to manage network connections, and (to an extent) help to control power consumption. These are described in the Types of Network and Network Communication Patterns sections in the following chapter.
Figure 2-29. The Lowes Iris home security motion sensor transmits its status at two-minute intervals as long as there is no motion; if it detects motion, it will wake up and transmit this information right away (image: Lowes)
Powering Devices Creates UX Challenges
UX designers don’t normally have to concern themselves with the electricity consumption of devices. But, in IoT, the secondary effects of trying to conserve energy consumption ripple all the way up to the UI level.
Devices often connect only intermittently. That means that communications are essentially asynchronous: it may take time for a message to reach all the devices in a system. Some data may be out of date or missing, and in some cases, different devices will give you different information about the status of the system. Whether and how much this matters depends on the type of service you’re building. (For more information on networking and continuity, see Chapter 3 and Continuity in Chapter 9.)
Power consumption is often at the root of some of the responsiveness challenges that IoT services pose for UX designers: intermittent connectivity and asynchronous communications (see Networking Issues That Cause UX Challenges for IoT in Chapter 3 for more details).
Edge devices are the things in the Internet of Things.
Many IoT devices are embedded devices: custom hardware and software specialized to perform a specific function. Connected sensors are a type of small embedded device, often deployed as part of sensor networks.
Sensors and actuators are the bridges between the Internet and the physical world. Sensors convert energy readings from the physical environment into numeric values that can be transmitted digitally. Actuators convert digital instructions into mechanical actions.
Embedded devices and sensors often have limited computational power and many run on batteries, so must make efficient use of processing and electricity. Maintaining a network connection requires a lot of energy, so many IoT devices only connect to the network intermittently. This can cause discontinuities in the user experience, where instructions take time to reach edge devices or some parts of the system may have more up-to-date information than others.
 This classification was inspired by Scott Jenson’s article “Of Bears, Bats, and Bees: Making Sense of the Internet of Things,” Frog’s Design Mind, August 2012, http://bit.ly/195mVm4.
 In technology terms, these are really just specialized embedded devices. But as we explain in Connected Sensors, they are likely to play a different role in the user’s experience of the product or service.