Month: December 2016

A Very IoT Christmas

by

Opening gift after gift Christmas morning is an event. Accompanied by family and laughter, gift after gift is opened, and this year my wife, Sarah, got me an Echo Dot, a Phillips Hue starter kit (with two white Lux bulbs included), and she helped her mom and stepfather pick out a Phillips Hue Color Ambiance as well.

Surprisingly for a guy who strongly believes in the future of the Internet of Things, I really don’t have that many off-the-shelf IoT devices. I’ve cobbled together a Pebble watch app that turned on a coffee pot, but this was for fun. I have a Google OnHub, which touts it’s ability to work with IFTTT, but I’ve never really saw the value in that without other smart home devices.

So, naturally, I wanted to connect all my new, shiny IoT devices. It was painless enough, I guess, to connect everything directly with my phone. Alexa was stuttering a bit thanks to spotty WiFi at Sarah’s mom and stepfather’s place, but once I put her in the hallway it worked out alright. You have to speak up, but workable. Thanks to Christmas morning network traffic, Alexa was having trouble enabling new skills. The screen on the Alexa app on that page were blank and trying to install a new skill by voice was met with a message that it “might take a minute.” After checking back after a minute, no dice.

With Sarah’s mom, and stepfather, and brother and his new girlfriend, we tried pushing the boundaries of what she was capable of answering without any 3rd-party skills. For the record, she can successfully tell you the average weight of a kangaroo, but will say “Hm, I’m not sure what you meant by that question,” when you ask “Who played ‘Prissy’ in the movie ‘Gone with the Wind’?” For the record, the average weight of a kangaroo is about 124 pounds. With some more hits and some more misses, each hit getting the raised eyebrows of pleasant surprise, and each miss being met with a bit of laughter and some head shaking by my stepfather-in-law, I decided it was time to try to figure out how to connect Alexa to the Phillips Hue bulbs.

Minutes turned into an hour as I set up the Phillips Hue hub and configured everything. This involved me tentatively walking into my parents-in-law’s bedroom to plug it into their router, and crossing my fingers as I unplugged something else for a needed socket. Then I signed up for the Hue account and connected it all up to my phone. Terms and conditions to use your lightbulb? Waiting for an update? Pressing the button on the hub to sync with your phone? Welcome to the future, I guess.

As a software developer, and knowing we are still in the early days of smart home tech, I expected a bit of a laborious process. I wasn’t surprised, but wasn’t necessarily pleased either, thinking of all the people who would like the benefit of IoT lightbulbs but don’t necessarily want the headache of setting them up. There are reasons for each part of the system, of course. You don’t want your neighbors turning your lightbulbs on and of, hence the hub and logging into the Hue service. You need to group the bulbs so you can, say, turn off the Living Room lights all at once. But, with this capability comes configuration time. Still, mesh networks would help eliminate the proliferation of hubs, and the setup process could be a bit more magical.

Once configured, it was useful to change the color temperature from “warm” to “sunlight,” and even different colors through the Hue app. However, the coup d’etat would be to say “Alexa, start the party!” and a certain Spotify playlist would play and the lights would dance to the music. Everyone would clap, my father would finally tell me those words I’ve been longing to hear for 28 years, “Son, I’m proud of you,” and I would receive the Nobel Peace Prize. I would weep tears of joy and for one singular moment, all would be right with the world.

Unfortunately, I failed. After hours of playing around with it, the weight of the truth began to burden my shoulders: this seamless dream is currently impossible using off-the-shelf connectivity.

After hours of downloading third-party apps, hitting the button on the Hue hub each time I wanted to sync, and doing quite a bit of Googling I realized that only parts of my dreams could come true. Yes, I can turn on and off the light with Alexa, and change the brightness, and even start “scenes.” I can sync IFTTT with both Alexa and Hue and now I can say “Alexa, start the party” and the lights will slowly change colors over time. But no syncing with audio.

Some third party apps promise to sync with the audio, Ambify being the most promising. On your Mac, you can stream from any audio source and it will sync your lights to the rhythm. It’s an audio processor, it doesn’t care if you are using Spotify or iMusic or anything else. Only one problem: I don’t have a Mac. Although, even if I did that wouldn’t help with the Alexa request party.

