From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../web/guide/mobile/a_hybrid_approach/index.html | 72 +++++++++++++++++++++ files/ja/web/guide/mobile/index.html | 75 ++++++++++++++++++++++ .../guide/mobile/mobile-friendliness/index.html | 51 +++++++++++++++ .../ja/web/guide/mobile/separate_sites/index.html | 51 +++++++++++++++ 4 files changed, 249 insertions(+) create mode 100644 files/ja/web/guide/mobile/a_hybrid_approach/index.html create mode 100644 files/ja/web/guide/mobile/index.html create mode 100644 files/ja/web/guide/mobile/mobile-friendliness/index.html create mode 100644 files/ja/web/guide/mobile/separate_sites/index.html (limited to 'files/ja/web/guide/mobile') diff --git a/files/ja/web/guide/mobile/a_hybrid_approach/index.html b/files/ja/web/guide/mobile/a_hybrid_approach/index.html new file mode 100644 index 0000000000..6437181c13 --- /dev/null +++ b/files/ja/web/guide/mobile/a_hybrid_approach/index.html @@ -0,0 +1,72 @@ +--- +title: ハイブリッドアプローチ +slug: Web/Guide/Mobile/A_hybrid_approach +tags: + - Mobile + - Responsive Design + - Web Development +translation_of: Web/Guide/Mobile/A_hybrid_approach +--- +

銀の弾丸はウェブ開発で見つけるのが難しいです — 状況に応じてさまざまなテクニックを最大限に活用する戦略に出くわす可能性が高くなります。 これは私たちの3つ目のアプローチです。 これは、別々のサイトとレスポンシブデザインのアプローチを組み合わせることでそれらの欠点のいくつかを回避することを目的としています。

+ +

このハイブリッドアプローチは、モバイル開発を3つの目標に分割し、次に各目標に個別に取り組むために利用可能な最善のテクニックを適用することを中心としています。 この記事では、ここでは例としてテクニックの潜在的な組み合わせの1つを紹介しますが、さまざまな状況ではさまざまな組み合わせが適切になります。 覚えておくべき最も重要な概念は、サーバー側とクライアント側のテクニックをあなたの状況に合うように組み合わせることができるということです。

+ +

長所

+ +

レスポンシブウェブデザインは素晴らしいです — 今のところそれはさまざまな状況でレイアウトをできるだけ良く見せるために利用可能な最良のテクニックです。 モバイルとデスクトップのユースケースが十分に似ている場合、これはレイアウト変更のための間違いなく好ましい選択肢です。 ただし、サイトのコンテンツをユーザーのコンテキストに合うように変えるためにクライアント側のテクニックを使用するのは面倒です。

+ +

幸いなことに、ここではクライアント側のテクニックを使用することに技術的に制限されていません — もう1つの選択肢は、サーバー側のユーザーエージェント検出を使用してユーザーに正しいコンテンツを表示することです。 これにより、サーバー側でコンテンツを変えるという複雑さが保たれますが、それでも私たちのレイアウトはレスポンシブデザインの柔軟性と将来の備えから利益を得ることができます。

+ +

レイアウトではなくコンテンツ専用のユーザーエージェント検出を使用すると、コンテンツごとに1つの URL を設定して、コンテンツのレイアウトをユーザーのブラウザーに合わせることもできます。 これは一般的に良いこと（英語）だと考えられています。 まったく異なる2つのサイトを管理するのではなく、ユーザーが気になるコンテンツのページに転送するだけです。 そしてデザインはレスポンシブなので、各ページはユーザーの画面上で可能な限り見栄えがよいことがわかります。

+ +

また、サーバー側のテクニックを取り入れることで、レスポンシブデザインのパフォーマンスの問題に対処することもできます。 例えば、レスポンシブウェブデザインに関してよく批判されている点は、フル解像度の画像が、常に縮小された画像を表示する携帯電話を含むすべてのデバイスに送信されることです。 この問題に対処するためのそのようなテクニックの1つ（リンク切れ）は、WURFL デバイス能力ライブラリと一緒にサーバー側のユーザーエージェント検出を使用して、ユーザーのデバイス用に適切なサイズの画像を送信することです。 これをサービスとして提供するさまざまな製品（英語）も登場しています。 もちろん、このテクニックには、ユーザーエージェント検出に関連したすべての欠点があります。 それでもうまくいかなくても、fluid images（利用可能なスペースに応じて拡大縮小する柔軟な画像）を使用するよりもパフォーマンスに関しては悪くありません。

+ +

