Designer learning Touch Panel Design?

Jeff

We have recently hired a new Graphic Designer. She does all of the graphic design for US Coast Guard Headquarters, which means she does a lot of logos and print stuff. Her background is all print, but she does have the skills to do digital stuff as well.

We'd like for her to start designing our touchpanels, so that I no longer have to. I'm an engineer, and I believe rule #1 for touchpanel design is "Don't let the Engineer design it."

Are there any good resources y'all know of for learning touchpanel design? I'm not entirely sure she's ever even used a touchpanel, so this would need to be rudimentary. Classes, books, websites, anything you've run across with specific guidelines for graphic designers would be helpful.

Thanks,

J

DHawthorne

I found the TPD4 online class to be helpful, and last I looked there was a recording of it available still. That will help her nail down the basics. After that, I would have her go through some existing panel designs and take them apart, modify them, and basically play with how she can make them better.

Spire_Jeff

I agree with Dave. The online course should introduce her to the basics of TPD4 and I think they even have a document that covers some basic considerations to touchpanel design. After she learns the basics, have her take one of your existing panel designs and change the graphics. This will introduce her to your particular implementation methods and techniques. There are plenty of ways to skin a cat, and it would probably be most helpful to you if she learned how you skin a cat first

Jeff

Jeff

Thats helpful, but I guess I'm looking a little more for "Why" than "How". I'm not worried about her learning the technical ability to put the buttons on the pages, but how to know which buttons belong on which pages. I'm still new at this myself, so its not something I can necessarily teach.

For example, I recently designed a touchpanel that had a Video Source tab and a Device Controls tab. Nobody got it. Nobody understood that you hit Video Source to choose what you watch and Device Controls to control it. I changed it to a different setup, and after my 3rd attempt I haven't gotten a call about it. I can't train people to use it, because I have several hundred people who end up using these systems, it just needs to be intuitive.

Is there a way to learn lessons like this without inconveniencing users who dont understand the system and having to design a system 3 times? Has anyone written a "common pitfalls in touchpanel design" document? Where does one get good, intuitive touchpanel designs to learn from?

Jeff

Spire_Jeff

Here are a couple of pointers I have learned over the years:

The less button pushes required, the better. We strive for 2 button pushes to accomplish everything (sometimes it's 3 depending on the size of the building/house being controlled.)

Do more for the customer that is hidden. Most people don't want to think about which input do I want to send to each output, They say I want to watch cable on this TV. Put it into terms that your grandmother would understand. You might have to do a little more coding to make it happen, but that is our job. Also, the user should not have to know or care about the actual hardware and how it is implemented. You are basically translating the technical mumbo jumbo into kid talk and vice versa.

Limit options. Most people are afraid of the basic operation of a system, there is no need to throw brightness adjustment, tonal control, 500 different sound fields, gamma adjustment, ... controls at them. If you feel that different sound fields are important, give them some guidance, call the 5 channel stereo button "Talk Show", call the Dolby Digital option "Movies" and call the NEO:Music option "Music". Leave the "bath house in Istanbul" sound field off unless they user specifically asks for it (IMHO).

Lastly, use FEEDBACK, but only if it is certain (try to use devices that guarantee correct feedback). The most powerful thing about a properly programmed interface is that a user can trust it and not fear it. Aim for feedback they are familiar with. Almost everyone uses a computer. Try to emulate some of the more common things you find here. Use colors sparingly and for highlights. If the interface uses every color in the rainbow, then it's hard to distinguish a highlighted situation like ALARM NOT READY TO ARM. I like to stick to a basic theme, like browns of different tones (or whatever colors work with the surroundings), then use common colors to reinforce a message. For example, in a security setting, when a zone is tripped, I use RED to highlight this. RED is generally considered to mean STOP. Obviously, use GREEN to indicate that everything is ok. You could even use YELLOW to indicate a potential problem that might need further checking. Don't go and try to make a new color scheme with Blue meaning alarm and Brown meaning ok because you think it looks cool or futuristic, it's not intuitive. Also, you can hide things that are ok. If there is a sensor that is normally good, don't display the good condition on the touchpanel. This way when it changes to a bad state, the addition of something (especially RED) to the touchpanel will be visually alarming and intuitively recognized as being different.

Also, when you are developing an interface, it helps to ask others. If there is a secretary near you, or someone from a different department walking by (or your significant other) ask them if they have a minute to look at your interface. Start by not telling them anything and see if they can figure out what the interface does or how they would use it. For more complex tasks, see if you can teach them how to use the interface in 30 seconds. If you can't make either of these things happen, you might want to consider changing your design. It always helps to bounce ideas off of other people, because not everyone thinks in the same way. Things you take for granted could be so foreign to a user that even a one hour training session wouldn't make your perspective clear to the user.

I think that's all I have,

Jeff

Thomas Hayes

I try to use icons whenever possible. Limit the number of page flips to the least amount required, don't clutter and place things logically. With all that said, my main thing is to keep it simple. Too many options will confuse the average user and make any over the phone help desk scatch their heads if there are multi-paths to the same function. I used my 5 year old son(he's 9 now) to design the same basic template that we are still using today.
Somewhere in my files I have a file that AMX crreated to help design panels to look and function simply, if I find it I'll post it.

DHawthorne

I strongly agree with Jeff that the less buttons the better, and the more ou can automate, the better.

I generally aim for a two-tiered paradigm: (1) choose what type of thing you want to do (watch, listen, control lights, etc.), then (2) pick the device you are going to use to do it with (source component, lighting keypad, etc.). Like Thomas, I prefer icons to represent these choices whenever possible. Selecting the system you are controlling, then selecting the device is 95% of all my customers have to do. The controller turns everything on, switches all the appropriate inputs, and starts the transport (when feasible). After that, they usually only need basic transport controls, and volume. Selecting a device brings up its control page. Changing to another device is no more than two buttons away, and if it's in the same system, only one. I try to stay away from "exit" buttons on control pages - instead I have, on the screen, the submenu to select another device directly without having to exit. Things like local lighting have an always-available button to adjust them without exiting your primary controlled device. TV's and projectors automatically select the best screen format for the source, with a means to manually override for special cases.

I think it's real important that your designer actually use the design. Let her play with new designs for your demo room, for example, and sit down and turn stuff on and off, get a feel for what's awkward or unnecessary.

jweather

Check out http://www.infocomm.org/dashboard for an industry consortium set of recommendations... pretty vague in my opinion, but a good place to start. The guidelines they used to reach their recommendations are probably more useful than their specific recommendations.

Your designer will of course have a completely different approach to interface design, but specifically for programmers, the first rule of designing interfaces is: Your User Is Not You. You're intimately familiar with this system, you know that displaying this over there requires the use of the scaler which means you can't do that other thing at the same time. Your user doesn't care. Try to get inside your user's head and figure out what they'll want to do with the system. Watch them as they start to learn it and use it. Whenever possible, collect "user narratives" of clients (real or imagined) using the system. Sketch an interface on paper and show them, or print up prototypes before your meetings and see if they can figure out what's what without too much pain.

GUI Design/Human Factors is an entire department in most medium-to-large software companies... sadly, it almost always falls to the programmer in control systems, with maybe a few icons or color choices from a designer, if you're lucky enough to have someone with aesthetic sense around...

Jeremy