I do have an iPhone, and some of those apps promise to “listen” to the audio to control the lights. The quality of these apps seem shady at best, with two- and three-star reviews pretty much across the board.  Hue Disco seems most likely to work, but the $3.99 barrier to entry and the lack of direct Alexa integration puts a damper on my excitement.

Through the Art of the Bodge I’m sure eventually I will put together some middleware that taps into the Hue and Spotify APIs to do something like what I want, but that’s a lot of manual steps. I’ve talked a bit about the UX of using IoT devices,  but we make a lot of progress in automation in setting them up and interacting with other devices as well. In a perfect world, I would bring home the Hues, plug them into a lamp and they would know what other Hue bulbs are around and automatically create rooms for me. It would know my phone is in the house and that it belongs to me, that the Hue bulbs belong to me, and that I can control them. They would automatically sync up to the WiFi network and authentication would be through voice or vision or some other biometrics. All the information I want to allow them to share would be shared, and that which I didn’t would not. It looks like our community of IoT creators have a lot of work on our hands as the Internet of Thing goes mainstream.

This is just the long way of saying I just want Alexa to start a party. Is that too much to ask?

‘Twas The Night Before an IoT Christmas

by
‘Twas the night before Christmas, in the automated home,
Not a device was stirring, not even one;
Google Home was set by the chimney with care,
Waiting for “Hey Google” to hang in the air;
The children were nestled all snug in their beds;
While visions of Phillips Hues danced in their heads;
And mamma with her Arduino, and I with my Pi,
On Adafruit with accessories in cart ready to buy,
When out on the lawn there arose such a clatter,
I looked at my Nest Cam to see what was the matter.
Seeing nothing, I asked Alexa in a flash,
“What’s outside, can you open the sash?”
“I’m sorry, I don’t understand…” she sweetly said,
And I realized the word “sash” was outdated and dead.
I manually opened the blinds to take a peek,
And saw a miniature sleigh shiny and sleek,
With no driver, only AI so lively and quick,
Was it a single company making it tick?
No! It was Santa, a hub controlling his tools,
Calling them by name on this evening of Yules,
“Now, Uber! now Volvo! now Mercedes and Google!
On Tesla! on, Toyota! on, Chrysler and Apple!
Get around that pedestrian and avoid that wall!
Now steer away, drive away, avoid any collision at all!
I stared as he flew, and dropped my Pi Zero,
“Wow! Level 5 Autonomy! Santa, my hero!
 Did he use networks of mesh or nets of neural?
Or AWS or Azure or another cloud cure-all?
And then, LEDs twinkling, I saw on the roof,
St. Nick disappear in a smoky electrical poof,
I unlocked my Kwikset Kevo, opened the door,
And came face-to-face with St. Nick. Score!
He was dressed in smart fabrics, from his foot to his head,
His clothes glistened with fiber optics in every thread,
A bundle of sensors he tied into his sack,
Both ancient and modern, from his front to his back,
I wondered—how did it all work? his fabric, so airy!
His systems, secure; his wireless signals didn’t vary!
His sensors were tiny! The power draw? Low!
And everything seemed lit by a magical glow;
I asked outright, “What’s your secret here, Nick,
with no screen to touch, no mouse to click?”
With a deep voice both musical and warm,
“There’s only one secret to this digital swarm,
There’s magic around us, surely you feel it,
That power and connection? It’s the Christmas Spirit!”
By a wink of his eye and a nod of his head,
I realized his meaning, though he left it unsaid.
Any technology, if it’s sufficiently advanced,
Can feel like magic and leave you entranced.
And the Christmas Spirit? I know that, too,
Working together makes IoT dreams come true,
I heard him exclaim while he flew out of sight—
“Happy Christmas to all, your future looks bright!”

Death By 1,000 Subscriptions: Figuring Out The IoT Business Model Of The Future

by

A path diverges in a wood.
― Robert Frost

The future involves a monthly bill. Microsoft is Office 365, the cloud service with the monthly or yearly fee. Adobe has completely phased out their buy-once use-forever model, favoring a $50-a-month service. Same-same with Quickbooks. TurboTax. Amazon Prime. Netflix. Spotify. Even smaller, more niche software have jumped on the SASS bandwagon. Buffer, a service I use to batch my Twitter activity, is about $10 bucks a month.

