User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
In something like a console application, is it better, when asking the user if they want to retry, or add another object, etc., to accept which of the following: (after taking only the first letter outputted to lower case)
Please ask if you need a bit more clarification as to what I'm asking.
Here an advice you'd find sometimes with child education:
It is better to provide a child with a specific set of options, instead of leaving it to them to work out the options themselves.
For example, instead of asking your child "What would you like to eat?" ask her "Would you like an omelette or rice?".
The argument is that children are yet to develop a rehearsed cognitive recall ability - so open questions can baffle them and possibly turn them decision-shy.
(Having said that, at the same time open questions are encouraged in many situations with children as they promote creative thinking and problem solving skills: -"Mummy, what does this button do?" -"Well, what do you think it might do?" and from here you guide them to the answer.)
Adults, while much better and rehearsed at recalling things, also have a problem with open questions per Hick's law.
Say you wish to arrange a meeting with a friend, which of the following is likely to yield a quicker decision making:
I hope you suspect the last one will. You might find that some people are well aware of this concept and use it as a technique for nudging others.
So when you ask a user a question but not making the possible answers clear, it's a bit like asking a child an open question, to which the (possibly subconscious) response might be: "How am I suppose to know what to answer this? What are my options?".
Providing the possible answers with the question solves this issue:
Would you like to continue [y/n]?
There are a multitude of design principles and evaluation technique that suggest designers ask the following questions (eg, Cognitive walkthrough):
Can the user tell what action needs to be taken in order to progress with the task?
And also:
Are these actions visible to the user?
"Would you like to continue?" means the answer for both questions will be 'no'.
"Would you like to continue [y/n]?" means the answer for both questions will be 'yes'.
Another issue that comes into mind is that of constraints, which are often put in place to prevent user errors.
If you don't list out the possible options [y/n], it's down to the users to guess what answers might be; and they may be wrong! You should expect a multitude of errors unless you actually limit the input to a limited set of values.
You could, of course, in addition to y and n input also accept yes and no although I'd think of it more as an error guard and won't spell the options on the interface.
I would generally say it depends whether which of the following is more important:
If 1 then go for your second option, if 2 then go for your first option.
Regardless of which one you pick, provided you stick to the same throughout your application then I would say it doesn't matter. However, I usually go for 'y' to continue and 'n' to stop/cancel and anything else gets ignored (maybe with a message).
If possible I suppose it would probably be user friendly to give at least a suggestion of what answers are expected / accepted. This could be as little as [y/n].
Otherwise after my opinion you would probably run the risk that users wouldn't answer at all since we're so used to clicking buttons. But that might of course depend on the context, the type of application and the related target audience.
Typically these kind of text-based (command line) workflows will have prompts, a la (y/n)?, that make it pretty clear what the application expects. I would say to stick with this familiar pattern.
Under the hood you could account for case differences or complete spelling of Yes or No (just look at the first letter), but I wouldn't take that too far (Affirmative probably shouldn't be an acceptable input =) Also be sure to provide a default option if it's not something that really needs to brick-wall the user with an input. Usually if I know a trusted command line application provides good defaults I'm OK hitting enter all the way through.
