Re: Caching data returned from POST, and conditional POST
Brian Gaines (gaines@cpsc.ucalgary.ca)
Wed, 3 Jan 1996 20:33:28 -0700
It would be nice to extend that concept and have a tag field that just
got returned. This would avoid having to tuck state info into hidden fields
under some conditions (where the user was not expected to store the state
info by saving the doc).
>I would surely like to see a serious research report which describes
>your methodology. My experience is that users use the BACK button on
>the browser to review the previously viewed material. To change the
>material viewed when the BACK button is pressed simply because the
>server state had changed is WRONG ... imagine a book with invisable ink
>which somehow has a page you just read change because you read the
>next page and flipped back. Back is not understood as UNDO from a
>transactional sense, it is UNDO of a page flip. Just as FORWARD is
>not REDO but rather flip the page forward.
You can see a paper on this at http://ksi.cpsc.ucalgary.ca/WWW/PortWeb
an application at http://tiger.cpsc.ucalgary.ca/Webgrid and a paper
on the application at http://ksi.cpsc.ucalgary.ca/WWW/CSCL95WG
I've been writing about the human factors of 'undo' for some 20 years
now. It has always been a mess. Only power users use it effectively.
Normal users try and use single-level undo to late, and are confused
by multi-level systems. What we have found on the web is that users
step back to regain a previous situation and then proceed from it.
Our methodology is always to observe actual user behavior and then
make the system conform to it. The naturalness of 'back' as 'undo'
on the web is very interesting indeed.
However, note that we are not continually undoing/redoing as users
step through the history list. It is the user action of initiating
a transaction from a past state that initiates the undo. So the user
is still using the history list to observe past states as you suggest.
It is a natural extension of that to allow them to recreate the
past state if they wish.
The key trick in user interface design is to minimize the number of
controls a user has to comprehend -- back and forward also supporting
undo is a major feature. I would not see a separate redo/undo as
a plus but rather as over-engineering the interface. The nice
thing about the web is that "back" in the history list has all
the contextual info that a user needs to understand an undo action --
it is an eminently natural way of presenting an undo capability.
If the server cannot support the undo it can just return a message
saying that, and perhaps return helpful info on alternative ways
of rolling back the transaction -- since the server can know both
the present and past states it can do a very good job of this if
appropriate.
> 3. Add via headers, response codes, methods, the ability for a
> application to control the history list. As new functionality
> I fully support the capabilities Brian and others have suggested
> to allow building better applications using generic web browsers
> by controlling the users history view. I don't believe redefining
> existing expectations is a good idea. I also believe this is a
> non-trivial activity.
This is well-addressed in the Holtman and Kaphan analysis.
>Part of this issue involves the grey area between caching and session
>history management which I have previously proposed as part of the
>agenda for the caching sub-group. Going beyond such clarifications
>seems like a longer term issue to define support for more transactional
>oriented applications.
>
Yes, it is a reasonable implementation technique for browsers to
use one caching mechanism for both, but they have very different
functions to the user. It is unavoidable that if one gets into history
list caching then one is into user models. This is the appropriate
differentiation: caching for speed/traffic-reduction should be
transparent to the user; caching for the history list has to support
the appropriate behavior for a particular user model. The Holtman and Kaphan
proposal addresses this.
I think this discussion does belong on the caching sub-list, have
posted it there, and suggest any follow-ups should go there.
b.