Incompetent Email Marketing = Lost Future Opportunities

Jakob Nielsen's Alertbox for October 31 is now online at:
  > http://www.useit.com/alertbox/newsletters.html
	
Summary:
Lack of personalization made an email newsletter completely useless
to the recipient, damaging long-term customer relationship efforts.
	
------------

User Experience 2005 conference

  > London, November 13-18

33 full-day tutorials over 6 days.
Come for as few or as many days as you like.

More info and full program:
  > http://www.nngroup.com/events

------------

I keep getting questions like this, so I decided to answer it in the
newsletter.

Q: "You mention many times that response time is important, and there are
tons of tools to measure response time, but what is an acceptable web
based application's response time?  What is a user's tolerance, not for a
shopping experience, but for an interactive application?"

A: I wish we could eradicate the term "web-based application" because it
distracts from the real issue, which is one of application UI design. We
don't have special guidelines for applications implemented in C++ relative
to apps implemented in Visual Basic. The fundamental usability
recommendations are the same, no matter the implementation, since we are
discussing user experience, not coding.

Therefore, the response time guidelines for web-based applications are the
same as for all other applications. These guidelines have been the same
for 37 years now, so they are also not likely to change with whatever
implementation technology comes next.

0.1 second: Limit for users feeling that they are directly manipulating
objects in the UI. For example, this is the limit from the user selects a
column in a table until that column should highlight or otherwise give
feedback that it's selected. Ideally, this would also be the response time
for sorting the column - if so, users would feel that *they* are sorting
the table.

1 second: Limit for users feeling that they are freely navigating the
command space without having to unduly wait for the computer. A delay of
0.2-1.0 seconds does mean that users notice the delay and thus feel the
computer is "working" on the command, as opposed to having the command be
a direct effect of the users' actions. Example: If sorting a table
according to the selected column can't be done in 0.1 seconds, it
certainly has to be done in 1 second, or users will feel that the UI is
sluggish and will lose the sense of "flow" in performing their task. For
delays of more than 1 second, indicate to the user that the computer is
working on the problem, for example by changing the shape of the cursor.

10 seconds: Limit for users keeping their attention on the task. Anything
slower than 10 seconds needs a percent-done indicator as well as a clearly
signposted way for the user to interrupt the operation. Assume that users
will need to reorient themselves when they return to the UI after a delay
of more than 10 seconds. Delays of longer than 10 seconds are only
acceptable during natural breaks in the user's work, for example when
switching tasks.

  > http://www.useit.com/papers/responsetime.html