あなたが説明する状況はかなり一般的です:ユーザーが一度に詳細に見ることができるよりも多くのデータにアクセスできるようにする方法。
質問に答えるにはいくつかの方法があり、正解は完全に主観的です。それは、ユーザーが連絡先を何を見ようとしているのか、または何をしようとしているのかによって異なります。本当に満足のいく解決策を得る前に、ユーザーが連絡先を何に使用するのかを知る必要があります。
推測するだけで(しかし、あなたは私よりもよく知っているでしょう!)、彼らがしていることは2つあると思います。
- ルックアップ:特定の連絡先を探していて、彼らはすでに自分の名前/ハンドルを知っています。
- 探索:特定の連絡先を探していますが、名前/ハンドルを完全に思い出せません。または、彼らはただ閲覧しているだけです。
すべてのソリューションに対してフィルタリングを行う場合、ルックアップの目標はほとんど問題になりません。探索の目標は、次の目的で設計することです。
- ランダムサブセット:基本的に参照するサブセットが残っているため、参照するのに最適な方法ではありません。新しいものを表示するには、明示的にフィルタリングする必要があります。探しているものが正確にわからない場合は、フィルタリングが困難です。
- 無限スクロール:最近人気のあるソリューションのようです。特に、1000以上の連絡先を「無限に」スクロールしている場合は、面倒だと思います。おそらく、Exploreの目標には適していません。
- ページング:これも面倒ですが、ページングがアルファベット順の並べ替えに関連付けられている場合は、これでうまくいく可能性があります。
- しきい値の制限:それで...単にフィルタリングに依存していますか?これは、ユーザーが1つのフィルターを適用しても、しきい値に達していないb / cが何も表示されない場合には、悪い場合があります(Johnsonという名前の人がたくさんいる可能性があります。これがあなたの名前です。検索)。また、何を探しているのかわからないときは、閲覧できることが重要だと思います。
私があなたの立場にあったら、連絡先のクラスタリングを紹介したいと思います。1000以上の連絡先がパフォーマンスの問題の多くであるとは思えないので(100万以上の話をしているとは言えません!)、10000以上は実際にはユーザーの制約です。つまり、一度に1000以上の連絡先を表示することはできません。
おそらくラストネームまたはラストネームとファーストネームでクラスタリングを導入することをお勧めします。次に、1つのクラスターにドリルダウンする方法をユーザーに提示しますが、他のすべての連絡先を折りたたんで、すぐに表示されないようにします。アコーディオン/ロロデックスパラダイムの連なりの何か。これにより、ユーザーは「すべての連絡先」を操作しているように見せることができます。おそらく、クラスターごとに最小数を導入して、クラスターが十分に小さい場合にわざわざ表示しないようにします(つまり、2、3、または5の連絡先のクラスターを表示する理由-連絡先を表示するだけです)。次にフィルターを適用すると、クラスターが溶けてしまいます。