Request Timeout

The ambiguous failure, handled honestly: packets that leave and never land, and a screen that admits the request may have gone through.

Waiting for the server…

Still open. We will stop at 30 seconds.

Build a request-timeout state that is honest about what it does not know. Structure: a small network diagram (client square, wire, server square), a heading, an explanation, and two actions. The diagram: three small dots travel the wire from client to server on a repeating loop, staggered about 0.35s apart, fading in at the start and out at the far end. They leave and never arrive - that is a picture of the actual problem rather than a spinner standing in for one. The server square stays DIM until the timeout, then lights in red with an offline icon. Colouring it earlier would say the server answered. The copy is where most implementations go wrong. During the wait: "Still open. We will stop at 30 seconds." A wait with a published end is a different experience from a wait without one. At the timeout: say the request MAY STILL HAVE GONE THROUGH and to check before sending it twice. Most timeout screens claim the request failed - that is a guess, and it is the guess that causes double charges and duplicate orders. The retry button is DISABLED while waiting and only becomes pressable at the timeout, so nobody fires a second identical request into a connection that is still open. Offer a second action - "check status" - because when the network is the suspect, a status page is the answer the retry button cannot give. Accessibility: the explanation is aria-live="polite"; the diagram is aria-hidden. Under prefers-reduced-motion, render the timed-out state with no travelling dots. Colors as tokens: paper card, one accent for the packets, a reserved status red for the failed endpoint. Build the component, not this demo of it. - Ambient motion that IS the component may loop: a drifting background, a marquee, a spinner while something is genuinely loading. - Do not add any timer, interval, loop or script that performs a person's action by itself. No auto-hover, no auto-click, no cycling through states, no pretend submitting, no replaying the interaction on a schedule. - Every state that answers a person waits for a real event from that person. - Placeholder copy and sample content are welcome. Simulated behaviour is not.

Rate it
0
0

We'd like to measure how the site gets used, with Google Analytics. It sets cookies. Everything the site needs to work runs either way. How we handle data