Open vs close questions
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:
- When would you like to meet?
- Shall we meet at 5pm, 6pm or 7pm?
- Shall we meet at 6pm?
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?
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
n input also accept
no although I'd think of it more as an error guard and won't spell the options on the interface.