User Interface Design Book for Electronic Devices?
ikeleib asks: "I'm in the process of developing a HVAC control system. The problem with most programmable thermostats and just about every other electronic devices is that they are hard to use. I've been trying to find a book on user interface design for electronic devices. All the books I've seen on interface design seem to focus on GUI's. Does anyone know of good books (or websites) on interface design for electronics? I'm talking about buttons and tiny screens, not web pages and dialog boxes. I've only been able to find one book (for $104)."
Try The Design of Everyday Things, Donald Norman.
I read it years ago and found it fascinating. Even though I wans't designing anything.
At Amazon
-- MarkusQ
...hire an industrial designer. Two good firms that specialize in industrial design are Frog Design and Ideo. Industrial designers specialize in designing human interfaces for mechanically controlled devices.
I wear tinfoil undies & yarmulka to protect from WiFi traffic. Everything should have ethernet and a web, or better yet, telnet cli interface. DB-9 and kermit are a close second choice. I wear tinfoil undies & yarmulka to protect from WiFi traffic.
Seriously, my favourite interface would be an API that I can access from perl, and someone out there(tm) would surely create four GUIs for it. There is no way to squeeze a decent interface into these things, It should all be standardized and done remotely from a computer.
The sooner home appliances adopt ethernet (say next to the power plug), the better. First on my list: sntp broadcast clients for TVs, VCRs, Microwaves, Ovens, and even (Ghasp!) alarm clocks.)
Remember, the objective is to design something that even an idiot could use correctly without having to swallow a manual. So, with that in mind, here's some (basic) advice.
1. Write down every feature that your device has and come up with simple, non-technical names for them (start is so much better than commence, reset is better than initialise, etc - you get the idea). Categorise them as best as possible. This will help you develop an intuitive menu system.
2. Before you commit your system to hardware, get some user feedback. If necessary, rope friends and family in to help you with this. Ask them what features they think are most important, which they think they would use the most, which they think should be grouped together, etc. Make a note of everything they say (a tape recorder might be a good idea) as even the smallest comment can be of immense help. Above all, be sure to use this feedback in designing your interface - you're far too attached to your design to be objective about what works and what doesn't work.
3. Build a prototype. Test it on your intended users. Ask for more feedback, on both the hardware and the software, and use what works. If necessary, lather, rinse, repeat as many times as you feel is productive.
4. Get short-, medium- and long-term user feedback once the device is in the field. Pay careful attention to what features people don't use - it could be because the feature is useless, or poorly understood, or just plain overlooked. Remember, the more your users get out of your device the more they'll appreciate it (and, similarly, the more successful you've been at designing a simple to use user interface).
5. If all else fails, Keep it simple stupid!
Good luck.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
The latest should really be on a web site somewhere, not in a dead-tree book IMO.
;-)
I grant, of course, that the latest isn't
necessarily the best, in all cases...
---
OT: The latest outrageous Australian proposal:
In Australia, if someone is to be defended
by a lawyer against a charge with national
security implications, [it is proposed that]
the LAWYER defending him/her must -first-
go through a high-level security clearance!
(I understand that this restriction applies
ONLY where the client -isn't- paying lawyers
fees, ie a pro bono client... and NOT where
the client is paying his/her own lawyer's
fees)
The other thing would be to consider looking for material on "ergonomics" rather than "user interface", as the terms seem to be desribing the same general concepts but UI seems to be mainly used in software and ergonomics is what people in other fields tend to talk about. I'm not familiar with the standard ergonomic lit/texts (aside from DoET/PoET, which I suppose counts), but there has to be material out there -- people have been studying this stuff for decades at least, and I know it was a hot industrial topic through the past decade or so.
DO NOT LEAVE IT IS NOT REAL
Divide all the features into two piles: basic functionality, and frills: Basic functionality is the stuff that defines your product. Without this, your product isn't useful. Frills are the other stuff that may be useful, cool, and possibly even set your product apart from the competition, but doesn't define the product.
For example, if you were designing a phone, basic funtionality is dialing numbers to make outgoing calls, and receiving incoming calls. Period. That's it. Frills include everything else: speed dialing, programmable ring tones, redial, phone book, call log, etc.
Now stick to this simple rule: No frill should ever, in any way, make a basic functionality feature any more difficult to use, harder to find, or less intuitive. Never!
For a classic example, consider those Nokia phones that have a single, multifunction button, that serves a SEND, END, MENU, and a zillion other multiplexed functions. You can be on a call, and need to hang up, but because of other unrelated features (e.g. address book access, volume control, etc.), the multi-function button doesn't happen to be behaving as an END button at the time. You've got to look at the screen and back out of menus, until you see END, and then push the button. That's ugly, and it's all because frills were multiplexed onto the same contols as basic functionality, in a way that interfered with the basic functionality.
I suppose a more sophisticated strategy would involve multiple categories of features, ordered from most basic to most frilly. In that case, no feature may ever be allowed to cause any feature in a "more basic" category to be any more difficult, or less intuitive. But with just 2 categories and a strict adherence to this rule, you'll already be ahead of 90% of the gizmos on the market.
.....ya know, a create your own desktop wizard would be a *good thing* for this legendary linux desktop. End all the window manager wars-maybe. At least cool for noobs, first time ya boot up you get a series of questions, click here, click there, la dee dah, eventually it goes "finish" and poof, what ya want, the apps ya want, the menus you want, all your bells and whistles a done deal.
ya ya I know you can do this now,in a way, but making a newbie friendly GUI wizard would be appreciated by quite a few people.
IBM has some nice stuff online. I agree with a lot of it. In your case, since you're designing a thermostat, and most people know how to use a traditional thermostat already, you should make your interface as close as possible to that which they already know. They're going into your device with a notion of what to expect. Don't deviate from those expectations, and you should be OK.
This sig intentionally left justified.
DDoonn''tt yyoouu mmeeaann llooccaall eecchhoo?? JJuusstt bbeeiinngg ppeeddaannttiicc..
Two word solution to any simple interface design:
Jog Dial.
#2. If I/O gets tight... multiplex it, and go back to step #1... no control should be multi-purpose!
--Mike--
Don't limit your self to books. Take a look at products that have done well (e.g., GameBoy, Palm, etc) and those that have failed (e.g., most VCRs, anything with CE, etc).
It is a bad thing to astonish users, so you should follow the industry standard procedure for interface design (as seen, for example, on all VCRs):
Another book you sould consider, though it is more geared toward personal computer interfaces, is Bruce Tognazinni's Tog on Interface also from Addison-Wesley (ISBN: 0201608421). Tog is now part of the Nielsen-Norman Group, which can be hired for HCI work, if you have the moolah.
Looking at the front panel of the device, can you tell me what state the system was in when the power failed, can you tell me what state the system will come up in when power is restored? Can I easily "safe" the system so that nothing bad happens to the equipment while the power company is busy doing evil things to the power feed?
I installed some HVAC-controllers a while ago. Quite frustrating..
;-(
1) Never assume the user has read the manual! Most people even don't think about it..
2) Do not hide buttons below a cover. Most people will forget to look there.
3) Make the text BIG! People grow old and won't be able to read those small fonts.
4) Most people don't want to do the effort to learn how to use it. Make it very simple or prepare to answer really stupid questions, over and over again..
History matters..
Titles on the above page that appear relevant to you are:
Zen of Palm
Palm OS User Interface Guidelines
I suspect your HVAC may not have as sophisticated a UI as a Palm but maybe their guidelines will give you some insights and rules of thumb.
good luck.
-joe
What's the most annoying part of setting a thermostat/timer/clock radio alarm? Hitting the darn button that increases the days/minutes/hours until you get to the time you want...unless you skip it, and then you have to go all the way around again. Very annoying.
Remember the classic Honeywell thermostats? Maybe make yours shaped like that. But make the round case useful--turn it into a big jog dial. You could use it to set your days and times and temperatures. Turn it one way, the value increases. Turn it the other way and your value decreases.
It should be rather responsive--It should be click.............increment. As soon as a click it over one stop I should immediately see the value change. And it should have a nice detented feel too it--not too lose, not too tight. Kinda like a newer microsoft mouse wheel.
OK, so that's how to set the day, time, and temperature. But we still have to tell it which of these that we are setting. Contrary to advice given above, I think you need modes to do this. If you can think of another way, great. Anway,
Hit the program button. The Weekday/weekend values show up. Spinning the jog dial rotates you through [Weekday,Weekend,Sun,M,T,W,Th,F,Sat]. You bop the program button to set it. The unit does something satisfying like beep or light up or whatever.
Now the time value shows up. You spin the dial until you get to your on time. Ideally, the whole 24 hour clock would fit on one or more rotations of the jog dial (IE, you wouldn't need a seperate Hours mode and Minutes mode). Bop the program button again to set the time. Once again, the unit makes a reassuring noise.
Finally, set your temp with the dial. Hit the program button again.
This isn't a complete design, you need some way to do multiple programs. But the important points are that it is easy to increment/decrement the value, and that it is obvious when you've programmed a given value.
This may exist already, and what I think it my idea is just my brain vomiting up something it remembers. Do you own study. (But if this is an original idea, I'd better not see a patent on it later!).
--Tim
Seriously, if what we're talking about here is going to be a wall mounted glorified thermostat, plan on it being used by an elderly arthritic in a dark hallway and it should work fine for everybody else.
Other worthless advice available at cost. E-mail me at earthstink.
I see even classic Slashdot is now pretty much unusable on dial up anymore.