Welcome to my home control blog!

I’ll start this blog by introducing myself. My name is Rick Ledoux, and I live in the Seattle area with my partner Gary. I’m the development manager of the developer tools team within the Parallel Computing Platform group at Microsoft. (Please note that this is a personal web log—the views expressed here do not necessarily reflect those of Microsoft.) I’m also a home control hobbyist, which brings me to HomeUX and this blog. In this post I’ll explain what I mean by “home control”, and introduce HomeUX.

This first blog post is pretty long, because I want to provide some background and context. I’ll try to keep future posts shorter.

I grew up enjoying science fiction, in part because I liked to imagine the different ways technology could be integrated into our lives in the future. In many ways that’s happened—for example, I never would have predicted the worldwide communication networks that bring us mobile phones and the Internet, at least not so quickly and ubiquitously. But in other ways we’re stuck in the past. Let me explain by starting with a simple example.

A simple on/off light switch is still basically the same device as it was about 100 years ago, which is fine—it’s cheap, intuitive, and reliable. Flip on, flip off. That’s actually a great user interface (UI)—it’s hard to imagine how to improve on that. But when the functionality becomes richer, it seems there’s opportunity for the UI to become worse. A 3-way bulb has 4 settings: off, low, medium, and high; a common UI is a knob that you twist to get to each of these settings. A logical UI might be to twist one way for brighter light and the opposite for dimmer light (or no light)—sort of like how a water faucet works. But most 3-way lamps I’ve used don’t work that way: you twist clockwise for brighter light, but twist the other way and you’ll either break the switch or unscrew the knob. Why that design? I’m guessing it’s due to manufacturing costs or something.

Okay, who cares about the idiosyncrasies of a light switch—it’s still pretty easy to use. But as more equipment has entered our homes and our lives, it seems the opportunities for a poor user experience (UX) multiply. (A note about terminology: I use the term “UI” to refer to the part of the software or hardware that we interact with; I use the broader term “UX” to refer to the entire experience, which includes the “mental model” you have of the device or program you’re interacting with, and your satisfaction with it, as well as any documentation or other material you may need to learn in order to use it.)

Consider the typical bedside digital alarm clock. Every fall I have to turn back the clock by an hour as Daylight Savings Time ends in my region. The UI is familiar but clumsy: press and hold the “Time” button and then press and hold “Hour” until the correct hour appears. If I overshoot, I have to wait until the correct hour rolls back around again. Ideally my clock would know about Daylight Savings Time; failing that, why not have buttons for simply adding or subtracting an hour? And if I need the ability to set the full time explicitly—i.e. if the clock can’t get its time from an external source—then a keypad would also be nice.  (A single knob to set the time would be even simpler to understand, though perhaps more annoying to use.)

Modern thermostats are another favorite pet peeve. As I write this, the thermostat on the wall reads 70 degrees Fahrenheit. Suppose I want it warmer; I press the “up” button, right? If I do that—if I press the “up” button once—the thermostat still reads 70, as if it were ignoring me. In fact, it was switching from “show the current temperature mode” to “set the desired temperature” mode, but the two numbers happen to be the same (as they very often are)—either my “mental model” of the thermostat needs to accommodate that, or I just need to keep pressing the button until something happens. Okay, that’s not too bad, but how do I set it to turn on the air conditioner above 75 degrees and the heat below 68 degrees? By pressing “Mode” until “Auto” is displayed, then up or down arrow until “Heat” is displayed—and, by the way, this “Heat” means “set the desired temperature”, not “furnace mode”, even though the same word on the same display means the latter at a different time. I get to where the display shows 68, then press “Mode” to switch to “Cool set mode”—but if I get confused and wait a moment too long I leave that mode, and now I’m in a mode where “Cool” means “air conditioning only” instead of “set the desired temperature”. Pretty awful UI. Actually a better UI, I think, is found on the old-fashioned mechanical thermostats: I’d move one lever until it points to “68” on the scale and another until it points to “75”—that’s it! Why not such a simple UI on a modern thermostat? Part of the reason is that so many features—including important ones that save energy by lowering the temperature during times you’re not home—are packed into a small unit that can’t take up too much wall space lest it be too expensive or ugly.

Okay, so some everyday UI isn’t great. What can I do about it? With the HomeUX project, I ask myself this: what if I could control the UI using a computer screen? I’m a programmer—that’s something I can do, at least for equipment that’s controllable by computer.

So, what would a better thermostat UI look like if it were on a computer screen? There would probably be a display that showed Current Temperature, and controls for setting the desired temperature range (e.g. 68 to 75). In many ways it would mirror the way you interact with that old-fashioned mechanical thermostat. For the more sophisticated functions, like setting a schedule for turning the furnace on and off, there would be separate UI that focused on that task—rather than reusing the same buttons and same display like my electronic thermostat is forced to do.

In other words, with a computer-based UI we could create a better user experience for controlling room temperature. But wait, you say—who wants to go and turn a laptop and run some program just to adjust the temperature? Good point! But, what if the computer-based UI were on a small screen in a convenient place in the room—perhaps sitting unobtrusively on a shelf in the corner—and what if you turned on and controlled the screen by touching it (i.e. no mouse or keyboard)?

