「デスクトップサイトを見る」は必要ですか？
多くのWebサイトで、携帯電話を介してアクセスすると、フッターにリンクがあり、デスクトップバージョンのサイトにリンクしています。逆の場合もあります（UX.SEは両方を実行します）。ただし、サイトが適切に作成されている場合、このリンクが必要である理由はわかりません。実際、モバイルサイトの主な理由は、デスクトップバージョンをより小さな画面で動作するように最適化して、基本的にworseユーザーエクスペリエンスにリンクすることです。
なぜこの傾向が生じたのか、そしてもっと重要なことはまだそうすべきですか？
必要な場合デスクトップ用とモバイル用のWebサイトのバージョンが異なります。
たとえば、多くのWebサイトは、モバイルで操作するには複雑すぎる機能をスクラップしています。たとえば、Facebookのモバイルバージョンは、その設定のすべてを備えているわけではありません。
デスクトップのようにWebページをより速く処理できる大きなタブレットがモバイルとして認識される可能性もあります。
上記の場合、モバイルWebサイトからスクラップアウトされた機能に単にアクセスするためにデスクトップバージョンに切り替える必要がありますORページ全体を処理できるデバイスでWebバージョンを体験するにはデスクトップとしてすぐに。
2つのバージョンを作成する代わりに、複数の画面サイズの機能とエクスペリエンスを損なうことなくレスポンシブなWebサイトを設計することをお勧めします。この場合、個別のデスクトップサイトとモバイルサイトがなく、それらを切り替える必要はありません。
個人的には、そのようなオプションが不可欠だと思います。
2つの理由から：
- ユーザーはデスクトップインターフェイスに慣れている可能性があります。たとえば、デスクトップからWebサイトにアクセスするために使用されるユーザーは、モバイルバージョンで慣れているコントロールを見つけるのが非常に難しい場合があります。これは、ユーザーがモバイルバージョンを1回だけ使用する場合（たとえば、コンピューターから離れているときに何かを確認する場合）は好ましくありません。
- 常に機能に違いがありますモバイル版とデスクトップ版の間で。モバイルバージョンでは役に立たない1行または1つのボタンであっても、それを必要とするユーザーは常に存在します。
デスクトップサイトの必要性の主な理由は、次の3つの箇条書きに要約できます。
- 互換性の問題
Limited Working Features（まだ全機能のロールアウトに取り組んでいます）- 代替のリダイレクト
Rich Experience
ほとんどのモバイルサイトは、メインサイトの機能のサブセットで始まったであるため、この傾向はモバイルサイトの出現と初期の人気段階で10〜12年前に発生しました。たとえば、私のバンキングアプリでは残高が表示され、アカウント間での送金は可能ですが、他の人への送金や、口座振替/スタンディングオーダータイプのアクティビティの管理はできません。 レガシーシステムの下にあるため、銀行やその他のエンタープライズグレードのソフトウェアは、通常、何年もハイテク債務を負わなければなりません。そして、そのようなシステムは、モバイル用に作成されたことはありません。デスクトップサイトへのリンクは、一部の機能を完了するための唯一の方法でした。
また、一部のテクノロジーは新しく、比較的実験的なものであるという事実の要素もありました。それは、特にモバイルの比較的急速に変化する世界で、さまざまなデバイス、オペレーティングシステムなどの数によって、うまくいかない場合があることを意味します。ユーザーにバグの多いメニューシステムで対抗させるのではなく、不格好ではあるが機能するデスクトップバージョンへのアクセスをユーザーに許可する方が適切です。
現在、モバイルインターフェースの一貫性は非常に優れているため、それほど重要ではありません。デスクトップと同等の機能を備えている傾向があり、テクノロジーははるかに成熟しています。ただし、ユーザーがデスクトップインターフェースに慣れていて、「何かを成し遂げたい」だけの場合は、1つのタスクを実行するためだけにモバイルサイトを再学習するのではなく、デスクトップインターフェースに切り替える方が好ましい場合があるという事実はまだあります。たとえば、StackOverflowについては、私は自分の方法をほとんど学びましたが、iOSアプリは私にとってかなり新しいものです。
結局のところ、ユーザーにデスクトップサイトを使用するオプションを与えるだけであり、どこかに目立たないリンクを設定しても害はほとんどありません必要な人がそれを利用できるように、フッターに書き留めます。
スマートフォンを横向きにすると、デスクトップよりも解像度が高くなります。 320x480向けに最適化し、2500x1400以上の小さなデバイスが付属している場合、問題が発生します。ほとんどのサイトのモバイルバージョンは、ほとんどの場合、最悪のUXです。 （-個人的には、最悪のUXです。つまり、モバイルバージョンが好きな人がいることは明らかです。そのため、モバイルバージョンは持続しますが、そうでない人もたくさんいます。--）
あなたはすべてのために計画することはできません、多くのもののためだけに。しかし、計画できない計画を立てなければなりません。誰でも間違いはある。また、モバイルフレンドリーなプランの多くは、モバイルデバイスによって破棄されます。キュートで気泡のあるデュプロブロックスタイルのモバイルデザインを希望するか、通常のハードエッジで本格的なズーム可能で信頼性の高い、使い慣れたサイトを希望するかを、ユーザーが自分で選択できるようにします。
まあ時々サイトのモバイルバージョンにはコンテンツがありませんこれはデスクトップバージョンでのみ利用可能です。これは多くの場合、帯域幅を節約し（画像の品質を低下させるか、一部の要素を完全に除外して）、視覚的な混乱を排除します。ユーザーは自分のモバイルデバイスからそのコンテンツを見たい場合があるため、デスクトップまたはフルサイトへのリンクを提供することをお勧めします。
モバイル/デスクトップリンクを維持することを支持するもう1つの論点は、サイトのモバイルとデスクトップのバージョンユーザーはデスクトップバージョンに慣れている可能性があるなので、デスクトップバージョンを好むということです。
スティーブクルーグの意見
Do n't Make Me Think、Revisited では、第10章でモバイルのユーザビリティについて扱います。 Steve Kruggは次のように述べています（強調は私のものです）：
常に「完全な」Webサイトへのリンクを提供します。モバイルサイトがどれほど素晴らしいもので完成しても、ユーザーに次のオプションを提供する必要があります。特にモバイルバージョンでは利用できない機能と情報がある場合は、モバイル以外のバージョンを表示する。 （現在の規則では、すべてのページの下部にモバイルサイト/フルサイトの切り替えを配置します。）
人々が移動機能へのアクセスと引き換えに、モバイルデバイスの小さなビューポートを介して拡大/縮小しようとする多くの状況がありますその瞬間に使い慣れるか必要になる。また、一部のユーザーは、横長モードで高解像度画面の7インチタブレットを使用するときに、デスクトップページを表示することを好みます。
要するに
- ユーザーはズームしたいです。これは、デスクトップバージョンがなく、モバイルバージョンでズームが無効になっているときに嫌いな私の最大の理由です。チェックボックスやショートリンクなどは非常に小さいため、クリックするのはほぼ不可能です。
- デスクトップ版にはより多くの機能があります。これは通常、モバイルファーストデザインの場合です。このアプローチでKrugが説明するように、まず最も重要な機能に基づいてモバイルバージョンを開発し、次にデスクトップバージョンに機能を追加します。人々は時々その追加機能を使いたいと思うでしょう。
- ユーザーはデスクトップバージョンに慣れています。特にKrugが説明しているケースでは、パラメータがデスクトップセットアップにより近い「モバイル」デバイスがあり、したがって、デスクトップバージョンの方が快適ですが、モバイルデバイスとして認識される場合があります。
はい、
デスクトップユーザーにサイトの別のバージョンが表示されている場合。これはユーザビリティの問題です。小さな画面では適切に表示されないサイトや、同じコンテンツを提供しないサイトをたくさん見ました。 （通常、「クイックメニュー」/ユーザーの90％が欲しいと思うコンテンツに削減された、私ではありません！）
これは主に「m.websites」（例：m.cnn.com）に使用されており、すでにトレンドから外れており、徐々に衰退しています。
m.websiteは、基本的にはURLが異なるWebサイトの同じコピーです。同時に2つのWebサイトにコンテンツをフィードします。例：m.cnn.comとcnn.comには、画面の最適化が異なるコンテンツの重複があります。
M.websiteには多くの落とし穴があります、それはグーグルがあなたのウェブサイトをどのようにインデックスするかに影響します。レスポンシブなWebサイトは、デスクトップ、テレビ、タブレット、またはモバイル画面であるかどうかに関係なく、画面について心配する必要がないソリューションとして提供されました。コンテンツは任意の画面サイズに適応し、すべてのプラットフォームでコンテンツの維持と配信を容易にします。
レスポンシブなWebサイトを設計している場合、技術的にバージョンを切り替えることができないため、「View Desktop Site」を追加するオプションは役に立ちません。 m.websitesとは異なり、Webサイトには1つのバージョンしかありません。
なぜこの傾向が起こったのですか？
ウェブサイトを開発するために、それらがどのように開発されるかに向けて3つの主要なアプローチがあります*：
- レスポンシブWebデザイン
- アダプティブWebデザイン
- 「デスクトップ」と「モバイル」の別々のサイト
レスポンシブWebデザイン（RWD）は、表示される画面サイズに合わせて変更されるようにサイトが設計される場所です。技術的な観点からは、サイトが自動的に変更されるようにメディアクエリがよく使用されます。たとえば、幅の広いブラウザウィンドウで3つの列として表示されるものは、ウィンドウが狭くなると1つの列に変わる可能性があります。
Adaptive Web Design（AWD）は、サイトが異なるデバイスに対して異なる機能または異なるコンテンツを使用するように設計されている場所です。 current画面のサイズではなく実際の画面サイズに依存する傾向がありますが、技術的な観点から、メディアクエリmayが使用されます。多くの場合、デバイス検出は動作を変更するためにも使用されます。たとえば、ワイドスクリーンのラップトップで3列として表示されるものを、画面の小さいスマートフォンで1列としてレンダリングできます。
個別のサイトは、サーバー（および場合によってはクライアント）が、要求を行っているデバイスに基づいて、レンダリングされるWebサイトを変更する場所です。技術的な観点から、デバイス検出は、デフォルトの動作を上書きするクエリ文字列値など、他のいくつかのインジケーターと一緒に使用されることがよくあります。さらに、これがm.example.com「デスクトップ」サイトではなく「モバイル」サイトを表示/リンクするときのURL。
あなたはまだそれをすべきですか？
この質問は意見が分かれ始めており、正しい行動が何であるかについては、人によって意見が異なります。
私の意見 RWDは大部分のWebサイトにとって正しいアプローチであり、AWDは一部のアプリケーションに適しています。特に、タッチスクリーンと比較してキーボードとマウスを使用するなど、機能が大幅に異なる場合**描画ベースのWebアプリケーション用。
RWDを使用している場合、コンテンツと機能セットは同一（または少なくとも合同）であり、個別のモバイルサイトがないことを前提として、「デスクトップサイト」がないため、「デスクトップサイト」にリンクすることは不可能です。同じサイトです。
AWDを使用している場合、コンテンツと機能セットは同じままである必要がありますが、「デスクトップ」エクスペリエンスにアクセスする手段を提供する必要がある場合もあります。機能検出でできることはそれだけであり、キーボードとマウスを備えた小さなタッチスクリーンデバイスを使用して、「デスクトップ」エクスペリエンスを実現する場合があります。このような状況では、ユーザーが動作を切り替えられるようにするのが適切です。これは、「デスクトップ」サイトへの実際のリンクを意味しない場合があります。これは、単にタッチスクリーンコントロールとキーボード/マウスコントロール間の切り替えを許可しているだけかもしれません。
別のサイトを使用している場合は、ユーザーが表示しているサイトを切り替えることができるようにするのが適切です。ユーザーがサイトの両方のバージョンを表示できないようにすると、法的な灰色の領域にも入るようになります。募集中の職種をリストするサイドバーのある記事を考えてみましょう。そのサイドバーが「デスクトップ」サイトでのみレンダリングされ、モバイルサイトに同等のリストを提供しない場合、モバイルユーザーはあなたがそれらを差別していると主張する可能性があります。
tl; dr：
「デスクトップ」サイトへのリンクは、「デスクトップ」バージョンと「モバイル」バージョンのコンテンツや機能に実際に違いがある場合にのみ必要です。
2つのサイトがなく、異なる画面サイズのユーザーに対してコンテンツを非表示/表示しない場合、そのようなリンクを使用する理由はまったくありません。
*私が使用している用語の正確な意味を管理する標準化団体がないことに注意してください。そのため、同じ概念に対して異なる定義や異なる専門用語を使用している可能性があります。
** 2つのアプローチを組み合わせることが可能ですが
@JonStoryに同意します。両方のサイトがある場合、完全なデスクトップサイトにアクセスするオプションを提供しない理由はありません。特に、モバイルが利用できないテクノロジ（Java、Flash）が導入されている可能性がある場合。
モバイルファースト開発の最新のサイトでは、デスクトップサイトを作成する理由がない可能性があります（例：Bootstrap一般的にサイト）。
レスポンシブフォーマットに移行するサイトでは、デスクトップサイトが理にかなっています。現代の優れたサイトは、「デスクトップ」バージョンとリンクを完全にスキップします。
もう1つの理由：ユーザーが現在モバイルデバイスを使用していない可能性がありますが、モバイルサイトを使用しているユーザーが投稿したリンクをたどっているだけかもしれません。
（もちろん、これはサイトにモバイル用と「デスクトップ用」の異なるURLが実際にある場合にのみ適用されます。）
たぶんそうではないあなたのサイト間に違いがあっても。少なくとも、ユーザーエージェントの処理が適切に機能している場合。
例：AndroidモバイルのSEの下部に「フルサイト」リンクがあります。この回答を投稿するために探してみたところ、.
「request dekstop site」用のブラウザー独自のメニューオプションは、2つの理由で簡単に見つけることができます。ページの最下部までスクロールせずにメニューにアクセスできること。サイトデザイナーの気まぐれに応じて動きません。また、サイトが「アプリのダウンロード」画面をポップアップした場合でも、いつでも便利に利用できます。これはすべてAndroid版Firefoxに基づいています。 Chrome前回タブレットで見たイルカと同じように見えました。
他の人が言ったように、この傾向は元々、完全なサイトがモバイルデバイスに移植された方法が原因で発生しました。初期の頃、人々は確立されたサイトを利用して、モバイルテクノロジーで作業し、帯域幅を節約するためにそれらを縮小していました。これにより、解像度、向き、ブラウザ機能が変更されました。多くの場合、機能はコンテンツの一部とともに削除されます。
今日では、適切な開発プラクティス（モバイルファースト、ブラウザー間の互換性、レスポンシブデザイン）により、「サイト全体を表示する」オプションが不要になります。
私にとって、「サイト全体を表示する」オプションを含めることは、UXの重要な概念の1つです。ユーザーがエクスペリエンスを制御できるようにします。あなたのモバイルサイトはベストプラクティスのモデルであるかもしれませんが、私はまだ完全なサイトで作業することを好むかもしれません。そのオプションが利用できない場合は、ブラウザを探すのではなく、イライラしてサイトを離れる可能性があります。
IOS、Android、およびMicrosfotブラウザーには「完全なサイトを要求する」オプションがありますが、これは興味深い開発ですが、そのオプションとその使用方法を知っているかどうかは、ユーザーに依存しています。
モバイルバージョンでおなじみの「サイト全体のリンクを表示」の下部中央を提供することは、今のところ良い習慣です。
これは、サイトのデスクトップバージョンが十分に確立され、おそらく別のチームによって開発された非常に異なるモバイルサイトに「移植」されているときに行われると思います。
ウェブサイトは製品であり、多くの内部関係者がいて、非常によく進化および調整されており、彼らは物事を壊すわけにはいかない（AmazonまたはYahooのホームページを考えてください）...またはWebチームに「簡単に入手するモバイルサイトの高速化」と、それが最も適切な方法でした。
デスクトップチームは、フル機能の主力製品の保守を担当し、最も堅牢なモバイルプラットフォームで実行できないようにするためにのみ調整します（deFlashing）。
モバイルチームは、iPhone 2、Blackberry、「フィーチャーフォン」など、「モバイル」の世界をできる限りサポートすることを使命としています。
それでも、多くのサイトでは、ゲーティング（モバイルサイトへの強制転送）またはデスクトップのみの操作（マウスオーバー、ファイルのドラッグなど）が必要なために、モバイルでは実行できないことをしています。
皮肉なことに、最も堅牢なモバイルサイトは、実際にはphpBBのような単純なサイトであり、モバイルデバイスを使用していることにさえ気づいていません。
私は2つのWebサイトを維持するスタッフがいないので、私の好みは後者です。メインサイトをスマートフォンで十分に機能し、デスクトップでも問題のないシンプルなものにします。もちろんこれはバスの下にフィーチャーフォンを投げます。
はい、必要です。モバイルサイトがどのような場合でも機能していない場合、またはユーザーがアクティビティの正確なフローを取得できない場合は、デスクトップサイトを使用することをお勧めします。
モバイルユーザーが増加している今日、すべてのサイトはこの「デスクトップサイト」のオプションを削除する十分な応答性を備えている必要があります。技術的な制限により、特定のサイトがモバイル用とデスクトップ用に別々に作成されている場合（実際には実行しないでください）、このオプションを使用する必要があります。
一部の人々はこの質問を過度に分析したと思います。私の見解では常に「いいえ」であり、これには2つの単純な理由があります。
それが 応答性の高い その場合、質問を無効にする「デスクトップバージョン」のようなものは事実上ありません。レスポンシブレイアウトは、要素がデバイスに適切にレンダリングされるように機能する必要があります しかし、それはまだ単一のウェブサイトであり、異なるバージョンはありません。
あなたが持っている場合 分ける デスクトップとモバイルのウェブサイト（2つの異なるサブドメインなど）の場合、これらは明らかに理由により作成されています。その理由は、モバイルデバイスの機能、画面サイズ、対話方法が、デスクトップデバイスよりも制限されているためです。モバイルでデスクトップバージョンを確実かつ簡単に使用することができないため、効果的に構築されました。
したがって、どちらの場合も答えは「いいえ」です。デスクトップデバイスとモバイルデバイスは大きく異なります。かなり最小限のサイトまたは基本的なサイトがない限り、Any Given Device（TM）でも同様に機能しない可能性があります。
はい、
ほとんどのモバイルでBluetoothキーボードを使用できます。一部のスマートフォンでは、ディスプレイをテレビまたはモニターに送信できます。したがって、スマートフォンが小さなタッチスクリーンで使用されているかどうかはわかりません。
また、モバイルバージョンのサイトには、多くの場合、バグがあります。（たとえば、モバイルバージョンのgmailは、私のスマートフォンで数週間動作しなくなりました。）