Entries

スマホのUI考 〜 ボタンについて


SuperPopCamとか作ったときに、体系的な資料欲しいなぁーとか思ってたことのまとめ。

色々と自分の中の考えをまとめるためのメモ。世の中のアプリは機能を半分にして、減った予算分をUIの練り込みにつぎ込んだ方が絶対よいアプリになると思う。
書いてる作業が一番考えまとまるので、ちょぼちょぼあげていこうかと、まずはボタンから。

指の大きさの制約を受ける
・Webとスマホを比較した場合、最大の違い。
・ピクセル単位でクリック位置を制御できるマウスポインタと違い、指は大雑把にしかタップ位置を指定できない。
・このためAppleはボタンの最小サイズとして44pxというガイドラインを作っている。
・視覚的に44px以下のボタンも実際のヒットエリアは大きめにする。
・またこれに留まらず、ボタンとボタンの間のマージンは空けられるだけ空けた方が安全。
・つまるところ「カッチリ」つめたボタンレイアウトのグラフィックは、なにも考えずに作るとスマホでは使いにくい。
・十分に幅の大きいボタンを詰めるのは大丈夫。
・ボタンレイアウトは重要度の高い機能から左から右、上から下。(一番左上は「戻るボタン」の予約位置)。
・ボタンレイアウトは操作のフローに従って左から右。
・ボタンの間が間延びする場合は、罫線等で間を持たせる。

持ち方について
・片手で操作するUIと、両手でもって人差し指で操作するUI、両手の親指で操作するUIは別物。
・利き手で作業するUIと、利き手で他の作業しながら左手で作業するUIも別物。
・例えば、「右手で鉛筆を持ちながら操作するアプリ」みたいのは、左手で押しやすいように設計する必要があるかも。
・片手(右)親指では、左下、右上、右下の順に押しやすい。
・片手操作のアプリの場合、画面下センターに3つぐらいのボタンで、画面上はほぼ触らなくてよいと一番使いやすいと思うが、Human Interface Guidelineとの共存をどうするか。。
・最重要機能は、右上か下センターに配置される可能性が高い。
・左利きはどうするか? 左右逆転UIの必要性は将来生まれるのか?多分生まれない。
・日本人の女性と、アメリカ人のファットメンが両方押せるぐらいの間隔が理想。
・右利き片手持ちの人が画面左側のボタンを右手で押そうとした場合、画面全体が隠れる。
・手が画面を覆わない位置としては、画面内の操作に関しては下ポジがベスト。
・画面の情報を見なくてもできる作業は上ポジでもOK
・操作の複雑なボタンやコンポーネントは上に持っていかない。
・左利きサポートを「人権問題」と捉えるか「市場原理」で捉えるか?

ロールオーバーがない
・どこがボタンか?押せるか?は触ってみなければわからない?
・ロールオーバーによるポップアップヘルプ等の技法は使えない。
・基本的には「全てのタッチできる場所」は立体にし、タッチできない場所は立体にしない
・カラースキーム他、ボタンのマナーを統一する(立体はその例)。
・ボタンが凹むエフェクトは必須。
・加えて音等のフィードバックも、あればあるだけよい。
・点滅表現は有効だが、モバイルの限られたリソースを食うので決め所だけ。

押すか離すか?
・ボタンは押した時に機能するか、離したときに機能するか?
・離した時に機能するほうがよい。
・離した場合なら、ユーザーが押してから考えを変えても、領域外に指を出してキャンセルできる。
・また押した後に補助ポップアップを出す選択肢を残せる(iPhoneのキーボード)。
・将来的に、ホールド系のジェスチャーを組み込める。リスクマネージメント。
・押して即座に発動だと、将来全てのジェスチャーを埋め込む機会を捨てる。
・「押す → 離す → ジェスチャー判定 → ボタン判定」と考える。

OKとCancelについて
・OKとキャンセルはどちらが右で、どちらが左か?
・Appleのガイドラインに従うならば、キャンセル、OKの順。
・基本的にはOKを押したらば処理を行う。キャンセルを押したらばその処理を行わない。
・「キャンセルをしますか? Cancel, OK」とかだと、Cancel押したときにキャンセルするのかわからんよね。
・正しくは「処理を中断しますか? Cancel, OK」にする。
・あるいは「削除しますか? Canel, Delete」のように、対になる単語をOKから動詞に切り替える。
・削除等、Undoのできない処理を行う場合にはCancelボタンの扱いをセンシティブにする。