上記のテクニックを組み合わせることで、純粋な別々のサイトよりも柔軟で、純粋なレスポンシブデザインよりも優れたパフォーマンスを持つ、モバイルウェブ開発戦略を得ることができます。

+ +

短所

+ +

混合アプローチの1つの欠点は、クライアント側とサーバー側の両方でコードパスの数が増加する可能性があることです。 これにより、他のアプローチよりも開発に時間がかかります。 しかし、適切に計画すれば、コードを保守可能な方法で整理することができます。 もう1つの欠点は、このアプローチはレスポンシブデザインに依存しているため、通常、レトロフィットとしてではなく、新しいプロジェクトまたは既存のフレキシブルレイアウトを持つプロジェクトに最も適していることです。 同様に、ユーザーエージェント検出を使用しているため、時間が経つにつれて検出ルールを更新する必要があります。

+ +

この選択肢を選ぶのが正しいとき

+ +

サーバー側とクライアント側のテクニックを組み合わせることは、常に考慮に値するものです。 非常に多くの選択肢があるので、採用した個々のテクニックの長所と短所を比較検討する必要があります。

+ +

多くの場合、ハイブリッドアプローチの複雑さが増すことは必然ではありません。 例えば、ユーザーが実際に使用しているデバイスに基づいてコンテンツを調整する必要すらないかもしれません — ブラウザーに機能があるかどうかを知るだけで十分な場合があります。 これは、Modernizr の JavaScript 機能検出または Detect It を使用して、クライアント側で識別できる可能性があるものです。 実際に自分のコンテンツを調整しようとしている軸を掘り下げて自問するのは害になることはありません。

+ +

サーバー側のテクニックをレスポンシブデザインに取り入れることについて説明しましたが、モバイルとデスクトップのユースケースが大きく異なる場合は、ハイブリッドアプローチを使用する方法もあります。 例えば、メディアクエリとフレキシブルレイアウトを組み合わせることで、別々のサイトのデザインの柔軟性を高めることができます。 あなたもモバイルサイトのデザインをタブレットにも快適に拡張するのに十分適応可能にすることができるかもしれません。

+ +

例

+ +

webowonder_mobile_and_desktop-300x225.jpgMozilla の Web O Wonder デモサイトでは、ハイブリッドアプローチの基本バージョンを試してみましたが、良い結果が得られました。 レスポンシブウェブデザインのいくつかの要素を使用して、サイトにモバイルレイアウトを設定したり、ユーザーエージェント検出を使用してモバイル向けの動画を提供したり、ユーザーが携帯電話の場合はデモを並べ替えたりします。 github でソースコードをチェックしてください。

+ +

私達はまたこのアプローチを含むもっと多くの開発をすぐにやることができます！ 実際、次のようなメインの Mozilla サイトへの1つの可能性のある道筋は、上の「長所」セクションに概説されています。

+ + + +

物事はまだ開発段階にあるので、これまでのところモバイルについてはそれほど多くはありませんが、新しい mozilla.org が github で成長するのをいつでも見ることができます。 私たちの進歩についての最新情報は Mozilla Webdev ブログを購読してください。

+ +

まとめ

+ +

万能の解決策はありません。 モバイルユーザーのコンテンツやユーザーフローを大幅に変更したいウェブアプリケーションは、おそらく別のモバイルサイトに移動する必要があります。 モバイルユーザー向けにコンテンツを変更する必要がないコンテンツ指向のページは、レスポンシブデザインで満足するでしょう。 モバイルユーザー向けのサイトのメッセージを少し変える必要があるが、レスポンシブデザインのメリットを享受したい場合は、ハイブリッドアプローチが最善の策です。 このような決定は、モバイルウェブ開発の中核をなすものです。 達成したいことについて具体的に考え、妥協点を認識しながら実用的なアプローチを選択することです。 がんばろう！

+ +

モバイルウェブ開発への取り組み

+ +

モバイルプラットフォーム向けに開発するための背景やその他のアプローチについては、以下の記事を参照してください。

+ + + +
+

原本情報

+ +

この記事は、もともと 2011 年 6 月 27 日に Mozilla Webdev ブログで「モバイルウェブ開発へのアプローチ 第4回 – ハイブリッドアプローチ」として Jason Grlicky によって公開されました。（英語）

+
+ +

 

diff --git a/files/ja/web/guide/mobile/index.html b/files/ja/web/guide/mobile/index.html new file mode 100644 index 0000000000..796f4e5f27 --- /dev/null +++ b/files/ja/web/guide/mobile/index.html @@ -0,0 +1,75 @@ +--- +title: モバイルウェブ開発 +slug: Web/Guide/Mobile +tags: + - Intermediate + - NeedsExample +translation_of: Web/Guide/Mobile +--- +

