Week 4 Session: Ninety-Nine Percent
Week 4. Determinate progress, where the system tells you something and the something is false.
8 March 2027
Everyone has watched a bar sit at ninety-nine per cent. This week is about why that happens and what it tells you about the whole component.
Harrison, Amento, Kuznetsov and Bell rethought the bar in 2007, and the follow up in 2010 went further by manipulating perceived duration with the animation alone. In the later study the strongest augmentation, backwards moving decelerating ribbing, cut perceived duration by 11% with the real duration held constant.
Sit with that. The same wait, the same process, a different number in the head of the person waiting. Nothing was made faster. Something was made shorter.
In the workshop#
You take a real progress bar and change one property of it, whether that is the easing, the direction, the rate of the animation, or where it pauses. Then you run it past someone who has not seen the original and ask them to guess the duration. Keep the real duration fixed. Write down the guess.
But wait, there’s more#
Windows has shown an estimated time remaining on file copies for decades, and the estimate is known for collapsing from twenty minutes to four seconds in a single step. The interesting part is that nobody has removed it. A number known to be wrong is apparently still better than no number, and this is the week where you have to decide whether you agree.
The spec
What you bring to the session. Written so a reader can tell whether it has been met without asking you.
- you can explain why a progress bar estimate is usually wrong
- you can name two animation properties that change perceived duration without changing real duration
- you can say who benefits from a bar that pauses near the end