The scrollbar’s position must map honestly to the real amount of data

What it is

A scrollbar’s thumb length and position are the external scale for “how long is this, and where am I.” A virtualised list inflates the scroll range with estimated heights. Once those estimates skew, the thumb lies: it looks like the middle when you are still in the first 10%; it looks near the end when half the data remain. Scrollbar-to-data mapping requires the scale to follow real row count and real row height, not the few rows the current window happened to measure.

Why it happens

Thumb length is viewport over total; thumb position is distance travelled over total. The denominator is total height. Virtualisation often uses “mean height of rows seen so far × row count” as that total. If the mean comes from short early screens, total is underestimated, the thumb runs long and late, and people think there is little content and that they are already deep. Taller rows later correct the total during the scroll, the thumb jumps, and place is torn on the spot. The reverse holds: tall rows first and short rows later make the list feel endless. Mapping should use real heights where it can; failing that, a stable estimate, and it should avoid rewriting the denominator mid-scroll. Infinite loading grows the denominator as you go and keeps shortening the thumb — a different “there is no end” lie, separate from windowed rendering.

Studying it

Build three virtualised lists — short then tall, tall then short, uniform height — and have people jump the thumb to “about half” and “near the end.” Record the actual row-index proportion and whether the thumb jumps during the move. Independent variables: height strategy (fixed / mean estimate / exact). Dependent variables: place error, jump count, misjudged remainder. Estimate strategies should err most when height variance is high.

Where it stops holding

With perfectly fixed row height the mapping can be exact and this barely fires. On touch, where the system hides the bar, the scale is already weak and a wrong mapping is harder to see, but tapping the track still lands on the wrong data place. If assistive values expose pixels rather than row numbers, a screen reader hears a meaningless height; report “item n of N” instead.

Applying it

• With fixed row height, total height is count × height; do not use a sampled mean.
• With variable height, use measured values for rows already seen and a conservative estimate for the rest; do not rewrite the height of already-scrolled stretches during one flick.
• When the thumb jumps, align the window by row index, not only by an estimated pixel.
• How to check: drag the thumb to the visual midpoint and see whether the row index is half the collection. An order-of-magnitude miss means the mapping is lying.

Related

• Within the group: E4.18.1 Virtualized lists render only what is on screen so long lists stay usable · E4.18.2 In-page find can fail under virtualisation · E4.18.4 Placeholder flicker during a fast flick hurts readability
• Adjacent: E5.07 Infinite scroll · E4.08 Split views and master-detail
• Search terms: scrollbar · scroll height estimate · virtual list offset