タブレット対応は最大画面を二列にする作業ではありません。
一覧と詳細を並べる価値、狭い幅へ戻す条件、文字拡大とキーボードで保つ操作をまとめて設計します。
横向きで表を編集できても、縦向きと文字拡大で主要操作が隠れないとは限りません。
アプリ開発の目的に合う無料相談先を先に整理したい方は、目的別の相談ガイドで外注と学習の選び方を確認できます。
| 設計方式 | 適する場面 |
|---|---|
| 適応型共通画面 | 幅が変わっても同じ作業を続ける |
| 大画面専用UI | 一覧と詳細を同時に確認する |
大画面を情報量ではなく作業の並行性へ使う
Androidの適応型画面はAndroidの適応型画面ガイドを参照し、ウインドウ幅に応じる構造を検討します。
タブレット対応は画面を広げる作業ではなく、一覧と詳細を同時に扱う価値があるかの判断です。
| 設計方式 | 広い幅で並べる情報 | 狭い幅で優先する情報 |
|---|---|---|
| 適応型共通画面 | 一覧と現在の編集対象 | 現在の選択と主要操作 |
| 大画面専用UI | 一覧、詳細、比較情報 | 編集中の内容と保存操作 |
| Webアプリ | ナビゲーションと作業領域 | 中心コンテンツと主要操作 |
単一列と二列表示は作業の並行性で比べ、広い画面に置ける情報量だけでは選びません。
未保存入力を幅変更の後にも残す
- 点検アプリなら、左の設備一覧と右の点検項目を並べると往復を減らせます。
- 分割表示で幅が狭くなった時は、一列へ戻して選択中の設備を見出しに残します。
- 同じ点検を三つの幅で通すと、画面の広さに依存しない情報構造を確認できます。
Androidの適応型画面ガイドの幅変更を再現し、一覧で選んだ対象と未保存入力が再配置後も残るか試します。
幅変更後に未保存入力が消えるなら、横向きで表を編集できても公開しません。
文字拡大とキーボード操作を合格条件にする
最大幅だけで二列化すると、狭い分割表示で情報の順序と操作対象が崩れます。
W3Cのアクセシビリティ指針が示す知覚と操作の観点から、主要機能がポインターだけに依存しないか確かめます。
- 幅ごとのレイアウト切替条件がある
- 一覧と詳細の選択状態を保持できる
- キーボードだけで主要操作を進められる
- 文字拡大時にも情報順序が崩れない
Android入門でiPad固有設計を確認しても、ポインターだけに依存する操作は残しません。
狭い幅と広い幅で同じ編集を通す
狭い幅、広い幅、文字拡大、キーボード操作の順で同じ入力を完了させます。
Apple側の情報階層と余白はAppleのレイアウト指針を基準にし、端末名だけで配置を固定しません。
利用者が読む、入力する、比較する時間を分け、中心作業を決めます。
文字拡大後も主要操作を隠さずに再現できなければ、配置を確定しません。
タッチ、キーボード、ポインターで同じ主要操作を完了させます。
文字拡大と回転を組み合わせ、情報やボタンが欠けないか確認します。
文字拡大やキーボードを含む利用しやすさはW3Cのアクセシビリティ指針の原則を試験項目へ変えます。
狭い幅、文字拡大、キーボードで同じ入力を完了するまでは端末対応済みとしません。
タブレット画面設計のよくある質問
タブレット専用アプリにする必要はありますか？
長時間の編集、一覧比較、複数情報の同時確認が価値なら専用UIを検討します。
閲覧中心でスマホと機能が同じなら、幅に応じて変わる共通画面から始められます。
iPadとAndroidタブレットを同じ画面にできますか？
情報構造を共有できますが、OSの操作規則、画面幅、入力機器には差があります。
代表端末で分割表示、回転、文字拡大を同じ手順で確認します。
大画面UIはどうテストしますか？
最小幅、中間幅、全画面で同じ作業を通し、移動回数と見失う情報を記録します。
タッチだけでなく、キーボードとポインターでも完了できるか確認します。
画面サイズではなく作業の並行性を設計する
タブレット設計の基準は画面サイズではなく、幅と入力方法が変わっても作業を中断しないことです。
- タブレットUIは情報量より中心作業と情報階層から設計する
- 狭い幅から全画面まで選択状態と主要操作を保つ
- 長時間の編集ではキーボードとポインターの操作が重要になる
- iPadとAndroidは共通構造を保ちつつOS別の実機確認を行う
Linux端末へ進む前に、並行表示する情報と一画面へ戻す幅を決めます。
