[thelist] [Usability/Javascript] Client-Side Form Validation - Pros & Cons?

[Frank]

At 07:46 PM 10/18/2002 +0530, you wrote:
 > We always do server-side validation and I opine that we
 > should be doing client-side validation to save on that
 > "one-trip return" lag in the event there are required
 > fields missing or there is an error in input.

 > We always use the forms to not rely on JavaScript to be
 > functional but at the same time to take use of the added
 > functionality if JavaScript is enabled (majority).

I'm not quite sure what your question is. You seem to have sold yourself on
the concept and are looking for third party re-enforcement. <g>

All of my forms are self validating - on the server side *and* on the
client side. Why? Theortically I could point to blind readers, Lynx etc...
That's mere justification, developer ideological wanking. The real reasons?

SERVER SIDE: NS4.7 is a piece of junk, but is still in popular use.
Javascript can break for the simple fact that there are about a billion
different configurations. I can script to be compatible across *most*
instances, but it's simply not possible (and worth the effort)  to deal
with *all* instances.

For example, reason #2 why I validate both on server and client side. I use
a little app called "The Proximatron". It's basically a proxy server that
GREPs and re-writes downloaded pages. It stops a good number of JavaScript
functions, such as pop-up windows, moving banners, flash advertisements,
etc.. Sometimes it will cause someone's validation code to break. How do I
know that someone isn't using their own version that might break my script?
So I use server side validation as a backup, because an error on an
e-commerce page simply isn't an option.

CLIENT SIDE: That having been said, one must remember the purpose of *all*
software. To modify human consciousness. People are moving mice, staring at
cursors, and boxes and windows that are nothing more than light projected
against glass. When I write a user interface, I must make it as simple,
easy and painless for the user to fall into the illusion that what they are
doing is "in the real world".

In the real world, when you place your hand over a flame, you get instant
feedback. That's how the real world acts. This is what human neurology is
built around. Good UI caters to the animal above all. Javascript provides
for "instant" feedback. The speed of feedback to an event is "logically
grouping" action and reaction, cause and  effect, not unlike keeping a
header and snap line with a paragraph. If the illusion of "connectedness"
is upheld, the user instinctively treats it as a single chunk of
information, it's still in "wet-ware RAM" and thus becomes "easy to use". I
want that, because it allows me to smoothly slide their consciousness onto
the next process: giving my client money.

Any break in consciousness causes "distraction", a break in the procedural
trance, and creates a space for new ideas to enter. Frutstration (negative
association to the experience and client brand), a pull to move to another
link other than the "give me your money" process, etc... Well done instant
feedback keeps the user focused on the task.

It also saves on system resources.  Better to download 2k worth of JS once
that reload 50k worth of HTML, images and various images.

Should one use client *and* server side validation? The answer seems
obvious: Yes, of course. Should we exclude server side validation in
favour? No, never, unless losing money is an acceptable solution.
Javascript provides the least break in consciousness. A page reload
provides more, but is still acceptable. An error on a page, or a mishandled
situation that causes the process to cease, and leave no option of the
uninformed user no choice but to leave is simply *not* an option. If it
were, there would be no justification for creating the web site in the
first place.

My verbose two cents.



--
Frank Marion <frank at frankmarion.com>      Tel: 416 825 7488