SIGIA-L Mail Archives: SIGIA-L: IE 5.5 Responsiveness Bug (long)
SIGIA-L: IE 5.5 Responsiveness Bug (long)
Date: Fri May 11 2001 - 15:39:37 EDT
I want to make the usability community aware of a rather nasty bug in
Internet Explorer 5.5. I believe this bug is very serious and will
significantly impact many web users, especially users with poor
connectivity (less than T1) and it will also more heavily impact users
of web applications or sites that do not respond in less than a few
Unfortunately, Microsoft is not going to fix this bug in their next
Service Pack (late summer last I heard). This is according to emails
I've seen from Microsoft to our internal Microsoft contacts.
Unfortunately, we've already upgraded many users, and are now dealing
with the consequences.
Below is a description of the bug and my personal analysis that I
communicated internally to web developers. I would like to hear this
list's very expert opinions on this issue. I'd also like to know if
others have already seen any impact from this bug.
The problem is basically that the browser will not change the cursor to
indicate that the system is busy after the user selects a link, button
or other action (i.e., the user invokes a function) in the web page.
(See below for Microsoft Knowledgebase link.)
This bug affects the RESPONSIVENESS of all web applications that an IE
5.5 user interacts with. Responsiveness is NOT the same thing as
performance. Here's a good description of responsiveness from the book
GUI Bloopers: Don'ts and Do's for Software developers and Web Designers
(Great book by the way!):
"...responsiveness has been repeatedly shown to be one of the most --
if not THE most -- important factor in determining user satisfaction
with computer technology. Unfortunately, this fact seems virtually
unknown in the industry."
"Highly responsive software lets you know instantly that your actions
were received (e.g., button presses, mouse movements), lets you
estimate how long lengthy computations will take, frees you to do other
things while waiting for a function to complete, manages queued events
intelligently, performs house-keeping and low-priority tasks in the
background, and makes use of idle time to anticipate (and precompute)
your likely future requests.
"Performance, on the other hand, has to do with how quickly the
software computes and displays the desired results. High-performance
software gives users their desired results quickly; low-performance
software makes users wait.
"The good news is that software can be responsive even when its
performance is low. The bad news is that much of the software in
today's market has both low performance and low responsiveness. Bad
The web, in general, has poor performance.
A lot of research on responsiveness has been done by human factors
experts in the past and it has been found that response time targets are
very small. 0.1, 1, and 10 seconds are the metrics that seem to be
common in most of the research I've seen. I won't go into the details,
since I expect many here are already familiar with this research.
Impact & Recommendations:
**Note that in IE the busy indicator is meant to double as both action
acknowledgement and busy indicator. E.g., When a user clicks on a text
or graphical link, the only indication that the click was acknowledged
is the busy indicator that should show. If the site/application can
not display the results (e.g., next page) within 1 second, then 2
important responsiveness problems occur: a) the user is not sure the
click was acknowledged, and b) the user is not sure the system will
return a result. I’ve seen users in usability tests wait just a couple
seconds, even with a busy indicator showing, and then click a link or
button a second time - this re-starts the function initiation, further
delaying the response.
This IE 5.5 bug will very likely greatly impact user satisfaction with
any web application that does not perform VERY quickly. Research shows
that users expect applications to perform consistently within a 1-3
second window in order to be considered “responsive”. I estimate that
IF ANY FUNCTIONS IN YOUR APPLICATION OR SITE DO NOT RESPOND WITHIN 3
SECONDS, THEN YOUR IE 5.5 USERS WILL BE IMPACTED BY USABILITY PROBLEMS.
They may re-select the function (re-initiating it) or start to get
frustrated, not knowing if the system is even working. THIS WILL VERY
LIKELY IMPACT USERS IN OTHER GEOGRAPHIES MORE HEAVILY THAN LOCAL USERS
due to differences in network performance.
Microsoft’s Knowledgebase Info on This Bug:
The first workaround they discuss doesn’t work (at least in our tests).
A full description can be found at
"To work around this behavior, you may be able to update the mouse
pointer's settings if you perform one of the following two methods:
You can move the mouse pointer to a different location on the Web page.
You can hover the mouse pointer over the taskbar or the toolbar."
Microsoft's stated reason for not fixing this problem is "the workaround
in the Q article was considered acceptable." I find it very hard to
believe that this assessment was done by anyone at MSR or in their
usability team as it is not realistic. Evidently, the rationale is that
we will train users to click a link, then move their mouse around until
they can figure out if the system is busy or not.
It's more likely that users will blame the application/site rather than
have any idea that the browser is the culprit or that they should do
anything new or different than in other applications or earlier
versions. Thank you Microsoft for letting your fellow developers and
customers take the fall on this one. :)
User Experience Architect
List archives are available at:
To subscribe or unsubscribe, send mail to majordomo_at_asis.org with the
appropriate command from the list below in the body of the message:
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:38 EST