SAP DESIGN GUILD

Human Performance at the Computer – Part 2: Making Applications More Responsive

By Gerd Waloszek, SAP User Experience, SAP AG – November 7, 2008

In this series of four articles I would like to investigate the topic of human performance at the computer, introduce new insights, and discuss performance-related issues that can be addressed by UI designers – including the concept of perceived performance. In this article, I would like to focus on the aspect of improving system responsiveness. In the following, I will point out that the challenge here is to find ways of reducing the waiting times for users even when processes are still running. We will also see that responsiveness is by no means a purely technical topic, because waiting times also impact users in certain ways. I will list recommendations for making applications more responsive and conclude the article by asking how control can be returned to users in the best possible way.

 

What Does Responsiveness Mean?

Definition

While the Wikipedia definition of performance includes the responsiveness aspect, this concept is easier to understand if one follows Jeff Johnson (2007) who insists that performance and responsiveness are not the same. Johnson defines responsiveness as follows:

The Wikipedia definition for responsiveness (probably not from the same person who defined performance) is quite similar:

This definition adds, in accordance with Johnson, that responsiveness is not the same as performance, and that a system with good performance can actually display poor responsiveness, and vice versa. Neither definition, however, explain how to evaluate responsiveness from a user's perspective.

Primary Question

To sum up, system responsiveness relates to the question: "How long do users have to wait at the computer?" It implies that "how long" can also mean "too long" and that there is a need to improve the system's responsiveness, or more specifically, to reduce the waiting times for users. When developers and UI designers attempt to address this need they face the challenge of finding ways to return control to the user even though some system processes – for example, the ones that the users just started – are still running. This sounds like a paradox, and some creativity is indeed needed here. I will present a number of approaches to this challenge later.

The question above might suggest that we are dealing with a purely technical issue here, but this is not the case. Waiting times also have a psychological dimension: Depending on their duration, they impact the users' cognition, attention, and motivation – I will discuss the details below. As a result, improving the responsiveness of a system requires a close cooperation between technology and UI design. Seeing waiting times from a user's perspective helps UI designers guide development and give advice on which aspects need further improvement and which are already good enough from a user's perspective and do not need any further resources investing in them.

Related Questions

The primary question that characterizes responsiveness can be supplemented with a number of related questions. First of all, we can regard the question above as a purely technical one and measure the waiting times. That is, we can ask:

If we find the waiting times excessive (according to some given criterion), we can inquire further and take introduce measures for improvement:

It would be better, however, to investigate how users react to waiting times and find user-related criteria for evaluating them. The respective questions would be:

Thus, we can modify the second question and include the user perspective in it:

As already mentioned, the modified question helps allocate resources appropriately. Finally, if waiting times cannot be reduced any further and they are still not in the "tolerable" range, we can ask:

The primary approach to making waiting more tolerable for users is to give them feedback. I have devoted a separate series of articles to this topic and will not discuss this aspect any further, here. Waiting can also be made more tolerable by putting the user in control, or by providing action or decision options. These approaches are closely related to those described for perceived performance. The latter term refers to the discrepancy by which users may perceive a system's performance differently from how it objectively performs. The respective question would be:

Perceived performance is covered in a separate article within this series. It is often difficult to distinguish between perceived performance and responsiveness and some approaches are therefore described redundantly in both articles.

 

Bringing in the User...

Before we look at approaches to making applications more responsive, we need to gain a basic understanding of how users perceive waiting times at the computer, what time ranges are relevant for users, and how they affect the users' thinking, attention, motivation and – ultimately – their work. For this purpose, I would like to present a table containing what I found in the literature and adapted to my needs. I will also add a few remarks and further data.

Time Ranges

Alan Newell (1994) was probably the first to define a (logarithmic) time scale of human action. In the late 80s and early 90s, his student Stuart Card, together with G. Robertson and J. Mackinlay, took a section from that scale and transferred it to human-computer interaction. Jakob Nielsen (1993), Alan Cooper et al. (2007), and, most prominently, Jeff Johnson (2000, 2007) republished and further refined and adapted the original table. Further relevant timing data can be found in Shneiderman & Plaisant (2004). The table below is my adaptation of these tables, includes results from my literature search, and partly puts the data in a new perspective.

Time Range Human Aspect User Interface:
Acceptable Response Times		 User:
Response/Feedback Does Not Appear Timely		 Comments on Untimely Response
0.1 sec
(0.05-0.2)		 Perception Acknowledge user input
(direct manipulation: key press, mouse click, open/close menu, highlighting, ...)		 Perception of smooth animations and cause-and-effect relationship breaks down Must not happen!
1.0 sec
(0.2-2.0)		 Dialog,
Operation		 Present result of simple tasks
(navigation, open new window), finish unrequested actions (auto-save)		 Engaged user-system dialog breaks down Should not happen; provide feedback, allow user to abort the process
3 sec
(2.0-5.0)		 Cognition,
Attention, Motivation		 Present result of common tasks (simple search/calculation) User has time to think: the system is perceived as slow, the user's focus starts to wander, and the user may turn to other tasks
10 sec
(5.0-15)		 Present result of complex tasks (complex search/calculation) User loses focus on task and may turn to other tasks
>15 sec Present result of very complex tasks (extensive search/calculation) User gets annoyed; detrimental to productivity and motivation

Table 1: Human time ranges

