Attack
of the Back Button
by John
S. Rhodes
Summary
Getting stuck on a
web page can be painful. The back button doesn't always work. While there
are many ways to escape from web pages, many users don't know the tricks. A
company can stop hurting users by doing more testing, using proper
development methods, and being aware of the issue.
Back Button Pain
I really hate
getting stuck on web pages. It is annoying when the back button is disabled,
or seems like it is disabled. This can happen for a variety of reasons but
the net result is the same: frustration. If you have spent any amount of
time on the web I am sure that you have been stuck on a site at least once.
It happens to me a few times per day. What a pain! If you don't know what I
am talking about and you want to get stuck on a page, try Couloir.org.
However, I suggest that you read this article before you make your visit.
On 20-June-2001 I
decided to talk about this topic. I said that the best way I have found to
get around this trap is by clicking on the Back button drop-down menu. I said that you can also move back a page by using the
right click context menu. That won't always work because developers can disable
or change
the menu. This is a shame because the back button is the lifeline
of the web user.
I decided to ask
WebWord readers if they knew about the Back button drop-down menu. You can still take
the poll and see the results.
Most people reading this article know how to use the Back button drop-down menu,
but interestingly there are some folks that didn't know about it. Average
users often don't know how to effectively use a web browser. In many of our
usability tests, users who get stuck on pages simply close the browser
window. They are angry and frustrated. They don't know how to right mouse
click or utilize the Back button drop-down menu. And, they don't tend to spawn
new windows (i.e., holding down the shift key while clicking on a link will
spawn a new window in Internet Explorer.). They don't tend to copy and paste
URLs. The bottom line is that most users generally have to go back to a
portal, search engine or major web site to find what they want.
Specifically, many users have to return to a top level page and navigate to
the page again. They have to start over. Argh!
WebWord Readers Respond
When I posted my
thoughts on WebWord, I didn't think much about it. However, for some reason,
I ended up getting a lot of email about this topic. Below are few valuable
emails.
Reader AJ writes:
John, regarding your link to an article
about creating a back button, the article misses the simplest method for
creating a "previous page" link - Server Side Includes. SSIs are
choice because they are not dependent on the user having javascript, etc.
SSIs spit out straight HTML.
If your web server supports SSIs, try
sticking the following code into a web page, then clicking a link to
arrive at that page. (You might need to rename the file extension to
.shtml, depending on how your server is configured.)
Return to <A HREF="<!--#echo
var="HTTP_REFERER"-->">previous page</A>
The above code should create a link
that returns the user to whatever page he came from, even if he came from a
search engine. It fails, though, if the user arrived at the page directly by
typing in the URL by hand.
If you are fortunate enough to be using
an Apache server with "eXtended Server Side Includes," you can
create a "smart" back button:
<!--#if expr="${HTTP_REFERER}
=/webword/" -->
Return to <A HREF="<!--#echo
var="HTTP_REFERER"-->">previous page</A>
<!--#else -->
Return to <A
HREF="http://www.webword.com/">front
page</A>
<!--#endif -->
The above code checks to see that the
previous page the user came from was indeed a WebWord page. If it was, the
link is generated with the words "Return to previous page," and
the link will lead to the previous page.
If the user came to the page from an
off-site location, the link will instead say "Return to front
page" and the link will lead to WebWord's front page.
The beauty of xSSI is if a user looks
at the source code, there is no indication how this magic was done. It's all
assembled server-side before the page is shown to the user.
To supplement AJ's email, here are some resources:
Reader AE writes:
A little known javascript trick, for
3.0+ browsers, instead of using document.location, use
document.replace("url") and the page from which the command is
executed will not be entered into the history. Good one for the
toolchest.
To supplement AE's
email, here are some resources:
Reader CN writes:
I think that the majority of sites that
disable the back button do it unintentionally. Like http://www.couloir.org
where the first page (index.html) contains a canned Dreamweaver script to
check the browser version before forwarding you on to the first content page
(main.html). The same problem is caused by lots of flash detection
scripts. The script sets the javascript location (or location.href)
property which loads the new page instead of location.replace() which does
the same thing but also removes the current document from the history
list. The practical upshot of this is that if the location approach is
being used and you hit 'back' from main.html, you get taken to index.html
again and the script re-executes and kicks you forward to main.html
again. If location.replace() is used, the back button takes you to the
page you were at before index.html. I'm surprised canned scripts don't
use location.replace() - the problem would be less ubiquitous then.
There's no real good reason to disable the back button. The situation
used in the "sometimes it is important to disable the back button"
isn't a good example. It's more effective to prevent the browser from
caching a form submission page instead of relying on javascript to block the
back button. As for getting around other people's disabling of the
back button, I have bookmarklet on my links bar that uses javascript to go
back 2 pages - saves 0.3 seconds over the back drop-down. :)
CN has more
comments on Dithered. I suggest that
you visit link
one and link
two to learn more.
To supplement CN's
email, here are some resources:
Final Comments
It is easy to
abuse the customer experience. It is easy to alienate users. It is easy to
frustrate people. Technology often gets in the way of itself. Developers and
designers accidentally build tools that are hard to use and understand. If
all users understood the Back button drop-down menu, right click context
menu, and Shift+click to open new windows, life would be better for
everyone. However, people don't have time to become experts, even with
simple tools such as web browsers.
I hope that you
learned a few things from this article. Now you must pay for this content.
It is easy to do. Simply visit
the discussion board and then share your thoughts, ideas, and code. Let's
help each other. I'll see you there!
Additional Reading
What next?
|
