📖 🧕🏼 〰️ モバイルインターフェースに関する研究 ⛩️ 📃 😒

アレクサンダードーソンによる「モバイルデザインの動向の研究」というタイトルの記事の翻訳を紹介します。 Smashing Magazineの発行の承認を得て、Habrahabrユーザー専用にUXDepotに転送されました。

Webデザイン業界は一度に多くの方向に発展していますが、その分野の1つは他のどのサイトよりもサイトを構築する方法に影響を与えています。インターネットへのアクセスを許可するモバイルデバイスの数が急増しているため、デバイスに適応するためにWebサイトを必要とするユーザーのサブカルチャーが生まれています。モバイルデバイスのWebデザインはまだ初期段階にありますが（この分野の動向に関する主要な研究はほとんどありません）、Web業界のこの重要な要素がどのように発展しているかを観察する必要があります。このエリアの開発の結果として登場しました。

この記事の目的は、モバイルデバイスのユーザーに便利で（できれば）便利な対話を提供するために、最も人気のあるサイトで使用されている方法について説明することです。分析されたサイトには、FacebookやAmazonなどの有名な企業が多数あります。統計と本当に興味深い発見とともに、モバイルWebデザインの世界への実際の遠足を準備しました。

このドキュメントはすべて同じですか？

モバイルデザインの進化し続ける分野におけるベストプラクティスと一般的な傾向を特定するために、人気のあるWebサイトのモバイルバージョンでの情報アーキテクチャとデザインの実装に関連する問題がどのように解決されるかを調査することを目的とした調査が行われました。この作業では任意の数のパラメーターをカバーできるため、いくつかの有用なことを学習する可能性が高いですが、その中のすべての質問に対する答えを見つけることができないことに注意することが重要です！

図 1：モバイル版は、あらゆるサイトの成功の重要な要素となっています。 Smashing Magazineには独自のモバイル版もあります。

この調査では、調査したWebサイトがモバイルデバイスを操作するときに相互作用を提供するものだけでなく、デスクトップブラウザーバージョンでは使用できない機能（便利な機能を備えたモバイルアプリケーションなど）を提供するかどうかも調査しました。マークアップ、設計決定、プログラミングレベル、およびモバイルサイトに固有の有用な機能のパターンも調査されました（可用性、一貫性、および使用されるアプローチのため）。

注：すべての研究が徹底的であるにも関わらず、非常に多数の研究されたパラメーターがあるため、不正確さや矛盾が作業に忍び込む可能性があります。

研究原理

私たちの研究の結果を発表する前に、評価されたパラメーターと、研究がどのように行われ、どのように結果が得られたかを説明するために使用された方法論について簡単に説明しましょう。この情報を使用して、この研究の限界を確認できます。起業家として十分な場合は、独自の研究を公開して、この研究の結果が他の状況に適用できるかどうかを確認できます。そのようなものを読むのは面白いでしょう！

図 2：これは、私たちの研究プロセスがどのように見えるかです。

研究方法論について。最初に、サイトのグループを選択しました（私たちではなく、独立してコンパイルされました）。次に、評価するパラメーターを選択しました。選択されたパラメーターの多くは、このような規模で（または慎重に）評価されたことはありません。いずれかのパラメーターが調査に該当するためには、特定の基準を満たす必要がありました。第一に、このパラメーターに関する研究の結果は興味深いものであったはずです（そして、モバイルデザインの分野でコミュニティが状況をどのように見ているかに影響を与えた可能性があります）、そして第二に、それらは統計的に重要であるべきです（明らかなことを書きたくない）。

注： 調査を実施した後、有用な結論が得られなかったため、結果からいくつかのパラメーターを除外しました。 そのため、たとえば、ページを表示するときに横向きと縦向きのサポートが発生しました-すべてのサイトがサポートされているため、これは重要ではないことが判明しました。

研究用サイトの選択