Actually, I have subscriptions to all of these services and more. I appreciate that the software evolves over time and the cost-benefit process of deciding to upgrade every year is in the past, instead I just have to decide whether I want to continue paying for the service or not. Also, I understand the proposition from a business perspective: monthly subscriptions are a much more sustainable revenue stream than the boom-or-bust cycle of big yearly releases. Get one or two bum releases and your company falls apart. Alternatively, if you lose a few subscribers from one month to the next, you have a chance to right the ship.

There are some negatives of this new world, though. In the past, one could buy a copy of software that is not so important to them and rarely upgrade – good enough was good enough, and the company got a sale. Now, especially with relatively expensive services like Adobe’s, the casual consumer is being separated away. That user that would upgrade every three or four years rather than yearly is now unable to make that choice.

As we start to connect more and more real devices to the internet, a problem begins to emerge. Those over-the-air upgrades and cloud services are not free, not by a long shot. But nickel-and-diming consumers, wrapping the weight of a new subscription around their ankles every time they add a new device to their network is unsustainable if we want to see the Internet of Things proliferate in the way the regular ol’ Internet did. Heck, all you needed to connect to the Internet was a mailbox and $9.99 a month. The magical AOL fairy would float down and leave a CD in the mailbox if you were a good boy or girl, you shoved it into the LITE-ON CD/DVD+-RW drive and after less than $10 a month, assuming you said no to all the crapware features, and you were surfin’ the web at a screaming 56 kB/s.

Today, if you want to keep a record of what the Nest Cam has been recording, you need to shell out $10 a month. For one service. Not that I blame them, like I said, keeping the lights on, upgrading the software, keeping the servers humming, and making a profit all have costs. But the monthly payment model, in my opinion, is unsustainable past a few devices. As the internet of things grows to dozens and perhaps hundreds of devices humming away in your home, their needs to be another business model. There are other ways, each with their pros and cons, that I’d like to discuss.

BYOS

That is, bring your own service. Nest Cam could, in theory, offer the software and upgrades for free and consumers could run their own copy on their own cloud provider like Microsoft Azure or Amazon AWS. The benefit for consumers would be, if they run services from many vendors on one cloud provider, there’s one cost associated with how much they spend. The benefit from Nest’s perspective would be not needing to run their own cloud services. Or, you could optionally run your own cloud. Consumer choice is good!

Why free updates? Make money from hardware sales, not restricting upgrades. Your bottom line could be affected from security breaches, which in turn could lead to recalls and PR disasters. One big negative for companies is that steady stream of revenue goes away, and another is lack of control over the servers these individuals run. How much liability do they have if a server is never patched? Questions like these have been answered, as I can run Windows Server on any server I please, but that lack of control is a consideration.

The Granddaddy of Services

Think of Spotify or Netflix here. Rather than me paying every single artist for a subscription to their songs, I am able to subscribe to a bunch of different record labels and artists all at once. The Netflix example is the same, but with movies.

A similar deal could arise with IoT. I could pay a single service, let’s call it Spotify IoT because I’m lazy with naming. In turn, they work out deals with IoT companies to measure usage and pay them a fair share of the revenue. The upside is I only have to pay one fee, and I assume Spotify IoT  would have better negotiating power than the average consumer.

The negative here is that Spotify IoT might not work with every company I want to work with (think Taylor Swift), or even if they figure out a way to work with every company providing an IoT service, they could continue to inflate the prices or not fairly compensate the many various IoT vendors.

The Services Dashboard

Instead of a granddaddy service that hides the individual cost of each child service, there could also be a dashboard that taps into the APIs of IoT companies to measure usage, report usage, and allow you a single point-of-entry to monitor and manage all the child services. In distinction from the grandaddy service, this dashboard would not obfuscate the price of each service, and in fact you would still pay each IoT company seperately (even if it was all through the Dashboard).

There would be many individual services, much like now, but you would have a much more manageable way of dealing with them. In addition, this dashboard could provide the ability to turn on and off individual features within each service to more precisely manage your spending. Don’t need that Nest storage for more than day or two? Turn off long term storage and save $3 a month.

