web-dev-qa-db-ja.com

同義語を支持して「アボート」を使用することを避けるべきですか?

「アボート」という用語は、状況によっては否定的な意味を持つ可能性があると聞きました(つまり、中絶に関連する問題が原因です)。そのため、80年代/ 90年代の一部のインターフェイスでは、おそらくDOSの普及により、この用語は回避されました。 '有名なAbort/Retry/Fail

この問題が英語圏の国で発生したのか、または「中止」という言葉がコンピューティングよりも中絶に強く関連していた(そしてソフトウェアが翻訳されていない)その他の国で発生したのか覚えていません。

いずれにせよ、それは少なくとも英語圏の国ではまだ保持されますか? 「中止」という用語が意図した操作により適しているように思われる場合でも、「キャンセル」または「終了」を使用するほうがよいですか。

37
anol

すべてのように、これはコンテキストに依存します。ただし、「中止」は、「終了」や「送信」などと一緒に、日常の会話で通常は使用されない「コンピュータワード」の1つです。これは、以前はテクノロジーを理解するためにコンピュータリテラシーコースを受講しなければならなかった理由の1つです。ありがたいことに、ユーザーエクスペリエンスとユーザー中心の設計哲学とは、人々にコンピューターに適応させるのではなく、ユーザーのために機能するようにコンピューターを設計することを意味します。

質問で述べたように、「中止」の最も明白で広く理解されている代替手段は「キャンセル」ですが、特定のコンテキストで意味のある、より「人間的」で説明的なフレーズがあると思います。

24
Matt Obee

リストされた単語は本当に同義語ですか?現在、参照を提供することはできません(おそらく、多くのソフトウェア開発者/プロデューサーもこの区別に従っていないためです)が、少なくともabortおよびキャンセルは少し異なります:

  • Cancelは通常の操作のように聞こえます。実際に開始する前に何かをキャンセルできます(設定の保存など)。呼び出す操作の選択をキャンセルします。特に、1分間キャンセルするか1時間キャンセルするかを考えると、何も変わりません。
  • 打ち切り一方、やや厳しいように聞こえます。実行中の操作を中止します。これは途中で終了し、ロールバックが必要になる可能性があります。何かを中止するかどうかの選択に直面した場合、操作がバックグラウンドで進行している可能性があるため、迅速に考える必要があります。 Abortは、「緊急ブレーキを引く」ことを意味します。

したがって、どちらの単語を使用するかは問題ではなく、いつ使用するかです。

代替案については、terminateabortのはるかに優れた代替案であると私は確信していません。特に、 terminateは、中絶について同じ意味を持つ可能性がありますabort

52
O. R. Mapper

言葉は微妙に異なる意味を持っています。

  • Stopは、何かが継続するのを防ぐことを意味しますが、必ずしも永続的にはしません。例えば。 動画の再生を停止します

  • 終了は永久に停止することを意味します。例えば。 プロセスを終了します

  • 中止は、完了する前に終了することを意味します。例えば。 中止ファイル転送

  • キャンセルは、何かを無効にすることを意味します。例えば。 サブスクリプションをキャンセルします

43

ソフトウェア開発者でもあるプロライフ政治行動委員会の元役員として:

ソフトウェア製品で「アボート」という用語の使用が不快または不快であることに気づきませんでした。プロセスを「打ち切る」とは、目的の操作を完了する機会を得る前にプロセスを強制終了することです。赤ちゃんを「打ち切る」とは、赤ちゃんが生まれる前に殺すことです。

私たちは定期的にプロセスを「殺す」ことについて話しますが、これはほとんど同じ考えです。

とはいえ、気になる人もいると思います。この用語を回避しても問題はなく、代わりに「キャンセル」や「実行を停止」など、代わりの意味を持たないものを使用します。 「Lynch」や「Rape」というラベルの付いた画面にボタンを配置しないでしょう。たとえソフトウェアが何をしていても、どれほど正確に類推してもかまいません。私はコードのコメントでそれらを使用するかもしれません...

14
Jay