And, what if that same touch screen, or another one just like it sitting beside your sofa could be used to control your audio/video equipment while watching TV? Instead of a half dozen (or more) remote controls with inconsistent placement of buttons that have tiny, inscrutable labels, why not logically arranged, finger-sized buttons and controls? Instead of pressing up-arrow to “page through” an on-TV-screen listing of music, why not just touch the album you want to play? I could go on and on, but this blog posting is already too long. (You could disparage this concept on the grounds of cost and reliability, and there’s some validity to both those arguments, but there’s mitigation as well. I’ll cover those issues in a future post.)

I created HomeUX as my playground for experimenting with home control ideas. (No, I’m not a professional UI designer, and so I make lots of dumb mistakes, but, hey, it’s fun!)  When my house was built in 1999, I specifically chose equipment (lighting, security, A/V, etc.) that could be more easily controlled by a computer—I’ll discuss the details in a future post. I bought touch screens—really just repurposed point-of-sale terminal screens—and have several in the house. The touch screens connect as secondary monitors to PCs that I already have. My first generation of home control software, called DNSvc, taught me a lot about what works and what doesn’t during the years Gary and I (and our lab rats—pardon me, I mean guests in our home) have used it. My second generation software, which I recently got up and running in my home, is called HomeUX.

This blog will discuss home control in general, and HomeUX in particular. Actually, there’s a third topic I’ll spend a bunch of time on: how to create touch screen UI in Silverlight (which is what HomeUX is based on). The truth is, home control is only interesting to a small number of developers; Silverlight is a much more broadly applicable, and so those topics are likely to be of interest to more people.

One last comment before I end this long blog post. I’ve used the term “home control” and not “home automation”, which is probably more common. The reason is that I’ve never liked “home automation” as a term—it suggests that the point is getting the home to somehow operate “automatically”. (A while back, a common home automation scenario was “turn on the coffee pot at 7AM”.) The way I see it, these days the home is actually quite automated already—the problem is that the user’s experience controlling all that technology is in serious need of improvement. I can’t improve the user experience (UX) of my thermostat or DVR remote control, but perhaps I can create a new touch screen UX that I can use instead. And that’s what HomeUX is all about.

7 Responses to “Welcome to my home control blog!”

  1. John Dougan says:

    Unfortunately Silverlight is really only interesting to those developers who have bought into the MS development stack or want to use devices with enough horsepower to drive it. Oh well, it’s your system.

    Have you considered making a handheld device (IPod touch, smartphone, etc.) location aware and have it be able to control the devices?

  2. Rick says:

    The devices I use to run the Silverlight-based home control UI are just PCs I already have in my house. For the most part they’re really nothing special — and performance seems to be fine so far. Actually one thing I like about Silverlight is that, often as not, I’m controlling my home from a laptop — and, with Silverlight, there’s no “installation” (just browse to the web site). I really like having a zero-install solution.

    It’s true that I assume hardware and OS that can run Silverlight. Other approaches are perfectly valid; this happens to be the approach I chose.

    Re. handheld devices: I certainly plan to create a Windows Phone 7 client. I like Windows Phone 7 specifically because of its strong Silverlight support, which should make it easier for me to port my software. (Again, other devices could be supported — I’m just lazy so I’ll start with what’s easiest.)

  3. John Dougan says:

    My devices appear to be much more…diverse…than yours. Can I at least convince you to make the client-server interface easily usable by other UI approaches than Silverlight? Also, a list of pointers to (and local copies of) the various 3rd party device protocol documents would be great….1/2 the trouble I’ve had controlling stuff is just getting info on how to talk to them.

    You were at UBC in the mid-80s and worked on TeX, right?

  4. John Dougan says:

    BTW, a number of the links at homeux.org are messed up…they have backslashes where there should be forward slashes. eg. http://doc.homeux.org/ServerDoc%5CDrivers%5CAggregator%5CDefault.htm

  5. Rick says:

    Re. diversity of devices: actually as a separate side project I like looking into nontraditional “devices”, including specialized UI built using microcontrollers. Another example of “odd diversity”: when I had my Lutron system installed in my house 10 years ago, I had a number of keypad buttons labeled “Audio” in anticipation of eventually using them as a simple input mechanism for my home control software – to pause/mute sound in a room without using the touch screen UI. I’m just about ready to hook up that software. Having said all that… yes, my regular touch-screen devices are all Windows-focused. It’s what I know best.

    Re. pointers/local copies of 3rd party protocols. I should definitely do the former — I agree they’re sometimes hard to find. I’m not sure about the latter (publishing local copies), for copyright reasons.

    Re. UBC and TeX: right — and, I’ll bet that’s where I recognize your name from. :-)

  6. Rick says:

    Oops, thanks for the catch. Should be fixed now. I guess the browser I use most of the time doesn’t make a distinction.

  7. John Dougan says:

    At the very least, keep local copies/mirrors of the protocol specs…inevitably the websites go off line or get reorganized into uselessness.

Leave a Reply