Google Developers Japan: タブレット向けアプリ品質チェックリスト

Local blog for Japanese speaking developers

タブレット向けアプリ品質チェックリスト

2013年1月25日金曜日

山崎富美 Developer Relations Team[この記事は Android Developers に掲載された "Tablet App Quality Checklist" という記事を元に翻訳・再構成しています。詳しくは元記事をご覧ください。-山崎]ユーザーエンゲージメントと収益

チェックリスト

コアアプリ品質のテスト
レイアウトを最適化する
余っている画面領域を活用する
タブレット画面用のアセットを使用する
フォントサイズとタッチターゲットを調整する
ホーム画面ウィジェットのサイズを調整する
アプリの全機能セットを提供する
ハードウェア機能を要求しない
タブレット画面構成を宣言する
Google Play のベストプラクティスに従う

テスト

テスト環境を整える

1. コアアプリ品質のテストCore App Quality Checklist（コアアプリ品質チェックリスト）テスト環境を整える

参考資料:

Core App Quality Guidelines（コアアプリ品質ガイドライン） — すべての対象端末において、Android アプリが必ず満たさなければならないコア品質条件の一覧。

2. 大画面に合わせてレイアウトを最適化する

「拡大されただけの UI」を解消する: タブレットの場合、単一ペインレイアウトにすると不自然な余白が生じたり、一行が長くなりすぎたりします。パディングを使用して UI 要素の幅を狭くすると共に、マルチペインレイアウトの使用も検討しましょう。

必要に応じて large（大）および xlarge（特大）画面用のカスタムレイアウトを用意します。また、画面の最小寸法あるいは幅・高さの最小値に基づいてロードされるようなレイアウトを提供してもよいでしょう。

大きめの画面については最低でもフォントサイズやマージン、間隔などの寸法をカスタマイズし、画面の使い方とコンテンツの読みやすさを改善します。

UI コントロールの位置を調整し、ユーザーがタブレットを手に持っているときに操作しやすい位置に配置します（横置きのときはサイドに配置するなど）。

UI 要素のパディングは通常、タブレットでは携帯端末の場合よりも大きくします。48dp 単位（グリッドは 16dp）にすることをお勧めします。

テキスト形式のコンテンツは、画面の端にぴったり沿った状態にならないよう適切にパディングを使用します。画面の端近辺では最低でも 16dp のパディングを使用してください。

テキストの行は長くなりすぎないようにし、1 行あたり半角文字で最大 100 文字とし、1 行あたり50～75 文字に収めるのがベストです。

ListViews やメニューには画面の幅全体を使用しないでください。

パディングを使用してオンスクリーン要素の幅を管理したり、タブレット向けにマルチペイン UI に切り替えたり（次の項目を参照）します。

参考資料:

Metrics and Grids（尺度とグリッド） — 画面上のタッチターゲットおよびその他UI要素の配置やサイズ変更方法を説明した Android デザイン用ドキュメント。
Devices and Displays（端末とディスプレイ） — 各種端末とディスプレイについての Android デザイン用ドキュメント。
Supporting Multiple Screens（複数の画面に対応する） — 複数の画面サイズでの表示を最適化するための UI 管理について詳しく説明した開発者向けドキュメント。
Configuration examples（構成例） — 特定の画面サイズについて、レイアウトやその他リソースを宣言する方法の例。

3. タブレット上の余っている画面領域を活用する

タブレット画面では、マルチペインレイアウトにすることで見た目のバランスがよくなると同時に、実用性も読みさすさも向上します。

追加のコンテンツを盛り込んだり、既存のコンテンツを別な形で扱ったりする方法を探ります。

タブレット画面ではマルチペインレイアウト（Multi-pane Layout）を使い、複数の単一ビューを 1 つの複合ビューにまとめます。こうすることで、増えた画面領域をより効率よく使用でき、ユーザーもアプリを操作しやすくなります。

画面の向きが変わったときに複合ビューのパネルをどのように再配置するのかを考慮します。

