- モバイル向けに作ったレイアウトをそのままデスクトップへ拡張すると、画像・文字・余白が過度に大きくなり、情報が長いページに散らばるコンテンツ分散によって使い勝手が悪化する
- 世界のWebトラフィックの55%以上がモバイルで発生していることから、モバイルファーストは広く使われているが、ミニマリズムと大型画像中心のデザインが組み合わさると、デスクトップでの情報密度が大きく低下する
- 13件の定性的ユーザビリティテストで、分散型レイアウトと圧縮型レイアウトを比較した結果、分散型ページは情報の探索と理解をより難しくしていた
- 分散したコンテンツはスクロールとクリックを増やしてインタラクションコストを高め、関連情報を複数の画面にまたがって記憶させることで、認知負荷・フラストレーション・信頼低下につながり得る
- デスクトップでは重要な関連情報を同じビューポートにまとめ、アコーディオンのようなモバイル専用パターンは限定的に使うべきである
コンテンツ分散とは何か
- コンテンツ分散とは、レスポンシブWebページのコンテンツが大きなノートPCやデスクトップ画面で過度に大きく引き伸ばされて見える現象である
- モバイルファーストのページがデスクトップでレンダリングされると、画面を覆う画像、膨らんだ大きな文字、過度なネガティブスペースによって長いページが生まれ、より多くのスクロールを要求する
- 一部のセクションだけに分散が見られる場合は大きなユーザビリティ問題にならないこともあるが、ページの大半が分散している場合、その累積的な影響は概して否定的である
- 大画面デバイスにおけるコンテンツ分散は、認知負荷、インタラクションコスト、コンテンツ理解の難しさ、ユーザーのフラストレーションを増大させる
コンテンツ分散を生むデザイン傾向
- モバイルファーストアプローチは、まずモバイル向けに設計し、その後タブレットやデスクトップ向けに調整する方式である
- 世界のWebトラフィックの55%以上がモバイルデバイスで発生していることから、このアプローチは広く使われている
- ミニマリズムは、Webサイトの中核機能やメッセージに不要なデザイン要素を取り除く
- 複雑に見える印象を避けるため、ネガティブスペースを多く使う
- 1画面のビューポートに表示されるコンテンツ量が減ることで、情報密度の低い長いページになり得る
- 大型画像中心のデザインは、現代のWebで高解像度画像を大きく使う流れと結びついている
- 大きな画像は視線を引きつけられるが、テキストコンテンツを過度に散在させる可能性がある
- デスクトップページに大きな画像が数枚あること自体はうまく機能する場合がある
- 大きな画像が多すぎると、画像の間にあるテキストベースのコンテンツがページ全体に断片化される
13件のユーザビリティテストの方法
- テストは13件の定性的ユーザビリティテストと半構造化インタビューを組み合わせて実施された
- 比較対象は、2種類のレイアウトと2種類のページタイプの組み合わせである
- レイアウト: 圧縮型、分散型
- ページタイプ: ホームページ、製品ページ
- 合計4つのプロトタイプを使用した
- 分散型プロトタイプは、実際のデスクトップWebページのうち、コンテンツ密度が低く、ネガティブスペースが広く、文字が大きいページを見つけて再構成したものだった
- 圧縮型バージョンは、元のページと同じコンテンツを使って別途制作した
- ユーザーは4つのプロトタイプでオープンエンドの活動を行い、各ページタイプの2つのバージョンを比較する追跡ディスカッションに参加した
- 研究全体の方法論は別の方法論ページにある
分散したコンテンツが生むユーザビリティ問題
- 分散がページの広い範囲にわたって現れる場合、全体のユーザー体験に大きな影響を与え得る
- 主な問題は次のとおり
- ページの長さとインタラクションコストの増加
- 認知負荷の増加
- ページの概念モデル形成の難しさ
- フラストレーションの増加
- 信頼性の低下
-
スクロールとクリックの増加
- コンテンツ分散は、より多くのスクロールを必要とする長いページを生み、アコーディオンのようなモバイル専用デザイン要素はコンテンツへのアクセスにさらに多くのクリックを要求する
- モバイルファーストのWebサイトが大画面でレンダリングされると、コンテンツが分散して長いページになり、ミニマリズムと画像中心デザインが組み合わさるほどこの効果は大きくなる
- コンテンツが複数のビューポートに散らばっていると、ページ内で特定の情報を見つけにくくなる
- テスト参加者は、分散型の製品ページで圧縮型バージョンよりも情報を見つけるのに苦労していた
-
モバイル専用パターンのデスクトップでの問題
- アコーディオンはモバイルでは多くの情報を狭い空間に折りたたみ、ページを短くし、ユーザーが関心領域へ直接アクセスするのに役立つことがある
- 大画面では長いページの問題が相対的に小さいため、アコーディオンはコンテンツの断片化を生み、重要な情報を探すインタラクションコストを大きく高める可能性がある
- ある参加者は、分散型プロトタイプの製品情報アコーディオンで、情報を読むために各項目を開閉しなければならなかったと反応した
- 別の参加者は、圧縮型ページの方がクリック数が少なく、情報がすぐ目の前にあるので良いと評価した
-
認知負荷の増加
- 画像が大きくなり、ネガティブスペースが広がるほど、テキストベースのコンテンツは複数のビューポートへ断片化される
- 関連コンテンツが画面単位で切り分けられると、ユーザーはそれらをひとまとまりとして捉えにくくなる
- 判断や意思決定のために異なるビューポートの情報を記憶したり前後にスクロールしたりする必要があり、短期記憶の容量は容易に圧倒され得る
- 圧縮型レイアウトは同じビューポートにより多くの情報を表示し、認知的負担を減らして、より楽な探索体験を提供する
- 画像の性質も断片化の感じ方に影響する
- 情報性画像は、ユーザーが有用な情報を得るために時間をかけて見るため、大画面に大きく表示されても追加負担は小さい場合がある
- 装飾画像は情報価値がないため、ユーザーは見ずに通り過ぎ、有用なコンテンツに到達するまで大きな挿絵をスクロールしなければならず、断片化の体感はより悪化する
概念モデルと信頼性への影響
- 分散型ページは、長くなったページと作業記憶への負担によって、Webサイトが伝える概念を評価し、概念モデルを形成することを難しくする
- ホームページのプロトタイプでは、参加者は4〜5個の提案をまとめて見て範囲を理解する代わりに、それらを記憶しながら理解しなければならず、より難しいと反応した
- 製品ページでは、価格、製品詳細、レビューのような購買判断要素が複数のビューポートに散らばっていると、ユーザーは情報を別々に消費して記憶しなければならなかった
- 重要な情報が一緒に置かれているか、より少ないビューポートに配置されていれば、製品や提供価値についての概念的理解を作りやすい
- 完結性の錯覚は、分散型Webサイトでより顕著になり得る
- 色のブロックがビューポートに強い水平線を作ったり、広いネガティブスペースがページが終わったように見せたりすることがある
- さらにコンテンツがあることを示すスクロールの手がかりがなければ、ユーザーはコンテンツを見落とす可能性がある
- ユーザビリティ問題が蓄積すると、分散型Webサイトはコンテンツが少なく、アクセスしにくいように見えることがある
- 一部のユーザーは、会社が情報を隠していると感じる可能性があり、その場合信頼性が低下し得る
- ユーザーは特に、Webサイトを探索し、提供内容を全体的に理解しようとする目的があるとき、圧縮型レイアウトをより好んだ
コンテンツ分散が役立つ場合
- ページ全体が分散していると累積的なユーザビリティ影響は概して否定的だが、特定の状況では体験に肯定的に働くこともある
- 1つのビューポートに表示されるコンテンツ量が減ると、ユーザーは一度に1つの強調コンテンツに集中でき、情報過多の認識も減らせる可能性がある
- ビューポート内のコンテンツ密度を下げて情報を強調する方法が有効なのは次の場合である
- 複雑なコンテンツを一片ずつ理解する必要がある場合
- ユーザーが表示されたコンテンツに慣れる必要があり、情報が多すぎると圧倒される可能性がある場合
- 高価値な画像を見せる場合
- 大きな製品写真は、ユーザーが製品の詳細を容易に確認できるようにし、価値を加えることがある
- 情報価値の高い画像は分散を正当化し得るが、埋め草の画像や単なる視覚的興味のための画像は、追加の利点なく分散だけを引き起こす
- ホームページのプロトタイプでは画像の価値がより低く、コンテンツ分散の肯定的効果はあまり観察されなかった
デスクトップ設計の推奨事項
- デスクトップレンダリングを別途評価すべきである
- デスクトップでページの大部分が過度に引き伸ばされているなら、重要なコンテンツをひと目で確認しやすいよう再設計するか検討すべきである
- 画像がもたらす価値を見極めるべきである
- 製品やサービスの文脈理解を助ける大きな画像を優先する
- 大きな画像がデスクトップで生む分散を受け入れるだけの価値があるか判断する必要がある
- 重要な関連コンテンツは同じビューポートにまとめるべきである
- 提供内容を理解するうえで最も関連性の高い情報を考慮し、前後スクロールを減らすデザインを選ぶべきである
- モバイル専用のインタラクションとデザイン要素は制限すべきである
- デスクトップでのアコーディオン使用は減らすべきである
- 同じコンテンツをデスクトップ向けに表示する適応的デザインを検討すべきである
- 分散は、重要ポイントや複雑なコンテンツに注意を集中させる戦略として限定的に使うのが適切である
結論
- ミニマルなデスクトップページの分散したコンテンツは、雑然さを減らし、重要ポイントや複雑な情報に注意を集中させることができる
- しかし、ページ全体がモバイルファースト、ミニマリズム、画像中心デザインに従って構成されると、デスクトップでのユーザビリティ問題は大きくなる
- コンテンツが複数のビューポートにまたがって引き伸ばされ、断片化されると、ユーザーは情報を消費し理解することが難しくなる
1件のコメント
Hacker Newsの意見
Danny O'Brienは古いブログOblomovkaを運営しており、2007年ごろに hinternet という言葉を作った
当時のインターネットは、技術エリートが自分たちのために運営していた場所に一般の人々も入り始めた時期で、hinternetとは、洗練された技術と価値のあるインターネットと、Viagraスパムやポップアップバナーのインターネットが別々に存在するという考え方だった
かつて技術エリートは、危険な地区に行くのを避けるようにhinternetをほぼ避けられたが、一般の人々にはそうした見分ける手段がなく、はるかに劣ったインターネット体験をしていた、という話である
今ではインターネットの大半がhinternetになり、銀行・住宅ローン・自動車ローンの支払い・公共料金といった必須システムも モバイルファースト で設計され、「本物のユーザー検証」を口実に、オープンプラットフォームでは壊れるようなダークな手法を使っている
かつてのhinternetが偽物の時計を売る薄暗い路地だったとすれば、今では準政府機関が背後で運営する垂直的な情報統合のディストピアに近く、IRSにログインするには、商品まで売っているID管理プラットフォームid.meを使わなければならない
洗練された小さな庭を育てようとする試みはあるが、成功はまちまちで、個人の立場では、本当に必要な用事以外でhinternetに参加する動機はほとんどない
この観点から見ると、「モバイルファーストWebデザイン」は、より大きな文脈から切り離された症状にすぎない
一方には学界・軍・政府の教養あるエリートが正当な創設者としており、もう一方にはEternal September以後に入ってきた大衆がいる、という構図である
結局、商人・投機家・詐欺師のような流入者たちが新世界の企業や銀行へ帰化した、という話になるが、ドットコム時代を植民地化の物語として見ると、エリートは自分の土地から追いやられた先住民となり、現代的な語り口にもよく合う
しかしこの寓話から抜け落ちているのは、実際の普通の人々である
1997年から2010年ごろまでのドットコム、Web 2.0、帝国づくりは、依然として既存の金と権力がインターネットへ移動し、少数の荒々しい「起業家」が加わった周縁的な出来事であり、99%は観客として残っていたが、今では牧場に追い込まれたようなものだ
人々のインターネット の可能性はまだあるが、フリーライドやコモンズの悲劇といった古典的な問題をほとんど解決できておらず、現時点では「Web 3.0とブロックチェーンWeb」は死んだように見える
再び公共的で高品質な、大きなインターネットへ向かうには、インターネットの歴史と物語、そして実際の利害関係者が誰なのかを、もっと綿密に見る必要がある
IRCとUsenet中心の使いにくい90年代のインターネットを指しているのか、無料ホスティングに違法コンテンツがあった90年代のアンダーグラウンドなインターネットを指しているのか分からない
フォーラム、IRC、Viagraスパム、goatseがあった90年代のインターネットが、今日のダークパターンや少数の巨大企業に支配された無菌化されたインターネットと、どう似ているのかよく見えない
モバイル利用のせいで コンピューター音痴 は減るどころかむしろ増えており、怪しいリンクをクリックしてブラウザツールバーをインストールし、その後だんだんダークパターンに感染していくようなものだ
親戚からコンピューターの問題で連絡が来ると、こうした状態をかなり頻繁に見る
“phonish” や “phonishness” のような表現を使うといつも低評価を受けるが、スマートフォンは生活を良くするより悪くし、人間がコンピューターに仕えるようにした感じがする
次のプラットフォームに期待している
迷惑メールフォルダ以外ではほとんど目にせず、それ以外はすべて選別されて「まともな」領域、あるいは特権的なインターネット居住区に近い形に調整されている
金はないが知識の面では裕福なようなもので、技術リテラシーのない層が広告やYouTubeのような有料サービスの 肉の盾 になる、コモンズの悲劇のような構造に見える
時間が経つほど、フロントエンドがスタックの中で最も難しい部分である可能性が高いことが明らかになってきた
人々は Bootstrap React アプリを適当に量産すれば完璧だと思っているが、すべてのブラウザ・デバイス・支援技術・言語で動作する複雑な UI を書くのは極めて難しい
HTML、CSS、関連する Web API に関する深い知識が必要で、優れたフロントエンドエンジニアはビッグテックでも非常にまれ
そこまで考える UX デザイナーはさらにまれで、そういう人材には100万ドルの価値がある
結局デザイナーに転向したが、どうせ尊重されないなら、少なくとも新技術のランニングマシンの上を走り続ける必要はないと思った
バックエンド開発も経験したし、それはそれで難しいが、お金のことを考えるならフロントエンドよりバックエンドを選ぶ
デザイン、バックエンド、フロントエンドをすべてやってみると、頭の中に評価と介入という2つの軸ができた
デザインは成果物が視覚的なので評価されやすいが、誰もが「もっとうまくやる方法」について意見を言い、簡単に口を挟んでくる
バックエンドは他のエンジニア以外からは干渉されないが、うまくできていても本来そう動くべきもののように見えるため、功績を認められにくい
フロントエンドはその中間で、見た目がよく正しく動けばある程度評価されるが、アプリが高速で反応性に優れていても、その功績の半分くらいはデザイナーに帰属することもある
同時に人々は他のアプリを基準に「こう動くべきだ」と言い、フロントエンド開発者はデザイナーが承認したものとバックエンドがサポートするものの間で、何とか動くようにしなければならない
コーディングはできるがデザイン感覚のない同僚たちと一日中争うことに疲れ、優れたフロントエンドエンジニアを形作る特性は、心理的コストの低い役割へ移るうえでも有利に働く
フロントエンド開発者は客観的な機械ではなく主観的な人間を相手にし、デザイナーやプロダクトマネージャーにも対応しなければならず、バックエンドエンジニアやインフラの制約も受ける
複数のデバイスやブラウザで動くようにし、他人が選んだフレームワークを使いながら、何も壊してはならない
すべてのフロントエンド開発者に敬意を表する
あらゆるものにパディングがあり、テキストにもパディング、テキストを囲むボックスにもパディング、そのボックスを含むテーブル行にはさらに大きなパディングがあった
その結果、一般的な 1080p 画面にはテーブル行が4つほどしか収まらず、各行に実際の情報はほとんどなかった
しかも何らかの理由で文字サイズをビューポート幅で定義していたため、古い 4:3 ディスプレイではほとんど使いものにならないほどだった
日・週・月単位で数十億件を処理し、データキャッシュとデータウェアハウス、リアルタイム通知、キューのワークロード、さまざまな API リクエスト、バックエンドシステム間の同期、複数のデータストア、マルチリージョン展開、冗長性、バックエンド障害対応まで必要なシステムを考えてみればよい
複雑な Web ソフトウェアでは、こうしたバックエンドの問題は一般的だ
そのバックエンドにつながるフロントエンドは通常、バックエンドの自動プロセスのせいで真夜中に問題が起きたり、ユーザー数やデータ規模を心配したりすることは少ない
フロントエンドの初期開発やブラウザの変化に伴う保守がどれほど難しくても、開発が終われば静的コードがはるかに複雑な下位システムとやり取りする形であり、その下位システムはデータやビジネス要件が変わるたびに継続的な注意を要求する
問題はモバイル優先かデスクトップかではなく、Web がユーザーの画面サイズや形状に合わせて流れるべき動的コンテンツだという事実を、いまだに理解していないデザイナーたちだ
Web は紙のような静的媒体ではなく、特定のサイズや形状に縛られるものでもないため、そのように扱ってはいけない
Web「デザイナー」がコンテンツを特定のサイズやピクセル解像度に無理やり合わせようとしてはならず、画面解像度や縦横比はあまりにも多様なので、コンテンツはそれに合わせて流れられる必要がある
フォントを大きくする必要がある視覚障害のあるユーザーにとっても、フォント拡大時にコンテンツが大きく崩れるとアクセシビリティは大きく損なわれる
こうしたページもモバイルとデスクトップのブラウザで動作し、どちらでも見栄えがよくなければならないが、それほど難しいわけではない
少し時間が余計にかかるだけで、メディアクエリと少しの JavaScript がそれを可能にしてくれる
同時に、この仕事を長くやってきた人にとっても混沌とした領域だ
最近はデザインのバックグラウンドを生かして設計段階にできるだけ関与し、実装してデプロイした後に「ユーザーの1%しか使わない微妙なビューポートで壊れる箇所を全部教えてほしい」という形で受け取り、CSS パッチやビューポート別のメディアクエリでレビュー段階や運用中に直している
すべての印刷本のテキスト行の長さがだいたい似ているのには理由があり、読みやすい幅は常に制限されるべきだ
幅が 300px のこともあれば 1920px のこともあり、マウスを使うことも、タッチだけを使うことも、その両方のことも、どちらでもないこともある
ハンバーガーメニューと象形文字アイコンだって
モバイルでなぜ使うのかは理解できる
コンテンツのためのスペースしかないなら、少数の機能だけを小さなアイコンにして、残りの操作をハンバーガーメニューに隠すのは筋が通る
でもスペースがあるなら、そう使うのはひどい
よく見ても手順が増えるし、悪くすればアイコンが何をするのか確かめようと試しているうちに事故を招く
Undo がまともに機能するならまだましだが、それすら壊れていてもいいと決めたように見える
昔の Apple HIG のように、デスクトップではユーザーがかくれんぼをしなくても「何ができるのか？」に答えられるよう、よく使う操作をメニューの外に出してラベル付きボタンに置くべき
Undo は後から付けるのが難しいので、最初から基盤として用意しておき、試行錯誤の代償を減らすべき
残念ながらモバイルデザインがあまりにも完全に支配してしまったため、ほとんどすべてがデスクトップで使われるアプリで、社内にデスクトップデザインを擁護する人がいても、UI デザイナーはハンバーガーと象形文字、壊れた Undo を選ぶ
しかもモーダルも激しく復活しているが、血圧のためにここでやめておく
moto e4 のような5年前の低価格スマホでも 1280x720 の画面で、アイコンにラベルを付けるピクセルは十分にある
象形文字アイコンは「私たちはユーザーが嫌いで、そのことを知らせたい」という設計に近い
ハンバーガーメニューも、選択肢の数を見ると廃止できる場合が多い
Gmail アプリもアイコンを横のバーに入れられるのにハンバーガーを使っていて、スペースが重要だと言うには、チャット・ビデオ・Spaces 用の下部バーはまた入れている
ユーザーがさらにスクロールできる選択肢があることに気づかないのではと少し心配だが、開くとコンテンツを覆うハンバーガーメニューよりは好み
すべての選択肢とその単語が見えるから
デスクトップではこうした処理は必要ない
ただ、デザイナーがそれを好む理由は、複数言語で一貫したデザインを保ちやすいからだと思う
たとえばドイツ語ローカライズは収めるのが難しいことがある
ここに隠された文脈依存オプションも加えたい
使えないときに無効化、つまりグレーアウトされたオプションは、少なくとも条件が合えば何かできるという可能性を示すので良い
ところが現代のデザインはそうしたオプションを隠してしまい、表示させる魔法の条件を知らなければ永遠に見られない
Ubiquiti の Unifi が例
スイッチポートを管理するページには「Select All」オプションがなく、まずポートを1つ以上選択して初めてそのオプションが魔法のように現れる
隠されているだけでなく、文脈も間違っている
無効なチェックボックスとして存在していれば、どのポートも選択していないときに「Select All」チェックボックスが無効なのは明らかに馬鹿げていると、誰もがすぐ気づいただろう
画面に多くのものがありすぎると簡単に怖気づき、フォーカスグループを支配するのがまさに彼ら
だからデザイナーたちは、このひとつのひどいルールに縛られてしまったように見える
この研究は実用面では筋が通らない
これらのページは、最小のスペースで最大の情報を伝えるためではなく、製品を売るために設計されたもの
コンテンツの分散による悪影響があると主張するなら、そのページが設計された目的を基準に測定すべき
ここでは明示的に e コマース・製品ページを研究しているのだから、関連する指標は、どのページがより高い製品価値を感じさせたか、コンバージョン率が高かったか、NPS が高かったか、ブランド好感度をより良くしたかである
ポータブルスピーカーは仕様で売るのではなく、ビーチで使う憧れのイメージで売るもの
製品詳細のアコーディオンを開いた状態にして「このページが伝えた提案をどれだけよく理解したと感じますか？」と聞けば、当然アンケートの点数は高くなる
より密度の高いページのほうがコンバージョンに優れていたら、むしろ驚くべきこと
これは F1 レーシングカーの硬いシートが悪いという研究を設計し、フォームをたっぷり貼り付けたうえでどちらが快適かをテストして、本来の指標はラップタイムだけなのに、快適性スコアが高いからそちらが優れていると宣言するようなもの
この記事が批判しているデザイン上の選択は、モバイルファーストデザインの結果ではない
実際、レスポンシブデザインが普及する前の2000年代後半の Web サイトもそういう見た目だった
たとえば Apple: https://www.versionmuseum.com/history-of/apple-website
実質的にはマーケティングチラシや看板の情報密度を比較して、すべてを伝えられていないと言っているが、それこそが目的
広告は仕様表ではなく、見る人に製品への欲求を起こさせるためのもの
しかし私にとっては、むしろ低品質なでたらめの強いシグナルになり得る
多くの Web サイトは、ウィンドウサイズを変えると UI を完全に変えてしまう
ブラウザをモニターの半分だけ占めるようにして、横に別のものを置きたいときがあるが、現代の Web サイトではウィンドウサイズを小さくすると UI が使い物にならなくなり、しばしば失敗する
うまくやれば素晴らしいが、多くの Web サイトが実際には2つのサイズカテゴリしかテストしていないかのように、過度に攻撃的に振る舞うというのも正しい
ビューを小さくすると機能やコンテンツにもうアクセスできなくなる、という意味なのか気になる
役に立つコンテンツを中央の細いカラムに入れる Web サイトが嫌い
さらに悪いのは、以前はまともだった Web サイトまで次第に壊れていくこと
たいてい新しい管理者が来て、「モバイルファースト」のビジョンで製品を「再構想」すると言い出すとそうなる
最近の Patreon が良い例
そして場合によっては、まともな Web サイトが完全になくなり、Venmo、Amazon Alexa、Chamberlain のような crapp に置き換えられる
本当に厄介なのは、hoverに相当するまともなタッチでの代替手段がない点だと思う。
モバイルファーストへ移行する中で捨てるには、あまりにも有用なUX要素。
それ以外は「そこまで難しくない」側に近い。
解くべき問題の中で、複数の画面サイズでそれらしく見せることは、時間と複雑さの面ではかなり下のほうにある。
少なくともモバイル版Firefoxで画像の代替テキストを見るときはそう使っている。
実際のhover検出は可能だろうが、スタイラスを使わない限りUXはいまいちだと思う。
Webデザイナーの立場からは、少し同意できない。
記事で挙げられている例は、1画面あたりのコンテンツがシンプルなほうがうまく機能する。
視覚的に把握しやすく、圧縮版には個人的に嫌いな多段レイアウトが多い。
高いコンテンツ密度はデスクトップアプリケーションには合うが、基本的にパンフレット型Webサイトである場所には合わない。
単なる誰かの感想ではない点はよい。
マーケティングページが数十年にわたる進化とテストの末に、ユーザーが欲しいと言うものではなく実際に欲しているものに到達していないとは考えにくい。
インターネットネイティブにとってスクロールは非常に自然な行動。
大きな画面を活用して視覚的に比較することにも有用性はあるが、記事の例はよくない。
「同じ情報を2x2グリッドに配置して、複数のサービスを同時に比較できるようにした」としているが、何を比較するのか分からない。
互いに異なるサービスだからだ。
製品仕様の例は気に入っているが、それはより多くの情報を見るためにより多くのクリックを求める、客観的なユーザビリティ問題に近い。
スクリーンショットが「縮小」されているため、多段構成が豊かで視覚的により魅力的に見える点を見るべき。
横方向のスペースを活用することには全面的に賛成だが、私たちが行動喚起ボタンについて学んだことは、単一要素のデザインにつながる。
パンフレットサイトやECサイトよりも、生産性サイトやツールのインターフェースにおけるモバイルファーストデザインのほうがいら立つ。
こういうツールに普通、誰が携帯電話でアクセスするのか。
過去の雇用主や居住地の名前・住所をモバイルキーボードで入力するのも苦痛だったが、日付入力はさらにひどかった。
日付ピッカーが現在の月と年から始まり、1か月ずつしかスクロールできなかったため、生年月日を入力するには約550回タップする必要があった。
高齢労働者という保護対象の階層に不均衡な影響を与えるのでEEOCに通報したい気持ちもあったが、新しい雇用主の人事に自分を紹介するよい方法ではなかった。
実際には小さな画面表示のようになり、これはWCAG要件でもある。