Slashdot Mirror

← Back to Stories (view on slashdot.org)

User Interface Design Book for Electronic Devices?

Posted by Cliff on from the real-user-interface-design...not-GUIs dept.

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)."

12 of 40 comments (clear)

  1. Try this by HybridTheory · · Score: 5, Informative

    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

    1. Re:Try this by UnknownSoldier · · Score: 2, Informative

      Yeas, TDoET / POET is a *great* read.

      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.)

  2. Also POET by MarkusQ · · Score: 3, Informative
    By the same author, "The psychology of everyday things", known in the trade as "POET".

    -- MarkusQ

    1. Re:Also POET by mclearn · · Score: 3, Insightful
      These two are actually the same book.

      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.

    2. Re:Also POET by elmegil · · Score: 4, Funny
      Rule of thumb: if you think something is clever and sophisticated, beware -- it is probably self-indulgence.

      None of that in Linux, mind you.

      --
      7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
    3. Re:Also POET by MarkusQ · · Score: 2, 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

  3. Some basic tips for you by WIAKywbfatw · · Score: 5, Informative

    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
    1. Re:Some basic tips for you by driptray · · 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.

    2. Re:Some basic tips for you by Anonymous Coward · · Score: 2, Insightful

      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.

  4. Not an answer to your question, but... by RockyMountain · · Score: 3, Insightful
    Sorry, I don't know of such a book. I'll just make one 2 cent suggestion.

    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.

  5. IBM's thoughts... by cei · · Score: 3, Informative

    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.
  6. My two cents by ka9dgx · · Score: 2, Interesting
    #1. Avoid modes, nothing is more frustrating that having multiple functions on one button or knob. I know that it might take more I/O lines or resources, but resist (at all costs) the urge to make things multi-functional. Devices should work without the manual, without training, and without knowledge of English as a primary language.

    #2. If I/O gets tight... multiplex it, and go back to step #1... no control should be multi-purpose!

    --Mike--