Freshness expectations follow content type, not what the system can do

What it is

People already arrive believing a ticker should jump, a mail list may sit at the moment it was opened, an encyclopaedia page may sit at the last edit. Expectations follow content type, not what the system can actually do. Shipping push does not make a help article feel like a ticker. Not shipping push does not make a one-minute-late chat acceptable. Capability can sit above or below expectation; whether the experience is right is scored against expectation, not capability.

Why it happens

Content types have already trained “should this move by itself” in daily life. Quotes, presence, unread badges are coded as live; articles, manuals, a completed-order snapshot are coded as still. That classification comes from how the object changes in the world, not from which channel a product uses. Opening a surface, people first fit a type-model, then watch whether it moves. More motion than the model is flicker and noise; less than the model is breakage.

Using capability as the excuse produces two mismatches. Capability high, content still: a heading rewrites itself to the latest edition while it is being read, and the model breaks. Capability low, content live: a conversation still shows last minute’s “typing”, and people start pulling to refresh. The repair is to fit this region’s beat to the type, or to fit how the type is presented to the beat (say outright that this quote is delayed) — not to pile on more channel.

Where it stops holding

A newly appearing type with no stable expectation (some generated-AI status, some collaborative canvas) cannot be slotted into “should be still” or “should jump”; the product has to say the model. The same object changes type across tasks: a stock is live on a trade screen and a still snapshot in an annual report. How fast “live” is allowed to be differs by culture and industry; a sports score and a bank balance both “should be new”, with acceptable delay an order of magnitude apart. Expectation is also taught by last use — a product that has long made still things jump will make jump the default for that type, and people will briefly misfit when they move to another product.

Applying it

• For each content type (live status / in-flight conversation / document / snapshot / report), list the freshness model people bring. Compare it to the actual beat. Find the “busier than the model” column and the “slower than the model” column.
• When a live type cannot match expectation, change the beat or name the delay. Do not defend with “the backend is actually latest”.
• Do not auto-refresh still-type body just because the channel is idle. Refresh on enter, on a manual action, or via a version prompt.
• How to check: delay a chat until it is clearly slower than a “conversation” model; people should pull or complain, even if a status line says connected. Swap a help article under the eyes for a new edition while it is being read; people should feel robbed, even if technically it was an update. Both columns must be reproducible.

Related

• Same group: I4.07.1 Different features need different freshness; not everything must be latest · I4.07.3 Label freshness so people do not misread how current the data is · I4.07.4 Strong consistency and high freshness usually trade off; products must pick
• Nearby: I4.03 Polling versus push · I3.01 Visibility of system status
• Search terms: expected freshness · content-type cadence · mental model of liveness