このページでは、モバイル端末で適切に機能するウェブサイトを設計するために必要となる、主要な一部のテクニックの概要を説明します。 Mozilla の Firefox OS プロジェクトに関する情報を探している場合は、 Firefox OS のページを参照してください。または、 Android 版 Firefox に興味があるかもしれません。

+ +

モバイル端末向けの設計とブラウザー間の互換性の2つの節に整理しました。また、 Jason Grlicky によるウェブ開発者向けのモバイルへの親和性のガイドも参照してください。

+ +

モバイル端末向けの設計

+ +

モバイル端末は、デスクトップパソコンやノートパソコンと比較して、ハードウェアの特性がまったく異なります。画面は通常、明らかに小さくなりますが、ユーザーが端末を回転させると、画面の向きがポートレートモードとランドスケープモードの間で自動的に切り替わります。通常、ユーザー入力用のタッチスクリーンがあります。位置情報や画面の向きなどの API は、デスクトップでは未対応であったりあまり有用でなかったりしますので、これらの API はモバイルユーザーに、サイトと対話するための新しい方法を提供します。

+ +

小さな画面での作業

+ +

レスポンシブウェブデザインは、ウェブサイトのレイアウトを表示する環境 — 特に、大きさと画面の向き — の変化に合わせることができる一連の技術を表す用語です。これには次のような技術が含まれています。

+ + + +

viewport メタタグで、ブラウザーに対してユーザーの端末の適切な表示倍率でサイトを表示するよう指示します。

+ +

タッチ画面での操作

+ +

タッチ画面を使うには、 DOM タッチイベントの作業をする必要があります。 CSS の {{cssxref(":hover")}} 擬似クラスを使用することはできないでしょうし、指はマウスポインターより太いという事実を考慮して、クリック可能なアイテムをボタンのようにデザインする必要があるでしょう。この記事、 designing for touch screens を参照してください。

+ +

pointer または any-pointer メディアクエリを使用して、タッチ可能な端末で異なる CSS を読み込むことができます。

+ +

画像の最適化

+ +

端末の帯域幅が低かったり高価だったりするユーザーを支援するために、デバイスの画面サイズと解像度に適した画像をロードして画像を最適化することができます。 CSS でこれを行うには、画面の高さ、幅、ピクセル比でクエリを行います。

+ +

CSS プロパティを使用して、画像を使用せずにグラデーションや影などの視覚効果を実装することもできます。

+ +

モバイル API

+ +

最後に、端末の向きや位置情報など、モバイル端末が提供する新しい可能性の利点を活用することができます。

+ +

クロスブラウザー開発

+ +

クロスブラウザーコードを書く

+ +

様々なモバイル端末で受け入れられ動作するウェブサイトを作成するには、以下のことが必要です。

+ + + +

例えば、一部のテキストに背景としてグラデーションを、 -webkit-linear-gradient のようなベンダー接頭辞の付いたプロパティを使用して設定する場合、最も良いのは {{cssxref("linear-gradient")}} プロパティの他のベンダー接頭辞が付いたものを含めることです。それを行わない場合は、少なくとも既定の背景がテキストとコントラストが付いていることを確認してください。つまり、ページが少なくとも linear-gradient 規則の対象外のブラウザーで利用できるようにします。

+ +

この Gecko 固有のプロパティの一覧と、この WebKit 固有のプロパティの一覧、そして Peter Beverloo の table of vendor-specific properties を参照してください。

+ +

CSS Lint などのツールを使用すると、コード内のこのような問題を探すのに役立ちますし、 SASS や LESS などのプリプロセッサーを使用すると、クロスブラウザーのコードを生成するのに役立つことがあります。

+ +

ユーザーエージェントの推測に注意

+ +

以上のような手法を使用して、ウェブサイトが画面の大きさやタッチ画面などといった特定の端末特性を検出し、それに適応することが望ましい形です。しかし、これは非現実的である場合があり、ウェブサイトがブラウザーのユーザーエージェント文字列を解析して、デスクトップ、タブレット、携帯電話を区別し、端末ごとに異なるコンテンツを提供することに手を出しがちです。

+ +

これを行う場合は、アルゴリズムが正しく、特定のブラウザーのユーザーエージェント文字列を理解していないために、間違った種類のコンテンツをデバイスに提供していないことを確認してください。ユーザーエージェント文字列を使用して端末の種類を決定するガイドを参照してください。

