スマートフォンやタブレットはタッチ操作が前提となるため、画面内のクリッカブルな要素は、人間の指でタッチ可能な大きさにする必要があります。デザイン」と呼んでいますが、画面の大きさに合わせてページ内のレイアウトを変更デザイン方法はいくつかあり、それらの仕組みを理解して組み合わせることで、各デバイスに最適な画面を提供することが可能になります。特徴的なものをいくつか示します。利用して画面サイズに応じて適用するスタイルを変更する方法です。スタイル自体を切り替えるので、レイアウトはもちろん要素の大きさや表示/非表示なども自由に指定することができます。明示的に指定する必要があるので、複数のデバイスに対応する場合は各々のデバイスの解像度を把握し、各解像度ごとのレイアウトを厳密にしておく必要になります。記述することにより相対的なサイズ指定が可能です。これを利用して、ブラウザーのサイズに合わせて要素のサイズが画面に対する割合を保ったまま自動的に変更するように記述することができます。デザインのように、エレメントを非表示にしたりといったことはできません。グリッドレイアウトリキッドレイアウトでは、要素のサイズが画面のサイズに合わせて自動的に可変していきますが、その大きさが必ずしもコンテンツの量にふさわしいとは限りません。なった場合は、フォントの大きさはそのままなので、余白が広すぎて読みずらい印象を与えてしまいます。レイアウトは、コンテンツのグリッド単位に求め、かつグリッドの大きさに上限下限を設け、画面サイズに合わせグリッド単位でのレイアウトが行うことができます。つの手法でのみ行う必要はありません。それぞれの得手不得手を把握し、お互いの不得意部分を補うような使い方をお勧めします。して考えた場合、高解像度の大画面で表示された際に、どのような表示になるのか考えておく必要があります。表示されずに隠れて操作できないという状況は発生しづらいので、見た目を気にしなければそのままでも機能的には構いません。固定ディスプレイの大きさに合わせてページ全体の画面を拡大してしまうか、コンテンツを中央部分に配置するなど、画面サイズが変更されても影響のないデザインを選択するなどです。前者は、ゲームの画面を思い浮かべてみると良いでしょう。並べて表示してもあまりうれしくはありません。いった場合にはディスプレイのサイズに合わせてゲーム画面のサイズを適切に拡大縮小します。画面サイズにあわせ拡大する)また、拡大縮小は行わずサイズは固定のまま、コンテンツの位置を中央に配置し、余白を均一にすることで整理された印象を与え、高解像度の大きなディスプレイで表示された際もデザインが崩れないようにするという方法もあります。いったデザインはブログやニュース記事によく見られます。アダプティブ(※)ディスプレイの大きさに合わせてレイアウトを変更し空白を埋める方法です。デザイン」には触れていません。ブラウザーの開発者ツールで確認することができます。ブラウザーの表示サイズを変更することができます。表示枠の方向を変更できます。ページがモバイルに最適化されているか検査してくれますので、こういったものを試してみるのも良いでしょう。セットが仮想マシンが無償で公開されているので、それを利用することができます。ブラウザーを使用することができます。月間無償で試用することができます。使い方については、以下の記事をご参照ください。ブラウザーの仕様が端末ごとにまちまちであり、シミュレーターの精度も高いとはいえませんでした。そのもののエミュレーターも提供されているので、実機を使わなくてもそれなりに高い精度の検証が行えるようになっています。以下の主だったスマートフォン用のシミュレーター/エミュレーターを紹介します。アプリの開発に使用するシミュレーターが付属しています。コンテンツの検証を行えます。パッケージの内にあるエイリアスから直接起動することもできます。手順は以下のとおりです。あるのでクリックして起動します。登録しておくと良いでしょう。開発元が提供しているものは無いようですが、サードパーティーの製品や、フリーソフトなど複数提供されているようなので、それらの中から評判の高いものを使うと良いでしょう。ユーザーであればそちらを使用することもできます。ないと考えたほうが良いでしょう。エミュレーターが付属しています。選択することで、サブメニューから具体的な機種を選んで起動することができます。エミュレーターを直接起動する方法については、同僚の高橋忍のブログの記事に書いてありますので、そちらをご覧ください。プラグインとして動作します。サイトより入手する必要があります。アプリの検証用ではありますが、単体起動して他のアプリケーションの検証も行うことができます。詳細について以下の記事をご覧ください。シミュレーターを直接起動する方法シミュレーター/エミュレーターでの検証の盲点シミュレーターやエミュレーターを使用するうえで気をつけなければならないことがあります。それは、それらのエミュレーションの精度が高くても、実際のデバイスとはハードウェアのスペックが異なるためまったく同じ動作になるとは限らないということです。アニメーションなどは、シミュレーター上できちんと動作したとしても、実機ではコマ落ちして使用に耐えないということも考えられます。バッテリーの持続時間や、ネットワークの状態なども同じ理由でシミュレーターなどでは正確な検証が行えません。通信環境を従量課金プランで使用するユーザーをターゲットとする場合は、ネットワークに流れるデータがそのまま金銭的なコストとなるので、通常利用でどれくらいの金額がかかるのか計測する必要があります。度以上は実機での検証を行うことをお勧めします。互換性の確保は、互換をとるための工数が少ないほうから行っていきます。いう順番で互換性を確保していきます。この順番は優先度、重要度にほかなりません。レガシーブラウザよりも、モバイルデバイスのほうが重要であるならば、検証の順番を入れ替えてください。サイトの構造とページ遷移、各ページのデザインが確定したら実際の製造作業に入ります。ファイルが必要になりますが、ここではそれらに関する作成や入手については触れません。コンテンツのへ要求は高まり、それを実現するための開発の難易度や工数は増えていきます。した状況を解決するために、開発にかかる工数と難易度を下げるためのライブラリや、フレームワークといったさまざまな仕組みが続々と生み出されています。した仕組みをうまく利用することで、開発の工数を減らしリリースまでのスピードを上げることができます。フロントエンド開発の工数を下げるためのライブラリやフレームワークといったものを紹介します。古くからさまざまな「ライブラリ」が提供されてきましたが、現在では、よりアプリケーション全体の機能を包括する「フレームワーク」というものが登場してきました。構造化されたデータを動的に描画出力できるテンプレートエンジンなども使用されるようになっています。書かれたコードの集合ですが、その使われ方に違いがあります。ライブラリは複数の関数が集まった、文字通りライブラリであり、ユーザーは自分のコードからライブラリ内の任意の関数を呼び出して使用します。それに対し、フレームワークはプログラム全体の動作を管理しており、ユーザーはフレームワークから呼び出されるためのコードやエレメントのプロパティを記述して使用します。以下のように記述するだけで、テキストボックスに入力された文字を下の段落に書かれた「入力された内容:」の後ろに続けて出力できるようになります。コードを記述する必要はありません。管理しているためです。コードを記述することで開発を行っていきます。ライブラリとフレームワークの違いは、ライブラリはユーザーのコードから「呼びだす」ものであり、フレームワークの場合は、ユーザーのコードは逆に「呼ばれる」ものであると言えるでしょう。サーバーサイドの仕組みのことを思い浮かべる人も多いかもしれませんが、ここでの「テンプレートエンジン」はクライアントサイドで動作するものです。エレメントをデータのひな形として使用し、同エレメントのインスタンスをデータの数だけ生成して値を設定し、親エレメントに追加する手法です。テンプレートエンジンとは、この処理をライブラリ化して簡単に記述できるようにしたものです。