Email Forms: Slient and Deadly

By Deane Barker • January 11, 2006 • 1 min read •

AI Summary

This post explores the challenges and pitfalls of using email forms on websites. The author highlights issues like spam, deliverability problems, and user frustration, ultimately advocating for alternative solutions that enhance communication without the drawbacks of traditional email forms.

I really hate email forms, from a developer perspective. Meaning, I hate forms that just email something somewhere and then forget about it.

The fact is that email is a horrifically dodgy medium to do anything with. Two-and-a-half years ago, I complained about Barnes and Noble doing this. A customer service form on that site apparently just sent an email, which didn’t get delivered, and I got “Message Delayed” messages back for two days.

And this is how email is – sometimes it just doesn’t work. It’s like a forward pass in a football game. The quarterback may intend to get the ball into the hands of the receiver, but the reality is that once the ball has left his hands, it belongs to anyone. It’s up for grabs until it is safely delivered into the arms of the receiver. Sure, it’s probably headed in the right direction (unless your quarterback is Kerry Collins), but it’s a crapshoot until it actually gets there.

The problem with accepting user input then just emailing it is that stuff will break, and then your data is gone, man. Mail servers can stop running, mail can get sent and just get lost, or it can get sucked up by spam filters.

And the big problem with losing email like this, is that it generally happens silently. You usually don’t find out anything is wrong until a few days later when someone calls and say, “Uh, we haven’t gotten anything from the Web site in a while…” And, by that point, how many are you missing? How much user input is gone? And can you even figure out who entered something so you can contact them and get the data again? Not usually.

What I’ve learned is that you still have to persist the form data on the server, even if you’re emailing it. This can be as simple as just serializing the data somewhere safe with a timestamp, so that if email starts vanishing, you can go back through the data and figure out at what point you stopped receiving stuff, and recreate what’s missing.

Usually, you can serialize the entire POST, but if you’re doing server side validation and the POST can get submitted more than once, you need to remember to delete what didn’t make the final cut. A more efficient route is to just write the body of the email you send to a text file with a timestamp in a directory that isn’t URL-addressable.

In a perfect world, you’ll never have to touch it and it will just sit there and accumulate. But this ain’t a perfect world, and having it is really handy when something goes bad.