+ +

複数のブラウザーでのテストTest on multiple browsers

+ +

ウェブサイトを複数のブラウザーでテストしてください。これは複数のプラットフォームでテストをするということです。 — 少なくとも iOS と Android です。

+ + diff --git a/files/ja/web/guide/mobile/mobile-friendliness/index.html b/files/ja/web/guide/mobile/mobile-friendliness/index.html new file mode 100644 index 0000000000..3b01479341 --- /dev/null +++ b/files/ja/web/guide/mobile/mobile-friendliness/index.html @@ -0,0 +1,51 @@ +--- +title: モバイルの親しみやすさ +slug: Web/Guide/Mobile/Mobile-friendliness +tags: + - Mobile + - Web Development +translation_of: Web/Guide/Mobile/Mobile-friendliness +--- +

モバイルの親しみやすさとは？

+ +

あなたが誰に話しているかによって、モバイルの親しみやすさ（friendliness）は多くのことを意味します。サイトのユーザーエクスペリエンスを向上させるための 3 つの目標（プレゼンテーション、コンテンツ、パフォーマンス）の観点から考えると便利です。

+ +

目標 1（プレゼンテーション）

+ +

「さまざまな画面サイズで適切に機能するウェブサイトを作成してください。」

+ +

最近では、携帯電話、タブレット、電子ブックリーダーなど、さまざまな形状のデバイスでウェブにアクセスできます。言うまでもありませんが、複雑な JavaScript アニメーションとマウスオーバー効果でいっぱいの固定幅で 3段組みのレイアウトは、2 インチ幅の画面と小型のプロセッサを搭載した携帯電話では見た目も感じ方もよくありません。タッチスクリーン用のサイズ（英語）の要素を持つ、すっきりと真っ直ぐ並んだページレイアウトの方が、はるかに適切です。最初の目標が、モバイルデバイスのユーザーの生活を楽にするような方法でコンテンツを提示することにあるのはこのためです。

+ +

目標 2（コンテンツ）

+ +

「モバイルユーザー向けにコンテンツを調整してください。」alaska_air_mobile_and_desktop-300x225.png

+ +

ユーザーが携帯電話を使っている場合、ユーザーがあなたのサイトで何をしたいのかを考えてみましょう。その好例が、アラスカエアのウェブサイト（英語）です。彼らのデスクトップサイトは訪問者に旅行を予約させることに焦点を合わせています。ところが、モバイルユーザーは、フライトのチェックインや、フライトが遅れるかどうかを確認することに関心があります。これを反映するようにサイトのコンテンツを調整し、モバイルユーザーのニーズを満たしています。

+ +

目標 3（パフォーマンス）

+ +

「遅い接続でも、ユーザーにスムーズな操作を提供します。」

+ +

近年物事は良くなってきていますが、ワイヤレスデータ接続を介してインターネットを閲覧することは依然としてかなりつらいこともあります。そのため、実際に必要なものだけをユーザーに送信するという、優れたパフォーマンスの実践（英語）を実践することがこれまで以上に重要になります。

+ +

視聴者を知る

+ +

厳密にはモバイルの親しみやすさの定義の一部ではありませんが、対象視聴者が誰であるかを定義することで、これらの目標はより具体的になります。例えば、モバイル戦略を選択するときに、どのブラウザーとデバイスを対象にするかを念頭に置くことが絶対に重要です。視聴者がアーリーアダプターでいっぱいであるならば、規格に優しいブラウザーのタブレットとスマートフォンに集中することができます。一方で、サイトのユーザーの多くが機能が低いブラウザーのデバイスを使用している場合は、実行可能な選択肢として特定の戦略が排除される可能性があります。

+ +

モバイルウェブ開発へのアプローチ

+ +

以下のアプローチは、さまざまな手段でこれらの各目標を達成することを目的としています。

+ + + +
+

原本情報

+ +

もともと 2011 年 5 月 4 日に Mozilla Webdev ブログに Jason Grlicky による「モバイルウェブ開発へのアプローチ 第1部 - モバイルの親しみやすさは？」として公開されました。（英語）

+
+ +

 

diff --git a/files/ja/web/guide/mobile/separate_sites/index.html b/files/ja/web/guide/mobile/separate_sites/index.html new file mode 100644 index 0000000000..2bafcd7453 --- /dev/null +++ b/files/ja/web/guide/mobile/separate_sites/index.html @@ -0,0 +1,51 @@ +--- +title: モバイルとデスクトップで別々のサイト +slug: Web/Guide/Mobile/Separate_sites +tags: + - Mobile + - Web Development +translation_of: Web/Guide/Mobile/Separate_sites +--- +

