I recently had to implement an HTML table in a web application that would display and allow editing rows of data. However, the number of rows you’ll get in the data is very uncertain. To avoid a ridiculously long web page, the table should not grow beyond a certain height and should instead show a scrollbar when there are more rows than can fit.
One thing that I find can be quite annoying is if a table is just a little bit too short for its contents, so that you end up with a single row off the bottom, for example an eleventh row in a table that is only ten rows high.
As a little experiment, I decided to make use of the table’s flexible height to prevent this situation: we would display an extra row if the number of rows is only one more than our ideal maximum height. So if your ideal limit is ten rows, it would stretch to accommodate up to eleven rows. For twelve rows or more, only ten would be shown at a time. This way it always feels like the scrollbar is justified, because it’s never just to get to that one extra row. I think it’s unlikely that users would notice this behaviour.
However, I am not sure whether this is a valid design decision. One could argue that since your true maximum is eleven rows, not ten, you are making life a little bit harder than necessary for your users whenever they have to scroll. Also, I have no empirical information about whether and how much people actually get frustrated in cases where only one row is out of bounds. It almost becomes an ethical question: is it worth a white lie?
I think the approach may be valid in some cases, but it depends on several factors:
- What is your maximum height? If your table can grow fairly high before showing its scrollbar, the cost of sacrificing a single row for this trick is less. However, if it can only be a few rows high, you are depriving users of a significant proportion of display area.
- How likely will you exceed that maximum? If scrolling will be necessary in the majority of cases, it may be wiser to grant people the extra height to maximise how much they can see at a time.
- How linear is the task? If people only need to read down the list of rows once, having to scroll a single row into view at the end is no big deal. But it might get frustrating when they have to repeatedly jump back and forth to compare or edit rows.
In my case, the table is fairly likely to contain tens or hundreds of data rows, and I only have space to show about a dozen at a time. So scrolling will often be necessary, and users will probably value every row they can fit on the screen. I’m not sure yet how likely people are to scroll back and forth, but the other two factors are probably enough to outweigh any gain in happiness that might result from not having a single row out of bounds.