The Fog

Fog Computing is the idea that to reduce computing idle time and reduce latency, you can use computing power from computers on your local network (or your neighbors) to off-load compute costs. In theory, you could create IoT devices that offload their compute costs to local devices and only use the cloud to get data from other fog computing devices across the world. There might not be a need for centralized servers, called the cloud, if the number of idle local devices continues to grow.

Having a fully foggy world is an unlikely scenario, however. It’s still very useful to have centralized cloud services, and that will likely remain true for decades to come. While fog computing will play a part in reducing server costs in coming years, it won’t displace cloud as king in the foreseeable future. This is a red herring.

Conclusion

As you can probably tell, there are no easy answers. The future will likely be a confusing mix of these solutions until push comes to shove. I’m counting on there being increased discrete services until SASS fatigue hits critical mass, at which point users will start to really question whether they need that next device to be internet-connected. Soon after, savvy startups will figure out a way to get hundreds of internet-connected things online while offering an attractive cost-to-benefit ratio for consumers.

 

 

 

Modularizing The Internet Of Things

by

The Internet of Things has many design considerations, and one very important tool that needs to be considered in all but the most disposable IoT devices is the idea of modularization.

You might be of the age where you remember going to work on the ol’ Buick with your dad. You handed him crescent wrenches in sizes like 5/8th and 7/16th sizes, because this is America and whole numbers are for Commies. These were good times. Sometimes your dad would swear, and scrape his knuckles, and would end up needing to wash the grease off his hands with Ajax and apologies to Mother.  Sometimes you’d take a sip of his Coors when he wasn’t looking and examine the shiny new part he was about to replace, or to your dismay, examine the jets of the carburetor he’s merely rebuilding. Shiny parts always seemed better.

If you liked shiny new things then, this is your time. Nowadays, in auto repair shops across the country, they don’t replace parts.  Parts are going the way of the middle class. No, what’s replaced now are subsystems. Or components. Or modules. And you can go ahead and full-on forget about rebuilding something.

Once the tolerances got too tight, replacing or rebuilding a single part is too expensive and error-prone for the backyard mechanic to do. And doubly so for the professionals who are paid per hour. No, if you have a bushing in your control arm go out, replace the control arm sub assembly. While that simpler time is gone where the average Joe could rebuild his Buick’s carb in his back yard, he’s traded that ease-of-maintenance for complex-but-efficient modularization.

Unfortunately, this fate has run amok in electronics. Even as few as ten years ago, phones had screws that you could use regular screwdrivers on to tear apart. Now everything is soldered and slapped together with glue, driving the iFixIt people crazy. The Samsung folks are probably looking very hard at the consequences of such thinking, thanks to the great dumpster fire that is the Galaxy Note 7.  It’s a story of burns, and smoke inhalation, and Samsung losing about $17 billion dollars in revenue.

When it comes to the Internet of Things, this cautionary tale is foreboding. What could have potentially been an easy fix via a battery replacement has now become a recall and PR nightmare. I am guessing the designers of the next Samsung devices in the pipeline will be given some requirements around being able to fix it, not just replace it.

There are many challenges to making bits and pieces of your hardware replaceable. All areas of technology are getting smaller, more integrated, and the push for thinner, lighter, more efficient lithe devices continues. Even in big devices like refrigerators and stoves and all the home automation stuff people associate with IoT, the manufacturing costs and design considerations that need to happen to make the smarts easily replaceable can be a hard sell to the marketers, the C-levels, and accountants. How do you justify the cost?Another barrier to entry is tying down standards. If you make something able to be upgraded, that means that future designs that want to take advantage of the same packaging are inherently limited in their designs.

As IoT becomes mainstream, questions will emerge when consumers are burned (hopefully only metaphorically). Is this secure? How do I upgrade the smarts of my refrigerator without replacing the whole thing? How will I keep it secure? How will I replace the broken sensor or computational unit within? If the company I bought this from goes out of business, can I still upgrade my components?

These questions are more easily answered with modularization, even if the practice is more difficult than the theory. And when those questions are on the forefront of every savvy consumer’s mind, the marketers, CEOs, and accountants will fall in line.

 

