Touch screen with buttons, drop-downs in touch screen

13 Aug 2010 - 7:16am
6 years ago
6 replies
1916 reads

Hi !

This is my first posting here, I’ve enjoyed reading many discussions in the past, so be gentle :)

Nr 1. Right now we are discussing back and fourth the use of buttons in addition to touch screen. I should mention that we do not have strict accessibility requirements, it is not a product for open spaces, where all tactile feedback is important.

I’ve managed to convince my team not to use input buttons for text/digits (like on ordinary telephone, or calculator) in combination with touch screen if we cannot offer qwerty-keyboard.  It will drive people mad with slower inputs etc and give a very confusing idea about how we just couldn’t make up our minds and pick touch-screen or no touch screen.
But I’m not too sure about skipping “physical” Main menu/ Back buttons having consumer products in mind. There is a concern about production cost, it costs less to produce just touch screen with no buttons at all.

Does anybody have any experience  and can share thoughts about why e.g. Home/Back button is presented on many devices in addition to touch screen?

I can think that it’s a shortcut and helps to determine touch screen discoverability: is in sleeping mode or shut down;  it has a clear hatch-escape principle incorporated, if user gets stuck in some dialogues, s/he can easily get back. If we don’t have it, Main menu button should be placed in every dialogue. The same is for Back button.
Something else I’ve missed?

Do you have any touch screen UI examples without any physical buttons? I’d very much appreciate it.  What’s are the cons except discoverability and more UI work with consistency in every dialogue? :-)

Nr. 2 Another question about  drop-downs in touch-screen, Saffer in “Designing gestural interfaces” says that designing drop-downs for touch screens is not always a good idea because of hover limitation. I know that Iphone started with that wheel-menu drop down, but I’ve seen some apps successfully using drop-downs? I couldn't find any rules about that. What do you guys think?

Thanks for reading, sorry it got too long :)



13 Aug 2010 - 10:14am

Is this a resistive or capacitive design?  You said that cost was an issue so I'll assume resistive.  In that case, reserved spaces for buttons might not be a good idea over the long term as wear patterns will appear on the flexible surface.

The only other argument I can think of for physical buttons to complement a UI would be in the case where the design can become modal,  in this world I would expect a degree of cognitive processing with a common virtual button over physical.  E.g. no matter what I'm doing on an iPhone, that home button is always in the same place doing the same thing (ok, 99.99% of the time(o;)  In scenarios where the user might be focused on other stimuli I expect the spatial aspect of the physical button to be a huge plus. As well as that I like having a physical anchor to the UI in touchscreen devices, but is alone worth the cost to your client?

With that all said I'm fascinated with restaurant tills and how they are both an affront to my senses and apparently usable. I've interviewed a few users and the general consensus is that theres a low learning curve with the most common layouts (no physical buttons)

just my 2c, not much help I suspect /pauric

17 Aug 2010 - 9:28am

Pauric, thanks for your answer!

Yes, you're quite spot on: it's resistive touch. Very good point about wear patterns, I've forgot about that, and that can probably be one the best arguments because of durability of the product. Restaurant tills are good examples, thanks. I've remembered some self-service cashiers as well (although less complexity). I've observed them (smth like that but no camera for product recognition) this weekend.  Whenever customer got stuck in UI, the personnel jumped up, swiped his/her card & put 9999 for pin code and the shopping could continue. :-).

14 Aug 2010 - 1:33am

It's an interesting discussion! I have also had to move my design skills to producing a touch screen (till) product recently, though our hardware was bought in rather than bespoke.

We've kept our back/forward buttons in the same place, (bottom left and right) to help the user stay oriented and provide consistency, though I must say we haven't thought about the screen wearing out!

In testing we have found that when a bug or issue means that you get 'stuck' on a screen, there is much less control over getting back (versus using a keyboard and mouse). But part of that issue is that as 'techies' we reach for hotkeys to solve problems, which ordinary users are less likely to do.

Maybe a physical button can provide an 'escape' route for such scenarios? My (personal day to day) experience of physical buttons is that they are usually to facilitate actions on non touch screens (the buttons are to left and right of the screen and a line 'points' to the screen, as in an ATM).

As for drop downs, we had to provide the same functionality in a Back Office and on the Touch Screen (selecting a travel product with different options). On the back office we used dropdowns and on the touch screen we used toggleable button groups.

Hope this helps?!

For what it's worth, Pauric, I've made my attempts to produce a till touch screen that isn't so awful looking! I think that some of them are a good example of how users can learn to use any system if they have to...!


17 Aug 2010 - 9:38am

Alice, thanks for sharing your experience. That's a great help!

That wearing argument is my hope :-).

Do you have any examples of what people tried to do when they got stuck, did you have any touch screen freeze? I'm imagining people will reach for on/off button, we want to keep them from doing that :).

Good luck with your project!

16 Aug 2010 - 8:56am
Magdalena Mateescu

Users sometimes complain about drop downs on the touch screen. They are less controllable compared to mouse interaction. Accidental touch of the screen is more likely than in the case of mouse interaction. 

17 Aug 2010 - 3:47pm

I am thinking pure psychology here: Users do not trust enough the software to feel that it will not quit/freeze on them. That is why a User needs to believe that there is that special button that clicks under his finger. It's that feeling that when everything is frozen, this button at least will be able to be clicked. 

If you were to produce a full touch screen calculator with auto on/off, Users would trust it to work at all times. Their jobs do not depend on it, they can easily use a workaround if something goes wrong. Now, a PC is a toolbox of such complexity that the User will simply not trust it to work perfectly, he will look for the physical button. In fact, if you hand it to test Users, the first thing they will do is make all kinds of gestures and multitasking to try and get a glimpse of lagging and freezing. Then they will tell you why they need the button.

I would suggest that a physical button is not an option - it is a workaround for not being able to convince the User that the device does not really need it. If your device works that good without it, then drop it. If you have doubts, then the Users will have too.

As for drop-downs, it's your device and only you can tell if there is enough space for the drop-down to develop gracefully. If there is enough room to control the component and make the selection, I would not see a problem there.

Syndicate content Get the feed