Design Tidbits

back Tidbits Overview

Tools for Design and Visualization

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

Examples of Poor Responsiveness

By Gerd Waloszek, SAP User Experience, SAP AG – August 4, 2009

In a number of articles, I have discussed various issues regarding human performance at the computer: I have looked at topics such as responsiveness, perceived performance, and system feedback, and in some cases I was also able to point to possible solutions. Until now, however, I have not provided a list of representative responsiveness issues in one place. With this article, I would like to close this gap and put together a list of examples of responsiveness issues, most of which are based on my own personal experience. However, I will not reveal the respective applications – my focus is not on blaming others, but on demonstrating possible issues. Some of them are, of course, also listed by Jeff Johnson (2007, 2000) as "performance bloopers."

The examples have been arranged into the following categories (although I am well aware that some areas overlap):

 

User Input Blocked

One of the worst things that can happen to users is that the system simply does not respond to their input. While this may only be the case for a couple of seconds, it can also last for several hours. In the worst case scenario, this agony may even be permanent, meaning users are forced to restart their computers and possibly lose valuable work in the process. In the following discussion, I will distinguish between three cases: computer startup, application startup, and long-lasting processes.

Computer Startup

The computer blocks user input until the startup process has (more or less) finished.

Possible Solutions:

  • Avoid shutting down the computer (as with mobile devices)
  • Save the computer's state on the hard disk at shutdown and reload the memory image at startup
  • Open the user interface on a step-by-step basis to user input (see my article Addressing A "Design Issue:" Start-Up Time; there I write of a "graded manner" of opening the user interface to input)
  • Ensure housekeeping tasks of secondary importance (for example, the loading of additional functionality) are processes in the background perform these tasks during idle time only.

The industry has recently identified computer startup as a serious issue and is attempting to cut this time down to about half a minute ("Users are spoilt by mobile devices," as an HP representative put it). Currently, a computer startup can take several minutes, providing the ideal opportunity to get a cup of coffee...

Application Startup

Applications, too, block user input when they are started, usually until they have loaded completely. Some applications display certain controls and commands during the startup to indicate progress (perceived performance). Often, however, the user can only use these controls long after the system has indicated that they are "available."

Possible Solutions:

  • Load only those modules that are of primary importance; load other modules in the background or during idle time.
  • Make functions available on a step-by-step basis, that is, start with the Windows controls, and show further functionality when it becomes available so that users see some progress.
  • Display information as soon as possible (do not show no white windows or empty spaces if possible). To indicate progress to users, display unavailable features in a deactivated state (do not mislead users by indicating a function is available when it is not).

Often, I find myself starting applications (once I am able to) while the computer is still starting up, making things even worse...

Long-Lasting Processes

Ideally, there should be no long-lasting processes, but despite all the progress that has definitely been made, computers are still not as fast as we would always like. This means there will always be processes that last for a considerable amount of time (from minutes to hours or even longer). It must be possible, therefore, for users to interrupt and/or abort processes that last for a long period of time.

File Loads

Loading a large file can take quite a while (with or without opening a new window). This applies particularly to PDF files, large images, or large text documents. I once found that when loading a PDF file, input to a browser application was blocked not just in the window into which the file was loaded, but in all the other windows as well.

Possible Solutions:

  • Allow keyboard and mouse input so that the user can at least abort the loading process.
  • Open further windows of the same application for user input.

This issue is mainly caused by the way the processing priorities have been set. Typically, the priority is set as high as possible for the loading process so that it is as fast as possible – but this comes at the expense of an application that is unresponsive to user input while the file is being loaded.

Page Loads

This is the counterpart to file load, but in this case, the content is loaded over a network (of course, a file may also load over a network). Again, the browser or client application may block user input until the complete page has loaded. In some cases, the page is displayed only after the content has loaded completely, leaving users in front of a blank screen.

Possible Solutions:

  • Allow keyboard and mouse input so that the user can at least abort the page load.
  • Allow keyboard and mouse input so that the user can start working on available content (may conflict with legal regulations*).
  • Display information incrementally to allow users to read/work as soon as possible (may conflict with legal regulations*).

*) In the case of business applications, legal requirements may forbid a page to allow input until it has loaded completely to prevent inconsistent content.

Database Queries, Extensive Calculations

It is not always possible for a user to interrupt or abort a database query (or any other potentially long-lasting process such as an extensive calculation). This was an issue in earlier ERP systems that seems to have been resolved now. However, aborting the query may not be straightforward: Blocking user input during a calculation is usually done to speed up the calculation. However, the speed loss caused by scanning for input events is minor, whereas a responsive system that puts the user in control leads to more satisfied users.

 

System not Keeping up with the User (Reaction Too Slow)