歴史的に、MS-DOSの中止/再試行/無視の質問は、I/Oサブシステムが原因で、ディスクセクターレベルからファイルシステムレベルを経由して基礎となるアプリケーションに問題を報告する方法がありませんでした。アプリケーションがファイルから一部のデータを読み取るように要求し、ディスクのブロック1571が読み取れなかった場合、DOSがアプリケーションに「申し訳ありませんが、ファイルの一部が読み取れないことがわかりました」と伝えるメカニズムは定義されていませんでした。選択肢は次のとおりです。

  • 中止-アプリケーションを完全に強制終了します

  • 再試行-要求された操作を繰り返し、正常に機能することを期待します。ディスクが取り外されていた場合、最後に使用されたディスクを再度挿入しても機能する可能性がありますが、別のディスクを挿入すると悲惨な結果になる可能性があります。

  • 無視-アプリケーションにランダムなデータを与え、最高のものを期待します。

中止は「要求された操作を単にキャンセルする」という意味ではなく、「アプリケーションを強制終了する」という意味であることに注意してください。これは非常に不快な場合があります。たとえば、誤ってファイルを書き込み保護されたディスクに保存しようとした場合、そのディスクを削除し、書き込み保護タブを削除してから、再挿入して「再試行」を押すと、動作する可能性があります。または、ファイル用のスペースがない場合アプリケーションにそのことが通知される場合。ただし、ディスクが何らかの理由で書き込み禁止になっている場合は、これは適切なオプションではありません。 「無視」する回数が多いと、アプリケーションはファイルが実際には書き込まれていなくても、ディスクに書き込まれたとアプリケーションに認識させますが、アプリケーションが書き込もうとしたすべてのセクターのキーを押す必要があったことを思い出します。 「中止」を押すと、アプリケーションが完全に終了します。保存したいのは、多くの作業を行ったばかりの場合ですが、ウィンドウからコンピュータを投げたくなるかもしれません。

DOSの初期の頃は、書き込み保護されたディスクの中止/再試行/無視プロンプトが表示されたときにディスクを変更すると、システムが完了するまで書き込み保護タブが検出されなかったため、データが破損することがよくありました。どのブロックを書き込むかを決定しました。ディスクを交換すると、そのブロックが新しいディスクに盲目的に書き込まれることになります。

より現代的なコンテキストでは、「中止」と「キャンセル」は同義語と見なすべきではないことをお勧めします。 3つのソフトウェア更新プロセスを想像すると、意味の違いがわかります。

  1. 更新プロセスが完了する前のいつでも、それを中断することができます。中断すると、システムはプロセスが開始する前と同じ状態になります。

  2. アップデートプロセスが完了する前であればいつでも中断できますが、中断すると、アップグレードプロセスを最初からやり直すまで、またはアップグレードプロセスを最初からやり直すまで、ソフトウェアは役に立たない状態になります。

  3. プロセスが完了する前であればいつでも、プロセスを中断して、ソフトウェアをアップグレードプロセスが完了するまで、または完了するまで役に立たない状態のままにできますが、プロセスは中断した時点から再開できます。

上記の最初のアクションは「キャンセル」と呼びます。 2つ目は「中止」です。 3番目のシナリオでは、「一時停止」または「一時停止」と呼びます[おそらく「一時停止」とマークされたボタンがあり、「一時停止」を含む使用可能なアクションの説明が表示されます]。通常、ユーザーは最初または3番目を必要とするため、ソフトウェアは2番目のシナリオを回避するように努力する必要があります。ソフトウェアは、ユーザーに2番目のシナリオを選択させることを避ける必要があるため、通常は「中止」アクションを行うべきではありません。ソフトウェアがプロセスを正常に中断できないが、ユーザーが失礼な中断の結果を受け入れても構わない場合は、「中止」という用語が適切な場合があります。

10
supercat

はい、使用しないでください。多分...

いくつかの視点:

  • 開発者の言語とユーザーの言語AbortCancelは、開発者にとって微妙な違いがあるかもしれませんが、ユーザーにとっては、精通度よりも親しみやすさや親しみやすさなどの要素の方がはるかに重要です。

    • ユーザー言語と開発者言語の極端な例は プラセボボタン で、開発者にはまったく何もしませんが、ユーザーにより親しみやすいエクスペリエンスを提供します。
  • 中止ボタンは時間の経過と共に廃止されました。これは政治的な意味合いと関係があるかもしれませんが、より良いUXへの一般的なシフトであり、対話言語の単純化であると考えたいと思います。

    • 例:Microsoftは下位互換性のためにストックAbortボタンを提供していますが、さまざまな docs の代わりにCancelを使用することをお勧めします。メッセージボックスボタンに関するガイダンスは次のとおりです。

