エラーアラートについて考える
Human Interface Guideline にはアラートの表示に関して次のような記述があります。
Write a title that clearly and succinctly describes the situation. You need to help people quickly understand the situation, so be complete and specific, without being verbose. As much as possible, describe what happened, the context in which it happened, and why. Avoid writing a title that doesn’t convey useful information — like “Error” or “Error 329347 occurred” — but also avoid overly long titles that wrap to more than two lines. If the title is a complete sentence, use sentence-style capitalization and appropriate ending punctuation. If the title is a sentence fragment, use title-style capitalization, and don’t add ending punctuation.
Include informative text only if it adds value. If you need to add an informative message, keep it as short as possible, using complete sentences, sentence-style capitalization, and appropriate punctuation.
日本語訳
簡潔かつ明確に状況を説明するタイトルにする。 ユーザに状況を素早く理解してもらう必要があるので、冗長な表現を避け、漏れなく具体的に記述します。できる限り、起きたこと、起きた状況、起きた理由について説明しましょう。「エラー」や「エラー329347が発生しました」のような、有用な情報を伝達しないタイトルにはしないでください。2行を超えて折り返されるような長すぎるタイトルも避けます。タイトルが完全な文である場合は、センテンススタイルの大文字化(英語の場合)を使用し、適切な文末記号を付けます。断片的な文をタイトルにする場合は、タイトルにふさわしい表現にし、文末記号は付けないようにします。
ここには具体例がなくていまいちイメージが難しかったです。
次の記事が Good/Bad の例がありイメージしやすくなりました。
Human Interface Guideline が更新されてしまったので、記事中のリンクを辿っても下記説明に辿り着けませんでした。
記事の原文を元に Human Interface Guideline に記載されていたであろうことを想像して抜粋してみます。
Write an alert message that describes the alert situation clearly and succinctly. An alert message such as “An error occurred” is mystifying to all users and is likely to annoy experienced users. (…) Write informative text that elaborates on the consequences and suggests a solution or alternative. Give as much information as necessary to explain why the user should care about the situation. (…) Informative text is best when it includes a suggestion for fixing the problem. (…) Express everything in the user’s vocabulary. An alert is an especially bad place to be cryptic or to use esoteric language, because the arrival of an alert can be very unsettling. (…) It’s a good idea to avoid using OK for the default button. The meaning of OK can be unclear even in alerts that ask if users are sure they want to do something. For example, does OK mean “OK, I want to complete the action” or “OK, I now understand the negative results my action would have caused”?
In the same way that it’s best to work with a professional graphical designer on the icons and images in your app, it’s best to work with a professional writer on your app’s user-visible text.
翻訳記事の対応する日本語訳
警告が必要となった状況を明確かつ簡潔に説明したアラートメッセージを書く。 “エラーが発生しました”のようなアラートメッセージでは、誰が見ても分かりにくいばかりでなく、経験のあるユーザほど混乱させることになる。(中略) 結論を詳しく説明する参考情報のテキストを書き、解決策や代替案を提示する。 ユーザがその状況に対処しなければならない理由を説明するために必要とされる十分な情報を提示する。(中略)参考情報のテキストには問題を解決するための提案が含まれているとベスト。(中略)一貫して ユーザに分かる言葉で表現すること。 アラートが出るだけでもユーザを非常に動揺させるため、アラートは不可解であったり、難解な言葉を使ったりすることは特に避けるべき。(中略)デフォルトのボタンとして“O K”を使わない方が良い。“O K”の意味は、ユーザが何かをすることについて、“しても良いかどうか”を尋ねるアラートであったとしても明確なものではないことがある。例えば、OKは“OK、アクションを完了したい”なのか、“OK、私の操作によって起きた良くない事態を今理解した”なのか、どちらでしょうか?
アプリケーションのアイコンやイメージを作り上げる際にはプロのグラフィカルデザイナーと一緒に取り組むことがベストな方法であるのと同じように、あなたが作成中のアプリケーションでもユーザが目にするテキストを決定する際にはプロのライターと一緒に取り組むことがベストなのです。
戻って現状のガイドに示される「簡潔かつ明確に状況を説明するタイトルにする」については、以下の部分に相当すると思います[1]。
Secure Empty Trash permanently erases the items in the Trash. Are you sure you want to permanently erase them?
“確実にゴミ箱を空にする”を使用すると、“ゴミ箱”にある項目が完全に消去されます。完全に消去してもよろしいですか?
非常に明確な例だと思います。こういう風にタイトルをつけると良いのですね。
-
macOS では No Title で iOS の Title 部分が macOS のメッセージに相当するものとして読み替えています ↩︎
ゆめみ iOS 研修課題へのフィードバック
以前の Human Interface Guideline のキャッシュらしいページ
GitHub リポジトリ
Alert は次の Modality に含まれる表現です。
モダリティとは、専用のモードでコンテンツを表示してユーザの注意を喚起するデザイン手法です。親ビューを操作することはできず、明示的にアクションを行わないと閉じることはできません。
English
Modality is a design technique that presents content in a separate, dedicated mode that prevents interaction with the parent view and requires an explicit action to dismiss.
Apple の iOS でアラート表示。 Find My を機内モードで起動した時
Apple Map App の機内モードで起動して Weather App の小さい View がオーバーレイして表示されていそう。この表現はアラートではない? どちらかというと前述と同様のエラービューなのか
どのアプリか忘れてしまった
Apple Music
TestFlight は開発者よりのアプリなので、 Retry を促している。この表示を見たらユーザが設定や環境を見直してリトライすることを期待していて、それが妥当な判断となっていそうか
iTunes Store
ライブアクティビティを使っていそう
通信状況の最新情報を表示するという適切な選択と思って良いだろうか。アラートと大きく異なるのは、ユーザの操作を中断しない点。かつ仮にオンラインに変われば、その状態を更新して表示し、閉じるという優れもの。 iOS の標準的な表現になりそうなら、研修課題にも追加してもみても良い気がした。
Apple Store エラービューかつ復帰の導線もない。良いのだろうか
Apple Support
エラービュー+リトライボタンと問い合わせボタン( Apple のアドレス帳が開く)
キャッシュがあるとアラートが表示されることもあった
Apple Watch
アラートを表示している
キャッシュがあった影響かもしれない
どのアプリか忘れた
ライブアクティビティ
Apple TV
エラービュー
Apple Home
エラービュー+リトライボタン
Apple Books
エラービュー+リトライボタン
Apple Maps
プレースホルダー+控えめに上部にAirplane Mode is on
Apple Reminders
削除したけど iCloud には残っているとアラート表示
「削除されたリマインダーは、完全に削除される前に最大40日間iCloudに残ります。」
ホーム画面からアプリを取り除くときの確認アラート
Delete App を選択すると削除確認アラート
他のアプリとはメッセージが FaceTime 向けになっていて、アプリを削除しても通話と発信は可能とのこと
自作のアプリの削除確認アラート
FaceTime と異なる一般的なメッセージが表示される
Material Design 3
Alert は Dialogs の使い方の一つとして触れられている
Guidelines に Do or Don't の例があってわかりやすい
Do
Use dialogs for prompts that block an app’s normal operation, and for critical information that requires a specific user task, decision, or acknowledgement
アプリの日常的な操作を中断する対話や、特定のユーザタスク、決定、もしくは同意に必要となる重要な情報には Dialogs を使用してください
Don't
Don’t use dialogs for low- or medium-priority information. Instead use a snackbar, which can be dismissed or disappear automatically.
低または中くらいの優先度の情報に Dialogs は使用しないでください。代わりに Snackbar を使ってください。消去できるし、自動的に非表示にもできます。
Do
This dialog title poses a specific question, concisely explains what’s involved in the request, and provides clear actions
このダイアログのタイトルは、具体的な質問を提示し、リクエストに関わる内容を簡潔に説明し、明確なアクションを提供します。
Don't
Don’t use dialog titles that pose an ambiguous question
ダイアログのタイトルで曖昧な質問をしないでください。
Do
Present non-critical information using other UI within the flow of app content
重要でない情報は、アプリのコンテンツの流れの中で他の UI 使って提示してください
Don't
Avoid putting non-critical information in a dialog
ダイアログに重要でない情報を置くことを避けてください