"Kirkdorffer, Daniel" wrote:
> You know the only problem I have with some of what Craig is saying below, is
> that I think that we should stop trying to fight the platform, and start
> developing for it. By that I mean we are developing "web" applications, so
> they should work with the environment they reside in, the web browser, and
> take advantage of the features of the browser. Don't just think of this as
> recreating the legacy interfaces they're replacing. The whole concept of
> controlling sequence of movement to me is a bit constraining in such an
> environment. Users should have more freedom than what they had on a 3270
> terminal 10 years ago, but it would seem that's not what people are willing
> to provide.
>
> That's not to say I'm discounting the challenge.
>
> Just my .2 cents.
>
> Dan
>
I can sympathize with Dan's feelings, and even agree with them to a degree.
But it seems to me that (for transactional processing or other state-dependent
applications, at least), we are having to fight with the platform quite a bit
already:
* Why should a servlet/JSP author have to mess with session management
in the first place? Because HTTP is stateless, and doesn't support it.
* Why do we have to curse HTML (and browser developers) trying to get
halfway decent looking screen layouts? Because HTML was not designed
for this, and the recent innovations to help (DHTML and stylesheets) are
still implemented incompletely, incompatibly, and with lots of bugs.
* Why can't we build "interactive" apps like you can with a GUI, where
the UI changes dynamically as you're inputting things? Well, this is
changing with DHTML, but we're not there yet. In the mean time,
designers are constrained to the frame-at-a-time sort of style that
typified 3270 screen-at-a-time applications.
* Why can't I disable screen controls like Back and Forward when their
actions are not relevant? Because there's no standard mechanism to
make this possible. It's only becoming possible to even disalbe a
text input field, or a check box, when it's contents are not relevant.
The whole concept of GUI interfaces was created to improve on the 3270 terminal
style of interaction, and it made a huge difference. But if you look a little
closer, you see that well-written GUI apps are often still very modal -- they
enable and disable screen controls (menu options, buttons, input fields, and so
on) on the fly. It just looks a lot prettier. If I could do that with HTML,
I'd feel a lot better about leaving the screen controls visible.
But the real key goes back to the requirements of the application -- no matter
what media you use to present it. Some apps require logical steps to be
performed in a certain sequence. With a 3270 app, or a client/server GUI app,
that's pretty simple to enforce. With the current generation of browsers,
that's a lot harder to do technically, and ths problem is excaberated by the
fact that users are used to navigating at will around web sites, and that is
their mindset whenever they sit down to a browser.
Yes, you can (without too much pain) make your web app recognize what state it
expects, and politely complain if the user does things out of order (much
better than crashing :-). But I don't think that is what Dan was getting at --
it really starts with application design. If your application can be designed
to be reasonably stateless, then by all means do so. But if you can't, you
still have to enforce modal behavior as required -- and the fewer chances you
give users to make a mistake in the first place, the better off you're going to
be.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