分析のためにサイトのグループを選択することは、もちろん、プロセスの重要な部分です。バイアスの可能性を排除したり、ニッチを考慮したりするために、 Google AdPlanner Listの最初の100サイトを使用することにしました。リストは1000サイトですが、最初の100サイトで十分であると判断しました
良いサンプルと非常に多目的な結果を得るために。

図 3：Google AdPlannerリストで最も人気のある1000のサイト-調査で使用された客観的な情報源。

パラメータ

推定されたパラメータについて話さなければ、この研究は意味がありませんでした。 2種類の基準に焦点を当てることに決めました。ユーザーがモバイルバージョンのサイトにアクセスする方法と、モバイルバージョンがどのように機能するかを特徴付けることです。ユーザーがモバイルバージョンのサイトにアクセスする方法は、既存のアプローチが多数あるため、注目を集めています。また、調査対象のWebページでモバイルデバイスのダウンロード速度、デバイスへのデータ転送速度、画面サイズ、タッチスクリーンの存在などを考慮に入れるかどうかを確認することも重要でした。

図 4：多くのパラメータが評価され、有益で有益な洞察が得られます。

起こりうるエラーの修正

もちろん、どの研究でも、間違いや偏った意見があります。この種の問題をできるだけ多く回避するために、個別にコンパイルされたサイトのリストを使用しただけでなく、調査対象の各モバイルサイトを最初にデスクトップで、次にいくつかのモバイルデバイスではなく、忠実度のためにエミュレータで実行しました。これにより、エラーの数を大幅に減らすことができ、別の日に各サイトを再テストして、何かが壊れたために結果が発生しないことを確認しました。

図 5：エミュレータを使用して、研究で使用するさまざまなデバイスの数を増やしました。

さて、最後に-結果

調査の基本原則が説明されたので、今から最も興味深いもの、つまり調査の結果についてお話します。多くのグラフとチャートの準備をしてください。そして、結果のいくつかが本当に驚くべきものであるという事実に備えてください。結果を個別のカテゴリに分割し、結果の異なる解釈の機会を提供しましたが、得られた情報が非常に明白になることを願っています。さあ、始めましょうか？

アクセス方法

調査のこの部分では、サイトのモバイルバージョンの存在がユーザーに明らかであるかどうかを確認することが重要でした。ユーザーがWebサイトにアクセスするとき、デバイスがサポートされているかどうか、またはサイトの通常バージョンが読み込まれるかどうかを知る必要があります。メインバージョンからのリダイレクトまたは自動デバイス検出が発生するかどうか、モバイルバージョンが別のサブドメインにあるかどうか、および通常のデスクトップブラウザーでモバイルバージョンのサイトに切り替えることができるかどうかを判断しました。

図 6：サイトのモバイルバージョンへの自動リダイレクトを行うサイトの数と、モバイルデバイスのオプションサポートを備えたデスクトップバージョンのみがあるサイトの数の比率。

図 7：WWWサブドメインでモバイルバージョンをホストしたサイトの数。

図 8：通常のデスクトップブラウザーで自分自身を開くことができるモバイルサイトの数。

図 9：Amazonサイトの.mobiバージョンがPCブラウザーで実行されている場合、m.amazon.comはPCユーザーをメインサイトにリダイレクトします。

モバイルデバイスを自動的に検出し、ユーザーをモバイルバージョンにリダイレクトするサイトの数は、予想よりも少ないことが判明しました（結局、多くの人は、ダウンロード速度を上げるためにモバイルバージョンを最初に表示する必要があると考えています）。しかし、これに伴い、1つの興味深い傾向に気付きました。PCからのモバイルバージョンのリクエスト中に1つ（answers.com）を除くすべてのサイトは、モバイルバージョンを開く機会なしにユーザーを強制的に通常バージョンにリダイレクトしました。

第1レベルのモバイルドメイン

