Author: Karl Vochatzer
Last Update: 02/28/2000
The goal is to maximize the
user's control of the system (or perception thereof) through appropriate
response times of system actions and events. Additionally, where there
are current technological constraints to achieving a desired goal a
response time goal will be set that may be attainable through optimizing
on the interaction of the variables that go into the equation .
Take page downloading as
an example of an event that has many variables that figure into the
response time. Near instantaneous download times would certainly be
desirable but hardware limitations currently restrict this from happening.
Given the current technology constraints and hardware platform chosen,
some of the constraints are that modems and phone lines max out at 56k
so downloads above that or even approaching that are not attainable
today. Therefore a goal for this example might be to download pages
to the client within 10 seconds of the initiating user action. Accomplishing
this goal requires investigating and adjusting the known variables or
constraints to fast download times (e.g., page size, bandwidth, processing
power, video graphics power, server factors, etc.). Decreasing and/or
increasing the size, rates, power and speed of the variables may allow
us to achieve or come closer to the desired performance goal.
The set of actions and events
listed below are taken from Marc's architecture meeting on Tuesday February
22, 2000. It was suggested that a few of them were prioritized as affecting
the user experience. I would content that all of them should be considered
as directly impacting the user experience with the exception of logging
for our benefit. I have proposed the following response time goal after
each action or event in accordance to published usability guidelines
for giving the user the sense that they are controlling the system and
not the other way around.
- Logging: not a
consideration of the user, but whatever the response time is it should
not impact the user in any way
- Cached Content Access:
< 100 ms to give the perception of instantaneous results
- Dial-out Delay
(connection time): < 10 sec. - the point at which users start losing
attention rapidly. Visual feedback should be provided to keep the
user informed of the progress. An informed user is more forgiving
of longer wait times than an uninformed user. Basically, the current
wait time of nearly 60 seconds to set the modem, dial-out, connect,
and receive data needs to be greatly reduced to approach the 10 second
goal.
- Line Speed (also
progressive load of HTML): current hardware/line limitation - as close
to true 56k as possible
- DNS Lookup: <
1 sec. - to allow the user's flow of thought to remain uninterrupted.
At the completion of the lookup the user should begin to see the progressive
download of the page requested and be complete in less than 10 seconds
total time.
- Navigational Speed:
100 ms for cached content and less than 1 second for server side content
navigation (keeping in mind that the complete download of the server
side page should occur in less than 10 seconds, the Page Download
and Display Time).
- Time-out Values:
time-out can occur at 15 minutes after the last keyboard or mouse
action. Although I don't have any usability data to support this time-out
goal, it should be based on the time from the last user initiated
action and not just on the fact that the user has not initiated a
server side download. This should help to minimize the frustration
experienced during a reconnection.
- Hang-up Response Time:
< 1 sec. - a slight noticeable delay is acceptable. Currently it
appears to take about 2 seconds to get the connection light on the
i-opener to turn off. Users have commented that they think that they
have to hit the key twice to make it hang-up when it is really the
fact that it takes over a second to get any feedback that the key
press took.
- Content Update Time:
we will likely never figure out the best time to deliver content updates
for the wide variety of users situations and user's needs in our target
market. With that in mind, it is recommended that the event be user
configurable so that the user gets a sense of control for the updates.
- Multiple Redirects:
not recommended, especially if it means that each redirect page is
flashed before the screen each time. See the current implementation
(02/28/2000) of the "going to the web page" redirect prior
to the display of the "off-line... please wait" HTML message.
- Application Performance
(e.g., mail): < 1 second, but as close to 100 ms as possible so
that perceived delays are minimized
- Screen Saver Initialization
(not in Marc's list, but it should be recorded): based on the disconnect
event at 15 minutes of idle time, it is appropriate to initialize
the screen saver at the same time. However, it would be in the interest
of the user to actually initialize a little prior to the disconnection
time. Doing this may alert the user and get them back on task. However,
the earliest recommended time would be at 10 minutes of idle time
- any sooner and it could begin to disrupt some users that really
are still looking at the current screen (maybe they read really slowly!).
Based on Jakob Nielsen's
book Designing Web Usability (pages 42-53).