The following examples include UI events that occur at a perceptual level. For the user to feel they are directly manipulating events on the screen (the perception of cause-and-effect, the perception of smooth animations, etc.), the system must be fast enough to satisfy the 0.1 seconds' time limit requirement. In the following section, I will distinguish between "one-shot" and "timed" user inputs: In the first case, users type or click. In the latter, the duration of the event is also relevant, for example, when users move or drag the mouse.

Display Lags Behind Input (Typing, Clicking)

The system's speed may be slower than the user types or clicks the mouse. The display of characters on the screen may, therefore, be delayed or the controls may not recognize user input on time.

Key Display Lags Behind Key Strokes

Characters appear on the screen much more slowly than the user actually types them. This is particularly detrimental to the productivity of professional typists, but may also confuse people who type slowly.

Possible Solutions:

  • Change the handling of events
  • Reorder the event queue
  • Change the processing priorities

Mouse Clicks Acknowledged Too Late

Changes to the states of UI controls and the corresponding actions appear on the screen with delays. State changes should happen within 0.1 seconds, associated functions typically within 1 second (depending on the task type).

Possible Solutions:

  • Handle immediate behavior (for example, highlighting, inversion, changes to the input's appearance) of the UI controls locally, that is, on the client computer.
  • Offer functionality (for example, displaying of menu items) locally, that is, on the client computer.
  • Provide system feedback if time constraints cannot be met for processes within 0.1 seconds (for example, display a wait cursor).

Display Lags Behind Input (Drag)

The system's calculation or event sampling speed may be slower than the speed at which the user drags the mouse or is required by the drag speed.

Drawing Lags Behind Cursor

The brushstroke, for example, in a draw or paint program lags behind the mouse cursor und "jumps" to its final position after the user has stopped moving the cursor (see figures 1 and 2).

Examples

Brushstroke lags behind the mouse pointer

Figure 1: Brushstroke lags behind the mouse pointer (photo)

Simulation of a brushstroke lagging behind the mouse cursor

Figure 2: The simulation of a brushstroke lagging behind the mouse cursor shows the details of the brushstroke (the cursor was not displayed during the screenshot)

Solution: Trade quality for quantity -> draw only a line and compute the final result (for example, the brush stroke) later.

Drawing Turns into a Polygon

In this case, the brushstroke, for example, in a draw or paint program is sampled at intervals that are too far apart. As a result, the drawn "curve" looks like a polygon (see figure 3).

The brushstroke is displayed as a polygon because the mouse position is not sampled quickly enough

Figure 3: The brushstroke is displayed as a polygon because the mouse position is not sampled quickly enough

Solution: Trade quality for quantity -> draw only a line only and compute the final result (for example, the brushstroke) later.

Object Lags Behind Cursor

A dragged object (for example, a window or box) does not follow the mouse movement, or does so only after a delay (and may jump between positions).

Solution: Trade quality for quantity -> draw only a frame or outline and show the actual object in the new position after the movement has stopped.

Control Causes Unwanted Delays

A control reacts too slowly to user input (not within 0.1 seconds):

  • Control Operation Causes Unwanted Delays: For example, the dropdown list, menu, fake checkbox, or menu button, opens too slowly (not within 0.1 seconds)
    Solution: Store data locally (on client) and do not load data via server roundtrip.
  • Control State Change Introduces Unwanted Delays: Highlighting or other control state changes do not appear on the screen within 0.1 seconds.
    Solution: Offer the functionality locally (on the client).

 

Impeding Human Performance (System Too Slow, Cumbersome Technology)

The examples given in the previous paragraph could arguably also be listed in this category because they impede the users' performance. They are different from the examples that follow, however, because the latter are at task level: Users typically expect delays here, although they would expect them to be shorter than they actually are. In some cases, users may expect no delays at all.

Page/Window Loads Too Slow After User Action

A page or window loads too slowly after the user clicked a link, button, or other UI control.

Solution: Depends on task context. This may require the user interface to be redesigned, including changing the UI technology.

(Unwanted) Page Reloads

Some page and window reloads are unnecessary from a user's point of view. Typically, they are caused by technological deficiencies or the use of inappropriate technology.

  • Page/Window Reloads After a Small Change to the Interface: For example, if the user clicks a tab on a tabstrip the whole screen is reloaded.
    Solution: Refresh only screen parts that have actually changed (delta management).
  • Page/Window Reloads After the User Misses a Button, Icon, or Link, for Example: After the user tries to click but misses a small icon, the entire page reloads.
    Solution: Correct this erroneous behavior if possible – if this is not possible enlarge the respective controls (following Fitts' law).

 

Final Word

In this article, I presented examples of poor responsiveness in three categories: (1) Systems that block user input, (2) systems that cannot keep up with user input, and (3) systems that impede the user by being too slow or by causing unnecessary delays. Tackling any of these issues will definitely make users happier and more satisfied, allowing them to feel in control and work at their own pace, thus being more productive.

 

References

 

top top