Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Androidでのお知らせ
Search
Benoît Quenaudon
April 07, 2016
Programming
0
160
Androidでのお知らせ
Benoît Quenaudon
April 07, 2016
Tweet
Share
More Decks by Benoît Quenaudon
See All by Benoît Quenaudon
36・15 Cash App
oldergod
1
180
Sweet Architecture
oldergod
1
360
Architecture at Scale (droidconNYC 2022)
oldergod
2
600
Managing gRPC with Wire
oldergod
2
520
Wire & Proto3
oldergod
0
79
Effective Reactive Architecture
oldergod
2
210
Wire 3 : Tackling gRPC with Kotlin
oldergod
0
970
Server Driven UI Workflow
oldergod
2
490
Applying Rx Best Practices to Your Architecture
oldergod
1
230
Other Decks in Programming
See All in Programming
Djangoにおける複数ユーザー種別認証の設計アプローチ@DjangoCongress JP 2025
delhi09
PRO
4
500
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
280
5分で理解する SOLID 原則 #phpcon_nagoya
shogogg
1
400
Lambdaの監視、できてますか?Datadogを用いてLambdaを見守ろう
nealle
2
650
GoとPHPのインターフェイスの違い
shimabox
2
210
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.6k
Rubyで始める関数型ドメインモデリング
shogo_tksk
0
140
Drawing Heighway’s Dragon- Recursive Function Rewrite- From Imperative Style in Pascal 64 To Functional Style in Scala 3
philipschwarz
PRO
0
140
Kotlinの開発でも AIをいい感じに使いたい / Making the Most of AI in Kotlin Development
kohii00
5
1.6k
バッチを作らなきゃとなったときに考えること
irof
2
550
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
160
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
250
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Unsuck your backbone
ammeep
669
57k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Side Projects
sachag
452
42k
RailsConf 2023
tenderlove
29
1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
We Have a Design System, Now What?
morganepeng
51
7.4k
Become a Pro
speakerdeck
PRO
26
5.2k
How STYLIGHT went responsive
nonsquared
99
5.4k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
Docker and Python
trallard
44
3.3k
Embracing the Ebb and Flow
colly
84
4.6k
Transcript
Android での 適切なお知らせ #toast #snackbar #dialog
アプリ内のお知らせ方法
お知らせ種類 1. ダイヤログ 2. スナックバー 3. トースト
Dialogs ダイヤログ
ダイヤログはいつ使う? ▸ 重要な情報を伝える ▸ アクションを求める
ダイヤログ ▸ モーダルの一種 ▹ 画面の一部も ▹ フル画面も
中断を減らす ▸ ダイヤログはユーザがやっているタスクにとって 中断になる ⇒ 本当にユーザに対して中断を入れる程のものな のか?
上に表示 ▸ ダイヤログは常に上に表示する ▹ ユーザはダイヤログに対するアクションをする必要 ▸ ダイヤログから更に他ダイヤログを開かない ▸ スクロール付きコンテンツを含めない
フルスクリーンダイヤログ例外 ▸ フルスクリーンダイヤログは違うダイヤログを開い てOK ▹ 例:日にちピッカー、カラーピッカー
スクロール付きコンテンツ ▸ 場合によって仕方ない ▹ 例:ユーザ一覧 ▸ タイトルは常にトップに表示する ▹ 選択された事項がタイトルと一緒に表示するが良い ▸
アクションボタンの位置を維持 ▹ スクロールしてもボタンは移動しない
他に表示したコンテンツ ▸ 可能ならインラインで拡張する ▸ ダイヤログ以外のコンポネントを検討する
ダイヤログのクローズ ▸ ダイヤログ外をタッチしたら ▸ バックボタン押下したら ▸ 必要な場合、アクションボタンだけでクローズする ようにもできる
Alerts ▸ 緊急の時 ▸ ユーザに承知が必要 ダイヤログ
タイトル無しのアラート ▸ アラートは殆どタイトルは要らない ▸ 短い ▹ 文書は2つまで ▸ 質問を聞く ▹
例:削除してよろしいですか? ▸ 何かを申告する
タイトル無しのアラート ▸ 良い ▹ アクション名で結果がわかる ▸ 微妙 ▹ 質問の回答になっているけどク リックした後は何が起きるがわ
からない
タイトル有りのアラート ▸ リスクのある場合のみに使用 ▸ タイトルとアクション名だけでユーザが理解できる ようにする ▸ 意味のあるタイトルにする ▹ お詫び、本当によろしい?等は避ける
Simple Dialog ▸ 詳細情報 ▹ ユーザのアイコン ▸ 細かいアクション ▹ アカウント選択
ダイヤログ
シンプルダイヤログの動作 ▸ ダイヤログ外のタッチかバックボタンではアクショ ンがキャンセルされ、ダイヤログがクローズされる ▸ オプションを選択したらダイヤログが自動にクロー ズする
シンプルダイヤログ ▸ Androidだと幅の単位は56dip ▹ モバイル上の最低幅 = 280dip ▻ 56dip *
5 ▸ アクションボタンは付けない dp とは密度非依存ピクセル http://goo.gl/lCIFky
シンプルダイヤログ特徴 ▸ 行の高さは自由 ▸ 画面の真ん中に表示 ▹ top・bottomより24dip離 ▹ left・rightより40dip離
Confirmation Dialogs ▸ ユーザが選択を確認す る必要 ▸ 単一値の時 ダイヤログ
確認ダイヤログ ▸ OKを押さないとダイヤログはク ローズしない ▹ キャンセルやバックボタンでアクション が変更が破壊されクローズ
確認ダイヤログ ▸ 一覧だけじゃない ▹ でも選択できる値は 一つのみ ▸ キャンセルボタンも 確認ボタンもある
Full-screen Dialogs ▸ モバイルのみ ▸ いくつかのタスク ▹ 例:イベント作成 ▸ 「保存」を押さない限り何
も保存しない ダイヤログ
フルスクリーンダイヤログ ▸ アクションボタンは上にある ▹ アクション名は動詞にする ▸ Xボタンやバックボタンは変更を 破壊してクローズする ▸ 変更があった時のみ確認ダイヤ
ログを出す
ナビゲーション ▸ 「X」の場合は変更時に保存しないという事をユー ザに伝える ▸ 「←」の場合は常に保存し続けているとユーザに 伝える
ナビゲーション 常保存 未保存
フルダイヤログ ▸ タイトルは動的ではない ▹ 短く ▸ 長い場合はダイヤログ内に入れる ▹ 例:多言語対応の時
Specs ダイヤログ
ダイヤログの仕様 ▸ ダイヤログ= ▹ 任意なタイトル ▹ コンテンツ ▹ アクションボタン
タイトル ▸ タイトルは省略しない ▸ 必要な時だけ使用 ▸ 何が求められているかを指定
コンテンツ ▸ テキストかUIコンポネント ▸ 単一のタスクのみ
アクション ▸ 細かい、範囲小さい選択肢を提供する ▹ 意味的に「OK」か「NG」のみにする ▹ OKアクション:保存する、削除する等 ▹ NGアクション:キャンセル、リセットする等 ▸
アクションはタイトルに関してわかりやすいアク ションを指定する
アクション NGアクションはOKアクションより 必ず左へ NGアクションは先に!
▸ OKアクションは選択がされるまで無効にしても良 い
承知アクション ▸ 進むにユーザが承知する必要がある時はアクショ ンを一つだけにする ▹ 中断になるため、違う方法で情報を伝えるように
アクション数 ▸ アクションは2つまで ▹ 参考・ヘルプ系のアクションは避ける ▻ 画面が移動したらアクションが決着していないし ▹ 更に情報が必要ならダイヤログ出す前に提供する
色 ▸ 自アプリのテーマに合わせて色を決めよう ▹ デフォルトでシステムのカラーが利用されている ▸ タイトル対コンテンツは対象的な色を使おう ▹ 文字列の無い言語(日本語、韓国語など)に更に重要
Snackbar スナックバー
スナックバー
スナックバー特徴 ▸ 軽重のフィードバックを一時に伝えたい時 ▸ アクションは有り ▸ スナックバーは同時に1つしか表示しない ▸ ほとんどのコンポネントより前に表示される ▹
フローティングアクションボタンと同じレベル ▹ ダイヤログ、ナビゲーションドロワー、ボトムシーツより後ろ
スナックバー動作 ▸ 画面に下からアニメーションで現れる ▹ 現れても入力をブロックしない(中断しない) ▸ 消える方法: ▹ ユーザがスワイプする ▹
時間が経った ▹ ナビゲーションが行われた ▻ スナックバーはコンテキストに紐付いている
スナックバー中身 ▸ テキスト ▹ 複数行は可能 ▹ アイコンの利用はできない ▸ アクション(任意)
儚いスナックバー ▸ 一時しか表示されない ▹ 表示中にダイヤログとか出たらスナックバーのタイマーが リセットされる ▸ ユーザビリティのため、スナックバーのアクション でしかアクセスできない機能は避ける ▸
常に表示するのも避ける ▹ 殆どのコンポネントより前に表示されるため
アクション ▸ アクションは一つまで ▹ 2つが必要ならダイヤログを使用する ▹ アクションが本当に重要ならダイヤログを使用
フローティングアクションボタン ▸ フローティングアクションボタンを踏まない ▹ スナックバーが現れると共にフローティングアクションボタ ンも移動させる
フローティングアクションボタン
Toast トースト
トースト
トースト特徴 ▸ アクションは無い ▸ 一行のみ ▸ 時間が経って消える ▹ スワイプできないので手動で消す事はできない ▸
コンテキストに依存しない ▹ スナックバーと違う
お知らせ方法
スナックバーについて ▸ Android1.0からトーストとダイヤログは存在してい た ▹ ダイヤログは使われすぎてUXにマイナスな影響があって トーストはできる事が少なすぎた ⇒ スナックバーが生まれたわけ
適切なお知らせ方法 状況や目的に応じてユーザの事を考えて お知らせしよう
リファレンス ▸ https://www.google.com/design/spec/components/dialogs.html ▸ https://www.google.com/design/spec/components/snackbars-toasts.html ▸ https://www.youtube.com/watch?v=puhfMX8jb9c
以上