ページネーション：ページごとに表示するアイテムの数をユーザーに選択させますか？
ユーザーが1ページに表示するアイテムの数を選択できるようにするのは理にかなっていますか？または、特定の状況で意味がありますか？いつですか？いつそうしないのですか？
これは、いくつかの大きなウェブサイトがそれを処理する方法です：
- Google：以前は高度な検索で使用されていましたが、Googleインスタントでは機能しません
- Bing：設定で設定できます
- アマゾン：いいえ
- Ebay：はい、このように見えます：
私の印象は、アイテムの数がロード時間に実際に影響を与えていた昔からの名残であるということです（そのため、一般的にはそれを低くし、より多くの帯域幅を持つユーザーがより高く設定できるようにします）。しかし、私が話をした多くの人々は、機能を維持したいと考えています。何かご意見は？長所と短所？
私は、ページネーションが良いデフォルト値がすべての違いを生むこれらのケースの別の1つであり、AmazonとGoogleが示すように、ユーザーからの選択の負担を完全に保つことさえ可能であると思います。
私の意見では、ページあたりの項目数の選択可能な値は、その1つのページに複数の競合する要件が含まれている場合にのみ意味があります。 大量のデータの概要をユーザーにすばやく提供しますおよびを圧倒せずに単一のデータ項目の詳細の多くを表示しますユーザー。
この場合、根本的な問題は、このページの目的が明確に定義されていないことです。
私の個人的な選択は、ページごとのアイテムの概念を排除し、ページの概念を取り除くことです。
ユーザーに表示されるページの現在の部分に適合するすべてのアイテムを表示するだけです。次に、ユーザーがスクロールダウンを要求したときに、残りの結果を自動ページネーション（自動ロード）します（Facebookが古い投稿をロードするように）。
データグリッドのページネーションとユーザー設定可能な「ページごとのアイテム」値を持つアプリケーションを書き直しています。これで、新しいアプリケーションには、スクロールバーにリンクされた「無限」の自動改ページのみが表示されます。これまでのフィードバックは非常に肯定的です。
よろしく。
ユーザー定義のページ付けは、少なくとも表形式のデータのコンテキストでは、私には正しいようです。
たとえば、Googleアナリティクスのテーブルについて考えてみましょう。
表示する行の数を設定することが許可されていなかった場合、多くの人がデータのテーブルの使い勝手が悪くなると思います。
ページごとに表示されるアイテムの最適な量を決定する原動力はパフォーマンスです。このパラメーターを構成可能にすることは、エンドユーザーにとって本当に役立ちます。たとえば、ユーザーがVPNやワイヤレスを介してアプリケーションにアクセスしている場合、スループットが低下する可能性があるため、1ページあたり100アイテムではなく20アイテムをロードします。ローカルLAN上。
このパターンは「昔」の名残かもしれませんが、それでも環境要因に応じて非常に多くの用途があります。最善の策;ユーザーの大多数を満足させる適切なデフォルトを見つけ、必要に応じてユーザーに選択させます。
また、データがフロントエンドに到達するのに時間がかかりすぎると、適切に実装されていない製品や遅い接続では、ページの読み込み時にタイムアウトになる可能性があることに注意してください。ページごとに表示される項目を選択すると、これを軽減できます。