iPhoneとモバイルWeb：ページネーションvs.ロードの追加vs.スクロール

Question

現在、iPhoneアプリと、ウェブから読み込まれた検索結果を表示するモバイルウェブサイトに取り組んでいます。いくつかの並べ替えオプションが利用可能で、すべての結果には写真があります。潜在的に何百もの結果があります。

リストをナビゲートするための4つのパターンが表示されます。

すべてをロードし、ページネーションの種類を使用せず、下にスクロールします。 Thoughts：ロードする必要のあるデータが多すぎます（速度とユーザーのデータプランに悪い）。
特定の数の結果をロードし、20と言って、従来のページネーション（「次のページ」と「前のページ」ボタン）を使用します。 考え：欠点：ユーザーが最初のページに戻りたい場合は、上にスクロールするのではなく、クリックし直す必要があります。長所：すべてのページに実際のURL（SEO関連）があります。モバイルWebソリューションの推奨バージョン。
20個の要素を読み込み、リストの最後に「さらに20個を読み込む」ボタンを配置します（AppleによってApp Storeで使用されます）。考え：アプリにとってはかなりエレガントですが、結果を自動的にロードできるのになぜそれを使用するのですか？（4を参照）
開始時に20要素をロードし、ユーザーがリストの最後に到達したときに次の20要素をロードします。 Thoughts：アプリの私のお気に入りのパターンは、SEOが適切に処理されていれば、モバイルWebサイトにも使用できます。

質問：他に考慮すべきことはありますか？私の考えに同意しますか？なぜ誰もがパターン4を使用しないのですか？（アップルさえも）

関連する質問：

Phil Cohen · Accepted Answer

アプローチ＃4は、iPhoneで特に便利です。iPhoneで、指を数回スワイプするだけでリスト全体をスクロールできます。結果のページを手動でクリックする必要があると、そのフローが壊れます。私はこのようにします— Appleは常に完璧であるとは限りません。;）

SEOの最適化に関しては、バックエンドで個別のURLを維持できます。ビューがスクロールされると、それらを自動的に要求するだけです（たとえば、/ results/1、/ results/2など）。

編集： この素晴らしい古い回答は、問題をより深くカバーしているようです。

Rahul · Answer

それはバランスの問題です。いくつかの考え：

ケース＃1では、後でスムーズなエクスペリエンスを実現する代わりに、前もって遅延ロードを我慢します。アプリのユースケースによっては、それが優先される場合があります（Twitterを読んで、20番目のツイートに到達するたびにロードを待つ必要があることを想像してください）。
ケース2の場合、データが変更される可能性があるため、すべてのページに実際のSEO URLがあるとは限りません。ページ付けされた検索のほとんどの設計規則では、ページ付けリンクをたどらないようにGoogleに指示しています。これは、個々の検索結果ページのインデックス作成は検索者にとってあまり価値がなく、データが変わる可能性があるためです。
ケース＃3の場合、これは前もって束をロードするGoogle画像などの状況でうまく機能しますが、多分ユーザーケースの80％が最初のページに満足しているとユースケースで規定されているため、あまり多くロードしたくありません。ただし、ユーザーが必要なときにさらにリクエストできるようにしたいので、「さらに読み込む」ボタンを用意します。
そして＃4に関する限り、これが頻繁に表示されない理由は、ほとんどのアプリが＃1で問題ないためです。 Xの結果ごとに新しいアイテムをロードすると、クイックスタートシナリオを優先する場合は優先されないストップスタートエクスペリエンスが作成されます（そうでない場合は、この種類のリストは適切なコントロールではありません））。

このような決定に直面したとき、私は一歩下がってデザインを再考する傾向があります。それが不可能な場合もあります。たとえば、上記のように、Twitterは本質的にリストであり、最初からすべてのツイートをロードすることはできないため、ユーザーはあちこちに負荷をかけなければなりません。。しかし、幸いなことにツイートは非常に軽いため、切り取る前にかなりの数のツイートを読み込むことができます。他のデータ、たとえば、それぞれの結果の写真がある旅行サイトでの検索結果については、別のデザインアプローチを検討するかもしれません。

James Crook · Answer

4の主な問題は、それらすべてが読み込まれたという幻想が崩れるときです。高速フリックで、突然、まだロードされていない画像のプレースホルダーを表示する必要があります。

なぜ誰もがパターン4を使用しないのですか？それは、同じサイズのプレースホルダー画像のギャラリーを先取りするユーザーにとってはナビゲートできないためだと思います。どこにいるかはわかりません。一度に20を明示的にロードしても問題はありません。それはあなたのユーザーを十分に遅くします。開発者はパターン4を使用しません。これは、プレースホルダーを使用したエントリを、画像がなくても見栄えよくしたり、ナビゲートしたりするための作業があり、それをうまく行うのが難しいためです。

4の問題を解決するための提案

画像の主要な色の近似値の近似値をほぼ瞬時に読み込む方法を見つけます。はるかに少ないデータ。次に、アプリで、画像とは何かを示すテキストでこれらの色を使用してカスタムプレースホルダーを構築できます。これはナビゲート可能であり、イメージが到着したときもそのままです。彼らがそうするとき、視覚的な外観のジャンプの不連続のより少ないでしょう。