Display options

Hoping for some feedback on these two list displays for empty states. The list is categorised by Month, Year and based on data, we can expect to have about 40 reservations over a 6 month period.

Option 1 shows the month (December 2017) with an empty state message while Option 2 will not display that month at all.

Personally, I am leaning towards option 2 as I think it is neater since you wouldn't have to define how many months into the future to show, for example, would you have to show all the way up to December 2018 with empty states.

I would like to see if anyone had any benefits of the Option 1 approach over Option 2?

  • who are the users of this application? what is the other context of use info? What would they do with these reservations; are they checking them against other scheduled events, or coordinating with other systems?
    – Mike M
    Commented Oct 3, 2017 at 2:20
  • It is a read-only list that is used to reference hotel reservations. Each reservation can be edited via an action from this page which takes them to a detailed view of that reservation. The user is the person making the reservations for multiple people in a small business. This page is used to refer to what is upcoming and make changes if needed.
    – Jaime S
    Commented Oct 3, 2017 at 2:22
  • 1
    At first glance (as innocent user) I greatly prefer first option.
    – Arvo
    Commented Oct 3, 2017 at 12:17
  • 2
    This is only easily solved if you TEST. TEST, TEST, TEST and find out what your users like. I prefer option 1 because in option 1 I can modify it to create a hyperlinked url that passes a parameter and states the following: "No reservations for December 2017, click here to create one..." and here I would take you to a create page and auto select the month of december.
    – JonH
    Commented Oct 3, 2017 at 12:27
  • +1 @JonH for a useful empty state: 'Create a reservation'.
    – Mike M
    Commented Oct 3, 2017 at 13:44

3 Answers 3


Option 1 does present more data, but is bound by a more explicit rule.

If someone looking out over a six month period for reservations, and is coordinating or receiving this data from other systems, option 1 is helpful, because it is explicit about the absence of data in a particular time period.

You probably have other reporting that handles this, but showing the lack of reservations can reinforce how the business is doing at a glance (i.e. 'wow, no December reservations? What's going on?'), but I don't know if that's relevant to your users.

Showing 6 months regardless of data also gives implicit order to the application (the chronology of months as we are accustomed to), and exposes a rule to the user (You are always seeing the next 6 calendar months), whereas option 2 might leave one to believe that either data hasn't loaded, vs. explicitly calling out the absence of reservations.

Test both options.

Either way, you can test with your users to see which option gives them more confidence with using the application.


Use Option 1 (explicitly display empty months) to reduce cognitive load on the user.

Consider the case where the user wants to know:

What month is Reservation 3 in?

But they have scrolled too far and have to scroll back up.

With Option 1 on the left, the user has found Reservation 3, and knows that it is in November 2017. With Option 2 on the right, the user must continue scrolling up to reveal the month.

This picture also illustrates that a question such as Are there any reservations in December 2017? is more difficult to answer with option 2.

  • This is a bad example. Consider the case where the user wants to know which month reservation 8 or 9 is in. Left version you have to scroll more, right version it would already fit on screen. And which way do people scroll the most, up or down? Commented Oct 3, 2017 at 20:49
  • @PixelSnader Consider the viewport filled with reservations 2 through 9 followed by February 2018. You still cannot say with certainty that reservation 9 is in January 2018. Commented Oct 4, 2017 at 2:38
  • @Harisson-Paine Not if your screen starts halfway down the page, no. But websites have a tendency to load at the top of the page and then users scroll down. You scroll past the section title for January to reach the reservation. Don't sacrifice common benefits for sporadic benefits. If you really think it's an issue, use sticky headers ( codepen.io/chrissp26/pen/gBrdo ) so the prior month is always visible. Commented Oct 4, 2017 at 7:27

This depends on the amount and type of content you have.

If you are expecting a lot of items (i.e. reservations) in your list, you should show the empty spaces. If you have few items, you should only show the filled spaces.

The more items you have, the less you waste.

If you have many items, you'll naturally tend to have less empty months. This effect works two ways, even. For example if you have 0,1,2,3 reservations per quarter you have a total of 30 rows with 3 empty, that's 10% wasted. But if you have 0,0,1,2 reservations you have 21 rows with 6 empty; 29% waste. Even though your content shrank by only half, your waste almost increased threefold.

Even if you don't get more empty months (0,1,1,1) you will still have 21 rows with 3 empty and that's a waste of 14%; higher than the initial 10.

Knowing, predicting, searching, and scrolling.

Knowing where something is is the fastest. Predicting is slower because you have to go where you think it might be, then have to check, and readjust. Searching is the slowest, because you have to check each item before you move to the next.

Scrolling with a mouse in any of those 3 is slower than using your eyes to skimming in one of the 3 ways because your eyes need time to re-ground themselves every time the screen moves.

Balancing two scales.

The biggest tradeoff you have to make is about reading versus scrolling.

If you have only a few items and if several fit on screen, people will skim/read the labels until they see the one they need. If something is off-screen they need to scroll to it.

Because reservation get added and removed constantly so you can't know nor predict where they will be within the month. If we have Andrew, Bart and Charlie, and Andrew cancels, the other two will change their position within the month. Same if we have reservations on 1st, 12th and 23rd, and 1st cancels.

It's worth dropping some empty months to reduce how often you scroll. You incur a slight slowdown in the single-screen navigation by going from predicting/counting the position of a month to having to skim each month label, but it outweighs scrolling.

But if you have a lot of items, you are going to have to scroll. We can't know where a month starts because the size of them fluctuates depending on amount of reservations, but we can predict where they will be because the months themselves follow a pattern. So users can count while scrolling in one motion, and predict 'February, March, April' rather than having to read the labels. As predicting is faster than searching, we want to let users predict where they are, which means leaving the labels in.

Another way to look at it is minimizing the amount of action changes. If you can keep them reading labels quickly without scrolling, that's perfect. If you can let them scroll without having to read, that's also good. But you don't want them to scroll read scroll read etcetera.

How important is date-searching?

A lot of factors go in here, so I won't go in detail but let's compare your content vs a generic blog. Type of content; reservations are highly time sensitive, blog posts aren't. Recognizability; reservations all have name/date/room, blog titles are designed to stand out from eachother. Need for specific information; if I want to read up on some CSS techniques there are many interesting related articles. If James Brown checks in, I have zero use for reservations for James Dean or Charlie Brown.

So in short, your user values date-searching a lot.

This specific case

You mention roughly 45 reservations in 6 months. Let's say that's 0,3,6,9,12,15 reservations per month. You end up with 51 rows of which 3 are empty - about 6.5%. So you could save 6% in time not reading the headers.

Based on your screenshots your headers and items are about 50 pixels high, so the whole page would be 2550 pixels. Realistically you have something like 600 pixels per scroll motion (1080p screen with browser tabs, task bar, app menu/header, some anchoring text), and then you skim and reground. That's 4 scroll actions for the whole list.

If you let people predict where they are going to end up (by making each month easily countable, using a good header and using different background colors per month) you can take this down to 1.5 scrolling action while counting blocks. 1 scroll where you predict you need to be, then skimming the page, and sometimes you're on the right bit, sometimes you need to scroll up or down once more.

So yeah, I'd definitely add all the months in your case.

But beyond that, think of other ways to optimize the navigation. How about a dropdown or list with the months at the top of the page? Then they only need to skim 6 lines of text and click one and they'll guaranteed end up at the right month. You could even combine it with a sticky header (https://codepen.io/chrissp26/pen/gBrdo) where the header is a list initially, and becomes a dropdown on scrolling.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.