調査の次の部分では、モバイルWebでトップレベルドメインが使用される頻度を判断しようとしました。実験の純度のために、サブドメイン（例：m）とトップレベルドメイン.mobi（および別のサイトにあるモバイルバージョン）のみが考慮されました。そのため、サブディレクトリ内のWWWドメイン内のサイト（たとえば、/ mobile /）にあるサイトのモバイルバージョンは考慮されませんでした。このデータは、.mobiドメインの人気度と、モバイルサイトでのサブドメインの使用傾向を示すことができます。

図10：モバイルドメインとその人気度の使用。

図 11：モバイルデバイス用に最適化されたサイトバージョンを持たないサイトの数。

図 12：サイトごとのサブドメインの平均数。

図 13：WAPおよびWMLプロトコルのサポート。

図 14：ユーザーを別の第1レベルのモバイルドメインにリダイレクトするサイトの割合。

図 15：PayPalは、モバイルサイトにドメインm。、 Mobileを使用します。 および.mobi。

多数のサイトにモバイルバージョンがあり、一部のWebサイトがユーザーをモバイルサイトにリダイレクトしているという事実にもかかわらず、.mobiドメインの使用は予想よりはるかに少ないことが判明しました。また、1つの異常な傾向に気付きました。他の国とは異なり、アジアのモバイルサイトでは（他の国で一般的な「m」または「モバイル」サブドメインの代わりに）「3g」サブドメインを使用することを好みます。 Appleデバイスのみが「タッチ」や「i」などの独自のサブドメインを取得できるのは幸運であることも注目に値します。

モバイルアプリ

調査のこの部分では、問題のリストからiOS、Android、またはBlackberry向けのモバイルアプリケーションがあるサイトの数を把握しようとしました。結果は要約されており、特定のプラットフォームで分割されていません。

図 16：（任意のプラットフォーム上の）モバイルデバイス用のアプリケーションがあるサイトの数。

図 17：モバイルアプリケーションはあるが、サイトのモバイルバージョンはないサイトの割合。

図 18：Internet Movie Database サイトには、モバイル版のサイトと、モバイルインタラクションをさらに強化するiPhoneアプリがあります。

TOP-100の多くのサイトにモバイルデバイス用のアプリケーションがあることは驚くことではありません。これらのサービスは非常に人気があり、広く普及しているからです。驚くべきことに、多くのサイトでは、モバイルバージョン（形式は問わない）がなくても、モバイルデバイス用のアプリケーションのダウンロードを提供しています。この傾向は、モバイルデバイスに適応したサービスへの移行が主に新しいモバイルアプリケーションの形であることを示している可能性があります。

平均読み込み時間

ここでは、モバイルサービスで無線ネットワーク帯域幅の制限と平均ネットワークユーザーの焦りの特性がどのように考慮されるかを理解するために、すべてのサイトの平均ロード時間を測定しました。 Wi-Fi経由でのみサイトをダウンロードしました（デバイスエミュレーター使用時の結果を均等にするために、3GまたはEDGEを使用しません）。また、キャッシュの使用も無効にしました。したがって、結果には、外部リソースのロードに必要な時間が考慮されます。

図 19：キャッシュなしのコールドブート条件でのサイトロード時間が最高、中、および最短。

図 20：Wi-Fiの使用時にロードに10秒以上かかるサイトの割合。

図 21：Wi-Fi経由でダウンロードするのに3秒以下必要なサイトの割合。

図 22：モバイルバージョンのYouTubeは、ダウンロード時間が最も短いものの1つです。

キャッシュを使用するとダウンロード速度が大幅に向上しますが、結果によると、モバイルサイトの大多数はダウンロードに5秒かかります。基本的に、ロードに5秒以上を必要とするサイトでは、ネットワークを介した情報の送信ではなく、サーバーの応答が遅いために遅延が発生することがよくありました。ユーザーは、画面に目的の情報が表示されるまで長く待つことを望まないため、サイトの読み込み速度が重要なパラメータになりました。

ホームページの重さ

