Tag Info

Hot answers tagged

13

If, as you say, as many as half your users aren't English speakers, why are you trying to communicate with them using English words? Why not show the Lira symbol (or better, some Lira banknotes) and arrows to the PayPal logo, pictures of your gift cards (or icons of gifts) etc.?


8

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


8

A scientific publication: Martin C. Maguire Senior Researcher, Loughborough University A review of user-interface design guidelines for public information kiosk systems http://scholar.google.co.uk/citations?view_op=view_citation&hl=en&user=FCZ_GjgAAAAJ&citation_for_view=FCZ_GjgAAAAJ:2osOgNQ5qMEC


8

Depending on the context, you almost certainly should show an error message (in order to reduce the likelihood of the user trying to use a function that is currently unavailable). If the context is very public and so help/support is generally unavailable, you probably should show a more general error like "Out of Order" if those features are core features of ...


6

There is good Question from before around general iPad design: Are there any good resources about designing touch screen interfaces? Design Considerations These are really high-level and do not touch on UI design in particular. Staff/Employees - Since it is an iPad kiosk I assume there will be people there. Employees are key to any business and this ...


4

The kiosks at museums are good examples for walk-up-and-use systems. I presume you could find relevant publications about them. This report by the Fluid project at OCAD University seemed to be good one that I was able to quickly search. The ACM Digital Library is a very good place to dig into if you are looking for research publications, although you might ...


4

I would not do any paging with navigation buttons. I would disable the continue button until the text box has been scrolled all the way to the end. The reality is your users are either going to read it or they are not. Adding more buttons or messing with the scroll buttons is not going to make someone read who doesn't want to read. You're just irritating ...


3

Create a clearly noticeable "back to start" button. Work from the following user stories: A new user comes to the screen and sees lots of stuff they don't understand. They realize that this is the input from the last user and realize that they should push the "back to start" button to clear the session. A user is in the middle of a session. He is curious ...


3

Standards don't matter if your goal is speed on this extremely simple screen. It seems like the ideal scenario for simple a/b user testing. Gather timing data for each version. If one is completed significantly faster than the other then you have your answer.


3

Firstly I'd say you have a legal team who appears from the outside to be protecting themselves more than helping you and your users. That they are forcing on your users constraints that are extremely uncommon makes this a difficult task. To answer your question depends greatly on your target hardware. If you're looking to deploy on infrared plane touch ...


3

We have to answer one big question here: Is it actually important for users to understand the full disclosure, or do you want them just to say they did? They're two different answers, because it's unlikely and unreasonable for people to read the full disclosure (and it's often used as a way to force unpopular constraints on a user if they just click though ...


3

Often when terms-of-use or license agreements are presented there is a checkbox to the effect of "I have read and agree..." that must be checked before the process can continue. And often one is not forced to scroll all the way through something before indicating agreement. Unless you feel there's a legal reason to force people to scroll down I wouldn't do ...


3

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


3

A kiosk application by definition should not expose its underpinnings. As a kiosk user, I should not have to understand the UI conventions of an existing platform to make the kiosk application easy to use. A common approach would be a wizard style interface. It would walk and guide the user to their destination and allow them to answer questions and move ...


3

Have you looked at some of the research papers at http://www.deyalexander.com.au/resources/uxd/kiosks.html There are some interesting articles there and though they might be not specific to what you are looking from a retail perspective ,they do provide insights into the cognitive aspect of kiosk specific design and how that influences interactions


2

I agree with you that you should have a back button available at all times because without a doubt users will make mistakes. If you plan on not having a back button on your confirm page, I would have a button available to go back to the form or whatever they are filling out. Here's an example why you would want that: User fills out the form User then moves ...


2

I'm not sure what benefit you're providing by doing this. You're simply making it hard to go back/cancel the operation if I didn't mean to be there. One of the biggest usability improvements we ever made to our kiosk software was putting the "Go Back" button in a consistent location on the screen (in our case on the bottom left, just above the footer). By ...


2

I think it can be confusing. Users come to a page with a goal to update the amount and might look for the Update button right away. User will look look for it, it is not present and the users might go back to see if they picked the wrong option. Also the user might want to go back even after they typed the account, if you change "back" to "update" there is ...


2

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.


2

The start over button is not only useful for the current user. When the current user walks away from the screen and leaves the machine in a non-default state, the next user should have an easy way to start over and get the entire context of the kiosk procedure. For example a ticket machine at a train station: when the previous user already made some ...


2

I think showing the keyboard by default causes the customer to pause to think too much... why is the keyboard loaded? what did I click on to load the keyboard? what field will i be typing into if I haven't clicked on anything? this doesn't do this on my iPad at home If this is occasional use, you don't have much persuasion time to change the normal ...


1

Yes there are. They are described in detail in About Face 3 (by Alan Cooper) and maybe earlier versions as well (I can't check since I only have version 3). The main guielines are: Make your click/touch targets large enough: 20 mm should be enough. Use soft-keyboard input sparingly: awkward for user and creates lots of fingerprints (which make the screen ...


1

There are could be a bunch of cases, I don't know all of your requirements and context. There are some factors which influence user interaction: if the event registration process is momentary, i.e. requires the presence of both users at the same time and place? Then your option 2 is good. The second user could enter his data and confirm, so the first user ...


1

I would let the first user do the entire registration: they log on as normal they register for the team event at this point, the software asks them to enter the name of the second person. Similar to when you book flights online; you enter the name and password number of your partner who's flying with you, but they don't need to also register themselves. ...


1

Surely there are, but I have to think where they should be. Surely you won't be able to find them under the term UX as their UI was pretty much the way they are today by the time this term was coined. In the past, related fields were ergonomy (which belonged to psychology) and Human-Computer Interaction (HCI). Perhaps industrial design could also be a good ...


1

The biggiest drawback of your design is that a user might want to "go back" even though some numbers have been typed in. And as others has mentioned - users often handle on instinct - " This button ment this the last time so when I press it again I expect the same function". If you want a button to do dual things you should consider using it when the ...


1

In our experience the best UX improvement we ever made to our kiosk software was putting the "back" button in the same place all the time. For us, the main menu lists buttons which each link to a "home screen" for a given module. The home screens don't contain back buttons but they do contain the main menu button. The advantage of that is that the user can ...


1

I would have the back button. It establishes the navigation pattern. It is a familiar term and would also be easy to find quickly in that location. i.e. Not too far away from where their focus would have been when making the original interaction. The Main menu button is slightly different in that it will return you to the main menu from anywhere.


1

In addition to a "start over" button, as mentioned previously, an automatic time-out is a must-have feature for any kiosk system. After X period of inactivity, you should reset the app to it's "home state". However, you should also provide a time-out warning before the reset, basically asking users "are you still there?" in case they're still there but not ...



Only top voted, non community-wiki answers of a minimum length are eligible