Orange Cone

This is an outline of a project that I've had on the drawing board for years, and it looks like I'm not going to actually instantiate it, so I decided today (after being prompted by a foo camp mailing list thread) to say screw it and give the idea out to the world, for better or for worse.

The core of my idea is this: that where ethernet-over-power (also known as Powerline, or HomePlug) is useful is for communication with and control of household devices. I've ranted for a long time that there isn't a good appliance communication protocol, but what I've come to realize is that it's not that there isn't a good protocol, but that all the so-called standards that try to solve smart device communications try to reinvent every layer at once. That's shortsighted, because it ends up with mass incompatibilities at all levels, so there is no agreement between device manufacturers at any level, and all of the consortia are just mini-trusts trying to get vendor lock-in so that they can be the sole suppliers of the technology. It's big companies trying to get vertically-integrated vendor lock-in and failing.

Look, folks, we have all of the pieces and we don't have to create any new standards. Here's how I see it:

1. Wifi is great for moderately high-speed general-purpose communication to easily-movable end-user devices (and I don't mean just "portable," since this includes things like printers and set-top boxes).
2. Cat6 is good for very high-speed communications between devices that don't move.
3. Bluetooth, zigbee, z-wave, and all of the other short-haul, low-power, low-bandwidth wireless standards are good for movable devices that need highly near-range communication.
4. Ethernet-over-power is good for low-speed communication to static devices.

I'm intentionally conflating the fact that these standards cover different layers of the OSI standard because my point is that we can just run completely standard communication protocols like TCP/IP and UDB over each of these lower-level media and build on that, rather than creating completely new end-to-end standards. If one of the low-level protocols doesn't work for an application for some technical reason, then it should be changed, not the upper-level protocols. That's the whole point of the model.

Anyway, I digress. My point here is to discuss a specific application for Ethernet-over-power. I've been enamored with this technology for a while, but it's struggled in the market by trying to compete with Wifi and failing. The lack of a wire, even if it's a power cable, will always beat out the wire. This competition has lead e-o-p's developers to continue to pour money into making it faster, rather than making the technology cheaper. This has limited its use to a small niche of people for whom neither Wifi nor Cat6 Ethernet works. That's essentially like saying "We're going to make cars for people who like cars that are neither fast, nor capacious, nor cheap." Sure, you'll find some niche, but it's not going to be big.

I feel that the big niche in smart household device communication. Essentially, optional low-bandwidth communication between devices that are already going to be plugged in that helps them work together, but doesn't form the core of their functionality.

Let me give you an example:

1. You subscribe your e-o-p-enabled DSL modem to an electricity price service. It gets spot prices every 15 minutes or so from one of the realtime electricity price services.
   
2. It then broadcasts that information as TCP/IP broadcast packets over the local e-o-p network.
   
3. Lights throughout the house/workplace are equipped with a digital dimmer that is listening to power price packets.
   
4. When the price goes over some value (which could be set once a day through a slightly different kind of broadcast packet) the lights go into power-saving mode and dim.
   

The lamps do not have to be sophisticated Internet-capable devices. They only have to know about a couple of different kinds of packets and to ignore all the other packets, which could be anything from digital picture frames downloading RSS image from the Internet at large, to appliances listening for "what time is it" packets that synchronize all clocks.

The technology all exists. All of it. And I'm sure it's already possible to make it cheap enough that it adds $1 or so to the price of devices at the low end. These devices do not have to be sold in special configurations that only work if you buy a single company's (or consortium's) products, they can just be sold as what they are: lamps, microwaves, picture frames, clocks, etc. The functionality only needs to come into play if you want it, and it device works as advertised whether there are any other devices on the house network or not.

The core value is that this solution creates a market justification for developing inexpensive devices that have the capability of augmented functionality, without requiring that functionality to take center stage in terms of what the devices do. This, I believe, makes the adoption of these devices by consumers more likely, and therefore the further development of such technology, and therefore the network effects that everyone wants. Until people start using the open standards that are already available, they will forever be stuck on lonely, unprofitable islands of proprietary standards, even ones that are touted as open.

[12/31/08 update: I just learned that this is called demand response in the energy business. So I guess what I'm advocating for is technologies for the development of small-scale demand response systems using ethernet-over-power broadcasts of energy pricing information.]

Posted by at 2:57 PM | Permalink | Digg this | Tag this in del.icio.us

I was one of the international keynote presenters at this year's Dansk IT Usability and Design conference. I would first like to thank them for the invitation: it was a pleasure to spend a couple of days in Copenhagen and an honor to present to such a distinguished organization (they're an IT organization that just turned FIFTY!).

