User Interface Design Book for Electronic Devices? 40
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 this (Score:5, Informative)
I read it years ago and found it fascinating. Even though I wans't designing anything.
At Amazon [amazon.com]
Also POET (Score:4, Informative)
-- MarkusQ
Re:Also POET (Score:4, Insightful)
He describes the title of the POET book as a "case history of design". However, after musing about the psychology and the clever acronym, he quickly follows up with some advice worthy of any user-interface designer: "Rule of thumb: if you think something is clever and sophisticated, beware -- it is probably self-indulgence."
In any case, the book is wonderful, insightful, and quite funny to read. I do some HCI work myself, but my gf read this book without any knowledge of UI and loved it on it's own.
You may also want to check out Interface Culture [amazon.com] by Steven Johnson. This book not only discusses interfaces from an electronic viewpoint, but how it affects daily life. An interesting and insightful read, as well.
Re:Also POET (Score:5, Funny)
None of that in Linux, mind you.
Re:Also POET (Score:1)
(Ow, the flames!)
Re:Also POET (Score:3, Informative)
These two are actually the same book. Are you certain? I only own POET, but I notice (from the provided Amazon links) that they have different ISBN numbers (0465067107 vs. 0465067093). Although they are both 272 pages long. Repackaging?
-- MarkusQ
Re:Also POET (Score:1)
Re:Also POET (Score:2)
Re:Also POET (Score:2)
Turns out my manager kept moving it back...
Re:Try this (Score:3, Informative)
You may find Chapter 1 of "Designing Object-Oriented C++ Applications using The Booch Method", by Robert C. Martin, to be usefull as well. (The rest of the book is great, but focuses more on the interfaces and implementation of the design.)
Skip the book... (Score:1)
Re:Skip the book... (Score:2)
Some basic tips for you (Score:5, Informative)
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.
Re:Some basic tips for you (Score:3, Interesting)
1. Write down every feature that your device has.....Categorise them as best as possible. This will help you develop an intuitive menu system.
This is the "feature-based" approach, which is sometimes the best way to go.
The alternative is the "task-based" approach. Instead of listing features, in this approach you attempt to put yourself in the shoes of your users and ask yourself what tasks you are likely to want to perform. Then you organise the interface around the list of tasks.
In GUIs, most menu systems are examples of the features approach, whereas wizards are an example of the task approach. Note that documentation can also be split in this way, between task-based and feature-based.
The features approach is the safest and easiest way, but the end result is never very impressive. The task approach, when done well, is fantastic, but when done poorly (or in inappropriate circumstances), is a nightmare, where the tasks don't match what the user wants, and the individual features have been buried inaccessably within the tasks.
wizardry (Score:1)
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.
Re:Some basic tips for you (Score:2, Insightful)
I think an activity-centric approach is better. For example, one approach would be to assign common activities to obvious pushbuttons. Use a modifer button or two ("shift"/"alt") in concert with the primary buttons for uncommon activities. Use a few shared LEDs of various colors/labels for status feedback. If you system is a finite state machine, have a second set of LEDs to indicate current state.
Re:Some basic tips for you (Score:1)
Good ideas. Another thing to consider in a design:
Don't let a cheap hardware design force a bad interface design.
- Spend the extra money to include a useful display. If it makes the design better, use an alphanumeric display with enough space to display messages in plain English instead of using only a two-digit 7-segment LED.
- Include enough buttons so that you have one function per button -- no multifunction buttons that change meaning depending on what mode the system is in.
- Don't be limited to a numeric keypad for data or parameter entry. Consider using a rotary encoder for setting parameters.
I think users should gladly pay a little more for a product that is easy and simple to use, versus a badly designed but cheap item.Couple of suggestions (Score:2)
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.
Not an answer to your question, but... (Score:3, Insightful)
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.
Re:Not an answer to your question, but... (Score:1)
Menus and keys/buttons with multiple functions are not very intuitive.
If your feature list is so long that menus and multi-function buttons are unavoidable, try to use them only for the more exotic frills. Dedicate a few buttons to the basic functionality, and perhaps a few to the more basic of the frills. Multiplex the remaining frills onto the remaining buttons. Above all, make sure that the basic stuff remains accessible at all times, and it's operation is not interrupted or modified in any way by the current state of the menuing system.
The best candidates for menus and multifunction buttons, if unavoidable, are things that are typically accessed very seldom or once only -- like setup features.
IBM's thoughts... (Score:4, Informative)
YYoouurr SSiigg (Score:1)
Re:IBM's thoughts... (Score:1)
Take the real CD. You have to open the cover of the CD in order to view track information. The application now doubles in size. This doesn't seem like the best way to accomplish this common task.
When designing software that people will use metaphors are useful but they have to be loose enough that they give users a good indication of their behavior but don't create unrealistic expectations or map so tightly they sacrifice usability for metaphor. The desktop example is a good example of this. It works in a similar way to my real desktop in that I can keep things I'd like to access quickly right in front of me. However I can't create little piles of things on my computer desktop and I can't access other peoples desks (networked computers) from my physical desktop. While I agree with your point of an object setting reasonable expectations of its behaviour through its interface I think IBM's model goes too far and creates usability hurdles in order to maintain a direct mapping to a physical device.
In the case of designing a physical device (like what the poster is asking about) the goal of creating an interface that sets expectations through its design is a good one. This could be done through a good layout of the buttons on the device, good iconography and, as others have mentioned, optimizing for a users common tasks.
BEHOLD: Jog Dials!!!! (Score:1)
Jog Dial.
My two cents (Score:3, Interesting)
#2. If I/O gets tight... multiplex it, and go back to step #1... no control should be multi-purpose!
--Mike--
Learn By Example (Score:2)
Two books (Score:2)
Another book you sould consider, though it is more geared toward personal computer interfaces, is Bruce Tognazinni's Tog on Interface [amazon.com] also from Addison-Wesley (ISBN: 0201608421). Tog [asktog.com] is now part of the Nielsen-Norman Group [nngroup.com], which can be hired for HCI work, if you have the moolah.
Unusual Conditions (Score:2)
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?
Assume nothing! (Score:1)
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..
Palm has UI guidelines (Score:1)
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
Here's my interface idea (Score:1)
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 [epinions.com]? 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!).
Rule Number One (Score:2)
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.