The 5 Principles of IoT UX Design

by

I had a great conversation with Jenae Ramos, UX designer and co-organizer of Orlando’s Downtown UX Meetup, talking about design and the Internet of Things. Jenae joked that designing for the screen involves many permutations of “fancy rectangles.” While that is completely selling the complexity of UX design short, I get the point. After years of  designing for screens, collectively the millions of professionals in the design community have come up with effective solutions to just about any problem that can appear in pixels. While bad user experiences still abound, and it does take professionals who know what they are doing to help shepherd the business and programming folks through the entire design process (including thinking about the user from time to time), I’m sure it can feel stale coming up with solutions within a rectangular flat plane.

Depending on what type of designer you are, thinking outside the bounds of that screen can either be scary or liberating. For the former, think of it as a field of freshly fallen snow waiting for you to make your mark. These are exciting, new frontiers that go way beyond weighing the pros and cons of a hamburger menu icon. It’s a three-dimensional world with new problems and solutions awaiting around every corner.

To get you started, I’ve outlined five of what I consider the most important UX design decisions you can make when creating a new, totally in-the-real-world Internet of Things solutions.

1. Enhance the Experience

This is the catch-all category. There are many UX design decisions that I can highlight here: don’t make the user worry about battery life, make sure the perceived performance is instantaneous, reduce cognitive load rather than add to it.

If you are trying to justify why you want to connect something to the internet, maybe you are approaching the problem the wrong way round. It can be a fun exercise to ask, “What if my coffee pot were connected to my watch,” and then to figure out why, but maybe the right question should be “How would the perfect coffee pot function?” and then start asking how connecting it to the internet might get you closer to that goal.

It’s a subtle but important difference. If connecting that coffee pot to the internet doesn’t enhance the experience, then don’t do it. I love the internet of things but would never advocate for using it if it fails to make the experience better.

2. Works Locally

No one, not even the Pope (especially not the Pope?) has internet access all the time. When designing for IoT, don’t assume always-on internet connectivity. The ideal woudl be to design for no internet connectivity at first and see how much functionality can be done locally before you need to access the internet. For example, if you are designing an umbrella that glows blue when it’s raining, include a barometer within it in case it can’t check the local weather over the internet.

As an aside, that linked umbrella was created by the writer of Enchanted Objects, David Rose. I highly recommend checking that book out.

Even if we could guarantee that the HTTP-connected present will be the protocol of the future, and we can’t, there’s the very real possibility that the servers you are running now won’t be running forever. Companies that get bought out or go under often leave connected users in the cold, and while that’s manageable when it comes to on-screen experiences, when that little computer is attached to a big device, switching vendors becomes a lot more difficult.

3. Upgradeable

The life cycles of connected devices are too long to assume that users will replace them every two years like a phone. Phone manufacturers can afford to integrate everything, knowing users will keep them for about two years and then replace them with another slab of screen. Things like washing machines and stoves have something like a 5-10 year lifespan, and even that can be extended by frugal buyers. What did your phone look like ten years ago?

Rather than stick users with outdated computing hardware permanently attached to their perfectly serviceable washing machine, good design would include the ability to easily upgrade the processing unit without affecting the rest of the device. Easily as in without tools. Modularizing the design can open possibilities of upgrade sales down the line, so win-win from a business and a consumer perspective.

This also goes for software. Provide a clear, understandable support policy. If you need an idea of what that looks like, use other software companies like Microsoft as an example. They clearly explain how long each of their products are going to be supported, and you should, too. I believe this is a user experience consideration because not knowing when service could just shut off creates anxiety in any knowledgeable consumer. As more and more IoT products end support unexpectedly, you want your users to know exactly how long they have before you stop support. This includes: when they will stop getting over-the-air-updates, when they will have to pay for phone support (if ever), what happens if your company goes under, what kind of uptime guarantee you have for internet-connected services, and what happens when support ends.

I would suggest that when support does end, the code gets open sourced and users are explicitly given permission to hack and upgrade their own devices. If you won’t support the device, give as many tools to the users to allow them to.

4. Extendable

