user-interfaceuser-experiencehuman-computer-interface

Is there a generally acceptable definition of (soft) realtime delays?


I'm trying to find a benchmark for how long users are willing to wait for a response from a remote service. In my case the response is for very useful but not business critical validation of data entry. I guess that there must have been some work done in the HCI space on this.

If you know of a generally accepted definition for soft realtime responses then great but I'd also appreciate your well reasoned thoughts.


Solution

  • US DOD MIL-STD 1472-F Human Engineering Standard has the most widely accepted requirements for maximum allowed response time (from Table XXII, page 196, times in seconds):

    Key Response (Key depression until positive response, e.g., "click"): 0.1

    Key Print (Key depression until appearance of character): 0.2

    Page Turn (End of request until first few lines are visible): 1.0

    Page Scan (End of request until text begins to scroll): 0.5

    XY Entry (From selection of field until visual verification): 0.2

    Function (From selection of command until response): 2.0

    Pointing (From input of point to display point): 0.2

    Sketching (From input of point to display of line): 0.2

    Local Update (Change to image using local data base, e.g., new menu list): 0.5

    Host Update (from display buffer): 2.0

    File Update (Change where data is at host in readily accessible form): 10.0

    Inquiry - Simple (e.g., a scale change of existing image): 2.0

    Inquiry - Complex (Image update requires an access to a host file): 10.0

    Error Feedback (From command until display of a commonly used message): 2.0

    As you can see, acceptable response time depends on what response the user is waiting for. For something like a pulldown menu appearing, it's 0.5 seconds max. For a full page load in a browser, you want something to appear in 1.0 s to 2.0 s and the full page loaded in 10.0 s. In all the above, shorter response times are better. Only in bizarre circumstances will users object to a 0.001s response time.

    In any case, if the response time will be greater than 0.5 s, then you need to provide feedback such as a throbber or hourglass sprite. If response time is a minimum of 5-15 s (depending on what standard you use), provide a progress bar. With a progress bar, very long response times (on the order or minutes over even hours) may be acceptable as long as you set it up for the user as a “batch” process rather than being an interactive program. It's much better for the user to make all input and wait an hour than to make input on four occasions, waiting 15 minutes after each.

    The above list has the accepted standards. How long your users are willing to wait (e.g., before giving up) essentially boils down to the user making a cost-benefit analysis. Is what I’m going to get worth the wait? What are my sunk costs? Is there an alternative (e.g., another web site) that can do it better? Can I do other things while I wait to make the most of my time? However, whatever users willing to do, you can bet they’ll resent delays greater than the standards above.