[thelist] targeting effectively

[aardvark]

> From: "David Kutcher" <david_kutcher at hotmail.com>
>
> Well, it's nice to see that as .jeff and aardvark have made abundantly
> clear in the last few emails they've written, they're in favor of
> doing everything that javascript is meant for on the server side.

actually, if you really read my posts, you'd see that i said that JS
should only be an add-on that doesn't block site use, and that
enhances the user experience...

if i have an e-commerce site, why wouldn't i validate on the server?
sure, i'd roll client-side validation out, but i'd make sure it doesn't
stop users from placing orders, and that when it fails, the server
takes up the slack...

> So, what they're advocating is that in essense, the majority of users
> that have javascript enabled should suffer because of the few that
> don't.  Why do they suffer you ask?  Because, instead of doing
> something so simple as a javascript validation on the client side
> where it belongs, .jeff and aardvark advocate sending all of the data

validation does not belong the client side... it has every reason to
exist there, but it *belongs* on the server so malicious users don't
fill your database with crap...  got any sites with only JS validation i
can hose to show you my point?

> to the server to be parsed, just so the server can turn around and
> send a message back to the user to tell them that they forgot to fill
> in a form element.

at least the server's doing it's job, then, when JS isn't enabled or
supported...

> Basically, by .jeff and aardvark deciding to take the onus off of the
> client using javascript (and the "moral" highground, they have
> punished the rest of the viewers by increasing server strain,
> increasing server bandwidth (lots more faulty messages), and requiring
> a user on a slower connection to have to contact the server and wait
> to get a reply telling the user that they forgot a form field.

a good UI results in less trips to the server anyway (something i've
successfully done many many times)... but yeah, i'll put that work
on the server, it's the only variable i control... i know exactly what it
can and can't do... i don't know that about my users definitively...

am i punishing those with JS?  nope, they still get the validation on
the client-side...

> Brilliant usability practices.

thank you, it is...

having experience building carts for many of the organizations you
buy your software from, i've had plenty of time to test my approach,
and since my carts are retained through backend changes, i feel
confident in my ability to do it right... higher orders, less
complaints...

because i allow those without JS to still place orders, but offer a
more refined experience for those with JS...

so, how am i punishing the user?  i'm still doing the client-side
validation, but i'm not silly enough to assume that it'll catch
everything... so the server acts as the back-up to that...