Quality Of Life InterneT Experiences (QOLITEs): "Little Things Mean A Lot"
Michael Etgen, email@example.com
Quality of Life (QOL) issues have become politically popular in recent years because they seem to have a profound effect upon human perception and behavior. QOL issues are generally little things that seem to mean a lot to people. There are many illustrative examples from the real world. If I walk in a park that has some trash scattered about, I won't feel too bad about tossing any trash I may have on the ground also. If I pass by a vacant home and there are one or two windows broken where rocks have been thrown at them, then it seems like no big deal to toss a rock myself.
The impact of QOL issues can be dramatic in the real world. New York's current mayor began a campaign of imposing serious penalties on what appeared to be minor QOL crimes such as jaywalking, subway turnstile jumping, etc. There is some debate about root causes, but it is apparently the case that when violators were penalized for committing minor crimes, all crime in general began to decline. When people notice that no one seems to care about or have pride in the appearance of a city or building, their resultant feelings about that place are often greatly diminished. Additionally, they seem to have a general resentment towards it.
I think the same general principle may apply to web sites/applications and the user experience. When little attention is paid to the details, even though the system may function well enough and the overall user interface is passable, I think users will come away with a feeling of inferior user experience. Although the little things may have meant little in terms of their overall performance and ability to complete their tasks on the site/application, I think people tend to remember and hang on to those little annoyances they've experienced. Therefore, I think that the Quality of Life InterneT Experiences (QOLITEs - pronounced like "qualities") are critical to gaining and keeping users of your site/application. Fortunately, it seems that most QOLITEs can be fixed without too much trouble.
In order to be aware of and overcome these little things that mean a lot, the User Experience Engineering division in AT&T Labs has begun to document specific QOLITEs and possible solutions. I will now discuss some examples of QOLITEs and provide solutions for the simple ones. Unless otherwise noted, code solutions should work both Internet Explorer and Netscape versions 3.0 and greater.
|| When the user is required to login to
the site or application through a page with only login and password
text entry fields, the user often needs to click on the login field
in order to start entering data.
the page has finished loading, then use the focus( ) event to put
the cursor in the first logical input element.
onload = document . form_name . first_input_element_name . focus(
|| The dreaded cross-browser
page printing problem... Internet Explorer does not give an easy command
to print the current page by simply clicking on a HTML button, like
Netscape does (i.e., assign this function: "window.print( )"
to the onclick event handler for the button). Well, after some searching,
there is a "simple" way to print with a basic button for
it does the trick. No more "print preview" buttons or labeling
buttons "print" that don't actually print the page.
||VBScript calls some Visual Basic functionality
to print the page. For more information, see
Thanks to firstname.lastname@example.org for the solution.
View the code at work in an example page.
|| When the user submits a form with one
or more errors, the system often provides just a link back to the
page with the form. No matter how descriptive the error message, it
requires a loss of flow in the user experience, and sometimes other
correct fields are reset when the user returns to the form page. (This
QOLITE has been discussed by many in the User Experience community,
but still appears in web sites/applications to such a high degree,
its worth mentioning again)
Solution 1: Check the form elements before the form is submitted
are erroneous and why.
Solution 2: Let the form elements be submitted to the server
without error checking on the client. On the page that is loaded
when there are errors, include not only the information about the
errors, but also the actual input elements so that the user can
correct them on that page without being forced to use the BACK button
or some other mechanism to return to the previous page.
The above QOLITEs are not necessarily fatal to a web site or application. Individually, they each may produce some annoyance for the user, but they do not prevent them from completing their tasks. For example, for the cross-browser printing problem, the user can always click on the print button in the browser window (if there is one and it is enabled) or go to the File -> Print command (if there is one). But, if I provide the user a HTML print button within the content that they wish to print, there is little ambiguity as to what to do to print the page, and therefore little chance for user annoyance when they can't figure out why the print button isn't enabled on the browser or why they keep printing your navigation bar (if you're using frames), etc.
Although users may expect some annoyances in general while using the web, I think the subjective user experience can really begin to decline when several QOLITEs are encountered in a single site/application. And more importantly, I think that when the user can tell that the site/application has attended to these details and removed the potential for these little annoyances, users are genuinely pleased and appreciative of the effort.
© Internet Technical Group
Last update: December 12, 1999
hosted by Sandia National Labs
Disclaimer: Neither Sandia Corporation, the United States Government, nor any agency
thereof, nor any of their employees makes any warranty, express or implied,
or assumes any legal liability or responsibility for the accuracy,
completeness, or usefulness of any information, apparatus, product, or
process disclosed, or represents that its use would not infringe
privately-owned rights. Reference herein to any specific commercial
product, process, or service by trade name, trademark, manufacturer, or
otherwise does not necessarily constitute or imply its endorsement,
recommendation, or favoring by Sandia Corporation, the United States
Government, or any agency thereof. The views and opinions expressed herein
do not necessarily state or reflect those of Sandia Corporation, the United
States Government or any agency thereof.