CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stewart Walker <[log in to unmask]>
Reply To:
Date:
Tue, 9 Sep 2003 11:27:31 +1000
Content-Type:
text/plain
Parts/Attachments:
text/plain (159 lines)
ORIGINAL POSTING

In a web app to be deployed via our intranet, when a user clicks the
browser's Back button a Page Expired message appears rather than the user's
previous page. In other words, the normal Back button behaviour doesn't
happen.

When I asked the developer about this, he said he did this deliberately to
avoid data integrity errors. However, I'd like the app to allow users to
use the Back button to go back to the previous page in the way they
normally would.

Has anyone come across this before, and if so, what (if anything) have you
done to work around it to preserve the normal Back button behaviour?


SUMMARY OF RESPONSES

Thanks to all who responded. There were two types of responses: possible
solutions and general comments.


POSSIBLE SOLUTIONS

esherman@healthmedia.com...
It's avoidable -- you just have to make sure the previous page is not
generated by a form submit, and that no-cache and expires=now are set.
Instead of submitting a form to the next page in a sequence, I submit forms
to the current page. The current page processes the form data and redirects
the browser to the next page (response.sendRedirect in java, or editing
Location in the HTTP header in php or whatever -- not a meta-refresh!).
Clicking on Back in the browser sends the browser to the previous page;
since no-cache and expires are set, the page is reloaded by the browser.
Since the page is not generated from a form submit, there is no expired
warning. Data is not old and data integrity is not an issue; when the page
gets reloaded, it pulls data the person entered into the form from the
database or session (or whatever it's been saved) and displays it.

Carolyn Divish ([log in to unmask])...
We had this problem too, and we solved it by putting all data entry pages
in a pop-up format.  So when the user clicks an "edit" button, a new modal
browser window opens on top of the main window.  The back button still
works on all the pages, but the user can't back out of a wizard and has to
finish the data entry pages before returning to the main window.

Bennett Lauber ([log in to unmask])...
The best solution is to push a URL to the Java.history that performs what
you want it to do.  Hitting the back button will
then navigate the user to that URL

Martin Hensel ([log in to unmask])...
If you can ensure that all users have JavaScript enabled, you can set
a hidden field when the user leaves the page, i.e. on clicking a
button or a link. OnLoad you can test if the field is set, which will
be only the case if the user pressed the back button. Reset the field
then and call a refresh.

Unfortunetely, when the page request included post data, most browsers
ask if the user is sure to send it again. I was not able to get rid of
this dialogue yet.

A system to avoid double actions on refresh should be implemented
anyway, however it mustn't produce an error message here.

The system doesn't work properly if you change data on the same page.
A user who is at a catalogue, clicks on checkout and 'remove item'
will be still at the checkout if he clicks back once. (He must click
twice to go back to the catalogue).

Be aware that many users try to use the back button as an undo button.
If the user clicked 'remove item'. He may click back with the
intention to undo his action rather than to go back to the catalogue.


GENERAL COMMENTS

Elizabeth Buie ([log in to unmask])...
I have seen it lots of times as a user, and as a user I hate it.

Andy Dent ([log in to unmask])...
I'm fairly certain this is a result of choices about your web app
architecture made by the developer. It should be possible to avoid this.
However, it may be too late. I would consider writing the requirement
for the application to support the browser Back button into the next
project.

Ash Donaldson ([log in to unmask])...
There's a simple concept called 'maintaining state' (that developers often
seem to avoid),
where the application 'remembers' what the user input on the previous page.
Developers often
avoid this as it means more thought is required as to how to re-structure
their code - but if
it's designed for in the first place, it's not that much overhead and
provides a much better
user experience (matching expectations to the application).

I've said it before and I'll say it again - if it looks like a browser it
must ACT like a
browser.  If someone deems that a 'web app' (something of an oxymoron in my
books) is
necessary, they have to work around the inherent limitations and make the
app work like the
browser.

John Malhinha ([log in to unmask])...
Seems you've run straight into a usability crossroads: sacrifice the back
button in favor of data integrity or activate the back button & run the
risk of having the user submit information twice and/or corrupt the data
captured. IMO, I've always thought that the use of the back button is not
warranted in all cases and that having clear navigation (like breadcrumbs
or a heirachy trail) would help lessen the need for the back button.

If it's simple one page form submit, is there a need to have the user go
back? Providing access points on the submission page would help bring the
user back to his/her page of origin, and not create any loss of placement
within his/her path.

If it's a wizard process, where it's a series of mutiple forms leading a
user through a process, I've used a combination of a "back button" within
the page where the developer can control the form logic and re-display the
preceding page with the data keyed in. Also, listing a series of steps, w
links to jumping back to the any of previous steps ("oh, I think I entered
in the wrong phone number again. let me go back and fix that.") allows them
to jump to any previous page in the process.

All in all, I think if you fight to keep the Back button functioning,
you'll run the risk of implementing a series of "catches" in order to make
sure the user knows he/she is viewing a page previously submitted
information and that any interaction on that page could affect what he/she
previously submitted. It could turn into a usability quagmire. Providing
them easy to follow, clearly expressed alternatives might be the safer
route. Users can easily adapt to not using the back button if that's their
preferred method of navigation. They have to do it elsewhere across the web
world.

Worse come worse, test them out. Let your user base dictate what they would
prefer. Being an intranet app, you've got quick easy access to your exact
users. Nothing better than that.

***end of summary***
_________________________________________________________________
The information contained in this email communication may be confidential.
You should only disclose, re-transmit, copy, distribute, act in reliance on
or commercialise the information if you are authorised to do so. Any views
expressed in this email communication are those of the individual sender,
except where the sender specifically states them to be the views of a
member of the National Australia Bank Group of companies.  The National
Australia Bank Group of companies does not represent, warrant or guarantee
that the integrity of this communication has been maintained nor that the
communication is free of errors, virus or interference.

    --------------------------------------------------------------
           Tip of the Day: Postings must be in plain text
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------

ATOM RSS1 RSS2