The Internet of Things (or IoT) is finally going mainstream. Not only do I read about it frequently online, but I’m now talking about it with clients at frog. Unfortunately, as it has become popular, it has also grown to the point where it can span everything from home Wi-Fi networks to smart cities. Much like the story of the three blind men describing an elephant, the essence of IoT depends on your point of view.
What we need is a simple breakdown, both physically and functionally, so we can discuss the many facets and challenges ahead. The simplest is to start by device category as there is a huge range of devices that can be thought of as being part of the Internet of Things. Fortunately, there are really only three broad physical categories: Bears, Bats, and Bees.
Bears are the big boys, the classic computers with big screens, user-visible operating systems, and many applications to install, launch, organize, and delete. These devices are the classic beneficiary of Moore’s Law: getting faster and more capable each year. Bears aren’t limited to just laptops but include mobile phones, tablets, and even smart TVs. Any device that is multipurpose and primarily driven by a user’s direct interaction is a bear.
To be fair, bears historically have not been a part of the IoT conversation as they are so big and expensive. However, bears are still the dominant computation device: they are our gateway into interactive devices. It’s not uncommon for some homes to be filled with a dozen bear devices, and they are starting to communicate and chatter among themselves. Of course, they’ve done that for years with simple home networks and web surfing; but both of these are, for the most part, about sharing files. Whether you are pushing a file to a printer, pulling a page from a website, or copying a photo to a server, it’s a fairly file-driven process.
What is new with bears is that they are forming into ecosystems or clans, if I can stretch the metaphor. (Technically a group of bears is a sleuth, but I can’t use that with a straight face...) For example, some consumers are now going "all Mac" by purchasing a MacBook, an iPad, an iPhone, and an AppleTV, because they just work better together. It’s not only about files any more but awareness (AirDrop), shared web services (iTunes, and iCloud), and video/audio streaming (AirPlay). Apple has built a series of proprietary protocols that go beyond the standards of the Internet.
But there are other bears out there: Microsoft, Amazon, Google, and Samsung. They are all building their own suites of services, creating their own clans and trying very hard to crowd out the other bears. Of course, innovation almost always occurs along proprietary lines. It is sometimes necessary for companies to experiment and not be hamstrung by standards and push the boundaries of what is possible.
But will it ever converge? Remember that email was once a series of incompatible islands until it standardized around the SMTP protocol, uniting everyone and creating a significantly larger opportunity. Unfortunately, bears are unlikely to play nice. They want to try a winner take all game and, at least in the short run, will shun any attempts to create a greater shared standard. I chose the term “bear” carefully. Bears are not only territorial but also very big and very grumpy.
Bats, on the other hand, are small and nimble. They eschew the grand multi-purpose functionality of bears and try to do just one thing well. They are still a bit experimental; but devices like the Nest controller, the Withings bathroom scale, or the Glowcaps medicine bottle are all good examples. What defines a bat is its need to be found (usually wirelessly) and interacted with (usually through mobile apps). They don’t care about fairly high-end bear-ish needs of file transfers or video streaming.
Right now these bats are, contrary to the metaphor, a bit solitary, each acting as a standalone device, usually storing information in their own siloed cloud. They are not using “the cloud” but rather “their cloud,” creating a cluttered sky of incompatible data. There will clearly be a need for bats to cluster around a shared cloud storage model. That, unfortunately feels a bit utopian as there are no clear standards to store this type of data in a uniform, sharable way. It’s also a bit out of scope for this article, but it seems inevitable that if a shared data platform existed, it would attract a wide range of bat devices.
Bats are what prompted me to write my “Mobile Apps Must Die ” blog post as their app-for-every-bat approach just isn’t sustainable. As we get more and more bats in the world, the user overhead of app maintenance is going to break down. This is the primary difference between bears and bats: bears carry their interaction within them as they can afford big screens and pointing devices. Bats, being small and inexpensive, need to have it added on by another device.
But we’re not quite done with bats as there is a new form of bat that sheds their solitary outlook, creating a proper swarm of bat-ish devices. This is the “smart home” concept: filled with smart lamps, heating systems, door locks, stereo systems, and video cameras that all work in concert. For example, when I open the door, the lights go on. This raises an entirely different need for bats: the ability to coordinate.
This is a nascent field. Very few products exist now, and those that do are copying bears’ proprietary behavior: they are creating proprietary protocols and custom applications to accomplish this coordination.
Again, innovation and experimentation must take place. I don’t begrudge any company for trying to create their own space. However, proprietary lock-in is so self-defeating in ecosystems like this. There is no way any single company can build every possible smart device for a home. The lessons from the Internet are so easily forgotten: you need to have an open "plumbing system" that allows everyone to play. Proprietary products can be built on top of that, but the more plumbing that is shared, the bigger the pie becomes.
This point is driven home when I discuss my Just-In-Time interaction concept: some feel that my "discover and interaction" model is too simple; it can’t handle the coordination that a swarm of bats needs. But this concern teases out a key point: when talking about the IoT, people immediately jump to coordinated swarms of devices. That is a mistake. The IoT demands a layered solution, exactly like the Internet. We must first have an open means of discovering every device. Second, we need to be able to interact with each one, openly and across any platform. Third, through RESTful API calls, devices can discover and use each other's functionality. Finally, and only then, can we build services that tie them all together. It’s not rocket science; it’s just the tried and true lessons we’ve learned from the Internet, but this time applied to physical devices, not servers.
Bees are completely different. They are tiny things that only really have power in swarms. There will likely be many types of bees, but I'll discuss three here. The first is what I’d call a “worker bee” which is a wireless sensor, usually put in factories to monitor production. This is often referred to as M2M or machine-to-machine, and while this is a huge industrial movement, it’s not frequently discussed in the design community. This type of bee works in swarms as entire systems of sensors are hooked up to monitor large factory processes and can have huge improvements in production monitoring and quality. Even though this is very big business, this crowd has realized the value of open industry standards. Fortunately, not everyone behaves like a bear.
Another type of bee, a “production bee” is any box or package that can be tracked. These objects don’t have any computation within them; they just use tagging technology such as NFC, RFID or even barcodes. These devices, by being both unique and trackable, gain a form of virtual computation. Each time a bee device is scanned, cloud storage is updated so it can have some data added to the cloud. Production bees are really a merging of a real life object and a virtual cloud computer.
Production bees are nothing more than trackable objects that collect data such as where they were made, how they were transported, what temperature they were held at, and when they were used. This was first proposed by Bruce Sterling, in his concept of “ Spimes.” Spimes are objects in space and time. It’s not as much about the object, but its journey: Where has it been and what has it encountered? It collects data like a bee collects pollen, hence this category name. The purpose of spimes is to revolutionize the production process, providing a more efficient and sustainable world economy.
The production bee doesn’t really want you to notice it, it’s just a bag of frozen garlic bread that has a secret history: it is part of an invisible system that works in the background. But there is a final bee type, an "interactive bee," that is its big brother.
An interactive bee is capable of everything the production bee does but adds interactivity. When I plop that frozen garlic bread on an interactive kitchen table in the near future, a digital window flies out on that surface next to the bread. It’s a webpage on demand within my environment. As interactive surfaces spread throughout my life interactive bees can leap onto them. In the case of garlic bread, it would show not only nutrition information, but also offer a video demonstration of how easy it is to use its “easy open packaging.” Interactive bees clearly could be over the top and must be user driven, but proper use provides a huge extension of the overall customer experience into any physical device. Now using an interactive table is clearly a bit futuristic, but I could have also used Google’s Project Glass goggles instead or if you insist, my mobile phone.
But interactive bees can go beyond even tagged objects. Anything physically stationary, like a bus stop, a tree, or even a statue in a museum can be geo-tagged and gain the same benefits. But instead of walking up to the bus stop and discovering where it was made, I instead find out when the next bus is coming. Similarly, everything in a museum becomes interactive, and parks have a clear history of everything done to their trees. Bees allow any physical object to become a hyperlink into an interactive world.
The Internet of Things is a growing, changing meme. Originally it was meant to invoke a giant swarm of cheap computation across the globe but recently has been morphing and blending, even insinuating, into established product concepts.
Bears are the old guard of computation but are assimilating much of the communication attributes of IoT. Bats are an entirely new category of devices, starting off as solo beasts but slowly, haltingly, turning into an interoperable swarm. Bees on the other hand, are a fascinating flip on the entire problem, virtualizing even the computation within each device.
What is clear from this exploration is that the old school capitalism of monopoly economics is not going to see us through. If every company wants to act like a bear, they win in the short run, but we all lose in the long run. We need to remember that the web is not the internet. The web tends to think in terms of winner take all systems like Facebook. The internet, on the other hand, was a fairly humble and simple means of discovery and access: the plumbing of the digital world that allowed the web, and eventually Facebook, to be built. We have to start thinking in layers. It’s perfectly fine if the very top layers are proprietary; that is not the problem. It’s when companies try to own every layer that things go wrong. We have to break up the concept of the internet of things from a proprietary play into a shared play: one where everyone can enter the playground. If we don’t get our head around this, we’ll be spending the next decade spinning from one tiny playground to the next.
Thanks to @stephanierieger for an early review of this post.
As frog's Creative Director, Scott Jenson was the first member of the User Interface group at Apple in the late 80s, working on System 7, the Apple Human Interface guidelines and the Newton. After that, he was a freelance design consultant for many years, then director of product design for Symbian, and finally managed the mobile UX group at Google. You can follow frog Creative Director Scott Jenson on Twitter @scottjenson.