- トースト通知の本質的な弱点は、ユーザーの現在の注意の向き先とフィードバックの位置が分離しており、直前に行った操作の結果をすぐに結び付けにくい点にある
- YouTube の保存フローでは、右側の Save ボタン、中央のモーダル、左下のトーストへと視線が移動し、インタラクションが途切れるうえ、遅延中のローディング表示もない
- チェックボックス変更後は、前のトーストが消えるまで待たないと最新の確認メッセージを見られず、トーストの Undo ボタンも、チェックボックスをもう一度押せばよい状況では不要である
- より良い方法は、フィードバックを操作位置の中に置くことであり、再生リストをボタンの下に表示し、チェックボックス変更中にローディング表示で進行状況を示せる
- トーストより悪いのは何のフィードバックもない状態なので、より良いフィードバックを設計・実装する時間がないなら、トーストはないよりはましである
トーストの根本的な問題
- トースト通知はたいてい、ユーザーの注意が向いている場所から離れた場所に表示される
- 直前に押したボタンや編集中の領域とは別の場所にフィードバックが出ると、ユーザーは操作と結果を結び付けて理解しにくい
YouTube の保存フローの問題
- YouTube の例では、ユーザーが画面右側の Save ボタンをクリックした後、画面中央のモーダルと左下のトーストを順に見ることになる
- このフローは視線を複数の場所へ移動させ、フィードバックも即座に理解しにくくしている
- トーストがローディング表示なしで遅延する
- モーダル内でチェックボックスをオン・オフすると、前のトーストが消えるまで数秒待たないと最新の確認トーストを見られない
- トーストの Undo ボタンは、ユーザーがチェックボックスを再度クリックすればよいため不要である
トーストなしで解決する方法
- 簡単な再設計だけでも、同じフィードバックをトーストなしで処理できる
- 再生リストをモーダルではなくボタンのすぐ下に表示する
- チェックボックスをオン・オフしている間、ローディング表示を見せる
- ローディング表示が消えれば、操作が完了したことを自然に分かる
- フィードバックがユーザーの操作した位置にとどまるため、別途トーストは必要ない
Gmail とコピーのフィードバック例
- Gmail でメールをアーカイブすると確認トーストが表示される
- しかし、メールが一覧から消えるだけでも、アーカイブの成功はすでに分かる
- ただし、取り消し機能やキーボードショートカットの使用時には、トーストのフィードバックが有用な場合がある
- クリップボードに何かをコピーした後にトーストが表示されるケースもある
- 例ではボタン自体がすでに確認状態を含んでいるため、トーストは完全に不要である
それでもフィードバックは必要
- トーストよりさらに悪いのは、何のフィードバックもないことである
- より良いフィードバック機構を設計・実装する時間がないなら、トーストはないよりましである
Cakedesk でトーストを避けた方法
- Cakedesk はオフラインファーストで、サブスクリプション料金のない請求書アプリであり、アプリ内でメールを送信できる
- メールの Send ボタンを押した後にトーストでフィードバックする代わりに、状態変化が同じフロー内で続くよう設計している
- 未送信の請求書には一覧に Send ボタンがある
- メール送信中はモーダルが開いたまま維持され、送信ボタンに送信中の状態が表示される
- 送信に成功するとメールが画面外へアニメーションし、送信完了を示す
- 一覧の Send ボタンは Paid チェックボックスに変わり、メールが送信されたことを確認し、次の有用な操作へつながるようにする
- ユーザーはコンテキストボタンを押して、メールが送信されたかどうかも確認できる
2件のコメント
つまり、悪いトーストが悪いってことですよね??
Hacker News の意見
https://en.wikipedia.org/w/index.php?title=Toast_(computing)
納得できない。論旨の大半は、重複した UXは悪い UX だ、というものに見える。
メールをアーカイブすると一覧から消えるので、それだけですでに成功を示唆しているとか、ボタンにチェック表示があるのでトーストは不要だ、という例には強く同意しにくい。同じ内容を同時に別の方法で伝えることはバグではなく機能であり、人間の言語全般にも存在する。理想的ではない条件でもメッセージが伝わるようにしてくれるからだ。
トーストはあらゆる操作の状態を1つの標準的な方法で知らせ、可能であれば取り消しまで提供するため、ユーザーがパターンを素早く学べるようにする。操作の近くに追加の表示を出すことにも価値はあるが、トーストと一緒にあることで意味が明確になる場合が多い。トーストをなくして複数の具体的な表示に置き換えると、ユーザーは文脈だけで「これで完了した」を意味するさまざまな表現を学ばなければならない。高齢者、視覚障害者、子どもには特に良くない可能性がある。
実際に邪魔にならない限り、トーストは悪い UX ではなく重複 UXであり、UX デザイナーは冗長性をなくすことに執着すべきではない。
YouTube の例では、チェックボックスは100%楽観的更新であり、トースト通知はバックエンドに非同期で送ったリクエストが成功したことを意味する。メールのアーカイブも同様で、メッセージは楽観的に一覧から削除され、トーストは実際にアーカイブされたことを示す。
むしろ変更のコミットに失敗したときだけトーストを受け取りたい。たいていトーストがぱっと出るのは、自分がやろうとしていることから注意を奪うし、操作した場所から画面上で離れているほどさらに気が散る。
ユーザーの注意がすでに向いている場所にメッセージを置くべきだ。UI が私の視線をそこへ誘導したのだから、そこに表示せよ、ということだ。
教訓は、厳密に必要でない情報をユーザーに送るな、ということだ。
追加の読み物:
https://en.wikipedia.org/wiki/Banner_blindness
https://en.wikipedia.org/wiki/Alarm_fatigue
https://en.wikipedia.org/wiki/Inattentional_blindness
https://en.wikipedia.org/wiki/Habituation
トーストは最悪の場合、文脈なしにユーザーへ伝えなければならない最後の手段としてなら筋が通る。たとえば、ユーザーがプレイリストのチェックを外し、保存中にプレイリスト一覧を閉じたところ保存に失敗したなら、操作の文脈は消えているので、画面のどこか任意の位置に情報を出すトーストも理解できる。
それでもユーザーにエラーをきちんと理解してほしいなら、トーストが最善ではない可能性が高い。YouTube のようにユーザーが商品である広告ベースのアプリでは、ユーザーがこうしたエラーを見逃してもあまり気にしない、あるいはむしろ望むことすらあるかもしれないが、業務用アプリなら、ユーザーがトーストを見逃したり別のエラーと混同したりすることに賭けたくはないはずだ。普通は、該当する要素を再び開いて、文脈の中でエラーを見せるほうがユーザーの助けになる。プレイリスト一覧を開き、変更が保存されなかった事実に注意を向けるアニメーションを付けることもできる。体系的に実装するのは難しい理想論かもしれないが、理想的には常に文脈内のエラーを見るべきだ。
最も悪い点は、トーストがあまりに早く消え、成功して当然の操作にまで不要に注意を引くことです。この2つが組み合わさると特にいら立ちます。注意は不必要に奪われるのに、あまりに早く消えるため、本当に重要な内容ではなかったのか分かりません。逆に、長く残りすぎて、すぐ見て使おうとしていたUIの一部を覆ってしまう変種もあります。
伝統的なデスクトップ方式がよいです。エラーメッセージは見逃さないようにモーダルで表示し、成功メッセージは時間制限なく常に表示されるステータスバーに、邪魔にならない通常のテキストとして表示する方式です。エラーモーダルがなければユーザーは操作が成功したと考えられ、確認が必要なら時間に追われることなくステータスバーで確認できます。付加情報も載せられます。
一部のアプリでは、ステータスバーのメッセージ履歴をポップアップで表示することもあります。この方式では、ステータスバーはコマンドライン端末の最後の出力行のようなもので、以前の出力も呼び出せます。
見逃した内容を確認しようとして通知を開くことがよくあります。重要そうに見えたものの、読み切る時間が足りなかったからです。そこで、途中で切れたメッセージのように見える項目を押せば全体の文脈に移動するだろうと期待しますが、実際には通知が消えてアプリが開くだけで、その問題へディープリンクされません。すると、アプリの標準UIの中で表示されるかもしれないし、されないかもしれない問題を探し回らなければなりません。
こういう経験を数え切れないほどしており、そのたびにこのようなシステムを設計した人に腹が立ちます。
今日、息子とこの問題に遭遇しました。子どもは読む速さを練習中で、新しいアプリを一緒に使っていたのですが、トーストが次々に出て追いかけるのが難しく、気が散っていました。結局、私が声に出して読んであげる必要がありました。もっと長く残るメッセージであれば、追加の助けなしでもうまくいったはずです。
YouTubeにはもっとよい例があります。
https://www.youtube.com/feed/historyに行き、右側の「Comments」を押してからコメントを1つ削除してみると、削除予定であることを示すトーストが1つ表示され、1〜2秒後に削除されたことを示すトーストがもう1つ表示されます。
複数のコメントを素早く連続して削除すると、まず削除予定のトーストが複数表示され、1〜2秒の遅延の後、それぞれの確認トーストが順番に表示されます。実際の削除も逐次進むため、すべての確認トーストを待たなければなりません。コメント10件を2〜3秒でクリックしたとしても、確認には10秒以上かかります。
ライブチャットのコメントも同じです:
https://myactivity.google.com/page?page=youtube_live_chat&co...
「トーストのUndoボタンは、ユーザーがチェックボックスをもう一度クリックすればよいので不要だ」という部分には、一般論としては同意しません。誤ってどこかをクリックしたが正確にどこか分からず、メッセージを見ただけで簡単に元に戻せるほどアプリに詳しくない場合、取り消しは非常に有用です。
極端な例として、背を向けている間にボールが棚から転がり落ちてキーボードに当たったとしましょう。何かが変わったのか。何が変わったのか。どう直せばよいのか。
トーストが意味を持つケースは一つだけです。ユーザーの現在の操作とは関係のない通知である場合です。今はなくなった Growl が作っていたOS型の通知に近いケースです
ユーザー操作へのフィードバックは、その操作の文脈の中で行われるべきです。非同期操作ならその事実が明確であるべきで、フィードバックは直ちにその作業が処理キューに入ったことを示すべきです。この場合、フィードバックはキャンセルやキューへのアクセス、さらに望ましくは進捗状況を見られる選択肢を提供すべきです
ボードからタスクを削除したなら、そのタスク上に元に戻す方法を表示することはできません。キーボードショートカットで取り消すことはできますが、ユーザーは視覚的にどうやって知るのでしょうか？
タスクリストにはタスクだけがあるべきなので、タスクの代わりにノートを入れることはしないでしょう。メッセージだけを表示する派生タスクのようなものも作らないでしょう。そうすると、タスクコンポーネントに機能のない意図を注入することになります。ユーザーにまったく知らせないのも嫌です。タスクが削除されたことは明白ですが、1クリックで起きた不安な操作をどう元に戻すかは明白ではないからです。だからといって、タスク削除の前に毎回うっとうしく確認を求めることもしないでしょう。タスクリストの中核機能なので、即座に実行され、即座に取り消せるべきです
こうした小さな特殊ケースはたくさんあるはずです。トーストは理由があって発明されました。人々がかわいらしく乱用したからといって、特定のシナリオで具体的に有用でないということにはなりません
こうした操作には画面上の文脈がなく、しばしば追加の行動が必要です。追加の行動がない場合でも、ユーザーの操作が検知されたと確認してくれるのは明らかに有用です
混乱した人のために言うと、この記事は焼いたパン [1] ではなく、UIウィジェットの一種 [2] についての記事です
[1] https://en.wikipedia.org/wiki/Toast_(food)
[2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)
ページで最も重要な単語なのに、技術系の読者の中にもこの専門用語を理解していない人がいるのは明らかです
ただし、ベーキングや朝食レシピに関心のある読者のおかげで、エンゲージメントはさらに上がったかもしれません
「トーストのUndoボタンは、ユーザーがチェックボックスをもう一度クリックすればよいので不要だ」について言うと、私はこの機能を特にありがたく思っています。メールをアーカイブしたつもりが、トーストで自分がスパム報告ボタンを押したと知らされたことが数えきれないほどあります。そうでなければまったく気づかなかったでしょう
原文が見落としているトーストのもう一つの根本的な問題は、Webの操作が非同期だという点です。操作が成功したのか、失敗したのか、サーバーに登録されてさえいるのか分かりません。トーストはサーバー状態についての非同期更新を与えます
もちろん、邪魔なトーストがあり、重要なUI内容を覆いながら閉じることもできない場合がある、という点には同意します
だから、何かを誤って押したらメールが突然受信トレイから消えた場合、取り消しボタンのあるトーストが必要です。ただじっとしていて、体がボタンに寄りかかって突然トーストが表示されたなら、それがあってよかったと感じるでしょう。できれば、実行された操作の説明と取り消しボタンがあるべきです
GimpでTabを押すとUI全体が隠れ、ショートカットを知らなければ戻す方法がありません。画像に集中して見たいアーティストにとっては望ましい機能です。しかし誤って押してしまい、「gimp how to fix interface disappeared」と検索しなければならなかった瞬間、undoボタンのあるトーストがどれほど欲しかったか分かりません。コンピューターに慣れていない人ならどう反応したか、想像もつきません
トーストは悪いUXになり得ます。たいていは、それが唯一のフィードバックである場合ですが、他の要素と一緒に使えば優れたものになります
ページリダイレクトと一緒に表示される確認トーストは、送信が成功したという追加の表示として有用です
標準のフォーム検証表示と一緒に表示される警告やエラーのトーストは、ユーザーが何かを変更する必要があるという優れた二次的な表示になります
特定されていないエラーを包括的に処理する用途で実装すれば、エラーページに送らずにユーザーのページ状態を保持できます
唯一の道具ではなく、道具箱の中の一つの道具として使えば、よい選択肢です
トーストよりもっと悪いものがある。隠しスライドパネルだ。基本的には隠されたトーストなのに、ある操作には必要でありながら、まったく直感的ではなく、見つけることも発見することもできない。最悪の体験は、他人のスマホで Waze を使っていたときだった。何かをしなければならなかったが、それが何だったかは覚えておらず、画面をぼんやり見ながら何をすればいいのか推測するだけだった。結局、その人がスマホを取り、右側から隠しパネルをスライドして見せてくれた
スペースを節約するのは理解できるが、本当にあり得ない。UX の専門家は、ユーザーがそれをどうやって推測すると期待しているのか？最近の UI は、子どものようにあちこちつつき回して発見する人を前提に作られているのか？
Discord のモバイルアプリは以前、左と右の両方のサイドバーでこの方式を使っていたが、ある時点で誰かが「スワイプして返信」ジェスチャーはアプリ内ナビゲーションより重要だという素晴らしい考えに至り、今では右サイドバーを見るには小さく曖昧なボタンを押さなければならない
「隠しパネル」については、ずっとバグだと思っていたが、誰かは良いアイデアだと考えていたのかもしれない
App Store でアプリを管理する Apple Connect アプリをよく使う。iPad Mini を縦向きで使っていて、自分のアプリの一つを選ぶと、戻るボタンがよく消える。すると別のアカウントを選ぶことも、現在のアカウント内の別のアプリを選ぶこともできない
iPad を物理的に横向きに回転させるまではそうだ。そうすると左側にナビゲーターが現れ、別のアプリを選んだりアカウントを切り替えたりできる
正直なところ、Apple App Store バックエンド全体の UX にはかなり失望している。フロントエンドもそれほど気に入ってはいないが、バックエンドは常に使う場所だ。プラットフォームの他の部分のユーザー体験にあれほど気を配っていることを考えると、かなり衝撃的だ