Slashdot Mirror
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)."
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 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.
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.
You have good ideas. But "an intuitive menu system" is a very GUI-centric idea. The poster does not want a GUI solution. Ever try to navigate through a menu tree with a 4-digit, 7-segment LED display? Not nice. It seems the poster wants knobs, sliders, switches, small displays (capable of displaying a crude text-UI? maybe, maybe not). Well, that's how I read it anyways, since there are good books out there already on menu design philosophies.
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.