ページの読み込み速度に加えて、ダウンロードされたファイルの重みと外部リソースも測定する必要があることがわかりました。多くのモバイル料金には重大な速度制限があり、モバイルトラフィックに対するメガバイトの支払いは高いままであるため、サイトがモバイルブラウザーでのダウンロード用に最適化されているかどうか、キャッシュされていないデータの量が平均的なWebと同じかどうかに注意する必要がありますデスクトップコンピューターのサイト。

図 23：キャッシュを使用せずに測定されたサイトの中で最大、平均、最小のキロバイト単位の重み。

図 24：キャッシュされていないダウンロードされたデータの合計量が100キロバイトを超えるサイトの割合。

図 25：ダウンロードされたキャッシュされていないデータの合計が25キロバイト未満のサイトの割合。

図 26 Softonic Webサイトは、ホームページの最大の重みによって際立っています。

このテストの結果は非常に興味深いものです。多数のサイト（主にWAP指向）の重量は25キロバイト未満（許容範囲内）ですが、モバイルデバイス用に調整されたと考えられるかなりの数のサイトの重量は100キロバイトを超え、ホームページの重量はほぼ0.5 MBに達することがあります！また、25 Kb以下のサイトの割合が100 Kb以上のサイトの割合と正確に一致したことに驚きました。

Doctype

Webサイトを作成するとき、最初の質問の1つは、Webサイトのコンテンツを表示するのに最適な言語または言語のバージョンです。 HTMLおよびXHTMLに関する宗教戦争はおさまりません。また、モバイルデバイス（XHTMLおよびWMLモバイルプロファイル）に適合した多くの種類があるため、さまざまなDTDの使用に関する統計が読者にとって非常に役立つと判断しました。そのため、調査のこの部分では、モバイルサービスのメインページで使用されるDoctypeを調べました。

図 27：言語バージョンやプロファイルなど、モバイルサイトでのマークアップ言語の配布。

図 28：モバイルプロファイルを使用するサイトおよび通常のプロファイルを使用するサイト。

図 29：WMLとXHTMLの両方をサポートするサイトの割合。

図 30：iPhoneに適合したモバイル版のDailymotionは、HTML5を使用する数少ないウェブサイトの1つです。

この調査の結果は、XHTMLがHTML（またはHTML5）よりもはるかに人気があることを明確に示しています。これは、多くのスマートフォンがHTMLとXHTMLをサポートしていることは注目に値しますが、HTMLにはモバイルプロファイルがないためです（結局、ほとんどの場合モバイルプロファイルが使用されます）。モバイルプロファイルとデスクトッププロファイルの使用率はほぼ等しいことが判明しました。また、iPhone用に最適化されたFacebookサイトは、Doctypeがまったくリストされていない唯一のサイトでした！

コードチェック

セマンティックWebとビジネスの標準に従うことの重要性を思い出して、ジェフリーツェルドマンによる「合格-失敗」の原則に関する簡単な検証テストを通じて多数のサイトを実施した調査の例に従って、このテストを実施しました。 Zeldmanは、Google AdPlannerのリストにあるTOP-100 Alexaから研究用のサイトを取得しました。 Webサイト開発における標準の順守はアルファやオメガではありませんが、このテストは、セマンティックWebにどれだけ近いかを調べるための調査に含まれています。

図 31：マークアップ配布で検証されたサイトの数。

図 32：指定したDTDによってホームページが検証されたサイトの割合。

図 33： MySpaceはほとんどと違いはなく、検証に合格しませんでした。

この調査は、ウェブサイトのモバイルバージョンのメインページのみに基づいていたため、結果は可能な限り完全ではありません。ただし、モバイルバージョンのサイトに注意が払われていることは明らかです。残念ながら、結果はZeldmanの研究の結果と一致しています。大部分のサイトは、選択されたDTDの基準を満たしていません。
これはすべて、開発者にとって最適化とコード品質によって設計が優先されるという事実によって強調されています。

コード分離

構造、スタイル、および動作を分離すると、ファイルサイズが小さくなります（コードの繰り返しを避け、キャッシュを使用することにより）。また、CSS3またはjQueryをモバイルサイトで使用してオブジェクトに動的な動作を与えるかどうかを確認することも重要に思えました。

