When is it appropriate to require the user to type out the entire word "yes" rather than simply accept "y" at a command-line yes/no prompt?

Question

I've seen several command-line applications, including OpenSSH, which require the user to type the entire word yes or no at a yes/no prompt, rejecting single-letter inputs like y. Here's an example:

The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': y
Please type 'yes' or 'no': yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.

Is this ever a good idea? If so, when should this be done? If not, what technical reasons might there be for a yes/no prompt to be implemented this way?

---

Update

The source code for the confirmation prompt is as follows:

/* defaults to 'no' */
static int
confirm(const char *prompt)
{
    const char *msg, *again = "Please type 'yes' or 'no': ";
    char *p;
    int ret = -1;

    if (options.batch_mode)
        return 0;
    for (msg = prompt;;msg = again) {
        p = read_passphrase(msg, RP_ECHO);
        if (p == NULL ||
            (p[0] == '\0') || (p[0] == '\n') ||
            strncasecmp(p, "no", 2) == 0)
            ret = 0;
        if (p && strncasecmp(p, "yes", 3) == 0)
            ret = 1;
        if (p)
            xfree(p);
        if (ret != -1)
            return ret;
    }
}

I suspect this is intended to protect against buffer overflows at the prompt, which is especially important for a security-sensitive application like OpenSSH. Neither y nor n is accepted as valid input, although a blank input is treated as "no". However, is this an appropriate decision from a UX standpoint?

Answer 1

What is the context of the question the user is answering, and what are the implications? This is the important question that helps guide the appropriateness of "Y" vs. "YES" (or "N" vs. "NO").

In this case you are dealing with a RSA certificate, which is a big deal. Accepting a certificate you don't mean to can have serious implications, so it is important to make sure that the user understands exactly how they are answering. Any input, other than "yes", is treated as a negative because that is the safest option.

In a GUI environment it is most appropriate to make the least destructive option the default. For example, putting a "Are you sure you want to delete?" dialog up should have the "No" option as the default. If the user just races to hit the return key without thinking than we want to make sure the system doesn't do something they weren't expecting.

This "annoyance" is done to protect the user. If the user makes an error, the system will exit the process in the safest way. If that isn't what the user wanted, they can easily reinitiate the steps to do it again. Having to go through an RSA certification process twice (because you didn't type "yes" the first time) isn't going to destroy your day.

Those who use the command line often can easily get in the habit of hitting 'y'+'return' without thinking too much about it. Requiring "yes" or "no" requires the user to engage in the process more. It is an appropriate UX decision when you want make sure that the action the system is about to take is significant enough that verifying the user's understanding is important.

Answer 2

A more generic answer to this question might be that we are dealing with two different design considerations here:

Firstly, we are talking about whether the question is more important than the answer, or if both should be designed to ensure maximum comprehension by the user. It seems like if the question is worded well it isn't enough to prevent the user from accidentally putting in a wrong answer by mistake or a change of mind, in which case the protection could be a secondary validation (i.e. the Undo function like Gmail). On the other hand, making the answer more difficult to input seems to combine both of the previous steps but seems to be rather inefficient as a means to provide input to a straightforward question.

Secondly, user expectations are not easy to manage, but within the context of how important the task is I believe designers can give users more credit about being accepting and tolerant of these measures. Having said that, it should still be made clear what the implications for the decisions that the users make will be, and perhaps provide a way for them to undo or revert changes easily if possible.

As a side note, it is probably a good idea to make the input for important decisions slightly more lengthy (if it doesn't have to be done very frequently) because our minds work different for a split second decision versus something that you take more time to think about. At least in the case where you do take more time, you process the information in more than one way and will probably lead to less mistakes or change of mind in the long run.