ボタンラベル
・冗長にならない限り動詞表現を使う。「Safari」よりも「Safariで開く」、「編集」より「編集する」
・目安としてはナビゲーションバーのボタンラベルは名詞で妥協し、大きなボタンは動詞表現にする。
・できるだけ日本語を使う。「Load」とか「Upload」とかを理解できないユーザー達も、iOSアプリを使い始めている。
・多言語化するとボタンのサイズの可変が起こる可能性が高いため、それを吸収できるようなレイアウトにする。フランス語は悪夢。
・「◯◯を表示しない」というような否定形の表現はできるだけ避ける。日本人がDon’t you ではじまる疑問文で混乱するように、苦手な人は多い。

ボタンアイコン
・Apple純正のアイコンは、純正アプリと同じ用途にのみ使用する。
・アイコンだけのボタンは基本伝わらない。
・ユーザーは押して挙動を見てから学習する。
・挙動が明解でない機能にはアイコンは使わない。
・アイコンだけのボタンが大量に並んだ場合、明解でなければユーザーは操作を放棄する。
・ユーザーが記憶しきれないほど大量のアイコン表現を使わない。
・「押したら取り返しのつかない処理」のボタンは、アイコンだけのボタンにするのは避ける。(例外:ゴミ箱)
・イレギュラーなアイコンは伝わらない。
・幾何学系のアイコンは伝わらない。
・アイコン+文字はコストが高いがベスト解。
・アイコンもちゃんと立体にする。

ボタンが多すぎる場合
・そもそもボタンが多すぎるUIが間違っている。
・どうしても必要で入らない場合 → サブボタンをまとめたパレットの表示スイッチを作る
・1:アクションシート
・2:ポップオーバー
・3:画面をスライドさせて専用UIを出す(マルチタスクの処理を参考に)。
・画面上に遷移や表示コントロール系を配置し、画面したには表示されている内容の操作系を置く。

ToggleSwitch
・純正のトルグスイッチは「設定の切り替え」であって、押してすぐに効果がでる使い方はしない。
・トグルボタン → 通常のボタンと視覚的にどう差別するか?
・iPhoneにはトグルボタンの公式な見解なし。

SegmentedButton
・リスト等の表示方法を切り替えるボタン。フィルター的な使い方。
・SegmentedButtonとTabBarの違いは。
・アプリケーションのモードそのものの変更は、タブバー。

CheckBox、RadioButton
・なぜiPhoneには公式のUIがないのか?それを考える。
・CheckBoxとRadioButtonは現実メタファー性が薄い為か?
・CheckBoxはToggleSwitchで代用。
・RadioButtonはSegmentedButtonあるいは、TableのChildPane、PIckerで代用。

Androidについて
・Androidはカオス(超主観)
・AndroidとiPhoneはUIのガイドラインが違うので、まじめにやるには同じアプリでもiOS版とはUIを「完璧に」変えるべき。工数とってもかかる。
・「戻る」ボタンは物理スイッチが担当するので、ソフトウェア上ではつけない。
・タブバーは上にもってくる。
・端末毎に解像度が違うのが悪夢。ボタンの押しやすさや指の距離が変動しまくり。 AndroidはWYSIWYGではないことを前提にレイアウトを設計する。
・ここから下はちょっとボタンの話題とずれるけど・・・
・Androidアプリは、自分の苦手な処理を他のアプリに転送して委譲できるのだが、このせいで複数の違ったマナーのアプリが連動するとカオス。
・でもインテントの可能性は∞なので、ここがiPhoneとの差別化の最大のポイントだと思う。
・本来AndroidのUIはiPhone以上に厳格なUIガイドラインを作りそれに100%従うべき。現状はアプリ間の実装の差がフリーダムすぎる。
・端末レベルならともかくアプリレベルでは、現状UIで戦局は変えられない・・・と思う。

2回目はフィードバックの話に。