図 34：個別のファイルではなく、インラインインラインスタイルを使用しているサイトの割合。

図 35：外部CSS 2.1またはCSS3を使用しているサイトの割合。

図 36：外部JSまたはjQueryを使用しているサイトの割合。

図 37：ウィキペディアのモバイルバージョンは jQueryライブラリを使用します。

モバイルページの読み込みを高速化するために、要素のスタイルと動作はそれらから削除されると想定していましたが、少数のサイトでは、すべてのコードがまだページに埋め込まれていました。また、ごく少数のサイトのみがjQueryフレームワークを使用し、同様に少数のサイトがCSS3のメディアクエリを使用してコンテンツのサイズを動的に変更します。ご想像のとおり、HTML5を使用するサイトの数は、CSS3を使用するサイトの数と同程度です。

フォント

タイポグラフィはウェブの不可欠な部分であり、情報の視覚化方法です。調査のこの部分では、Webで安全に使用できる書体とフォントファミリがモバイルサイトで使用されているものを調べました。また、デフォルトのフォントに依存し、フォントのシーケンスを示さないサイトの数、およびシーケンス内のいくつかのフォントを示すサイトの数にも注意しました。見出しフォントだけでなく、すべてのサイトコンテンツのフォントを調べました。

図 38：ヘッドセットが最初に表示されます。

図 39：フォントシーケンスを持たない（および既定のフォントを使用する）モバイルサイトの割合。

図 40：各サイトの指定されたファミリ内の指定されたフォントの数。

図 41：ウェブサイトm.naver.comは、ウェブで安全でないヘッドセットを使用するリスクがあります。

この研究の結果は私たちを驚かせました。いずれの場合も、フォントファミリが指定されると、sans-serifフォント（ヘッダーとテキストの両方）が優先されます。セリフフォントは使用されませんでした。場合によっては、フォントファミリがまったく示されませんでした（おそらく、これは異なるモバイルデバイス上の異なるフォントの存在の不一致が原因です）。これに加えて、かなりの数のサイトがフォントシーケンスを示していなかったため、これらのサイトではデフォルトのフォントが使用されています。

見出しのコントラスト

, . , , , .

図 42: , .

図 43: , .

図 44: , .

図 45: 56.com .

, , , ( ). , . — .

. , . , — .

図 46: , .

図 47: , .

図 48: eBay , , .

, , , , . , , , . , .

, . - ( ). , , , , , , , — , , ( ). , .

図 49: , .

図 50: Facebok .

. , . 100 !

. , , , . ( ).

図 51: .

図 52: , .

図 53: Daum.net «PC Version».

- “ ” “ ”. , , , ( ). , , .

図 74：Yahooはそのコンテンツをいくつかのクリックスルーパネルに分割しました。

この結果は、スクロール可能なパネルがほとんど使用されないことを示唆しています（これは、ほとんどのサイトに「クールな」スクリプトがないことを間接的に示しています）。この結果は、トップ100に含まれるWebサイトのタイプが原因で得られた可能性があります（ポートフォリオサイトおよびその他のデモサイトでは、パネルスクロールがより頻繁に使用されます）。デザインの一般的な簡素化（どのサイトでもスクロール可能なオーバーフローは使用されませんでした）とともに、スクロールを単純化するためにラバーレイアウトが使用されました。

進む

使用した選択には広範囲の異なる種類のサイトが含まれていましたが、異なるニッチでは結果が異なる可能性があることに注意する必要があります。たとえば、この調査がポートフォリオサイトで実施された場合、結果は異なります。そのようなサイトでは、ユーザーのニーズが異なるため、異なるインタラクションを作成する必要があります。それでも、問題のサイトで見られる傾向は、
他の多くのサイトに適用する

図 75：さまざまなWebサイトでさまざまなトレンドを見つけることができますが、それでもすべて類似の類似点があります。