複合ビューは、携帯端末用 UI（上）の複数の単一ビューを 1 つにまとめ、より充実した効率の良いタブレット用 UI にします（下）。

1 つの画面は Activity サブクラスとして実装されますが、個々のコンテンツパネルを Fragment サブクラスとして実装することを検討します。こうすることで、さまざまなフォームファクター全体で、またコンテンツを共有するすべての画面にわたって最大限にコードを再利用できます。

どの画面サイズでマルチペインUIを使用するかを決め、それぞれのレイアウトを適切な画面サイズバケット（large/xlarge など）、あるいは最小画面幅（sw600dp/sw720 など）で提供します。

参考資料:

Multi-pane Layouts（マルチペインレイアウト） — マルチペイン UI の使用に関する Android デザインガイド。ナビゲーションを平面的にし、より多くのコンテンツをタブレット UI に盛り込む方法の例などが記されている。
Planning for Multiple Touchscreen Sizes（複数のタッチスクリーンサイズを計画する） — タブレットやその他端末向けに、直感的で効果的なナビゲーションのデザイン方法を段階的に説明する Android トレーニングクラス。
Designing for Multiple Screens（複数の画面を設計する） — タブレットやその他端末向けに、直感的で効果的なナビゲーションのデザイン方法を段階的に説明する Android トレーニングクラス。

4. タブレット画面用に設計されているアイコンなどのアセットを使用する表1. アイコンタイプ別の未加工のアセットサイズ

密度

ランチャー

アクションバー

小型/コンテキストタイプ

通知

mdpi

48x48px

32x32px

16x16px

24x24px

hdpi

72x72px

48x48px

24x24px

36x36px

tvdpi

(hdpi を使用)

(hdpi を使用)

(hdpi を使用)

(hdpi を使用)

xhdpi

96x96px

64x64px

32x32px

48x48px

アクションバーや通知、ランチャーのアイコンは、アイコンのデザインガイドラインに従ってデザインし、タブレット上でも携帯端末と同じ物理サイズにします。

ピクセル密度固有のリソース修飾子（resource qualifiers）を使用して、適切な代替リソースセットがロードされるようにします。

参考資料:

Iconography（アイコンについて） — さまざまなタイプのアイコンの使用方法を説明した Android デザイン用ドキュメント。
Providing Resources（リソースを提供する） — 端末画面の特定の領域に対して、レイアウトとドローワブルリソースセットを提供する方法を説明した開発者向けドキュメント。
Supporting Multiple Screens（複数の画面に対応する） — 複数の画面サイズでの表示を最適化するための UI 管理について詳しく説明した開発者向けドキュメント。
Supporting Different Screens（さまざまな画面に対応する） — 各種画面サイズ・密度に合わせてユーザーエクスペリエンスを最適化するプロセスを詳しく学べる Android トレーニングクラス。

5. タブレット画面用にフォントサイズとタッチターゲットを調整するスタイル設定可能な属性（styleable attributes）寸法のリソース（dimension resources）

テキストは、タブレットの画面サイズやピクセル密度で表示したときに大きすぎたり、小さすぎたりしないようにしましょう。ラベルは、該当する UI 要素に合わせて適正なサイズにし、またラベルやタイトルなどの各種要素が不適切な位置で改行されないようにします。

オンスクリーン要素については、タッチターゲットの推奨サイズは 48dp（最低でも 32dp）ですので、タブレット UI 用にいくつかの調整が必要かもしれません。ほとんどのユーザーを対象とした実装方法については、尺度とグリッド（Metrics and Grids）をお読みください。一部のユーザーのニーズに対応するには、大きめのタッチターゲットを使用するのが適切な場合があります。

比較的小さなアイコンについては、TouchDelegate を使用するか、または透明ボタン内でアイコンをセンタリングすることで、タッチ可能な領域をできるだけ 48dp よりも大きくします。

参考資料:

