web-dev-qa-db-ja.com

コマンドラインのyes / noプロンプトで単に「y」を受け入れるのではなく、Word全体を「yes」と入力するようにユーザーに要求するのが適切なのはいつですか？

OpenSSHを含むいくつかのコマンドラインアプリケーションを見てきました。これらのユーザーは、yes/noプロンプトでWord全体のyesまたはnoを入力する必要があり、yのような1文字の入力を拒否します。次に例を示します。

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.

これは良い考えですか？もしそうなら、いつこれを行うべきですか？そうでない場合、yes/noプロンプトをこの方法で実装する技術的な理由は何でしょうか？

更新

確認プロンプトのソースコード は次のとおりです。

/* 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;
    }
}

これは、プロンプトでのバッファオーバーフローから保護することを目的としていると思います。これは、OpenSSHのようなセキュリティが重要なアプリケーションにとって特に重要です。空白の入力は「no」として扱われますが、yもnも有効な入力として受け入れられません。しかし、これはUXの観点から適切な決定ですか？

inputconfirmationcommand-lineprompt
23
bwDraco

ユーザーが回答している質問のコンテキストとは何ですか、どのような意味がありますか？これは、「Y」と「YES」（または「N」と「NO」）の適切性を導くのに役立つ重要な質問です。

この場合、あなたはRSA証明書を扱っていますが、これは大きな問題です。意図しない証明書を受け入れることは深刻な影響を与える可能性があるため、ユーザーが回答方法を正確に理解していることを確認することが重要です。 「yes」以外の入力は、safestオプションであるため、負の値として扱われます。

GUI環境では、最も破壊的でないオプションをデフォルトにすることが最適です。たとえば、「削除してもよろしいですか？」ダイアログの上には、デフォルトで「いいえ」オプションが必要です。ユーザーが何も考えずにreturnキーを押すために競争する場合、システムが予期しないことをシステムが実行していないことを確認したいと考えています。

この「煩わしさ」は、ユーザーを保護するために行われます。ユーザーがエラーを犯した場合、システムは最も安全な方法でプロセスを終了します。それがユーザーの希望に反する場合は、手順を簡単にやり直すことができます。 （最初に「yes」と入力しなかったため）RSA認定プロセスを2回実行しなくても、1日が無駄になることはありません。

コマンドラインを使用する人は、よく考えずに「y」+「return」を押す習慣を簡単に身に付けることができます。 「はい」または「いいえ」を要求すると、ユーザーはさらにプロセスに従事する必要があります。システムが実行しようとしているアクションが、ユーザーの理解を確認することが重要であるほど重要であることを確認したい場合は、適切なUX決定です。

35
Evil Closet Monkey

この質問に対するより一般的な答えは、ここでは2つの異なる設計上の考慮事項を扱っているということでしょう。

まず、質問が答えよりも重要であるかどうか、または両方がユーザーによって最大限に理解されるように設計されるべきかどうかについて話します。質問の文言が適切である場合、ユーザーが誤って間違って回答したり、気が変わったりするのを防ぐには不十分であるように思われます。その場合、保護は二次検証（Gmailのような元に戻す機能）になる可能性があります。 ）。一方、答えを入力することをより困難にすることは、前のステップの両方を組み合わせるようですが、簡単な質問に入力を提供する手段としてはかなり非効率的です。

第二に、ユーザーの期待を管理するのは簡単ではありませんが、タスクがいかに重要であるかという文脈の中で、デザイナーはこれらの措置を受け入れ、許容することについてユーザーにもっと信用を与えることができると思います。そうは言っても、ユーザーの決定にどのような影響があるかは明確にしておく必要があり、可能であれば、変更を簡単に元に戻したり元に戻したりする方法をユーザーに提供する必要があります。

余談ですが、重要な決定の入力を少し長くすることをお勧めします（あまり頻繁に行う必要がない場合）。一瞬の決定とより多くのことを行うことで、私たちの考え方は異なるためです。考える時間。少なくとも時間がかかる場合は、情報を複数の方法で処理するため、長期的に見れば間違いや考えの変化が少なくなります。

1
Michael Lai