「確認のためにプロジェクトの名前を入力してください」を使用するのはなぜですか？
あなたが長い間GitHubユーザーであれば、おそらく次のようなものを見たことがあるでしょう。
これは、公開/非公開ステータスの切り替えやアーカイブ/削除など、リポジトリに対して破壊的な可能性のあることを行うたびに発生します。
プロンプトはアクションボタンをクリックした後にモーダルで表示されるため、これは偶発的なアクションを防ぐための追加の手段です。
しかし、私に関する限り、これは「別の障壁を設定する」には効果がないか、「追加の確認」として扱いにくい。 URLまたは入力ボックスの真上（上の太字のテキスト）からリポジトリ名をコピーできますが、これは追加のボタンをクリックするよりもさらに複雑です。
私の意見では、真っ赤なエクストラモーダル button キーボードのアクション（Enterキーなど）に応答しない場合はこれで十分です。マウスを明るい赤色のボタンの上に移動してクリックすると、さらに注意が必要になります。これはそれほど面倒ではなく、Enterキーを押すだけの障害は単純かつ効果的です。
この「プロジェクト名を入力する」が優れたUIデザインであることを誰かが説明できますか？
これは必ずしも「優れたUI設計」ではなく、誤って削除されないようにするためのすべての対策を講じ、ユーザーが削除対象を完全に認識していることを確認する。
ここのこのブログエントリはそれを非常によく捉えています：
誤って押す可能性がある確認ボタンをユーザーに提供する代わりに、テキストフィールドを提供し、「削除」という単語を入力して確認するようにユーザーに要求します。ユーザーがテキストフィールドに「削除」と入力した場合、ユーザーが削除することは間違いありません。誤って削除ボタンを押すことはありません。ユーザーが削除する前に、何をするかを確認テキストフィールドで確認できるので、ユーザーが削除しても後悔はありません。
ユーザーが誤って削除しないようにする方法-UXの動き
確かに、ボタンを押す方が簡単ですが、常に名前を読み間違え、間違ったアイテムを削除する可能性があります。
名前を入力する（またはコピーして貼り付ける）必要がある場合、ユーザーが誤ってそれをしないことが99％確信できます。彼らは遅くともコピー・ペーストの名前を強調表示したときにそれを理解するでしょう。
さらに、これは通常、非常に重要な削除操作にのみ使用されます。これらは非常にまれにしか発生しないので、それを簡単にするか、または煩わしさを減らすことについての議論は、実際には成り立ちません。
関連する質問は次のとおりです。
明確に「良い」UIデザインであることは、ユーザーが望むものをユーザーに提供することを意味するものではありません。多くの場合、ユーザーが自分のより良いバージョンになるのを助けることを意味します。
既に述べたことに加えて、このパターン（およびいくつかの類似パターン）により、UIの速度が低下します。一般に muscle memory-> speed-> mistakes-> sad path。
あなたがヘルスケアで働いていると想像してみてください。ユーザーが一般的なタスクで「フロー」を作りすぎると、誰かを殺す単純な間違いをする可能性があります。直感に反しますが、インタラクションを必要とすることでユーザーをフローから引き出すのは良いことです（常に同じ場所に表示され、筋肉のメモリに追加できる単純な確認ダイアログ以上のもの）。
テキストの入力は、この一例にすぎません。私も見ました：
- ボタンが使用可能になる前にボタンにタイムアウトを追加する。
- プロセス継続ボタンの配置をランダム化します。
- ロックの追加（例：パスワードを使用して管理者としてプロセスを実行）
これらのパターンはすべて、ユーザーが前に進む前にプロセスを精神的に評価するのをやめるのに十分な迷惑をかけることを目的としています。
これは、次のことを確実にするためです。
- あなたは自分がしていることの危険性を理解しています。
- 最も重要なことは、正しいリポジトリを実際に削除していることです。
ユーザーが長い名前のリポジトリをたくさん持っている場合、それらを混同するのは簡単です。名前を入力することは、間違った名前を核にしないようにするための良い方法です。これは本当に悪いことです。
未使用のキーボードキーを（AutoHotKeyを介して）断続的に使用するために左マウスクリックとして再マッピングし、マウスの手首の使いすぎによる負担を軽減し、マルチタスク時に間違ってその場所でそのキーを押すことがあります。また、マウス自体をたまにぶつけたり、ダイアログのボタンを誤ってクリックしたりすることもあります。
「私に考えさせない」は非常に良いルールですが、ユーザーがまれに破壊的なコマンドを実行することで実際に実行されることに正確に集中できるようにするのは理にかなっています。ユーザーに、「iBug/example-repositoryリポジトリを、Wiki、問題、コメントを含めて削除してください」というフォームの全文をそのまま入力することを検討して、ユーザーの意図を明確にしますthemselves =その状況では、ユーザーはそのリポジトリで一度だけそれを行うため。
実際にコードを書く人は、完全で明確な、正しくスペルされたテキスト行を非常に頻繁に入力する必要があるため、プロジェクトで実行できる最も破壊的なアクションを確認するために、そのような行をもう1行入力することは不合理ではありません。
私の意見では、キーボードのアクション（Enterキーなど）に応答しない明るい赤いボタンを備えた追加のモーダルで十分です。マウスを真っ赤なボタンの上にmoveしてボタンをクリックして、さらに注意を促す必要があります。これはそれほど面倒ではなく、Enterキーを押すだけの障害は単純かつ効果的です。
（強調を追加）
あなたは彼らが「マウスを動かす」必要があると確信しています？毎回？解像度の異なるデバイスを使用している場合でも、想定どおりに表示されないことがありますか？または、ズームインされている場合は？タッチ入力はどうですか？マウスを使用していない人はどうですか（能力の違いなどにより）？次に、アクセシビリティを損なうことなくキーボードに応答することを確認する必要がありますが、誤って削除することはできません。
無差別に次のベストプラクティスsimplyに対する反対意見があります（それらがベストプラクティスであることによる）場所）または少なくとも「他の人が何をしているか」、特に彼らが常に実際にはそれほど優れていない場合、私は通常彼らが最高になっていることを指摘したいと思います予期せぬ問題が発生するため練習してください。そして、それらのポイントが分からないからといってそれらに対抗しようとすることは、通常は悪い考えです。広く/広く採用されているベストプラクティスであるものを検討する場合は、それが意味があり重要であり、おそらく長期間にわたって（おそらく1人だけではなく、より多くの人々の間で）発生した強力な根本的な理由があるという仮定から始めます。一人以上でレビューされた）あなただけではおそらく同じ問題のセットに専念している（そしてあなた自身の視点だけがあなたを導く）。グローバルな整合性の問題は言うまでもありません。
@ BigChairの回答 とともに @ Bryce Howitsonの回答 両方なぜこれが一般的に回復不能なアクションのベストプラクティスであるのかを詳しく調べます。 UI設計では、回復不可能な重要なアクションに摩擦を生じさせることが重要であり、これらはどちらもこのコンテキストのトピックを非常によくカバーしています。
ただし、可能な場合、ただし、実装が可能である場合は常に別のパスを使用することをお勧めします。
そもそもアクションを回復不能にさせないでください
そうは言っても、前進する最善の方法は、ユーザーアクションが回復不能なソフトウェア状態そもそも。ソフトウェアを使用するユーザーにUIが公開するものは、ソフトウェアが内部で行う状態と1：1の関連するセマンティクスで一致する必要はありません。関連するアクションをアクティブ化したときに起こることの技術的な実装と一致しないように、それを使用している人に何かがどのように表されるかは問題ありません。
ユーザー入力のみに基づいて、ソフトウェア表現でそれらをdeleteしないでください。 マークそれらをストレージ表現から削除し、それらを取得する手段を提供します（ごみ箱など）。製品を使用している人が自分自身を取り戻すことができないコーナーに戻ることができる状況の作成を許可しないでください。可能な限り、これらのタイプの確認の必要性を回避することは、UXが優れているだけでなく、関連するサポートの問題（UXの側面でもあります）におけるサポート要件と関連する摩擦のレベルを削減します。誰かが何かを「削除」しているときは、十分に明確にして、アクションの実行中とその後の両方で、実行したアクションを元に戻すこともできることを確認します（つまり、がまで、画面を読み取らずにアクションを実行せずに何かを誤って「削除」した場合、元に戻す場所を確認できます）。
私はすでに私が偶然の間違いと呼ぶものを作りました：
- ボタンを押した2番目の手をシフトしました（「キャンセル」が必要で、「OK」になりました）。または、広告がポップアップしてページが移動しました。
- 指示がわかりにくいので、間違ったボタンを押しました（もちろん、それほど破壊的ではありません）
- 私は「ああ、いやいや」で、パニック状態で間違ったボタンを押しました
- 私はそうかもしれないし、そうでないかもしれない Juan Pablo Davila
これが、私がそのような場合に、筋肉の記憶が示唆するものとは異なる行動をさせるプロセスを本当に好む理由です。
Githubがここで実行しようとしているのはユーザーエラーを回避することですが、ドンノーマンが日常のデザインで言及しているように、具体的には「スリップ」します。
スリップは、ユーザーが1つのアクションを実行しようとしたときに、最終的に別の（多くの場合は同様の）アクションを実行するときに発生します。たとえば、「o」の代わりに「i」を入力すると、スリップとしてカウントされます。誤って練り歯磨きの代わりに歯ブラシに液体ハンドソープを塗ることもスリップです。スリップは通常、ユーザーがオートパイロットを使用しているとき、および注意リソースを手元のタスクに完全に費やしていないときに作成されます。
引用の最後の部分は特に関連性があると強調します。
Nngroupの次の記事では、スリップを防ぐ方法について説明しています。
スリップタイプのミスは、多くの場合、現在のプロセスに非常に精通しているエキスパートユーザーによって行われます。システムの使い方をまだ学んでいる新しいユーザーとは異なり
https://www.nngroup.com/articles/slips/
Githubを使用する人々のタイプを考えると、彼らは GDS Digital Inclusion Scale のようなもので非常に高いと考えます。これは、彼らがスリップをする可能性が高いエキスパートユーザーであることを意味します。
次に、この2つをまとめて、プロジェクトに数百時間を費やしているが疲れているエキスパートのGithubユーザーに共感を示し、どのプロジェクトに参加しているかを忘れ、意図しないときに削除を押します。彼らはどのように感じますか？
多くのGithubユーザーは多数のリポジトリーを所有しており、削除ページでは、注意を払っていない場合、それらを区別することはあまりありません。おそらく、「100万ポンドのプロジェクト-ドラフト」リポジトリを削除するつもりでしたが、 「ミリオンポンドプロジェクト」。
これは彼らがやっていることであり、私はそれを効果的なUIデザインと考えます。回復不可能な操作の方法に役立つ制約を設けることは良い習慣です。