In my presentation I rolled up a bunch of my ideas from the last six months and added some examples of some new projects (such as Disney/TechnoSource's Clickables-PixieHollow product line) and I talked about the iPhone's applianceness.

You can download the presentation (792K PDF) with extensive notes.

The gist of this keynote, as with many of the presentations I've been giving over the last six months, is that a combination of ubiquitous computing, wireless networking and item-level identification is changing the nature of people's relationship to everyday objects. This change, in turn, creates a number of deep user experience design challenges as objects become intertwined with services and as computation becomes a more ingrained part of how the object is designed. In other words, objects that we find familiar now dematerialize into services, while abstract ideas that had been services before materialize as new, and unfamiliar, appliances. This crossover is pretty alien and implies a rethinking of relationships and design processes.

I'm still working on the practical implications that these big ideas boil down to, but I'm beginning to see the outline of what it implies for the world in which design is going to happen for the next 5-10 years.

Posted by at 7:10 PM | Permalink | Digg this | Tag this in del.icio.us

I recently lamented in Twitter that my blog posting has become shovelware from my presentations. That mostly shows how busy I am--which is actually good--but it's also a shame, since I like having the time to use this as the public notebook it's supposed to be. However, even though I don't have time to update the blog as often I would like, I realized that I'm still generating content that's not in formal presentation or book form. It just (as Paul Boutin recently noted in Wired) just happens in different channels. Here's two more pieces of shovelware, one from a familiar source (a talk I gave at UC Berkeley's School of Information) and one from a different source.

Materials that dematerialize

(image CC by Only Sequel)

In what's becoming a ThingM tradition, I spoke last Thursday at Prof. Kimiko Ryokai's Tangible Interfaces class at UC Berkeley. Tod spoke to the same class last school year. My presentation was called Materials that Dematerialize ( 740K PDF) and it brought together several high-level thoughts I've had recently about how the social effects of ubiquitous computing and Internet of Things technologies create challenges for experience designers. Specifically, it brings together the themes of "information processing as a material" and "information shadows that turn everyday objects into services" that I've recently been thinking about.

Cloud computing, ubicomp, service design, interaction design

Here's a discussion that I had with Tom Igoe and Brian Slesinsky on Facebook in response to another Twitter post I had made (you can find the original here).

Mike Kuniavsky at 6:02pm November 10
A thought: service design is what links cloud computing and ubicomp. It meets industrial/interaction design at the device/service interface.

Tom Igoe at 6:14pm November 10
How exactly does cloud computing differ from the web?

Mike Kuniavsky at 6:20pm November 10
There's terminology slippage, for sure. You could also ask how the Web is different from the 'Net. I think it's a question of where the data lives and whether devices are expected to be the homes of data, or whether data primarily lives in centralized services that live on the Net and are exposed and manipulated by a variety of devices, some of which are physical, some of which live on the Web or other distribution mechanisms. I agree that I think that "grid computing," "distributed computing," "cloud computing" and "service oriented architecture" are probably all describing the same concept. I'm trying to use the most evocative terms and to relate them.

Tom Igoe at 6:29pm November 10
I think the web and the net, there's a qualitative leap there, because the former made visual communication easy, right? I'm still undecided on whether cloud computing offers any new insights on what we're doing.

Service design kinda does, in that it suggests a different way of approaching the problem, in terms of who owns the assets. Though it's basically what Ray Anderson was on about in "Mid Course Correction," but his thinking on that pre-dates service design, and his action probably pre-dates the web. Seems service design mostly gives a name to the concept, and the net -- and the web, if you want -- make it easier to implement.

Sometimes I wonder what ubicomp would have looked like if the web hadn't happened. I suspect the banks and credit card companies would have made it happen anyway.

Brian Slesinsky at 9:34pm November 10
If you don't know or care which machine(s) your application is running on, it lives in the cloud.

Mike Kuniavsky at 11:24am November 11
The question is in the definition of "application." It used to be relatively straightforward to figure out where "the code" ran, but when a widget on my phone sends an SMS to a service that's then syndicated to an aggregator which then generates addition information that's then displayed back on my phone, what's the "application"? That's why the service becomes the focus of the design, because there are now many possible ways that a person can interact with a single set of functions, still have it feel like a single thing at the core, even though there is no single "application" that's running on a single "machine." Think of how the service of banking is provided through ATMs, online banking, phone banking and human tellers, all of which run different codebases on different hardware, and yet still deal with the same money.

[On a tangential note, I was first exposed to the ideas of cloud computing when it was presented as the Andrew File System, a distributed file system that was being worked on at the University of Michigan in the late 80s and early 90s when I was there. It's interesting to see how the ideas of using networks to distribute computing evolve. In many ways the core ideas don't change, but the model of what people need changes, and what was considered esoteric and irrelevant suddenly becomes interesting when framed a different way. In this case, the distributed file system was abandoned and forgotten until it re-emerged as a service distribution infrastructure.]

Posted by at 2:50 PM | Permalink | Digg this | Tag this in del.icio.us

Woohoo! ThingM's second product, BlinkM MaxM, has hit the store shelves (first at Sparkfun, soon at FunGizmos).

It's (to quote myself), "BlinkMs bigger, crazy sibling. It's an intensely-bright smart LED for prototyping that comes as a package of two components, a control module (MaxM Master) and a daughter board with three ultrabright LEDs (MaxM Blaster). [...] Its trio of LEDs are 50 times as bright as a standard BlinkM and more than 1000 times as bright as a standard LED."

I'm also proud of its interactivity. It has 4 analog input lines so that in addition to being an LED replacement that's smart, it's also interactive. We expect to have some examples showing it in a range of applications soon. I'm most excited by the automotive application possibilities. Since it runs on 12v, you can hook it up to car batteries or (and this is a "don't try this if you don't know what you're doing" type of suggestion) directly to the car's electrical system. The possibilities for gaudy, interactive car lighting are infinite. I'm very excited.

Posted by at 4:03 PM | Permalink | Digg this | Tag this in del.icio.us

I wrote an article on ubiquitous computing user experience design for ACM's interactions magazine. The final article is only available to subscribers, but here's a preprint version of it:

Ubiquitous Computing User Experience Design

I think 2005 was the year we began living in the world of commonplace ubiquitous computing devices. That year Apple put out the screenless iPod Shuffle, Adidas launched the adidas_1 shoe, and iRobot launched the Discovery—its second-generation vacuum robot.

Sadly, even though we live in that world, the user experience design of most everyday ubiquitous computing devices—things you see in gadget blogs—is typically terrible. That’s because we do not address ubicomp user experience design as a distinct branch of interaction design, much as we did not treat interaction design as separate from visual design in the early days of the Web.

In the last couple of years, I have conducted research for and designed a number of ubicomp user experiences. In the process, I've seen some of the seams between industrial design, interaction design, architecture, and ubiquitous computing user experience design. In this article, I have tried to pull together some approaches that seem particularly valuable in the ubiquitous computing user experience world. None is unique to it: They’re all general design guidelines, but they seem to apply particularly well to the particular design challenges of this field.

Make Tools, Not Platforms

Like the fashion aphorism that just because you can wear two things together, it doesn’t mean you should, the ability to do arbitrary information processing does not imply the need to design yet another general-purpose device. We have laptops and phones for that.

It is because CPU power is so cheap that ubicomp UX design should concentrate all design and processing on a narrowly focused set of functionalities. Yes, a single device can be a dictionary, a calendar, a notebook, an alarm clock, a TV, an audio recorder, play every media format, and work as an 8-bit game machine, but doesn’t that just sound like an underpowered laptop?

Define Services Before Designing Devices

Service design gives to ubicomp UX the notion that every object is more than just a stand-alone tool; it's now the representative of a service. A physical, networked object is an avatar of a service that can be accessed in many other ways. This requires that affordances for the immediate task be included in the design of the product experience, and that the relationship between various pieces be taken into consideration.

ThingM, my company, developed WineM, our prototype smart wine rack, as an avatar of a service. The rack uses RFIDs on each bottle to track where every bottle is and then displays information using glowing LEDs behind the bottles. When we designed it, we treated the rack as one way to provide access to a service that associated a specific bottle with metadata about it, which was in turn part of a system that linked wine producers, distributors, retailers, and consumers together in such a way that everyone in the chain benefited from adopting the technology. The rack is a particularly visual manifestation of the service, but the service would be available through an API that could be accessed through many avenues.

Don't Overload Affordances

Ubicomp UX inverts several basic assumptions of traditional screen-based interaction design. While Web and software design aim to represent physical-world tasks on a monitor, the goal of ubicomp devices is to skip representation and directly enable activities in the world. Likewise, while many of the challenges of screen interaction design involve using rich general-purpose input and output methods in a novel way, many ubicomp products use narrow-focus, specialized devices.

Mixing the two philosophies can create confusion. Your doorknob doesn’t double as a volume control for your stereo, though in today’s fly-by-wire world, it can. For example, when BMW developed its iDrive system, which mapped a large number of different functions to a single input device, the mismatch in expectations created interface havoc that took the company many revisions to correct.

(image copyright Nick Humphries, CC Licensed)

Don’t Reinvent the Wheel

Although the ubiquitous computing industry is new, the field itself is close to 20 years old; it predates the Web. It’s relatively unusual that a technology takes as long to leave the research world and enter the market, and it’s a situation that provides an unusually rich backlog of academic and corporate research projects to learn from. Virtually every idea appearing commercially has been tried and documented in conference proceedings. When doing background research for a museum project, we discovered more than 20 closely related academic and commercial projects. Reading those gave us important guideposts that let us focus on creative solutions that improved on what had come before, without first having to recreate it. It took a couple of days of reading and synthesis—and saved us weeks of wrong directions.

Respect the Society of Devices

Few devices exist in a vacuum. General-purpose computers are designed largely to stand alone or exist as a hub connecting a bunch of peripherals. Technology-savvy Westerners simultaneously carry (or ride in) a large number of devices, everything from laptops to smart key fobs.

(image copyright Joichi Ito, CC Licensed)

Riffing off of Marvin Minsky’s Society of Mind, let’s call this technology cloud the society of devices. Each device does something specific, and some are more powerful than others. How do they all work together? How do they integrate into the larger set of devices and services out in the world?

On the interaction-design level, this means understanding users and their needs in light of the all of the devices that they may have. For example, while it’s possible to get email on many different devices, presenting it in a way that respects the unique constraints of a device and stays consistent with other devices becomes key when helping people transition between them. Text email accomplishes this using a universal format (text) with a well-defined structure (To:, From:, etc.). The minute that an attachment is included or there is HTML in the message, that consistency vanishes.

Create Physical Behaviors, Not Visual Representations

Screen interface design is essentially a visual practice, with some audio. But screens are expensive, power hungry, and large. Too many quickly overwhelm vision, our primary sense, and become a distraction, rather than a tool. However, not all information is so primary that it requires the attention of our primary sense.

Industrial design incorporates the physical senses of temperature, texture, and vibration into devices. Ubicomp UX is essentially the coupling of these two sets of ideas to create behaviors that match information priority with available sensory bandwidth and less cognitive load.

For example, say I’m looking for a new apartment in the town where I already live. I don’t need to move, but I’d like to. I set my (hypothetical) GPS unit to download a data stream of apartments that match my criteria of price, size, neighborhood, and proximity to at least three cafes with free Wi-Fi. As I drive/ride/walk around the city when I approach one of these locations, the GPS vibrates in proportion to how well it matches my criteria. I don’t need to look at it; I just need to feel it to get the crucial piece of information.

(photo by Timo Arnall)

Use Information Processing As a Material

When a designer can include information processing in a product for very little cost, the calculation becomes not one of complexity, but of competitive advantage. Including a CPU to produce behaviors in a product becomes a line item when deciding what to make it out of, rather than the expensive core around which to wrap a case. And like a material, that information processing capability creates some new capabilities, and imposes new constraints. We designed BlinkM, a smart LED, with this in mind. It’s designed for interaction designers, industrial designers, and artists to prototype sketch ideas in hardware. The user experience around it emphasizes its role as a material. We designed it to be inexpensive, robust, and to offer just enough capabilities to be easy to work with immediately, while still remaining openended.

I believe that ubiquitous computing technologies are incredibly powerful. However, ubicomp user experience design is still a very young discipline, without a track record of obvious best practices. In its failures, we see the inadequacy of applying older design paradigms to the capabilities of new technologies. If design people first encounter new technologies through design, then careful reflection on our design processes early on is essential for increasing the chances of technology’s positive impact. That time is now.

Posted by at 12:07 PM | Permalink | Digg this | Tag this in del.icio.us