Ivan Marsh said:
Since I don't restrict user input at this level, I've never had any use
for an onPaste handler. I only audit input onChange and onSubmit (both
for the user's convenience, only) and, of course, on the server side, to
protect the application.
So you have an onChange handler on every input field you use just in case
someone pastes information incorrectly into the field? Seems like a waste
of time and bandwidth to prevent a non-issue to me... but I guess that's
just me.
Ivan Marsh said:
I hope you stretched first, before jumping to that conclusion. You could
hurt yourself.
I have onChange handlers on fields where it will save the user
time/effort/frustration to have the value audited on the spot, rather
than waiting until they hit the Submit button.
...and you're suggesting I'm jumping to conclusions? What magical
algorithm do you use to determine those fields?
Ivan Marsh said:
I'm sorry, I confused you with that guy with years of UI experience.
Okay... so you've abandoned convention, standardization and consistency...
employed a method of development you can't explain ...
... employed a method of development you can't explain ...
Ivan Marsh said:
It also occurs to me that if you've been doing a job for 25
years and haven't internalized enough of the process that you
"just know" some things, you're not welcome on my team.
Ivan Marsh said the following on 8/29/2007 2:26 PM:
Lee may, or may not, have a "team" but some people lack tickets to the game.
Trust me... it's something I "just know".
Just wanted to rant about people who think it's a good idea
to restrict user input.
I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".
It whined that the Confirmation Code was invalid.
Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.
The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.
That's bad user interface design.
The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.
Lee said:Ivan Marsh said:
You need to decide whether or not you value your customers.
If you do, you should do everything you can to make their
experience pleasant, or at a minimum, free of frustration.
That doesn't mean that MAXLENGTH is a bad idea. As a /user/, it
infuriates me when I enter my entire ZIP code and then later get a
message back from the damfool server saying that it wants only the first
five digits.
First, you're implying that the Confirmation Code was supplied by the
web server or the system behind it. Can you be certain that spaces are
not significant?
Second, the code is a security feature. Perhaps the designers decided
that it should be input very carefully. It might be a genuine design
decision, even if not what you would do.
Third, a better solution is to have a 12 character field and let any
redundant whitespace characters be discarded in the server.
Incidentally, my credit card has a space between each group of four
digits, but web servers won't accept the spaces. Grrrrr.
<snip>John G Harris said:
Client-side audits are good when they make things easier for
the customer. It's probably easier for them to be told that
they left off a digit immediately, instead of waiting until
after they've submitted the form. By then they may have
closed whatever they're copying it from.
<snip>
Note that I'm suggesting that the form field should be longer than the
longest Code value. In your case the copy-pasted Code would have gone to
the server unchanged and been accepted as correct. There is nothing
useful any client code could do.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.