Experience with large touch panels and performance

[Grampa_of_Oliva_n_Eden]

I have been asked to put together an application that uses (2) large touch panel displays ( >22 inch but < 36 inch).

What advice would you share regarding the interface and how large screen sizes affect performance?

If you have experience or would like to offer any warnings, please feel free!

Thank you,

Ben

[Mike Ashe]

I'm a fan of glass surface acoustic wave (SAW) touchscreens as opposed to resistive, capacitive or infrared. They tend to last longer, are more precise. Look into ELO Touch Technologies and Guide to Choosing a Touch Technology

Don't go into sticker shock:

32 Inch Intellitouch wall mount touch screen

YMMV

[David Boyd]

Ben,

Of late, we've used several Vartech 19" rackmount LCDs (running 1280 x 1024 native resolution) which are fitted with capacitive touchscreens. They're used on a general production line environment, and they've been very well accepted by the folks who interact with them. The LV app runs fullscreen and has a minimal number of tabbed pages, using slightly outsized buttons, dropdown listboxes, etc.

Not too expensive, though Vartech occasionally sends me marketing emails touting their latest 46" sunlight-readable touch-enabled hi-res NEMA4X-firehose-washdown models, which I don't even want to hear the cost of...

...but there are Vartech models larger than 19" which may fit your requirements without bankrupting your client.

Did your question about "large screen sizes affecting performance" imply large desktop pixel dimensions? Even the jumbo (32" and above, widescreen format) monitors I've seen typically only have resolutions of 1920 x 1080 or so, which seems a typical hi-res mode for any good desktop graphics adapter.

Good luck!

Dave

[Grampa_of_Oliva_n_Eden]

Thanks guys!

This is good info for me to think about before I get into this too deep.

I'll post back after we learn some more, after all these things take time.

Ben

[Yair]

Re: the interface - my experience was with smaller displays (15" which have an embedded, relatively weak PC), but it might help you. The point about the weak PC is important, because when it was time to run one of our applications (with some additional CPU-thirsty software), we found out that the processor was at 100% all the time and the application was a bit sluggish.

• As Dave said, make things larger. Pay special attention to enlarging controls vertically because that's the direction people tend to miss.
  
• Space things out. People tend not to be exact.
  
• Be sparse. The UI for a touch screen should be much less crowded than a standard one.
  
• Avoid tabs as they don't look that great for these kinds of applications. I prefer a cluster of buttons which you compare with its old value using a value change event and use that to switch pages in the tab control. You need property nodes to lock out the controls which can not be clicked (like the currently selected page) and you need to reset the cluster so that only one button is pressed.
  
• Definitely run your program in full-screen. You wouldn't normally want your users to interact with the OS. If you need a keyboard, you can open the Windows one by calling OSK.exe, but its buttons are relatively small and can't be modified.
  

All of these may vary depending on the application and the type of the screen, but they've helped me.

[Grampa_of_Oliva_n_Eden]

QUOTE(yen @ Jun 3 2007, 12:08 PM)

Re: the interface - my experience was with smaller displays (15" which have an embedded, relatively weak PC), but it might help you. The point about the weak PC is important, because when it was time to run one of our applications (with some additional CPU-thirsty software), we found out that the processor was at 100% all the time and the application was a bit sluggish.

• As Dave said, make things larger. Pay special attention to enlarging controls vertically because that's the direction people tend to miss.
  
• Space things out. People tend not to be exact.
  
• Be sparse. The UI for a touch screen should be much less crowded than a standard one.
  
• Avoid tabs as they don't look that great for these kinds of applications. I prefer a cluster of buttons which you compare with its old value using a value change event and use that to switch pages in the tab control. You need property nodes to lock out the controls which can not be clicked (like the currently selected page) and you need to reset the cluster so that only one button is pressed.
  
• Definitely run your program in full-screen. You wouldn't normally want your users to interact with the OS. If you need a keyboard, you can open the Windows one by calling OSK.exe, but its buttons are relatively small and can't be modified.
  

All of these may vary depending on the application and the type of the screen, but they've helped me.

Thank you Yen.

THe nature of the GUI objects are the subject of this project were we will be allowing users to compose their own GUI's to understand how different people interact with a variety of systems.

Ben