「モバイルファースト」はまだ関連しています
私は、クライアントサイトでの展開用の新しいWebアプリケーションプロジェクトについて話し合っており、誰かが「なぜ？」
レスポンシブデザインはすべて低解像度のモバイル画面のケータリングに関するものでしたが、最近の携帯電話やタブレットの解像度ははるかに高くなっているようです。一部の最新の電話は、クライアントサイトで一般的に使用されているほとんどのデスクトップモニターよりも解像度が高くなっています。
したがって、それは単なるピクセル以上のものでなければなりません。携帯電話（およびタブレット）は、デスクトップと比較して非常に異なる対話モードを備えています。しかし、実際の問題は、すべてのデバイスで機能する複雑なWebアプリケーションをどのように作成すればよいのか、できれば各デバイスのバージョンがないことです。
編集：時間を割いて私の質問に回答してくださった皆さんに感謝します。私の質問は新人の質問のようですが、私はまだ答えが何であるかわかりません。おそらく答えがないからでしょう。
デスクトップ、ラップトップ、タブレット、モバイルで機能する複雑な基幹業務アプリケーションのシナリオでは、クレイジーな妥協をせずに単一のサイトを作成することさえ可能ですか？
「モバイル」サイト（m.whatever.com）を別にすることはデクラセであると言われましたが、実装がはるかに簡単で、維持します。
とにかく、素晴らしいフィードバックをありがとうございました。私はそんなに大きな反応を期待していませんでした。私のビジネスアプリケーションシナリオに関して、他に追加するものがあれば、ぜひ聞いてください。改めて感謝します。
はいといいえ。もちろん、モバイルファーストはまだ関連です。
それはピクセルについてではありません。画面サイズは均等ではありません。コンテキストと場所、注意と利便性と移植性と制約とコンテンツと戦略と組織と関連性についてですそしてライフスタイルとはるかに。
レスポンシブデザインできます結局、新しいペンキのコートに過ぎませんしばらくすると、薄さ下は透けて見えます。レスポンシブウェブサイトは、自動的に自動的に意味しません。それは確かに少し役立ち、それはプロセスの部分ですが、豚に口紅を付けた場合、それは豚のままです-レスポンシブWebサイトは自動的にレスポンシブコンテンツを作成しません。
モバイルサイロになるつもりはありませんでした。「モバイルファースト」とは、モバイル向けのウェブサイトやウェブアプリを設計することを意味すると考えるのは誤りですまず、ドアの前で「ここでモバイルを使用している」と言っているようなサイロのように。 Mobile Firstは、モバイル向けのサイロを作成するのではなく、それらのサイロを削除することについて非常に重要です。
モバイルファーストは方法論–考え方です。モバイルが提供する制約と機能を備えた設計についてです。制約付きの設計では、新しい機能を備えた設計がイノベーションを引き付ける一方で、集中して優先順位を付ける必要があります。うまくいけば、プロセスから学んだことがモバイルだけでなくあらゆる場所でコンテンツに利益をもたらすことになります。
「モバイルファースト」はに関連していますが、ソリューション全体ではありません-ロングショットではありません。
個人的には、「モバイルファースト」の「モバイル」という言葉は、文字通り、多分トンネルのビジョンが多すぎて、考え方ではなくコマンドとして捉えられていると思います。
したがって、「モバイルファースト」を唯一の設計戦略として採用しないでください。mobileに重点を置きすぎないでください。ただし、無視しないでください。
おそらく、このアプローチのより良い用語は「Content Everywhere」かもしれません。
これは一種のバックアップです 設計会社Work＆Coがバージンアメリカのウェブサイトを再設計したJoe Stewart氏 ：
デザインとデザインプロセスまたはレスポンシブについて全体的な考え方を考えると、モバイルファーストで物事を見る方法があると言う人もいますが、レスポンシブだとすべてが最初。一度にすべてを考えることができると、本当に安心します。
質問の編集されたコメントに応答するには：
article または slideshare のNeil TurnersがTUIを使用した経験など、他の人が複雑な基幹業務のためにモバイルにアプローチした方法のケーススタディを見つけることは価値があります。
以下は、私自身の関連スライドの一部です モバイルUXのスライドシェア
実際のところ、モバイルは今も存続しています。実際、一瞬Wordmobileを忘れましょう。コンテンツは多数のデバイスで使用できます。どこかで、片側に大画面エクスペリエンス、反対側に小画面エクスペリエンスという線を引きたいと思う場所。その行がm.whatever.comサイトを持つというあなたの決定である必要はありません。
ますます重要なのは、大画面または小画面で異なるコンテンツを配信することではなく、デバイス間を移動するときに一貫したエクスペリエンスを実現する方法です。
includes小さな画面を含む長期的なコンテンツ戦略を持つことは重要です。モバイルとデスクトップで異なる戦略を持つことは、災害への道です。
異なるコンテンツの配信についてではなく、異なるコンテンツの配信について考えてください。
レスポンシブウェブデザインではない低解像度のモバイル画面へのケータリングについて。高解像度でも低解像度でも、すべての物理デバイス画面サイズに対応します。
言い換えれば、モバイル画面の解像度が高くなったからといって、物理的な小さな画面のままです。追加の解像度は、より多くのデータをそこに詰め込むためだけのものではなく、より鮮明で明確な表示を提供するためのものです。
相互作用についても同じです。たとえば、タッチとクリック。最後の質問については、どのようにしてすべてのデバイスで機能する複雑なアプリケーションを作成するのでしょうか。 Mobile Firstは依然として賢明なオプションですが、他のオプションもあります。それはすべて、プロジェクトの特殊性に依存します。
最初にモバイルを使用することをお勧めします。デスクトップから始めてアイテムを取り除くよりも、シンプルなデザインから始めて構築する方がはるかに簡単です。
しかし、他のものと同じように、デスクトップ（およびタブレットでは忘れられない）も重要なプラットフォームであることを忘れている間、誰もが「モバイルビューポート」ボックスのチェックを急いでいるので、モバイルファーストは少し流行です。
モバイルを第一に考えて構築されていて、デスクトップのエクスペリエンスが低下しているデスクトップデザインを修正するように何度も依頼されました。コンテンツが左揃えに詰め込まれているため、不要なアコーディオンやエーカーの余白を考えてください。
Mobile Firstは、セット全体ではなく、多くのツールの1つです。
UXの観点から見た「モバイルファースト」に関して、非常に良い答えがいくつかあります（これはUX SEであるため、これは完全に意味があります）。しかし、「モバイルファースト」はプログラミングの観点からも非常に重要なフレーズであることを理解することが重要です。
プログラミングの側面は2つの基本原則に基づいています...
- CSSでレスポンシブデザインをコーディングする場合、一部（多くの場合） メディアクエリ を使用する必要があります。メディアクエリは画面の解像度などをチェックし、CSSの次のブロックを適用するかどうかを決定します。 メディアクエリは、その前に来たすべてのCSSの上に構築されることに注意してください。
- 帯域幅は、モバイルデバイスでは希少なリソースです。 T1回線を使用してオフィスのデスクトップコンピューターに複雑なWebページをロードするのは簡単ですが、3G接続で実行されている古いスマートフォンに同じページをロードするのははるかに困難です。
これら2つの事実を組み合わせると、次のような結果になります...サイトを「モバイルで最初に」構築する場合、モバイルデバイスはページを適切にレンダリングするためにbare minimum CSSをロードするだけで済みます。 。同じページをより大きなデバイスで表示した場合（おそらくインターネット接続が改善されている場合）、そのデバイスには、適切にレンダリングするために必要なだけCSSをロードできるという贅沢があります。
基本的に、「モバイルファースト」のアプローチは、最小のデバイスに最もシンプルなCSSを提供します。
この引用についても簡単に説明します。
「モバイル」サイト（m.whatever.com）を別にすることはデクラセであると言われましたが、実装がはるかに簡単で、保守も簡単だと思います。
残念ながら、あなたは非常に間違っています。 （レスポンシブデザインを完全に回避して）別のモバイルWebサイトを構築すると、最終的に2つのWebサイトになります。これは確かに簡単ではありません。対処する2つの完全なコードベースが提供されます...バグが発生する可能性が2倍、新機能を追加する場所が2倍、開発者が慣れるためのコードが2倍になります。
要約すると、「モバイルファースト」は依然として（プログラマーにとって）関連性があり、レスポンシブデザインは素晴らしいです！
全体的な画面サイズ、デバイスの電力、および操作方法は明らかに重要な考慮事項ですが、「モバイルファースト」は、ユーザーがモバイルデバイスでサイトを表示しているときにユーザーがどこにいて何をしているのかと同じくらい関係があります。
例1
航空会社のWebサイトにアクセスするデスクトップの訪問者は、のんびりと運賃を閲覧し、おそらくフライトを予約したいと思うかもしれません。座席を選択したり、マイレージマイルを確認したり、搭乗券を印刷したりしたいと思うかもしれません。
同じサイトに移動して飛行機に乗ろうとする人は、フライト状況、ゲート情報、現在迷っている空港の地図、QRコードで搭乗券を表示する機能に関心を持つ可能性があります。
例2
- タブレットの訪問者がレストランのウェブサイトにアクセスすると、写真、行き方/連絡先情報、オンライン予約またはレビューが必要になる場合があります。
- 同じサイトへの電話訪問者は、これらすべてに加えて、ソーシャル「チェックイン」機能、地域の特別情報を知らせる地理位置情報、またはデバイスから注文して支払う機能を必要とする場合があります。
どちらの場合も、同じ基本的なコンテンツとデータモデルを使用できますが、主要な機能への焦点は大きく異なります。これは、レイアウト、構造などに少なくとも画面サイズと「タップvsクリック」以上の影響を与えます。
アプリ/サイトを整理してこれらの状況を検討し、最も必要なものをユーザーに提供する（したがって、ユーザーを幸せな顧客として再訪させ続ける可能性が高い）は、「モバイルファースト」の真の重要な概念です。 「小さなタッチスクリーンの取り付け方」の問題は、実際の目標を達成するための1つの要素にすぎません。
さまざまなものを再配置/表示/非表示にするユニバーサルな「レスポンシブ」サイトを作成するか、まったく別の「m.domain.com」モバイルサイトを作成/維持するかを決定することは、状況に対するユーザーシナリオの違いと複雑さによって異なります。機能とコンテンツがよりモジュール化された方法で構築されている場合、特定のシナリオ/デバイスクラスで共有または優先されるコンポーネントを選択するのが簡単になる場合があります。