In our kiosk app, the buttons to proceed are placed on the right of each screen.
In one of our input screens, the designer doesn't have enough space to place the button on the right while keeping the input buttons at a large size, so has suggested moving the button to the left.
I feel that it is worthwhile making the input buttons smaller (the screen we are designing for is 15") in order to keep the button position consistent.
What are your thoughts?
I'd say it depends on what you consider a "large size". According to this article on kiosk design guidelines, targets should be at least 26 mm wide and at least 26mm tall. If you can achieve that minimum size with the smaller buttons, I would go with the consistent button placement (the design on the left).
If you cannot achieve at least 26mm, then I would try to come up with a third design that doesn't require a compromise. Perhaps this would work?
download bmml source – Wireframes created with Balsamiq Mockups
If no other design will work, then you might have to bite the bullet and change your button placement.
The size of the buttons can be vitally important on many touch-screens, and location on the screen has a profound effect on the minimum effective size.
As I explained in another issue, one of the main issues with kiosks is parallax:
What that means is that buttons at a more severe angle from the user's eyes (like at the bottom of the screen, if the screen is mounted relatively low down) are harder to target than those directly in front of them. This effect can be improved by recalibrating the screen to compensate for the parallax, but that only works if every user's eyes are at the same level.
This effect is most pronounced on projected capacitive touch (PCT) screens which require an additional layer of glass. These are the screens most often found in public areas since all sensitive electronics are behind glass. Infrared laser light plane (LLP) screens are less pronounced, and generally quite cheap to expand to 40 inches and above. The LCD itself can do a lot to exacerbate or reduce this effect too, with new technology like fully-laminated displays (on most new consumer tablets), the distance between the observable image and the front of the screen is reduced.
So to answer your button size question directly: you cannot avoid having large buttons on most kiosk hardware, since large buttons are sometimes the only way to allow users to hit their intended target despite the parallax effect.
Of course, if your button size is large enough (and you've tested it with multiple user heights on the real hardware to ensure it is), then consistency of button placement matters hugely. For most kiosk software, it'll be used mostly by users who are not familiar with your software. Generally speaking, kiosk software is highly-customised and branded, and users are therefore unable to rest on the conventions they may be familiar with on various platforms. That means you have the duration of that first-time use to make them feel comfortable navigating the software.
Generally the easiest way to do that is to give them an obvious, consistent method for progress ("Next", "Continue", "Yes") and regress ("Back", "Cancel", "No") through the steps.
Looking at your examples, I agree with DanM's suggested redesign for this screen. For your previous examples, be wary of putting your "yes" and "no" buttons so close together. On some screens the difference between where a user places their finger and where the touch-screen registers a press can be as much as 8mm (more than a quarter of an inch)!
Good question! I am leaning towards a smaller button but in consistent location. I think users are less likely to notice (be interrupted by) a smaller button size than a different location of the button, especially, if the screen is part of the multiple screen flow when all other buttons are always on the right.
Another solution may be to use a non-standard keypad config for example a row of numbers like on the top row of a keyboard
Splitting the buttons into different columns will make the use of the application slower since your users will need more eye fixations to find what button to use next.
In your example, is there really a need for an update button. Can't you always show the result? Would it be possible to replace the update button in your screen designer's suggestion with a result area? Always showing the result is also better usability since it keeps the feedback loop as short as possible cuts down on the number of clicks the user has to make.
If you really need the update button wouldn't an alternative be to place it below the "7" and to the left of the "0". Make it stand out a bit by giving it another colour or something similar. So that it's easy to tell it apart. Then it's at least as big as the other buttons.