enter image description here

特定のアプリでは実際にAbortのニュアンスを追加する必要があるかもしれませんが、おそらくこれらの視点は、メリットとデメリットのバランスの取れた決定を推進するのに役立ちます。


Googleトレンドは実際の使用状況を示す信頼できる指標ではありませんが、興味深い見方を提供します(クリックして拡大)。

enter image description here

6
tohster

私の直感では、一般的に大したことではありませんが、代替案を考えることができれば、代替案を使用するのが賢明だと私は言います。言葉は、意図しない意味の潜在的な重大度だけでなく、コンピューティングコンテキストで誰かがこれらの意図しない意味をどのように(思わない)考えているかという点でも異なります。

例:

  • killは、その主要な意味が深刻であるため問題がありますが、言語は軍事的で殺人的な隠喩でいっぱいなので、ほとんどの場合無害である必要があります。ただし、殺害に関連する外傷の割合が高い人口統計を対象とするソフトウェアでは、Wordをおそらく使用しないでください。
  • 終了は問題ありません。これは、そのキルの意味が主要な意味ではなく、一部の特定のコンテキスト以外では通常使用されないためです。これは、誰かが単語に問題を抱えている可能性を排除するものではありませんが、これはほとんどすべての英語の単語で発生する可能性があります。
  • abortは、今日の主要な意味が妊娠の終了であるため、問題があります。ユーザーにはおそらく女性が含まれます。それらの一部が中絶(または流産)に関連したトラウマ体験をした可能性は、誰かが簡単な意味での殺害に関連したトラウマ体験をした可能性よりもはるかに高いでしょう。

killまたはabortなどの「トリガーワード」を使用する場合、ごく一部のユーザーが大脳モードから脳を切り替えるリスクがあると思います(理由)脳幹モード(純粋な本能)に数分間。これらのユーザーにとって一般的に不愉快な経験に加えて、これは不規則な入力につながる可能性があります。

問題の単語を見るのに慣れている状況では、リスクが大幅に軽減されます。たとえば、Linuxユーザーに「kill -9」を使用するように指示するか、DOSユーザーに「(A)bort」を選択するように指示しても無害ですが、このようなコンテキストを一般化したり、Wordを関連するコンテキストに転送したりします(たとえば、「kill」または「古いインターフェイスのラッパーである新しい種類のインターフェイスの[中止]ボタンは、必ずしもそうではありません。

3
user61286

感度とは別に、「アボート」自体は解釈が多すぎます。これは、ユーザーがアクションを繰り返すことができる状況でよく使用されるため、これらの回答の多くで説明されているほど最終的なものではありません。多くの場合、ファイル転送も再開できます。

即時効果を考慮して、停止、一時停止、または割り込みを使用します。操作をすぐに再開できるコンテキスト(一部のファイルのダウンロード)があるか、再起動すると一部の作業が繰り返される(最初の部分が再度ダウンロードされる)可能性があります。一時停止は、すぐに再開できることを意味すると思います。

ファイルをコピーする場合、すでにコピーされたファイルをそのままにしておくか、今のところクリーンアップして後で再試行することができます。

2
Andy Dent

Abortはより専門的な用語なので、日常的に使用しますが、それでも専門用語であり、十分な「素人」ではありません。

とは言っても、開発者がそれでいいのであれば、それを誰のために構築するかは本当に異なります。あなたが通りの外の普通の人のためにそれを作っているなら、彼らは最終的に「中止」がプロセスを停止することを意味することを理解するでしょう。

アクションを説明して、次に何が起こるかを明確にします。

それはすべてコンテキスト内ですが、「終了」の方がはるかに優れているとは思いません。

2
Choizilla

私はかつて、データのコレクションの状態(診断アプリで表示可能)を「Stillborn」と呼んでいました。これは創造的すぎることがわかりました。私は英語のネイティブスピーカーではなく、意図する意味は「ステージングが終了し、データの状態が無効または不明であり、それ以上処理できない」でした。アプリがリリースされるとすぐに、私はコンサルタント/ユーザーから強いプッシュバックを受け取り、「拒否」などのより中立的なものに名前を変更する必要がありました。

同じ診断アプリにも「中止」ボタンがあり、これは不満は言うまでもなく、コメントを上げることはありませんでした。これは正常であることが判明しました。

1
Jirka Hanika