As members of an internal SAP project about perceived performance, we are often asked: "How do I give feedback in the event of delays?", and "How do I deal with start-up time?" I devoted the article series Waiting at the Computer: Busy Indicators and System Feedback to the first question. The second question, however, has been addressed only briefly up to now under the heading "design issue," which indicates that this is indeed a tough issue. In this article, I will look at the issue of start-up time in more detail and will highlight a number of approaches to making it shorter and thus more tolerable for users. However, do not expect me to provide an easy solution. In the following, I will address both computer start-up and application start-up.
According to Shneiderman & Plaisant (2004), rapid start-up is an important design issue, particularly from a user's point of view. The authors state that users get annoyed if they have to wait several minutes for a laptop or digital camera to be ready for use. Consequently, they characterize fast starts as a strong distinguishing feature in consumer electronics. The authors also explain that there can be a trade-off between rapid start-up and rapid usage: Rapid start-up often implies that later use is slowed down because data or a function then has to be loaded when required. The other option would be to load everything at start-up that might be needed later, thus causing a longer delay at start-up but ensuring that most actions are performed rapidly.
It is hard to make a general recommendation, but it is evident that rapid start-up is more important for a digital camera (which is also a computer) or handheld computer than for a desktop or laptop computer. Nowadays, digital cameras start up in the one-second range, while computers typically start up in the one-minute range. In fact, my computer at work starts up in around three to five minutes.
There have been long discussions about the above-mentioned trade-off between rapid start-up and rapid usage. As far as I understand it, popular wisdom seems to opt for longer start-up time in order to achieve rapid usage later. In a recent New York Times article, however, Richtel and Vance (2008) discuss current attempts by a number of manufacturers to reduce the start-up time of operating systems – and thus computers. The article indicates that computer start-up time is still an important issue and that users no longer tolerate start-up times of several minutes (because they have been "spoiled" by mobile devices, according to one company spokesperson – see below).
The other important start-up time for computers is application start-up time. This is the time needed by an application from being started by the user until the user is able to interact with it. As you can see, I deliberately did not define start-up time as referring to the completion of processes. The usual assumption is that all initialization processes finish during computer or application start-up time. But in my opinion, it is more useful to define the end of start-up time as the moment from when users can interact with the computer, even though the user's interaction may be limited because certain processes have not finished yet.
I would also like to emphasize that start-up time is not only a technical issue. There is also a human component that needs to be considered. Start-up delays make users wait, and we can ask how users can use them efficiently and not just waste their time. For example, I mentioned earlier that my computer can take up to five minutes to boot in the morning. That provides a good opportunity for me to get a cup of coffee or chat with colleagues. There are days on which I have to reboot the computer several times in the morning, for example because new software is being installed. This can, however, result in too much coffee, and my efficiency goes down again! Long application start-up times are usually a good opportunity for checking your e-mail inbox or surfing the Web (provided that you do not need to start those applications). Thus, modern life offers some compensation for annoying waiting times – it may be acceptable for users in some cases but not in others. All in all, we can conclude that we also have to consider the work context when discussing such issues: A possible outcome may be that the effects of delays are not as severe as they looked first seemed.
In the following, I would like to present a few findings from the literature that seem relevant to the discussion of start-up time.
According to Brown (1988), the position of a delay is a key factor in determining an acceptable response time. Delays that occur after the user has completed a planned sequence of actions are less disruptive than those that occur in the middle of a sequence (the author calls this the "effect of closure"). Regrettably, he does not make any statements about delays at the beginning of an action, but I would presume that these are not as disruptive as delays in the middle of an action sequence. All in all, the effect of closure should caution us against introducing too long delays in the middle of action chains, for example caused by loading data that was not fetched during initialization.
In addition, there is evidence that a few long response times leave a greater impression on the memory than a large number of shorter ones. This would imply that if data has to be loaded after initialization, it should be loaded in small packages that users do not notice.
In a recent New York Times article, Richtel and Vance (2008) discuss current attempts to reduce the starting time of computers. Here are just a few quotes from the article: A Hewlett-Packard spokesman stated that "we have been spoiled by the handheld devices. (...) Hewlett-Packard research shows that when boot times exceed more than a few minutes, users have an exaggerated sense of the time it takes. Four or five minutes can feel like an eternity." As mentioned above, this is only true if you cannot use these delays efficiently for other purposes. In the article, it is also stated that HP's goal is to offer PCs that boot in 30 to 45 seconds and that in 18 months, the goal will be down to a range of 20 to 30 seconds. It is evident that to achieve such short start-up times, certain compromises need to be made, and I will look at appropriate technical options further down.
Of course, application start-up time, also called launch time, should also be as short as possible. Apple (2007), for example, offers some hints on how to make the launch of applications appear faster: "The best way to make your application seem fast is to display your menu bar and main window as fast as possible." This principle can, of course, be extended – an approach that I once called "graded return of control." I will discuss this technique below.
In the following, I will present a number of approaches to reducing start-up time. These approaches contrast with the prevailing preference for longer start-up times to achieve rapid usage. They allow users to interact with the computer and thus continue work as soon as possible. Please note that the following approaches are mostly variants or applications of approaches to improving responsiveness and perceived performance.
The Apple Code Speed Performance Guidelines (2007) recommend loading only the necessary resources during the initialization of applications, because this approach not only reduces the time for starting up, but also keeps the overhead and memory footprint of the application low.
Apple's recommendation to launch applications in a "light weight" manner can be extended in the following way: Defer the loading of background data as well as housekeeping tasks to the background (typically to additional program threads) and later points in time and open the application to user input before these activities have been completed. For example, there is no need to block user input in an image browser until all thumbnail previews have been updated and fine-tuned. Threads can take advantage of multiple processors, but they can also cause a certain overhead and interfere with each other; they also use additional memory. In unfavorable conditions they can even impact performance adversely – so they need to be used with care.
We all know that computers are idle most of the time, waiting for user input. Therefore, system idle time is a resource that can be used for loading additional data or for doing housekeeping tasks without annoying users with unexpected delays after they have started an action. "Intelligent use" of idle time means, for example, that times of inactivity are used for computing probable results in advance. This helps avoid delays when the user actually starts a function or inspects data.
In my article about improving responsiveness, I recommend displaying partial results, thus allowing users to continue working as soon as possible. For application start-up, this recommendation has to be adapted by applying the principle of "graded return of control." The example above from Apple points in the right direction: By displaying certain screen elements before the application is ready, users get the impression that the application is starting up faster. However, as I pointed out in my article, it is important not to cheat users. Instead, you should only display screen elements that are actually available for interaction or show them as disabled if they are not ready yet.
To achieve faster application start-up, it may also be appropriate to supply users with a fast preliminary result (that is, a representation of an object) and perform time-consuming calculations at a later point in time. Jeff Johnson's (2007) quote "fake heavyweight calculations" means that you should show the fast fake first and quickly and the final result later (namely after there has been some computer idle time that allowed the system to compute the final result).
It is also important to allow users to abort an application during start-up and start another one. Nothing is more annoying to me than launching the wrong application (which can easily happen with a mistaken mouse click) and having to wait for a long, long time until I am finally allowed to exit the application.
Shneiderman & Plaisant (2004) point out that rapid start-up time is a tough design issue. As a recent article in the New York Times shows, computer start-up time is still on the to-do list of major computer and operating system manufacturers. In addition, users often face intolerably long application start-up times. In both cases, developers have to decide between rapid start-up and rapid usage. While rapid usage is typically the preferred option, this article tries to demonstrate that, by using intelligent approaches, developers need not sacrifice rapid usage for rapid start-up, which, as Shneiderman & Plaisant point out, can be a distinguishing feature of consumer products – and is also highly relevant in users' daily work at the computer.