Fake progress spends later trust

What it is

Fake progress borrows the look of a determinate bar to tell a ratio the system does not have: crawling forward on a clock, jumping to eighty percent before work starts, sitting at ninety-nine percent until a last step. It looks determinate; the meaning is false. After one exposure, people discount later true percentages too. This leaf is not “use determinate when you have a total,” and not “don’t hint remainder when you don’t.” It is the cost of counterfeiting a ratio.

Why it happens

A determinate bar trains a calibration: position of the bar maps to position of the work. Fake progress breaks that calibration on purpose, buying a few seconds of “already fast.” People decide on the broken calibration—ninety percent, so don’t cancel, don’t switch—then idle in that last ten percent, and file “this product’s bar lies.” Later true transfers and installs, wearing the same shape, are no longer treated as ratios: people cancel early, or ignore a truly stuck bar. Trust migrates across tasks. A fake bar in an export contaminates a real bar in a download. Fakes also couple to “fast then freeze”; the freeze is exactly when an honest ratio is needed, and when a fake ratio is weakest.

Studying it

Give the same people one bar that is obviously decoupled from work (clock-driven to ninety-nine percent, then a long stall), then a later truly determinate bar.

Independent variables: whether the first bar was fake, whether the fake was a fast start or a stuck ending, whether the second task is announced as “real progress this time.” Dependent variables: premature cancel on the second task, whether percent still drives decisions, later judgment of “is the bar trustworthy.”

Do not only ask whether the first run felt smooth. Fakes often feel smoother the first time; the damage is written on the second. A study with one task cannot see the transfer, and so cannot see the destruction this leaf cares about.

Where it stops holding

Smoothing jitter in real progress (the bar does not leap backward on a brief stall) is not fake, provided the bar never runs past confirmed completed work. An entrance animation from 0 to 1 percent is usually tolerable if real data follows immediately. Starting indeterminate and switching to determinate when a total arrives is not fake if the switch does not treat the animation’s position as completed ratio. A mandated minimum display time that drives the bar forward is already a fake, even if the motive is “don’t flash to done.”

Applying it

• Let bar position map only to confirmed completed work; when no new work is confirmed the bar may stop, it may not crawl itself.
• Ban time scripts that “go to n percent then wait for real work” and that “always leave a sliver for the last step.”
• When switching from indeterminate to determinate, start at zero or at known completed work, not at the sliding animation’s position.
• Verify by stalling the real work: does the bar still move. If it crawls, it is fake. Then watch whether people still trust the numbers on the next real bar.

Related

• Within the group: E6.09.1 When a total can be estimated, progress must be determinate · E6.09.2 Indeterminate progress does not convey time remaining
• Adjacent: E6.08 Loading indicators · E2.15 File upload · E6.04 Global status messages
• Search terms: fake progress · deceptive percent · progress trust