Metrics and Grids（尺度とグリッド） — 画面上のタッチターゲットとその他 UI 要素の配置やサイズ変更方法を説明した Android デザイン用ドキュメント。
Typography（書体） — アプリにおける書体の使用方法の概要を説明した Android デザイン用ドキュメント。
Supporting Multiple Screens（複数の画面に対応する） — 複数の画面サイズでの表示を最適化するための UI 管理について詳しく説明した開発者向けドキュメント。
Supporting Different Densities（さまざまな密度に対応する） — 端末画面の特定の領域に対して、レイアウトとドローワブルリソースセットを提供する方法を説明した Android トレーニングクラス。

6. タブレット画面用にホーム画面ウィジェットのサイズを調整する

ウィジェットのデフォルトの高さ・幅は、タブレット画面と最小/最大リサイズ高さ・幅に合わせて適切に設定します。

ウィジェットは 420dp 以上のサイズに変更できるようにし、垂直または正方形ウィジェットの場合はホーム画面の 5 行以上、水平または正方形ウィジェットの場合は 5 列以上にまたがるようにします。

9 パッチ画像が正しくレンダリングされるようにします。

デフォルトのシステムマージンを使用します。

アプリの targetSdkVersion を 14 以上に設定します（可能な場合）。

参考資料:

Adding the AppWidgetProviderInfo Metadata（AppWidgetProviderInfo メタデータを追加する） — ウィジェットの高さ・幅の寸法を設定する方法を説明した API ガイド。
App Widget Design Guidelines（アプリウィジェットデザインガイドライン） — ウィジェットのサイズの設計、管理のためのベストプラクティスとテクニックを紹介した API ガイド。

7. アプリの全機能セットをタブレットユーザーに提供する

アプリは少なくとも携帯端末と同じ機能セットをタブレットにも提供するようにします。

例外的なケースとして、ほとんどのタブレットにおいてハードウェア的に対応していない、あるいはユースケース上対応していない一部の機能については、省くか他のものに置き換えても構いません。下記に例を示します。

携帯端末では電話機能を使用しているが現在のタブレットでは電話機能を使用できない場合は、この機能を省くか、関連する機能に置き換えても構いません。
多くのタブレットには GPS センサーが搭載されていますが、一般的なユーザーは、タブレットを持ってランニングをすることはまずありません。携帯端末向けアプリで、端末を身につけてランニングしたときに GPS で追跡し距離などを記録する機能を提供しているとしましょう。タブレットではそういったユースケースの需要がないと思われるため、この機能をタブレット向けに提供する必要はないと考えられます。

タブレット UI から機能や性能を省くことになる場合は、ユーザーがそれらにアクセスできないようにするか、いわゆる「グレースフルデグラデーション」として代替機能を提供するようにします（ハードウェア機能については次のセクションも参照してください）。

8. タブレットに搭載されていない可能性があるハードウェア機能を要求しない

アプリのマニフェストには、android:required=”false” 属性で宣言されている場合を除き、タブレットで使用できない可能性のあるハードウェア機能や能力に対しては <uses-feature> 要素を含めないでください。例えば、アプリが次のような機能を要求しないようにします。

android.hardware.telephony
android.hardware.camera （バックカメラを参照）または
android.hardware.camera.front

同様に、アプリのマニフェストには、タブレットでは適切でない可能性がある機能要件を暗示（imply feature requirements）する <permission> 要素は一切含めないでください。ただし、android:required=”false” 属性で宣言されている当該 <uses-feature> 要素を伴っている場合はこの限りではありません。

参考資料:

Permissions that Imply Feature Requirements（機能要件を暗示するパーミッション）— アプリのマニフェストで宣言した場合、望まないフィルタリングの原因となる可能性があるパーミッションのリスト。
<uses-feature> — マニフェスト要素 <uses-feature> の解説と参考ドキュメント。
Testing the features required by your application（アプリケーションが要求する機能をテストする） — アプリが要求するハードウェアとソフトウェア要件（明示的または暗示的要件）のセットを決定する方法を解説。

