|Human Performance at the Computer – Part 2: Making Applications More Responsive|
|Addressing A "Design Issue:" Start-Up Time|
|Review ofGUI Bloopers 2.0 (Jeff Johnson)|
By Gerd Waloszek, SAP User Experience, SAP AG – August 4, 2009 • original article (design tidbit)
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):
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.
The computer blocks user input until the startup process has (more or less) finished.
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...
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."
Often, I find myself starting applications (once I am able to) while the computer is still starting up, making things even worse...
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.
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.
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.
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.
*) In the case of business applications, legal requirements may forbid a page to allow input until it has loaded completely to prevent inconsistent content.
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.
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.
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.
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.
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).
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.
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).
Figure 1: Brushstroke lags behind the mouse pointer (photo)
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.
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).
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.
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.
A control reacts too slowly to user input (not within 0.1 seconds):
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.
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.
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.
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.