*) Because these times are only rough guides, most authors simply list the powers of 10, such as 0.1, 1, and 10 seconds; I have extended the numbers into consecutive ranges but please do not take the transition points too literally. The limit of 2 seconds for the dialog level may already be too high.
**) T took the terms "simple," "common," and "complex" tasks directly from the literature. In my opinion, they are only of limited use because they do not clearly describe the task types at the respective levels.

Note: This is a more recent adaptation of the table presented in Waiting at the Computer: Busy Indicators and System Feedback – Part 1.

Interpretation

Basic Time Ranges

Basically, we find three relevant levels or time ranges:

The cognitive level can further be subdivided with respect to its impacts on the users' thinking, attention, and motivation. We might also add the level of annoyance at about 15 seconds, but this can more or less be regarded as a facet of the cognitive level.

Consequences from a User's Perspective, More Facts...

From a user perspective finish the following operations within:

The users' tolerance for longer delays depends on (see article on perceived performance):

If users receive no feedback the following happens after...

Users' sensitivity to changes and variations in waiting times:

 

Techniques for Improving Responsiveness

In the following, I will attempt to answer the question of how real or improved responsiveness can be improved, and I will provide recommendations that refer to different aspects. Figure 1 shows the premises for improving responsiveness and the respective approaches, which focus on processing and on user-input aspects:

Premises for improving responsiveness and the respective approaches

Figure 1: Premises for improving responsiveness and the respective approaches

Please note that Jeff Johnson (2007, 2000) also provides a list of items for improving system responsiveness that differ somewhat from the recommendations below.

Presentation Strategy

Processing Priorities, Parallel/Background Processing

Processing Strategy

Event Queue Handling

User Input/Event Handling

 

How to Return Control to Users?

When I looked at the topic of responsiveness more closely, I hit upon an issue that has seemingly not received much attention in the literature: the question of when and how to return control to the user. Many sources state that it is important to put the user in control and not to block his or her actions. They also mandate that users should be able to abort long-running processes or switch to other applications. But the details of how to optimally return control to users remain unclear. To stimulate a little progress here, I would like to make a few distinctions and come up with a proposal.

Types of Control

Let me distinguish between the following types of "control" (there are probably more):

I cannot see any reason why users should not be able to perform simple window operations immediately – these operations can be faked anyway. Resizing may be a bit more complex but could also be faked by invalidating the current state of the window during the resize process. Scrolling is more complex because users should only be able to scroll as far as content exists.

Aborting an application or a process should also be possible immediately. I often find myself starting an unwanted process and wishing to cancel it at once. An abort operation should at least be allowed after a few seconds. For example, users may realize that a process will take much longer than they expected and want to cancel it. In addition, switching to other applications should also not be blocked in multi-tasking systems. Temporarily turning to other tasks reduces (and utilizes) the users' idle time and leads to better perceived and actual performance.

In the context of returning control to the user, enabling user interaction in the content area of a window or Web page is a highly critical issue that requires careful handling. One such critical decision is whether the Save function should be enabled before a screen or page has loaded completely. There are both UI design and legal aspects involved here. In many cases, however, there are no external reasons why, for example, the scrolling of list items or the selection of objects should be blocked while data is being loaded or initialized. One example of a "non-critical" case is the image browser that I use on my computer at home: The browser initially displays thumbnails of the images that are located in a selected folder. Regrettably, it blocks user input even after the thumbnails have been refined (it seems as if the browser is still loading or initialing data in the background). When the browser finally accepts input, it is extremely sluggish. Only after a certain point in time does it "speed up "– the initialization seems to be complete at last.

Graded Return of Control

While it seems to be difficult to provide general recommendations for returning control to users – particularly with respect to interactions regarding the content area – it looks to me as if a "graded" approach to returning control makes sense:

This "return of control" can be made visible to users by gradually enabling the respective controls (window controls, menus, buttons, and so on). Microsoft Outlook is an example of an application that gradually enables controls. Regrettably, it "cheats" users because it enables controls and screen areas before they are actually responsive. This behavior may look "better" at first sight but it ultimately confuses and frustrates users. Therefore, I would like to encourage the Outlook programmers to continue on the way they already started and "do it right."

 

Conclusions

Discussions about human performance at the computer typically refer to performance, which more or less means system speed. While increasing speed is an essential step in improving the performance of a system, the real problem often lies in the responsiveness of a system, that is, in the way in which a computer system responds to user input and how long it makes users wait until they get a result and can continue their work.

It turns out that improving the responsiveness of a system is a much more challenging endeavor than improving its speed. On the technical side, advanced programming strategies and manipulations that may be beyond the scope of application developers are needed. Often, however, the necessary techniques are not provided by the technical platform in use. On the user's side, we need to know what the targets for waiting times are and, if these are not attainable, how waiting can be made more tolerable for users. Target times also help avoid optimizing aspects that are already good enough from a user's perspective.

The following question requires consideration of both user and task needs: When should control be returned to users and how? That is, which input should be allowed first and which only after a process has finished? In my opinion, it is not easy to make general recommendations here. Instead, developers and designers need to look closely at an application and at the tasks it performs in order to come up with informed decisions. With more experience in this area, it will probably become easier to provide general recommendations.

Finally, this article shows that handling responsiveness appropriately requires a lot of effort on the developers' side. I understand that it is easier to stick to simpler programming techniques and hope for ever-faster computers, but history has shown that this hope is an illusion.

 

References

 

top top