Wandering Thoughts archives

2012-06-11

What bits of a form are useful to check on the client side

I spent part of today adding more JavaScript to our account request system, in the form of some client side form validation code. As part of this I wound up considering which bits of form validation are worth doing in the browser.

Of course, for some people the answer is 'all of them'. This may be justified or worthwhile in some environments, but my view is that I don't have the time or energy to write a second copy of form validation code (and any needed backend services to support it) for all fields. Until the day comes when I can write one set of validation code and have my framework magically generate both client side and server side code from it (along with the AJAX callback services necessary to support it), I'm going to need to pick and choose 'high value' form validation on the client side.

My conclusion is that the fields that are really worth adding client side validation for are the fields that people can't completely check for themselves just from inspection. This sounds abstract and obscure, so let me give a concrete example. Our 'request an account' form asks for both your name and the login that you want; on the server, we validate that you supplied a name and that the login you asked for is a valid login that is not already taken (or requested). Someone filling in the form can easily see whether or not they've supplied their name, but they have no way of knowing whether or not the login they've picked is already taken. Client side validation of the login gives people immediate feedback on this without them having to go through the slow process of form submission and examining the results. As a side effect, it lets them check several different logins so they can pick the one they like best (because, unlike form submission, they are not committed to a choice that the system accepts).

(By contrast, client side validation of the name field would just be telling people 'hey, the name field is still blank', which is something they can see for themselves if they look.)

A related approach would be to figure out what problems the submitted forms are most likely to have, on the grounds that these give the highest payoff from early detection and feedback (in the form of users having to go through fewer cycles of 'submit form, get errors, try to fix errors, repeat'). I think that this is going to get you more or less the same results unless your form is unclear (or confusing), but the advantage is that if you wanted to you could drive this from logging actual validation errors on the server.

(This is obvious but worth saying: client side validation is never a replacement for server side validation, it's only a supplement. You always have to have full server side validation, so the question is how much immediate in-browser validation you add on top of it.)

web/WhatToValidateClientside written at 23:27:59; Add Comment

Choosing how slowly your mailer should time out email

Here's a little provocative question: why should mailers have timeouts on email delivery at all? Wouldn't it be more helpful to users to never give up on a message?

In practice, there are at least four reasons to configure your mailer to expire sufficiently old messages:

  1. some hosts or domains will never accept your email; they are permanently unresponsive (sometimes in general, sometimes just to you).

  2. there's so much unexpired old email in the mailer queue that it starts causing problems for your mailer or the system in general.

  3. sysadmins get irritated when they see huge queues of (so far) undeliverable email; among other things, it's clutter.

  4. expiring and bouncing the message is how the sender gets a copy of their email back so they can do something else with it.

    (This is a pretty weak reason these days, since in today's world most people's mail clients already keep a copy of all of the email they send.)

The latter two reasons are relatively uncompelling, which leaves the first and the second as the primary drivers of email expiry times. And it's really just the first reason, because if you need to set email expiry time based on the second reason you probably already know it because your system has likely exploded under the load of too many old messages.

(I suspect that not many sites send enough email that the second reason is a serious concern. And if it is, there's a bunch of technical measures you can take to reduce the problem.)

The challenge with the first issue is telling the difference between a host that's temporarily down (or unreachable or experiencing problems) and a host that's permanently unresponsive. If we could do this reliably, the right thing to do would be to immediately bounce email for permanently unresponsive hosts and never expire email for hosts that are temporarily down. Since we can't, we have to go with a heuristic: we assume that hosts that have not accepted the email for N days are most likely hosts that are permanently unresponsive.

What's the right value of N? On the one hand, that's a good question. On the other hand, it's the wrong question because this is a heuristic. Heuristics generally do not have a single 'right' answer; instead they have a whole spectrum of answers depending on your specific circumstances (and in this case also depending on what the destination is; for instance, you might know a bunch about this for email inside your organization).

However, we can turn this around by asking what's a reasonable amount of time to expect a temporarily down mail machine to stay down before it gets repaired. My view is that there are reasonable circumstances where a mailer can be down for four or five days at a minimum. If this strikes you as extreme, consider a small organization where the mail machine dies on the afternoon or evening of a long weekend; take three days for the long weekend itself, and then they could easily lose a day or two to getting a new machine and configuring it.

(The extreme case around here is a small department who has their mail machine die just as Christmas vacations start. If they have no spare machines, getting a new server delivered might not happen until two or more weeks later, after Christmas vacations are over and the buildings are open again.)

So if you need a simple number that is not too large, my answer would be 'at least six days'. As it happens, our current mailer configuration times out email to outside domains after six days (more or less), although I don't think we did this sort of thinking about the issue before going with that number.

sysadmin/MailerExpiryTimes written at 02:11:26; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.