E6.01.2toast dwell timedesignresearch

Dwell time must scale with text length

Aliases: snackbar duration · time on screen · reading-time match

What it is

Dwell time is how long a toast remains visible before it auto-dismisses. The question is not whether the message should vanish on its own—that is a different decision—but how much time reading gets once auto-dismiss is already chosen. A fixed two or three seconds treats a four-character “Copied” and a twenty-character failure reason as the same stimulus. The short line still occludes content after gaze has returned to the task; the long line is gone before the second clause is read. Matching dwell to text length means visible time rises with readable characters and complexity, rather than a global constant.

Why it happens

Silent reading time grows roughly with character count, but a toast is rarely treated as a paragraph to finish. People first classify the shape as “a piece of feedback,” then decide whether to move gaze from the control. That shift costs time; object names, quantities, or causal clauses add an integration step beyond raw reading. A fixed duration assumes every message has the same perceptual cost. Overtime on a short message leaves residue that covers a button or list tail. Undertime on a long message captures tone (red, failed) but not the object (which item, why). Entrance and exit motion also eat the labeled interval, so the readable window is shorter than the nominal timer.

Studying it

Hold the primary task constant and vary visibility across short, medium, and long versions of the same toast.

Independent variables: character count, presence of proper names or numerals, whether entrance animation counts toward the timer, whether the user is already reading nearby text. Dependent variables: verbatim recall, ability to name the object in the message, rate of early manual dismiss, and whether people search for the content after it vanishes.

Do not rely on “felt long enough” ratings. The useful cut is the duration where recall collapses: shorter, object information is lost; longer, manual dismiss rises, which means residue has become interruption. Character density differs across languages; the same millisecond budget does not transfer from English to Chinese.

Where it stops holding

Icon-only or single-word confirmations gain nothing from a length formula; extra time is only extra noise. Screen readers speak at their own rate. When the visual timer and the spoken utterance disagree, end of speech is the better bound, not pixel disappearance. A toast that also hosts an action (Undo, View) must cover reaching and tapping, which is a motor budget beyond reading match. Low vision and magnification wrap one line into several; estimate length from the visual span after wrap, not from source character count.

Applying it

  • Bucket duration by copy: shortest for word-level confirmations, medium when an object is named, longest when a reason clause is present; do not ship one global millisecond value.
  • Start the timer when the text is stably readable; do not count entrance motion as reading time.
  • Read the real strings aloud in each shipping language, time that reading, and keep the toast up at least that long plus time to shift gaze.
  • Verify with someone who did not write the copy: the moment the toast vanishes, ask who the object was and what happened. If the object cannot be named, dwell was too short. If the primary task stays blocked until they reach to dismiss, it was too long.

Related

  • Within the group: E6.01.1 Auto-dismissing toasts cannot carry must-read information · E6.01.3 Consecutive toasts should queue rather than overwrite
  • Adjacent: E6.12 When notices dismiss · D1.14 Duration of feedback · E6.02 Banners
  • Search terms: toast dwell time · snackbar duration · reading time

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E6.01.2