APIs. The beautiful three-letter-word that is music to any developer’s ears. Make sure whatever you are building has one, because there are use cases for the product that you are lending your UX experience to that you have never thought about. The true power of the Internet of Things isn’t the one-to-one interactions between your device and that cloud service you manage. It’s the interactions between your device and all the other devices!

Whenever it is possible, and safe, to allow a user to connect, control, and read information from your device, make sure that can happen. Your users will thank you.

5. Secure

Is security a user experience decision? Ask any one of the users that have had their baby monitors hacked. “Hacked” is a loose term when you don’t secure your devices. What I’m trying to say is, design for security from the outset. I don’t think anyone expects user experience designers to be able to implement the latest security measures, but understand what the basics are and advocate for the user.

Conclusion

After the design process, you’ll have come up with something your users are delighted to use every day. All of the unknowns that are so prevalent in today’s technologies have answers, thanks to your efforts. They know they will be able to use it five and ten years from now, even if the company gets bought out. They know that even if the internet as we know it today is supplanted with different protocols or technologies, they will be able to upgrade and extend their experience on their terms, or just let it work locally. They have control of the experience, and while the fact that this thing is internet-connected certainly enhances the experience, it does not control it or limit it. All of these benefits, thanks to your efforts as the IoT User Experience Designer.

Internet of Things vs. Ubiquitous Computing vs. Pervasive Computing

by

What are the differences between ubiquitous computing, pervasive computing, and the Internet of Things? These terms are full of subtleties, but my simplified is simply that the Internet of Things is ubiquitous or pervasive computing in a more limited scope.

Ubiquitous and pervasive computing, which you can think of as pretty much the same thing, is the idea that computers will eventually be so small and cheap that no matter where you are computers will surround you. To get a better idea of what that world might look like, check out MIT’s Project Oxygen.

“In the future, computation will be human-centered. It will be freely available everywhere, like batteries and power sockets, or oxygen in the air we breathe.”
― MIT Project Oxygen

I’d take a small bet that you think this concept is a little absurd. Computers everywhere, like the oxygen in the air we breathe? The imagery conjured up, in my mind at least, includes silicon with heavy metals floating into our lungs. Not good.

But then again, we are not beholden to our past. I’m sure that in the 1964 when Doug Englebart famously created the prototype for the first computer mouse, even he might not have known that the world would adopt his device as one of the primary ways of interacting with computers within just a few decade’s time. In that same year, what is considered the first supercomputer appeared on the scene. The CDC 6600 had a whopping 10 MHz of CPU clock speed. To put that in perspective, it would have to be about 200 times faster to reach the speed of an average modern laptop.

The point is that the world changes. What seems insane today might be reality tomorrow. As long as human ingenuity exists, computers are still likely to get faster, smaller, and cheaper as time goes by. The death of Moore’s Law is inevitable, but with technologies like quantum computing, carbon nano-tubes, and even optical computing on the horizon, there is hope yet to keeping Moore’s Law alive in spirit by doubling the speed of computers every few years. Eventually, we may find wetware computers, or computers built from living neurons, are easy to grow and are built with environmentally-friendly and easy-to-access building blocks. The concept may be weird to us now, but in 1964 we were just getting to the end of the vacuum tube era of computing. Again, the world changes.

So why draw a distinction between IoT and Ubiquitous Computing? Aren’t they the same thing? I believe that the Internet of Things is already here, just in limited scope. We have lights that talk to thermostats that talk to the internet. The popularity of IFTTT is a decent litmus test that indicates we have enough things talking to each other than we can declare that the Internet of Things have arrived, even if the scope is not yet fully realized.

Ubiquitous computing, in contrast, means that computers are everywhere. In our walls, floors, and ceilings, in our desks and windows, in fact, they may cease to become a separate entity to be talked of at all. That’s not an internet-connected wrench, that’s just a wrench. Of course it has a computer in it, of course it talks to the internet, of course it interacts with other objects. Why wouldn’t it? Everything does. That’s just the basic nature of it, as common as paint or pigment.

That is the difference. In one reality, one that already exists, we marvel at the novelty and usefulness of our objects talking to each other. In another, more far-off reality, we take it for granted. Perhaps a small difference in writing but a huge difference in the affect on our lives. The Internet of Things is but a temporary stop on the way to ubiquitous computing.