レスポンシブWebデザインの実装(基本編)
ここでは、基本的なレスポンシブWebデザインの実装方法、手順等についてまとめています。なお、入門者、初心者の方にわかり易いよう、実装の手順に従って内容をまとめていますが、参照し易いように、一部、実装の応用テクニックについても紹介しています。
「レスポンシブWebデザインの実装(基本編)」の目次
1.はじめに
ここでは、基本的なレスポンシブWebデザインの実装方法、手順等についてまとめています。なお、入門者、初心者の方にわかり易いよう、実装の手順に従って内容をまとめていますが、参照し易いように、一部、実装の応用テクニックについても紹介しています。
入門者、初心者と書きましたが、それはレスポンシブWebデザインについてであり、ここでは、Web制作、HTMLやCSSの入門者、初心者は想定しておりません。HTML、CSS等、Web制作の基礎知識、基本スキルについては問題ないことが前提で書かれています。ご了承ください。なお、Web制作の初心者が、レスポンシブWebデザインでサイト制作を行うことは不可能ではありませんが、サイト制作に継続して携わっていく可能性があるのであれば、まずは、最低でもHTMLやCSS等Web制作の基本をある程度先に学ぶことをお勧めします。もし、Web制作の基本を学びつつ並行してレスポンシブWebデザインでサイト制作に取り組むのであれば、自分がやっている作業、設定、使用している技術等々が、何を意味しているのか、何のためなのか等々を、しっかり把握、理解しながら作業を進めるように心がけましょう。
ここで解説するサイト制作、実装の手順・流れは、あくまでも一例であり、レスポンシブWebデザインでサイト制作を行う上での唯一の解というわけではありません。もちろん、現時点で、この方法がよいと思われるものをまとめてはいますが、様々な他の手順、方法もあります。また、制作するサイトの規模や内容、個人で作業するのか、チームで作業するのか、チームの規模、スキルの度合いによっても、適正な手順・流れは変わってくるはずです。適正な制作手順、方法論を得るには、やはり経験を積み重ねていくしかないと思われます。当サイトは、その手始めの一例として、参考にしていただければと思います。
2.実装の前に(1)ワークフローについて
まずは、制作ワークフローについて。ワークフロー、作業手順といってもいいでしょうか。実装とはまた別の話ではあるのですが、非常に重要なことですので。
レスポンシブWebデザインのサイトを制作する際のワークフローと、従来のサイト制作を行う際の一般的なワークフローでは、一部に違いがあります。
従来のワークフローは、Photoshop等の画像編集ソフトで作成したデザインカンプを元に実装(コーディング)し、サイトを作成するという流れが一般的だといえるでしょう。しかし、レスポンシブWebデザインでは、複数の画面サイズに対応することが目的であり、その画面サイズに応じて、レイアウトも変化します。複数のレイアウト分、デザインカンプを作成するのは、著しく制作コストが上がってしまい、非効率でもあり現実的ではありません。
レスポンシブWebデザインでは、簡易的なラフスケッチ等大枠のレイアウトだけ決め、実際に実装(コーディング)しながら、複数の画面サイズに応じたレイアウトでテスト、確認を行い、調整を行ってまた確認、というような手順を繰り返しながら作り込んでいく流れが一般的だといえるでしょう。
個人にしろ、制作会社等の組織内でのチームにしろ、ある程度のサイト制作経験を重ねているのであれば、それぞれに確立されたワークフローがあるかとは思います。個人で単独で作業をする場合であれば、まだ何とか柔軟に対応し易くはあるでしょうが、チーム複数人で作業を行う制作スタイル、特に、画像関連、HTML、CSSの作業者が別である場合などは、レスポンシブWebデザインでのサイト制作のワークフローの流れ作業していく上で、戸惑いや混乱が生じるかもしれません。レスポンシブWebデザインでのサイト制作が初めての場合は、その点を考慮しておくことも必要でしょう。
レスポンシブWebデザインに限らず、またチーム、個人にも限らず、新しい技術等を導入する際は、ある程度の戸惑いや混乱は仕方がないともいえるでしょう。引き続き、レスポンシブWebデザインでのサイト制作を行う可能性が高いようであれば、各々に適したワークフローの早期確立も、視野に入れながら作業を進めていくことも重要だといえるでしょう。
更に一言
Web制作において、マルチデバイス対応が無視できない、半ば必須になりつつある現在、従来重視されてきたピクセルパーフェクトなデザイン、サイト制作は、とても難しく、効率も落ちることから、あまり重要視されなくなってきたといえます。サイトを閲覧する環境が多様化しているので、ピクセルパーフェクトを求めるのではなく、どのような環境のユーザーにも、情報を正しく届けることこそ重視するべきだという考え方になりつつあるようです。
しかし、サイトの特性によっては、ピクセルパーフェクトが求められることもあるかもしれません。ピクセルパーフェクトを求めつつ、かつマルチデバイス対応を行う必要があるとしたら、レスポンシブWebデザインでは、難しい面があるかもしれません。そのような場合は、本当にレスポンシブWebデザインでのサイト制作でいいのか、他のマルチデバイス対応を選択するということも含めて、熟考が必要かと思われます。
3.実装の前に(2)調査・分析、サイト設計、画面設計
「調査・分析」「サイト設計」「画面設計」、制作フロー上、全部まとめて「サイト設計」とする場合もあるかもしれませんが、要は、実装(コーディング)に入る前の、設計フェーズについて。
レスポンシブWebデザインでサイト制作を行う場合、サイト設計の段階で、従来のサイト制作では意識する必要のなかった、あるいはそれほど重要視されなかった点について、検討し判断しておかなければならないことがあります。
まずは、対象デバイスについてです。従来の場合でも、対象ブラウザが明確にされることは珍しくありませんでした。しかし、レスポンシブWebデザインでは、対象デバイスを意識する必要がある場合もあります。
レスポンシブWebデザインは、マルチデバイス対応の一手法なので、レスポンシブWebデザインで正しくサイト制作を行えば、それだけで、どのようなデバイスにも対応したサイトが完成するはずです。それは間違いないのですが、より具体的には、デバイスの画面サイズに応じて、レイアウトやデザインを切り替えるという制作手法です。個人が、趣味の個人サイトを作るという場合ならばまだいいですが、クライントから受注をした上で商用サイトを作る際などは、クライアントの要望等で、何らかの特定端末での見栄え、ユーザビリティについて、重要視することを求められる場合があるかもしれません。あるいは、特定の端末、特定の画面サイズのユーザーを重要視する必要がある場合も考えられるでしょう。後でトラブルに発展しないように、端末や画面サイズについては、 前もってクライアントと打ち合わせ等しておく必要があるでしょう。
次は、ブレイクポイントについてです。
ブレイクポイントの詳細については後述しますが、ブレイクポイントは、レスポンシブWebデザインでサイト制作を行う際の、主要技術、骨子の一つといえます。サイト設計の段階で、しっかりと検討し、明確にしておくことが求められます。
次は、古いブラウザへの対応についてです。
対象のブラウザを明確にし、古いブラウザについてどう対応するかについては、従来の制作手法でも意識する必要がありました。レスポンシブWebデザインでは、一部の古いブラウザでは、未対応の技術を使用することになります。対応策がないわけではないので、対応をするのか、あるいはしないのか、サイト設計の段階で検討し明確にしておく必要があります。なお、その具体的な内容については後述します。
次に、タッチデバイスへの対応について。
従来は、原則としてPCからのアクセスを想定しており、マウスで操作されるというのが前提のUI(ユーザーインタフェース)でした。しかし、スマートフォンやタブレットは、指での操作を行うタッチデバイスですので、UIもその点を意識して設計する必要があります。
これは、レスポンシブWebデザインに限らず、何らかの方法でマルチデバイス対応のサイトを制作するのであれば、半ば必須ともいえるでしょう。これまでタッチデバイス向けのサイト制作経験がない場合は、特に注意が必要でしょう
また、対象デバイス、対象ブラウザをどうするか、古いブラウザへの対応をどうするかについての際、特にいえることなのですが、対応程度のレベル分けをするのもいいでしょう。対応するか否かの二択ではなく、対応する程度を段階的に分けて検討する方法です。具体的な例を一つ挙げると、「レイアウト、機能が、意図した通りに完璧に表示される」「少々の崩れがある」「見栄えは悪いがコンテンツを閲覧はできる」「非対応」等々の段階に分けるなどです。
最後に、重要なことをもう一点。これは、サイト制作経験が豊富な方々には、釈迦に説法だと思いますが、初心者や経験の浅い方に向けて。
ここまでお読みになってお気付きになられている方も多いかとは思いますが、レスポンシブWebデザインで一度もサイト制作、実装の経験がないと、サイト設計を行うのは非常に難しいでしょう。個人のサイト制作で、特に期限等の制約がないのであれば、試行錯誤を繰り返しながら制作を進めていくのもいいでしょうが、ビジネス(仕事)としてサイト制作を行う場合はそうもいきません。正しくサイト設計を行うためにも、レスポンシブWebデザインでの制作が全くの未経験なのであれば、デモやサンプルで構わないので、少なくとも一度は、レスポンシブWebデザインのサイトを実際に実装する必要があるでしょう。
4.実装の前に(3)作業環境を整える
レスポンシブWebデザインでサイト制作を行うにあたり、特別な作業環境が必要ではありません。これまで、サイト制作を行ってきた方々であれば、同様の作業環境で特に問題はないでしょう。
ただし、レスポンシブWebデザインで制作されるサイトは、画面サイズに応じてレイアウトやデザインが変化するので、それを確認する環境が必要になります。その都度サーバーにUPするなどして、実機(スマートフォンやタブレット)で確認する方法もないわけではないですが、非常に効率が悪いでしょう。
といっても、これも、必ずしも特別なツール等が必要なわけではありません。単純に、ブラウザの横幅を縮めたり広げたりするだけで、画面サイズを変えることができます。ただ、この方法も、いちいちブラウザの幅を手作業で変更する必要があり、作業効率はよくないでしょう。また、画面サイズ(ピクセル数)がわかりにくいというデメリットもあります。
これらを改善するには、複数の方法があります。FIrefoxやGoogle Chrome等のブラウザに用意されている、開発者向けの機能を利用するのも一つの方法です。FIrefoxは「Web開発>レスポンシブデザインビュー」、Google Chromeは「その他のツール>デベロッパーツール」を使用すると、ブラウザ内での画面サイズの変更が簡単にでき、様々なデバイス(画面サイズ)ごとの表示確認の効率が上がります。
また、これら以外にも、様々な専用ツールやプラグインがあります。例えば、「VIEWPORT RESIZER」(http://lab.maltewassermann.com/viewport-resizer/)、「Responsivator」(http://johnpolacek.github.io/Responsivator/)などです。あるいは、PCでスマートフォンの表示確認を行うための、エミュレータやシミュレータ等を利用する方法もあるでしょう。
このように、様々な選択肢がありますので、個々の作業スタイル、好みに合ったものを使用するといいでしょう。ちなみに、当サイトの作成時は、FIrefox「Web開発>レスポンシブデザインビュー」、Google Chrome「その他のツール>デベロッパーツール」、「VIEWPORT RESIZER」を併用しながら作業を行いました。
更に一言
これはレスポンシブWebデザインでのサイト制作とは直接は関係ないのですが、個人的に、レスポンシブWebデザインでのサイト制作を学習し、実際にサイト制作を行おうとした際、いい機会なので、その他についても、新たに取り入れたり学習しようと考えました。具体的には、新しいエディターを導入し、CSSの設計手法についても学習し、新たに取り入れることにしました。
レスポンシブWebデザインを新たに学習し、導入するだけでもそれなりに大変であり、余裕がないとできないことではあるでしょう。しかし、何かきっかけがないと、新たな技術等を導入する機会もないものです。もし可能なのであれば、これまで気になってはいたが着手することのできなかった、新しい技術等の採用を検討するのはいかがでしょうか。
レスポンシブWebデザインを学習するにあたり、個人的に新たに取り入れたことの情報については、レスポンシブWebデザインについて一通りまとめることができた後に、改めてまた紹介したいと考えております。
5.実装の前に(4)実装の手順・流れについて
実装を開始する前にもう一つ、実装の手順・流れについてです。
当サイトでは、モバイルファーストのコンセプトに基づいて、小さい画面サイズを基準としたレイアウト、デザインから作成します。
(手順1)HTMLの用意 ベースとなるHTMLを用意します。コンテンツの素材(画像、原稿等)も準備します。場合によっては、古いブラウザへの対応も行います。
(手順2)Viewportの指定 Viewportを指定し、スマートフォン等で表示した際、縮小して表示されないようにします。
(手順3)CSSの初期設定 CSSの初期設定、リセットCSSの導入を行います。小さい画面サイズを基準としたレイアウト、デザインを完成させるべくCSSの記述を行います。
(手順4)フルードイメージの導入 フルードイメージを導入し、画像が動的に拡大縮小されて、ブラウザ(画面)内に収まるようにします。
(手順5)メディアクエリの設定 メディアクエリを利用し、大きい画面サイズについてのレイアウト、デザインを行います。
(手順6)フルードグリッドの導入 フルードグリッドを導入し、サイトをフルードデザイン(リキッドレイアウト)化します。
おおよそ、以上のような手順・流れとなります。これら一連の作業の後、調整、確認を繰り返し、サイトを完成させ、テストを終えたら公開です。
6.実装(1)HTMLの用意(古いブラウザへの対応)
いよいよ実装開始です。まずは、ベースとなるHTMLの用意です。コンテンツの素材(画像、原稿等)も準備します。
といっても、この段階では、特別にレスポンシブWebデザインに特化した作業はありません。それぞれのチームや組織、あるいは個人々々で、HTMLを実装していく手順、お作法があると思いますが、まずは従来通りで構わないでしょう。ただ、この段階で、レイアウトやデザインを細かいところまで詰めて作り込んでいくことは避けるべきでしょう。レスポンシブWebデザインでのサイト制作は、実装、調整、確認を繰り返しながらサイトを作り込んでいくのがよいとされていますので、ピクセルパーフェクトにこだわるのは非効率です。コンテンツの素材についても、(原稿は別ですが、)画像素材も、実装を進めながら適正なサイズに調整することとなるであろうので、この段階ではある程度適当なサイズで構いません。リサイズが前提なので、少し大きめなものを用意しておくのもいいでしょう。
ベースとなるHTMLをどの程度のものとするかは、サイトのレイアウト、コンテンツの内容等々により違いもあるでしょう。この辺りは、レスポンシブWebデザインによるサイト制作の経験を重ねることが必要かもしれません。
なお、HTMLについてですが、必ずしもHTML5でいけないというわけではありません。HTML4やXHTML1.0でも、レスポンシブWebデザインでのサイト制作は可能です。しかし、近年の主流はHTML5ですし、今後、デファクトスタンダードとなる可能性も高いと思われますので、特別な理由、事情がないのであれば、HTML5を使用するのがいいでしょう。
次に、一部の古いブラウザへの対応についてです。ちなみに、必ずしもこの段階での対応が必要というわけではありません。
古いブラウザへの対応は、レスポンシブWebデザインにおける必須事項というわけではありません。レスポンシブWebデザインを実現するためのいくつかの技術について、対応していない一部の古いブラウザは非対応とし、対象ブラウザに含まれていないのであれば、必ずしも対応を行う必要はないでしょう。
というわけで、古いブラウザへの対応の詳細は、ここ基本編ではなく、実装の応用編として別途解説いたします。(鋭意制作中です)
7.実装(2)Viewportの指定
レスポンシブWebデザインを実現するための、本格的な実装の開始です。まずは、Viewportの指定です。
Viewportとは、スマートフォンのブラウザの多くで設定されている仮想ウインドウサイズのことです。PC向けのみに作られたWebサイト(マルチデバイス非対応のサイト)にスマートフォンでアクセスした場合、それぞれのブラウザに設定されたViewportの値に基づいて、サイトが縮小されて表示されます。
レスポンシブWebデザインでは、そのViewportを明示的に指定する必要があります。Viewportの指定は、レスポンシブWebデザインを実現する上での必須作業の一つといえます。
方法は簡単です。レスポンシブWebデザインでは、通常、HTMLのhead要素内(<head>~</head>)に、以下のmeta要素を設定します。
<meta name="viewport" content="width=device-width, initial-scale=1.0">
ちなみに、「width=device-width」は、Viewportの幅をデバイスサイズに合わせるという意です。「initial-scale=1.0」は、最初の表示倍率を1倍とするという意になります。
Viewportの指定には、他にも様々な指定方法があります。その詳細は、実装の応用編として別途解説いたします。(鋭意制作中です)
8.実装(3)CSSの初期設定(リセットCSS導入)
ここでは、CSSの初期設定、リセットCSS導入、また、併せてタイポグラフィ(文字周り)のスタイルの基本設定を行います。
ただし、これらは、レスポンシブWebデザインにおける必須事項というわけではありません。ですので、これらについての詳細は、その目的も含め、実装の応用編として別途解説いたします。(鋭意制作中です)
なお、HTMLについては必ずしもHTML5でなくてもいいのですが、CSSについては、CSS3の新機能であるメディアクエリを利用しますので、CSS3の使用が必須となります。
CSSが用意できたら(初期設定、リセットCSSの導入が終わったら)、CSSを記述し、レイアウト、デザインを調えます。モバイルファーストのコンセプトに基づいて、小さい画面サイズを基準としたレイアウト、デザインから行います。小さい画面サイズの具体的なサイズは、現在であれば、横幅320pxとするのが一般的でしょう。ただし、この最小サイズをどれだけとするかは、制作するサイトによっては違いがあるでしょうし、何よりも今後のデバイスの動向によっては、変わっていくことも考えられるので注意が必要です。
以降、横幅を、小さい画面サイズの横幅に固定して、小さい画面サイズを基準としたレイアウト、デザインを進め、次項のフルードイメージの導入まで行いましょう。
9.実装(4)フルードイメージの導入
次に、フルードイメージの導入です。フルードイメージとは、画像をブラウザ内に収めるための技術手法のことです。フルードイメージを導入することで、画像がブラウザ(画面)から横にはみ出してスクロールバーが出るようなことはなくなり、ブラウザ(画面)サイズに応じて、縦横比を維持したまま、動的に拡大縮小されるようになります。
画像を全く使わないのであれば不必要ですが、それはレアケースだと思われますので、現実的には、レスポンシブWebデザインを実現するための必須作業の一つといえるでしょう。
具体的には、CSSのimg要素に、以下のようなスタイルを適用させるよう記述します。
img {
max-width: 100%;
height: auto;
}
max-widthプロパティは、主要なブラウザでは対応されていますが、IE6では未対応です。しかし、IE6を搭載したスマートフォンは存在しませんし、現在では、かなり古いブラウザの一つでもありますので、対応する必要はないと思われます。
10.実装(5)メディアクエリの設定
次に、メディアクエリの設定です。メディアクエリも、レスポンシブWebデザインを実現するための主要な技術要素の一つです。
メディアクエリはCSS3の新機能で、「ウインドウの幅」「画像解像度」「デバイスの向き」などを条件に、HTMLに適用するスタイルを切り替えることが可能になります。
メディアクエリを利用する際、「ウインドウの幅」「画像解像度」などの、適用するスタイルを切り替える条件となるものをブレイクポイントと呼びます。ブレイクポイントの検討と決定は、レスポンシブWebデザインによるサイト制作において、非常に重要なポイントの一つです。実際には、実装段階ではなく、その前の、設計段階で決定しておくのが望ましいでしょう。
具体的なメディアクエリの設定方法は、以下のような構文をCSS内に記述することになります。
@メディアタイプ and (条件・ブレイクポイント) {}
レスポンシブWebデザインでサイトを制作する場合、ブレイクポイントは、ウインドウの幅(画面サイズ)とするのが一般的です。次に、メディアクエリの具体例を紹介します。
/* ここに全画面サイズ共通のCSSと、767px以下のCSSを指定 */
@media screen and (min-width: 768px) {
/* ここに768px以上(~1023px)のCSSを指定 */
}
@media screen and (min-width: 1024px) {
/* ここに1024px以上のCSSを指定 */
}
メディアクエリを利用して上記のようにCSSを構築すると、画面サイズ(=ウインドウ、ブラウザの幅)「767px以下」「768px~1023px」「1024px以上」のそれぞれの場合に応じて、適用するCSSを切り替えることができるようになります。また、この例では、768pxと1024pxがブレイクポイントということになります。
ブレイクポイントに応じてメディアクエリを設定したら、画面サイズごとのCSSの記述です。具体的には、レイアウトを段組にしたり、画像や文字のサイズを適したサイズにしたりと、画面サイズに応じたレイアウト、デザインとなるように、CSSを記述していきます。
メディアクエリで指定する「メディアタイプ」は、一般的なレスポンシブWebデザインで指定される上記の「screen(=画面サイズ)」以外にも種類があります。また、条件のプロパティも「min-width」以外にもありますし、それら以外についても更なる詳細情報があります。一般的、基本的なレスポンシブWebデザインサイトであれば、上記の構文で十分ですが、メディアクエリの更なる詳細、ブレイクポイントの詳細については、実装の応用編として解説いたします。(鋭意制作中です)
11.実装(6)フルードグリッドの導入
最後に、フルードグリッドの導入です。フルードグリッドとは、Webページの要素を、グリッド(罫線や升目)に沿って配置する「グリッドデザイン」と呼ばれる手法と、ブラウザのウインドウサイズ(横幅)に応じて各要素を伸縮させてレイアウトを維持する「フルードデザイン(リキッドレイアウト)」と呼ばれる手法を組み合わせたレイアウト手法です。
まずは、フルードグリッドの必要性について。制作するサイトの内容、制作者の考え方によっても違いは出るでしょうが、ブレイクポイントの数は、2つか3つ、多くても4つ程度とするのが一般的でしょう。しかし、サイトにアクセスするデバイスの画面サイズは(ある程度のサイズの傾向はありますが)まちまちです。PCのブラウザであれば任意にウインドウサイズを変えることができます。なので、2~4程度のブレイクポイントで、全ての画面・ウインドウサイズに、完全に対応できるわけではありません。画面サイズに対してページの横幅が大き過ぎてはみ出してしまい、横向きのスクロールバーが出てしまうこともあれば、逆に小さ過ぎて、余白が目立つ表示になってしまうこともあります。このようになるのを防ぐため、画面・ウインドウサイズに応じて、フレキシブルに適正なレイアウトでページを表示する手法がフルードグリッドです。
実装手順としては、まずはグリッドデザインを用い固定レイアウトでページを作成し、レイアウトが整ったら、ピクセル(px)単位で指定されている要素の横幅(width)等の値を%に変換し、フルードデザイン(リキッドレイアウト)化します。
グリッドデザインは、レスポンシブWebデザインに特化した手法、技術というわけではありませんので、ここでは省略します。しかし、実装の応用編として別途まとめたいと考えています。(鋭意制作中)
グリッドレイアウトを用い固定レイアウトでのページ作成が終わったら、フルードデザイン(リキッドレイアウト)化です。具体的には、ピクセル(px)単位で指定されている要素のwidth、margin、paddingの左右の数値を、以下の計算式で算出したパーセント(%)値に変換します。
求める%値 = 変換する値 ÷ 変換する値の親要素の幅 × 100
width等のピクセル(px)単位の数値を、上記の計算式で算出した%値に変換したら、フルードデザイン(リキッドレイアウト)化の完成です。デバイスの画面サイズ、ブラウザのウインドウサイズに応じて、レイアウトが伸縮して画面・ブラウザ内に収まり、文字のずれやかぶりなどもなく表示されるはずです。
更に一言
実際にレスポンシブWebデザインでサイト制作を行っていて感じたのですが、「Viewportの指定」「フルードイメージの導入」「メディアクエリの利用」は、ほぼ必須といっていいと思いますが、「フルードグリッドの導入」については、レスポンシブWebデザインを実現する上で、必ずしも必要ではないのかもしれないと感じました。それは、制作するサイト(ページ)にもよります。段組のない1カラムのレイアウトで、コンテンツの内容やデザイン、ブレイクポイントの設定の仕方等々にもよりますが、場合によっては、必ずしもフルードグリッド化されていなくても、マルチデバイス対応は可能です。
ただ、この件に関しては、個人的に完全に腑に落ちているわけではないので、もうしばらく経験を積んで、考えがまとまったら追記したいと考えています。
12.調整、テスト、公開
実装が終わったら、調整、テストを行った後、いよいよ公開です。
といっても、実際は、実装、コーディングを行いつつ表示確認(テスト)、調整(コーディング)、確認(テスト)、調整(コーディング)を繰り返してページ(サイト)を作り上げていくという流れが、より実作業に近い流れだといえるでしょう。
サイトが完成したら、最終テストです。実装、コーディング中は、常に実際のデバイス(実機)で表示確認(テスト)を行うのは難しいものです。最終テストでは、可能な限り実機を使用するのが望ましいでしょう。とはいっても、全ての実機でテストを行うのは、現実的には不可能です。世の中には、既に無数のスマートフォン、タブレットが存在し、かつ今後も増え続けていくであろうからです。対象デバイスが明確になっていれば対象デバイスの実機、それ以外は、世の中に多く普及しているデバイスの実機でテストを行い、それ以外は、エミュレータやシミュレータを使用するのが現実的ではないでしょうか。より多くの実機でテストするほうが望ましいのは確かですが、コスト、スケジュールとも大きく関わってきますので、それらも考慮してテストで使用する実機を選択する必要があるでしょう。そして、これらテストに関する詳細は、設計段階で検討、決定しておく必要があるでしょう。
また、スマートフォンやタブレットは、画面サイズだけではなく、もう一点、PCと大きく違う点として、タッチデバイスだという点があります。従来のようにマウスを使って操作するのではなく、指を使っての操作となります。繰り返しになりますが、実装、コーディング中に、常に実機での確認は難しいと思われますので、テストフェーズの実機で確認できる際に、タッチデバイスとしてのユーザビリティについても確認する必要があるでしょう。
最終テストが終了すれば、ようやく公開です。
posted on 2015.09.09