モバイルウェブ開発への「別々のサイト」アプローチは、モバイルウェブユーザーとデスクトップウェブユーザーのために異なるサイトを作成することを含みます。このアプローチにはプラス面とマイナス面があります。

+ +

長所

+ +

この最初の選択肢はこれまでで最も人気があります — ユーザーエージェント検出を使用して、携帯電話のユーザーを別のモバイルサイト（典型的には m.example.com）に転送する方法です。一言で言えば、このテクニックではサーバー側のロジックを使用してモバイルウェブ開発の 3 つの目標（英語）すべてを一度に解決します — ユーザーのブラウザーが携帯電話のように見える場合は、携帯電話用にフォーマットされ、速度が最適化されたモバイルコンテンツを配信します。

+ +

概念的には単純ですが、特にテンプレートをサポートする CMS またはウェブアプリケーションを使用している場合は、これが既存のサイトに追加する最も簡単な選択肢です。モバイルユーザーにはモバイル固有のコンテンツ、スタイル、およびスクリプトのみが送信されるため、この方法では、ここに示されている他の選択肢のどれよりも最高のパフォーマンスが得られます。最終的に、デスクトップとモバイルでまったく異なるユーザーエクスペリエンスを実現できます — 結局のところ、それらは 2 つの異なるサイトです！

+ +

短所

+ +

残念ながら、このアプローチは欠点がないわけではありません。手始めに、モバイルユーザーに公開したいサイトの各ページに対して 2 つの異なるページを管理しています。CMS を使用している場合は、この重複を最小限に抑えるようにサイトのテンプレートを配置することが可能です。ただし、モバイルとデスクトップでテンプレートに違いがあるときはいつでも、コードには複雑な原因がひそんでいます。同様に、2 セットのフロントエンドロジックをコーディングする必要があるため、これにより新しいサイト機能の実装時間が長くなります。

+ +

ただし、それよりもさらに重要なのは、ユーザーエージェントの検出には本質的に欠陥があり（英語）、将来を見据えたものではないという事実です。新しいブラウザーが登場するたびに、それに対応するようにアルゴリズムを調整する必要があります。そして誤検知は特に怖いです — モバイルサイトを誤ってデスクトップユーザーに配信すると当惑させるかもしれません。

+ +

この選択肢を選ぶのが正しいとき

+ +

sumo_screenshot.pngまず、対象視聴者に古いかローエンドのフィーチャーフォン（英語）のユーザーが含まれている場合は、この戦略をある程度（英語）採用する必要があるかもしれません。これは、一部のフィーチャーフォンのデフォルトブラウザーは、デスクトップを対象としたウェブサイトと同じマークアップをサポートしておらず、代わりに XHTML-MP や古い WML などの形式を理解するためです。

+ +

この要因はさておき、この戦略が他の方法よりも本当に優れているケースが 1 つあります。モバイルデバイスでユーザーに提供したい機能がデスクトップのそれとは極端に異なる場合は、別々のサイトを使用するのが最も実用的な選択（英語）になる可能性があります。これは、完全に完全に別々の HTML、JavaScript、CSS を携帯電話と PC に送信するという選択肢があるからです。

+ +

このアプローチを使用することを余儀なくされるもう 1 つのケースは、何らかの理由で既存のデスクトップサイトを変更できず、100% 別のモバイルサイトを必要とする場合です。理想的ではありませんが、少なくともこの選択肢があります。

+ +

例

+ +

Facebook、YouTube、Digg、Flickr など、あなたが実際に目にする主要なウェブアプリケーションのほとんどがこの方法を選択しています。実際、Mozilla はモバイル版の addons.mozilla.org（AMO）と support.mozilla.org（SUMO）にこの戦略を選択しました。このアプローチの例の背後にあるソースコードを実際に見たい場合は、AMO または SUMO（リンク切れ）の github リポジトリをチェックしてください。

+ +

モバイルウェブ開発へのアプローチ

+ +

モバイルプラットフォーム向けに開発するための背景やその他のアプローチについては、以下の記事を参照してください。

+ + + +
+

原本情報

+ +

この記事は、もともと 2011 年 5 月 13 日に Mozilla Webdev ブログで「モバイルウェブ開発へのアプローチ 第2部 - 別々のサイト」として Jason Grlicky によって公開されました。（英語）

+
+ +

 

-- cgit v1.2.3-54-g00ecf