Steve Dirickson writes:

>And so we come to the real hurdle in getting to browser-based apps:
>not the user-browser interface, but the server-browser state
>negotiation: who keeps track of what, where do they keep it, and how
>do they share it? As Lars has mentioned, maintaining that state using
>current technology is not for the faint of heart. And as Richard
>points out, for developers used to the paradigm of
>   a server that maintains a lot of state information,
>   a client that is little more than an infinitesimally intelligent
>(but fast!) piece of paper, and
>   a "do this, don't do that, <trivia: what goes here?>" interaction
>completely controlled by the server
>the browser-style app requires some distinctly non-trivial changes to
>the usual way of doing things.

Apple's WebObjects solves the state problem very nicely by making sure
that the same object that painted the page is also called to process a
GET or POST from that page. This is more than just saving session state
(which it does as well); it creates a logical "hard link" between the
browser and the code. The result is that programming for the Web with
WebObjects feels very much like programming for VPlus. State variables in
the program can be tied directly to input fields on an HTML form: when
the user hits the Submit button, your variables magically fill with data
from the form, just as in a COBOL/VPlus application. WebObjects also has
a very nice way of handling repetitions, such as data-driven multiple
table rows -- even when the repeated rows have input fields.

There's a catch to this in that a programmer who takes full advantage of
WebObjects makes the browser app feel less like a browser app to the
user. The real problem here is the "Back" button. To really pretend to be
in a VPlus-like environment, the programmer can ask WebObjects to turn
off page caching in the header. This forces a repost when the user hits
the Back button. WebObjects detects the repost and returns the form in
its current state, thus preventing the code from being confused.

However, this now means that the *user* is confused. She has put an item
in her shopping cart, hit submit, decided that she doesn't want the item,
and rather than using the "delete" checkbox or "remove" button you've
provided for the purpose, hits Back instead. The browser responds by
making a trip back to the server, which repaints the page according to
the current state, showing her the form with the item still on it. This
accurately reflects the program's state, but isn't what the user
expected. While there are ways of avoiding user confusion in the
shopping-cart example (too complex to discuss here), there's no
completely general way out of this: the user may view Back as an Undo,
but some operations can't be undone.

Over the past six months, I've been working on a school management
application that's browser-based using WebObjects. Since what's usually
considered the "hard part" -- state management at the session and screen
level -- is a nonissue, I've been trying to design better Web-based
interaction strategies for those cases where the program has state and
the user's task has state. (Batch data entry with a computer-checked hash
total is a typical example.) Designing HI storyboards for the Web is very
different from designing them for VPlus or for direct GUI interaction.
You have to figure out all the things that the user would be able to do
by backtracking through the cache and make sure that you provide
non-backtracking paths to accomplish those same things.

In addition, you have to put much more effort into leading the user into
doing the right things in the right order. If you don't, the user will
resort to backtracking, dual-window and other tricks that at best will
confuse the user as he fights your state management, and at worst will
confuse your state management. (The latter is worse because you're now in
the position of telling the user you did something different than what
you actually did.)

Ah, progress.

-- Bruce



--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback AT optc.com                |     -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *