Re: Caching data returned from POST, and conditional POST

Shel Kaphan writes
>Are your usability studies in the paper you cited earlier?  I'd like
>to see them.  I can believe there are some situations where what you
>say will work, but I can also give examples where it won't.  The usual
>shopping basket example suffices.  If you have a search form followed
>by a "put this in my shopping basket" form, and the user backs up to
>the search form to select another item, and finds that the first item
>is no longer in the shopping basket, I guarantee they will not find
>that to be intuitive.

Shel, following our discussion, I've spent some time puzzling out the
various possibilities and came to similar conclusions, i.e. that
different interpretations make sense in different situations. It
depends on the user's model of the situation -- for example, who 'owns'
the data -- do they see themselves as making changes to a remote database
or just analyzing data they are going to store later. Our studies were
carried out of a system where the state information is carried entirely
within the form and the server remains stateless. Users generate a lot of
data through successive transactions and want to preserve it
so they see themselves as the owner, and the form stored on their machine
is their data file. We never mentioned undo but our observations and analysis
of the logs show them undoing transactions by using "Back" -- the paper
explains how "Back" acts a multi-level undo but doesn't present the
observational studies.

However, I can also envision a situation in which user goes back either
to "undo", or conversely to "repeat" a transaction (repeat because he or
she remembers that the earlier screen had just the right data). I'm sure
I could create a system where some users did one and others did the other,
both finding it the natural thing to do. In such a system the server
should be designed to query the user to resolve the ambiguity, but it
shows that "Back" can be used in several ways as you suggest.

I also realized that reposting the same transaction might seem strange,
but in TP this is a common situation -- an order or invoice or booking
gets sent more than once and the system must detect the situation. It
is simple to detect a repost because the server generated the form and
can store an ID indicating what transaction sequence it belongs to.

The reason I was in favor of Netscape's behavior in validating "Back"
was that a document sent back to the browser may contain time/state-
sensitive data as well as transaction state. For example, I may send
the current DJ index as well as a stock order form. Whether the user
expects to find the latest value when they go back or is checking on the
old value is an interesting issue. It should be part of the system design
to determine which will occur, and it is also part of the design to project
this to the users.

What is happening in all this is that the web has become capable of
supporting heavy-duty TP systems and that raises issues of system
design, integrity, etc, together with user training, usability, etc.
It would be nice to think that one could design new forms of TP system
that preserved some of the pleasant side of web culture, informality,
user control, etc, rather than just resurrect CICS.

best wishes for the new year, b.

Dr Brian R Gaines               Knowledge Science Institute
                                University of Calgary         Calgary, Alberta, Canada T2N 1N4
403-220-5901  Fax:403-284-4707

Received on Sunday, 31 December 1995 19:02:41 UTC