Addressing A "Design Issue:" Start-Up Time

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.

Questions

A Design Issue

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).

Redefining Start-Up Time

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.

Not Only a Design Issue!

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.

First Answers

In the following, I would like to present a few findings from the literature
that seem relevant to the discussion of start-up time.

Location of Delay

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.

Distribution of Delay

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.

Start-up Time of Operating Systems and Applications

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.

Approaches

Preamble

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.

"Light Weight" Application Launch

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.

Defer Processing to the Background or Parallel Threads

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.

Use Idle Time Intelligently

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.

Offer "Graded" Control

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.

Fake Heavyweight Calculations

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).

Allow Users to Stop an Application Launch

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.

Conclusions

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.