リストのカテゴリ：空の状態または非表示？
空の状態のこれら2つのリスト表示に関するフィードバックを期待しています。リストは月、年で分類されており、データに基づいて、6か月間で約40の予約があると予想できます。
オプション1では月（2017年12月）に空の状態メッセージが表示されますが、オプション2ではその月がまったく表示されません。
個人的には、オプション2に傾いています。これは、将来の何ヶ月を表示するかを定義する必要がないためです。たとえば、空の状態で2018年12月までずっと表示する必要があります。
オプション1のアプローチの方がオプション2よりもメリットがあるかどうかを確認したいのですが。
オプション1はより多くのデータを提供しますが、より明示的なルールに拘束されます。
予約のために6か月間外を見ていて、他のシステムからこのデータを調整または受信している場合、オプション1が役立ちます。これは、特定の時間におけるデータの不在について明示的であるためですピリオド。
おそらくこれを処理する他のレポートがありますが、予約の欠如を示すことで、ビジネスの様子を一目で確認できます（つまり、「12月の予約がありません。どうなっているのですか？」）。しかし、それが関連しているかどうかはわかりません。ユーザーに。
データに関係なく6か月を表示すると、アプリケーションに暗黙の順序が付けられ（慣れている月の年代順）、ユーザーにルールが公開されます（常に次の6か月が表示されます）。一方、オプション2は1つを残す場合があります。どちらのデータもロードされていない、または予約がないことを明示的に呼び出すことを信じる。
両方のオプションをテストします。
どちらの方法でも、ユーザーとテストして、アプリケーションを使用する上でどのオプションがより信頼できるかを確認できます。
オプション1（明示的に空の月を表示）を使用して、ユーザーの認知負荷を減らします。
ユーザーが知りたい場合を考えてみましょう：
予約3は何月ですか？
しかし、彼らはあまりにも遠くにスクロールし、上にスクロールしなければなりません。
左側のオプション1で、ユーザーはReservation 3を見つけ、それがNovember 2017にあることを知っています。右側のオプション2では、ユーザーは上にスクロールして月を表示する必要があります。
この写真は、などの質問も示していますDecember 2017に予約はありますか？ は、オプション2で答えるのがより困難です。
これは、コンテンツの量と種類によって異なります。
リストに多数のアイテム（予約など）が必要な場合は、空のスペースを表示する必要があります。アイテムが少ない場合は、塗りつぶされたスペースのみを表示してください。
アイテムが多いほど、無駄が少なくなります。
アイテムが多いと、当然、空の月が少なくなる傾向があります。この効果は2つの方法で機能します。たとえば、四半期ごとに0、1、2、3の予約がある場合、合計30行で3つの空があり、それは10％の無駄になります。しかし、0、0、1、2の予約がある場合、21の行に6つの空があります。 29％廃棄物。コンテンツが半分だけ減少したにもかかわらず、無駄がほぼ3倍に増加しました。
空の月（0、1、1、1）が増えなくても、3つの空の行が21行あるため、14％の無駄になります。最初の10より高い。
知る、予測する、検索する、スクロールする。
どこにあるかを知ることが最速です。予想通りに移動し、確認して再調整する必要があるため、予測は遅くなります。次の項目に進む前に各項目を確認する必要があるため、検索が最も遅くなります。
これらの3つのいずれかでマウスを使ってスクロールすると、3つの方法のいずれかで目を使ってスキミングするよりも遅くなります。これは、画面が動くたびに目を再接地する時間が必要になるためです。
2つのスケールのバランスをとります。
あなたがしなければならない最大のトレードオフは、読み取りとスクロールについてです。
数個のアイテムしかなく、いくつかが画面に収まる場合、人々は必要なものを見るまでラベルを読み飛ばします。画面に表示されていないものがある場合は、スクロールして表示する必要があります。
予約は常に追加および削除されるため、knowもpredictそれらがその月のどこにあるか。 Andrew、Bart、Charlieがいて、Andrewがキャンセルした場合、他の2人は月内にポジションを変更します。 1日、12日、23日に予約があり、1日キャンセルの場合も同様です。
スクロールする頻度を減らすために、何カ月も空にしておく価値があります。月の位置を予測/カウントすることから、各月のラベルを読み飛ばす必要があるまで、シングルスクリーンナビゲーションで若干の速度低下が発生しますが、スクロールよりもその方が重要です。
ただし、アイテムが多い場合は、スクロールする必要があります。予約の量によってサイズが変動するため、月が始まる場所をknowすることはできませんが、predict月自体がパターンに従うため、それらはどこにあるか。そのため、ユーザーは1つの動きでスクロールしながらカウントし、ラベルを読む必要がなく、「2月、3月、4月」を予測できます。予測は検索よりも速いので、ユーザーが現在位置を予測できるようにしたいと考えています。つまり、ラベルをそのまま残しておきます。
これを見る別の方法は、アクションの変更量を最小限に抑えることです。スクロールせずにラベルをすばやく読むことができれば、それは完璧です。読まなくてもスクロールさせることができるなら、それも良いことです。しかし、あなたは彼らがスクロールして読んだり、スクロールして読んだりしたくありません。
日付検索はどのくらい重要ですか？
ここには多くの要素が含まれているので、詳細には触れませんが、コンテンツと一般的なブログを比較してみましょう。コンテンツのタイプ。予約は時間に非常に敏感ですが、ブログ投稿はそうではありません。認識性;予約にはすべて名前/日付/部屋があり、ブログのタイトルは互いに際立つように設計されています。特定の情報の必要性。いくつかのCSSテクニックについて読みたい場合、興味深い関連記事がたくさんあります。ジェームスブラウンがチェックインした場合、ジェームスディーンまたはチャーリーブラウンの予約の使用はありません。
つまり、ユーザーは日付検索を重視しています。
この特定のケース
6か月で約45件の予約について言及しています。 1か月あたりの予約数が0、3、6、9、12、15だとします。あなたは51行で終わり、そのうち3行は空です-約6.5％。したがって、ヘッダーを読み取らない時間を6％節約できます。
スクリーンショットに基づくと、ヘッダーとアイテムの高さは約50ピクセルなので、ページ全体は2550ピクセルになります。現実には、スクロールモーションごとに600ピクセル（ブラウザータブ、タスクバー、アプリメニュー/ヘッダー、アンカーテキストを含む1080p画面）のようなものがあり、それからスキムして再グラウンドします。これは、リスト全体の4つのスクロールアクションです。
人々が最終的にどこに行くのかを予測させる場合（各月を簡単に数えることができるようにし、適切なヘッダーを使用し、月ごとに異なる背景色を使用することで）、ブロックを数えている間、これを1.5スクロールアクションまで下げることができます。 1スクロールする必要があると予測し、ページを読み飛ばします。適切な位置にいる場合もあれば、もう一度上下にスクロールする必要がある場合もあります。
だから、ええ、私は間違いなくあなたのケースですべての月を追加します。
しかし、それ以外に、ナビゲーションを最適化する他の方法を考えてください。ページの上部に月があるドロップダウンまたはリストはどうですか？次に、6行のテキストを読み飛ばして1行クリックするだけで、最終的に正しい月に到達することが保証されます。スティッキーヘッダー（ https://codepen.io/chrissp26/pen/gBrdo ）と組み合わせることもできます。ヘッダーは最初はリストであり、スクロールするとドロップダウンになります。