9. 対応しているタブレット画面構成を宣言する

必要に応じて、適切な属性を使い <supports-screens> 要素を宣言します。

マニフェスト内でアプリが <compatible-screens> 要素を宣言している場合は、その要素には、必ずアプリが対応しているタブレット画面のサイズ/ピクセル密度のすべての組み合わせを指定する属性が含まれていなければなりません。できれば、アプリでこの要素を使用するのは避けるようにしてください。

参考資料:

<supports-screens> — マニフェスト要素 <supports-screens> に関する解説と参考ドキュメント。
Declaring Screen Size Support（画面サイズ対応を宣言する） — 複数の画面サイズでの表示を最適化するためのUI管理について詳しく説明した開発者向けドキュメント。

10. Google Play への公開に関するベストプラクティスに従う

アプリは、すべての画面サイズ（携帯端末とタブレット）に対して 1 つの APK として公開し、Google Play への掲載は 1 つにします。その理由は、次の通りです。

ユーザーが検索やブラウズ操作、プロモーションからアプリを見つけやすい
ユーザーが新しい端末を入手したとき、アプリを復元しやすい
レーティングやダウンロード統計がすべての端末での合計になる
タブレット用アプリを別物として公開すると、ブランドとしてのレーティングが弱まる

必要であれば複数の APK サポート（Multiple APK Support）を使いアプリを配布する選択肢もありますが、ほとんどの場合は 1 つの APK ですべての端末に対応することを強くお勧めします。

• 製品詳細のページにて、次のような方法でアプリのタブレット向け機能を目立たせます。

アプリがタブレット上で動作しているときのスクリーンショットを最低 1 枚は載せましょう。できれば横向きと縦向きそれぞれのスクリーンショットを 1 枚ずつ載せてください。こういったスクリーンショットを載せることで、アプリがタブレット向けにデザインされていることをユーザーに明確に示せると同時に、あなたがタブレットアプリをデザインする上で力を入れた点をアピールできます。
アプリの説明にタブレット対応であることを明記します。
アプリのリリースノートや更新情報に、タブレット対応であることを盛り込みます。
アプリのプロモーション動画に、アプリがタブレット上で動作している様子を加えます。

アプリがきちんとタブレット端末へ配布されていることを確認します。Developer Console にて、アプリの対応端末リストをチェックし、対象のタブレット端末からアプリがフィルタリングされていないことを確かめます。

タブレットユーザーにアプリの存在をアピールしましょう。タブレットでのアプリ使用を紹介するマーケティングや広告キャンペーンを企画します。

参考資料:

Publishing Checklist（公開のためのチェックリスト） — アプリの公開、テスト、Google Play での提供開始に向けてアプリを準備する際の推奨事項。
Google Play Android Developer Console — アプリを Android ユーザーに公開するためのツールコンソール。

タブレット用テスト環境を整えるエミュレートした端末（emulated devices (AVDs)）表 1. 代表的なタブレットテスト環境には、下表の各行の端末（代表的なチップセット、プラットフォームバージョン、ハードウェア機能構成を備えたもの）を 1～2 台準備するのがよいでしょう。

タイプ

サイズ

密度

バージョン

AVD スキン

7 インチタブレット

large または -sw600

hdpi,
tvdpi

Android 4.0+

WXGA800-7in

10 インチタブレット

xlarge または -sw800

mdpi,
hdpi

Android 3.2+

WXGA800

Creative Commons Attributes 2.5（クリエイティブ・コモンズ表示 2.5）Content License

ラベル

ブログアーカイブ

2024
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2023
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2022
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2021
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2020
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2019
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2018
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2017
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2016
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2015
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月

2014
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2013
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2012
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2011
- 12月
- 11月
- 10月
- 9月
- 8月
- 7月
- 6月
- 5月
- 4月
- 3月
- 2月
- 1月

2010
- 12月
- 11月

Feed

"プロダクトに関するご意見はプロダクトフォーラムにお願いします"

Google
Privacy
Terms