この調査の結果が最も人気のあるWebサイトだけでなく特徴的であることを確認するために、さらに10のサイトを調査しました（これらの結果は、主な結果のチェックとして意図されているため、ドキュメントには含まれていません）。その中にはさまざまなサイトがありましたが、ほとんどが同様のアプローチを使用していたか、特定の使用シナリオのためにわずかに変更しました。したがって、特定された傾向はウェブ全体に存在すると考えています。

注： また、上位100のサイトの多くは、リストにある他のサイトのサブドメインまたはローカリゼーションであることに注意する必要があります。 しかし、結果をゆがめるようなサイトは少なすぎました。

一般的な傾向

モバイルデザインの一般的な傾向には、ユーザー自身にこの選択肢を提供する代わりに、モバイルデバイスのユーザーをモバイルバージョンのサイトにリダイレクトするスクリプトの使用が含まれます（これは、使いやすさの点で両刃の剣であるため、興味深いです）。別の確立された傾向は、ユーザーがモバイルバージョンのサイトにいることをユーザーが理解するのに役立つサブドメインの使用です。最後の一般的な傾向は、ごく少数のサイトのコードが検証に合格するという不快な事実です！

図76：一部のサイトでは、モバイル版はMobifyなどのツールを使用して実際に自動的に生成されます。

他のタイプのサイトのモデル

調査が他のタイプのサイトで行われた場合、グラフは少し異なって見えるかもしれません。例としては、ポートフォリオサイトでのCSS3の使用率が高いこと、中小企業の企業サイトでのモバイルアプリケーションの数が少ないこと、研究がソーシャルネットワークに焦点を当てている場合に必須の許可を持つサイトの割合が高いことが挙げられますまた、コンテンツ指向のサイト（Smashing Magazineなど）では、ページの重量が重いことは明らかな副作用です。

図 77：デザイナーSimon Collisonは、WebサイトでCSS3メディアクエリを使用して、さまざまな画面サイズに合わせてデザインを調整します。

可能な研究の改善

私たちの研究は改善される可能性があります。 iPhone 4、Blackberry、Nokia電話、Windows Mobileデバイス、2、3のAndroid電話など、多数のデバイスでサイトをテストしたにもかかわらず、エミュレーターを考慮せずに多数のデバイスとの互換性を調査できました。。また、より多くのサイトをテストすることで得られる結果の精度を高めることも可能です（サイトの数を1000に拡大するのは素晴らしいことです）。

図 78：特定のニッチのサイトでさらに研究を行うことができます。 たとえば、 The Guardianのようなニュースサイトです。

モバイルデザインの未来

この研究の結果は興味深いものですが、特定されたトレンドをフォローするだけでなく、新しいトレンドを探すように刺激されることを願っています。インターネットがまだ10代の場合、モバイルWebは赤ん坊です。これは、ユーザーのニーズがどれだけ満足されているかを調べるために実施される調査とともに、トレンドがさらに速く変化することを意味します。モバイルWebは未来の産業であり、それに注意を払う必要があります。

ウェブサイトを構築する方法は、jQueryのようなフレームワークのため、HTML5やCSS3のような標準の開発のため、そして新しいブラウザと異なる画面サイズを備えた新しいデバイスの出現、そしてWebサービスは徐々にクラウドに移行しています。モバイルデバイスのデザインには基本的な傾向（水平スクロールの欠如など）がありますが、この急速に成長する視聴者に関心を持つデザイナーが増えているため、今後数年間は暑くなるでしょう。

。
翻訳者からのPS： この記事を楽しんでください。 翻訳の誤りをご指摘いただければ、喜んで訂正いたします。 午後に私に書いてください:)

モバイルインターフェースに関する研究

アレクサンダードーソンによる「モバイルデザインの動向の研究」というタイトルの記事の翻訳を紹介します。 Smashing Magazineの発行の承認を得て、Habrahabrユーザー専用にUXDepotに転送されました。

このドキュメントはすべて同じですか？