[NCLUG] html form to email cgi advice

Chad Perrin perrin at apotheon.com
Mon Feb 20 15:06:40 MST 2012


On Mon, Feb 20, 2012 at 03:24:40AM -0700, Anthony Foiani wrote:
> 
> > On Sun, Feb 19, 2012 at 09:29:33PM -0700, Anthony Foiani wrote:
> >> Almost all of your reasons have to do with the ease of the server /
> >> provider side; my complaints with your reasons are mostly on the
> >> consumer side.
> 
> Chad Perrin <perrin at apotheon.com> writes:
> 
> > Sometimes, making things easier on the provider side means helping
> > the provider actually provide better service.  Do you expect better
> > service from the company that can quickly sort incoming messages and
> > ensure they get to the right people, or from a company that has some
> > minimum-wage part time high school student hired on the advice of a
> > middle manager's brother (who has high hopes for his son, who's
> > "real good with computers") that can't legally even work enough
> > hours to handle the volume of email the company gets?
> 
> Ah, strawmen.  Love 'em.

You brought up the minimum wage so-and-so argument.  If it's a straw man,
it's your straw man.


> 
> > I don't know of much magic involved in filling in these fields:
> >
> >     Name:
> >     Subject:
> >     Email Address:
> >     Message:
> >
> > . . . and pressing the "Submit" button sure doesn't seem very difficult
> > to figure out, either.
> 
> But the original query involved attachments as well.  Even gmail has
> issues with this -- their default is to use flash to make attachment
> uploads work "in the background", but there's a fallback for "pure
> HTML" synchronous uploads as well.
> 
> I doubt that most organizations have the wherewithal to implement this
> level of competency and fallback, yet everyone that participates in
> the email world (meaning, most people online for the last 15 years)
> has a resource that already does that for them.
> 
> Also, see below for my observation that your proposed form of "from /
> subject / message" provides no more structure than a free-form email,
> which invalidates pretty much all your other comments.  
> 
> (Except, possibly, the "we might reply to you if you jump through all
> these hoops" one.)

You make assertions here for which you have no support.


> 
> >> If you start doing things like "go through a big form, then answer
> >> a captcha to send us mail", you're saying "our time is more
> >> important than yours."
> >
> > By contrast, you could just say "Screw it.  Don't contact us,
> > because the last time we posted an email address on the site it
> > brought our mail server to its knees.  Good luck!"
> 
> Once again, that's a provider / service problem, not a web UI or
> consumer issue.
> 
> I never said "don't give any contact info".  I said "give a simple
> email address".

I know you didn't say "don't give any contact info", but sometimes people
just aren't going to do that, and for very good reasons, and your answer
to them is "don't use an alternative" -- which leaves us with "don't give
any contact info" becaues you're not going to convince someone to do
something that eats up ungodly amounts of time and loads everyone up with
frustration.


> 
> Shall I insert an ad hominem here, about your reading comprehension,
> taking things to extremes, and inserting unspecified extra issues into
> the topic at hand?

Shall I insert some observations here about how you're just not getting
it, then blaming me for your lack of ability to grasp reality?


> 
> >> > 3. Where contact is utterly useless without specific information
> >> >    being provided, a web form provides a way to require that
> >> >    specific fields be filled out.
> >> 
> >> And then those pulldowns ...
> 
> > Anyway, I never said anything about product selection pulldowns.
> > That's your contribution, and not mine.
> 
> They're a logical consequence of narrowing the possibilities of
> entries.

It is if you ignore the fact that sometimes people know how to think for
themselves, and do not always just run to utterly ludicrous extremes so
they'll fit your view of how best to make them look stupid.


> 
> You were the one that mentioned web forms as providing structure; if
> your structure is nothing more than "from / subject / body", then
> you're not providing any more structure than a raw email, and this
> entire branch of your argument falls apart.

Incorrect.  Asking for a "subject", for instance, does not mandate that
the information typed into that will be the Subject: header of the email.
It just means that your form handling script will have the information of
what the sender thinks is the salient thesis statement for the
communication, and can store that summary wherever you want it stored.


> 
> In my experience, "making the incoming queries easy to parse / file"
> means that things like "subject" (or artificial extensions such as
> "category") are provided by pulldowns.  If I'm lucky, the provider had
> the foresight to offer "Other" for covering the weird corner cases.

In your experience, then, you deal with people who are going to do things
wrong no matter what form of contact they offer, and no amount of
mandating they use email addresses on web pages in plain text is going to
change the bureaucratic nonsense going on behind the scenes.  You've
solved nothing.


> 
> > [lack of updates to pulldowns being] a problem with the management
> > of the site, and not with the usefulness of email forms.
> 
> Oddly enough, the use of a raw email address and a bit of human
> sorting on the incoming side allows for such an upgrade to happen
> transparently.  Amazing.

Oddly enough, you ignoring good points in favor of repeating yourself in
a sarcastic, condescending tone doesn't actually make any meaningful
counterpoints.  Amazing.

It's amazing that you don't even give me anything worth countering.


> 
> > Automation of certain types of contact handling can *help* provide
> > better customer service.  If you get an *immediate* receipt email
> > [...]
> 
> Raw emails can provide receipts with even less effort than coding a
> web form.

. . .

Good job, there, intentionally not getting my point.  Yes, I believe that
was intentional, and not just stupidity.


> 
> > assuring you that your email was properly forwarded to someone who
> > can respond to it [...]
> 
> Which I'll believe about as much as any other announcement from a
> faceless corporation.  That is to say, not at all.
> 
> What I do believe is that my input has been entered into some system
> where the lowest-cost provider will eventually try to reply to my
> needs by echoing a script.  Said script is intended to help some
> people, while (hopefully) providing some escalation / clarification
> path for those that are not helped by the script.

Well, that's just good sense (not believing them).  Faceless corporations
screw customers, regardless of what means of contact they offer.  You've
still solved nothing.

What I assumed we were talking about was organizations where someone
cares.  If you're talking about organizations made up of bureaucratic
drones and office politickers, then I'll just bow out with something like
"Sure, you can suggest any policy you like.  It doesn't matter, because
nothing will change."


> 
> I do not see any difference in this behavior between "fill in the form
> in detail then click 'submit'" vs. "just send us an email and we'll
> try to figure it out.".
> 
> The latter tend to have much more humane scripts, however, and if the
> responder has been there any amount of time, they can often apply
> human learning and insights to short-circuit the process.

Citation needed.


> 
> And the former takes more time -- often much more time, as many of
> them end up requiring registration or other hoops.

Tell me how getting an automated receipt email takes longer than waiting
until the next business day to see if someone emails you back saying
"Thanks for the email, we'll look into it."

Never mind.  Don't tell me, because I know the answer: "It doesn't."
That was rhetorical.


> 
> (E.g., if I take 15 minutes to go through a complicated form to select
> exactly which product is involved, then get my message added to a
> queue which is then examined 48 hours later by some other automated
> script, then I might eventually find out that the particular product
> is prone to a certain failure scenario.  Sending a more general e-mail
> to a human, there's a much better chance that such a failure cluster
> would be spotted quickly.)

A fifteen minute complicated form is beyond absurd, and anyone offering
that kind of craziness to send a message is incompetent to handle emails
by hand competently, so you've still solved nothing.

. . . speaking of straw men.  Your commentary is full of them, but I
still take the time to offer token "no, that's silly" responses so you'll
hopefully learn something from the experience.


> 
> > response within the first couple hours.  Such autoresponses can also
> > be used to give more useful information for how to help customer
> > support help you, for that matter.
> 
> ... which still says "our time is more important than yours: please
> spend more of *your* time making sure you've jumped through *our*
> hoops, before we deign to reply to your missive."

Yeah -- 'cause nobody ever wants to learn more.

You're just a luddite looking for excuses to complain about technology.
Admit it.  I can't even imagine a reasonable human being who doesn't fear
technology saying these things that you're saying, as if using technology
to expedite the process somehow automatically means everyone gets
screwed.


> 
> > $10/hr to do initial parsing, classification, filtering, et cetera
> > -- tasks that can be just as easily (and probably in a less
> > error-prone manner) accomplished by an automated system -- is a
> > ludicrous expense more worthy of luddites than of people who want to
> > actually help their customers.
> 
> Except it's not automated.
> 
> You're asking your customers to do your work for you.

I'll be perfectly clear:

HOW the FUCK is "fill out this ten-second form, as opposed to a
ten-second email plus thirty seconds of dicking around with an email
client, and hit Submit" asking the customers to do all of my work for me?


> 
> That's rude and lazy.

It's ridiculous BS invented by you because you can't bring yourself to
have an honest discussion.  You ignore 90% of what I say and twist the
other 10% into something totally unrecognizable, then attack that based
on your fear that someone somewhere is conniving to use a web form to
ruin your life.  It's maddeningly unreasonable.


> 
> > No, of course not -- because I don't use email forms to
> > inconvenience users.  I use them to ensure that things are handled
> > more efficiently.  If you're using them to inconvenience people,
> > you're doing it wrong, which may be due to a severe lack of
> > imagination on your part.
> >
> > Who says it's "bob@" anyway?  
> 
> I do.

Well, then . . . I won't hire you to handle customer support, because
you're clueless.


> 
> I have had the experience of sending mail to support at example.com, and
> getting back personalized replies (which I value and appreciate).  I
> do get concerned about replies and chains, and have occasionally added
> the original address back into the CC on the mail thread so that I'm
> not relying on a single point of contact.

That's not a webform's fault.  That's not my fault.  That's the fault of
someone who will mail back to you from "bob@" no matter how you get the
message to them.  You've solved nothing.  All you've done is wasted my
time.


> 
> (I do view this as a failure on the provider's part, but I am quicker
> to forgive such a failure than I am to deal with layers of "automated"
> "support".)

Basically, you're only willing to forgive unprofessionalism if it's from
people whose bumpkin-like handling of *electronic* mail mitigates your
technophobia.  That's ludicrous.


> 
> > What if it goes to an issue tracker so that there are a dozen people
> > ready to pick it up next in their daily work?  What if it goes to
> > the CEO of a small company as well as to one of the two support
> > people, because the CEO likes to ensure things are being handled
> > properly within a fifteen-employee company?
> 
> How does role-based email contradict such activities?  I see them
> promoting them, honestly.

Role-based email doesn't contradict such activities.  Role-based email
doesn't contradict anything I've said.  The fact I was pointing out some
of the potential benefits of automated systems in no way claims that
role-based email contradicts anything except *your* assertion that
someone named Bob is using his gmail account to respond to your support
query.  *You* are the one who claimed role-based email contradicts
anything at all beyond that.  *You* are the one who ignored my very
explicit statement that there's no prohibition against using role-based
email in anything I said, so *you* do not get to ask that question
without looking like a horse's ass.


> 
> > What if you have absolutely no idea how different companies do
> > things, and are just complaining about stuff you don't understand?
> 
> Ah, ad hominem.

I wonder if you understand how that term is meant to be used.  I find it
doubtful.  You just throw it around as if it's a way to claim some kind
of victimhood in a fallacious attempt to discredit me.


> 
> Let's see.  I've been doing email since 1986 or so, staring with IBM
> VMNET (this was before NSFNet got merged into ARPANet, and certainly
> before the true Internet came about in the early 1990s).

Good for you.  Big effing deal.


> 
> I've worked for startups, medium-sized companies (e.g.,
> musicmatch.com), and for large companies (e.g., yahoo.com).

Good for you.  Big effing deal.


> 
> I've had (admittedly, trivial) works published in The Perl Journal.  I
> had a tiny patch accepted into perl itself.

Good for you.  Big effing deal.


> 
> I managed to create a certain use case that exposed a fault in the
> Linux Kernel, and helped the linux-kernel list resolve the issue.

Good for you.  Big effing deal.


> 
> I've been active in BLUG since 1996 or so, and have given a few
> presentations (mostly on Perl).  A lack of recent physical
> participation and presentations has more to do with location (having
> left the Front Range in 2001 and not moved back) than any other
> reason.  I believe that a quick search of the archives will show that
> I do still offer helpful replies when I can do so.

Good for you.  Big effing deal.


> 
> So I don't think that I can be characterized as "anti technology".

Sure you can.  There's a point beyond which you appear to fear
automation, ascribing all kinds of mystical evils to it that have the
power to destroy anyone's ability to provide better customer service,
even in the face of very specific examples of how it can be used to
enhance customer service.  You ignore facts and logical arguments in
favor of just blindly railing against the evils of automation.  That's
pretty anti-technology.

The actual Luddites of auld were not against *all* technology, after all.
They just didn't like the new stuff that they found personally offensive
because they did not understand things like technological advancement in
a systematic way, economics, and the fact that other people with
differing goals have a right to live their lives as they see fit.  That
all fits pretty well with the way you're reacting to the idea that a web
form will not guarantee that the people who deployed it are Evil.


> 
> > Your contentious "I hate technology, and you're stupid for liking it"
> > attitude is kind of getting on my nerves.
> 
> Horribly sorry.  I suppose I should stop replying to public email
> lists.

No -- you should just stop telling people "Don't use web forms, because
they're evil, due to the way I wave my hands like this -- and you're an
idiot if you don't agree with me."


> 
> I'm not anti-technology.  I'm anti "let's make the customer do our
> work for us" laziness, compounded with frustrations I've had over the
> last 10+ years on trying to communicate with the providers of
> components that I otherwise enjoy using.

No, you're anti-technology, at least in this case, because the technology
in question is actually something that can reduce the workload of the
customer and improve responsiveness if used properly, but you pretend the
absolute opposite is the case out of some kind of utterly unreasonable
thought process that defies description or clear definition.


> 
> > Using role-based email addresses does not mean that you don't get
> > things from multiple sources in a single inbox.
> 
> So sort it and reply to it using those same role-based emails.  Again,
> the detail of which actual human (or automated system) replies to a
> particular email message doesn't need to be exposed; what matters is
> that the customer has a single point of contact.

Yes, of course, because we should all have to maintain thirty-seven
inboxes a day, thus having no time to actually do any real work, and it's
impossible to send an email from a specific address even if you're
reading the email to which you want to respond in a general-purpose
inbox.

Oh, wait -- that's not impossible at all.  What the hell are you talking
about?


> 
> > Clearly.  I think all of your reasons for disagreement are facile,
> > quietly condescending, and weirdly anti-technology.
> 
> Interestingly enough, I belive it's *your* point of view that is
> condescending.  You're assuming that the customer is not capable of
> following simple directions.

I'm just frustrated with your condescension and technophobia.

I'm not assuming the customer is incapable of anything (though some
customers probably are).  I'm assuming that customers don't want to do as
much, and that they like faster response times with fewer errors in the
process.  I started out assuming you would actually read what I was
saying with an open mind, too, but I've stopped making that unreasonable
assumption now, and started assuming you're just trolling me.


> 
> Your method insists that someone having issues with, say, a home
> router, must select their operating system from a pulldown list.
> That's crap.  A router is, hopefully by definition, agnostic to such a
> variable.  But you mark it as "required".  (Better yet, you program
> your automated system to reject everything that's not from IE on
> Windows.)

WTF are you talking about?  Stop assigning *your* arguments to *me*.


> 
> [As you point out, I'm the one bringing up pull-down lists at all, let
> alone something as specific as OS-for-a-router; as I mention above,
> however, I believe that this is the most likely embodiment of your
> desire to encode information in the form before the user is even
> allowed to contact you in the first place.]

I believe that you do not care what I'm saying, and can have this entire
discussion with your own imagination without my input at all, because the
moment I said that webforms are not the devil's tools you stopped paying
attention to the actual implications of my arguments.  You don't care
about the truth; you care about what straw men you can set up in an email
that occasionally borrow a word from what I said without paying any
attention to my actual message.


> 
> My ideal is to have a company publish a simple page for support:
> 
>   If you have a problem or question, please mail us at
>   support at example.com.  If applicable, please include the following
>   information:
> 
>   * Product name (on front of box)
>   * Model number (on bottom of box)
>   * Serial number (also on bottom of box)
>   * What version number does the product report (if available)?
>   * What platform (operating system, version, hardware) are you using
>     to access the product?
> 
>   * What did you try to do?
>   * What did you expect would happen?
>   * What actually happened?
> 
> Run that through a human -- even a temp with 4hrs training -- and you
> have a more fluid, intelligent, and convenient method of reporting
> errors than any web form.

My ideal is a company that looks at the actual facts and chooses the
right process for the circumstances, whether it involves a web form, an
email address on a webpage, a telephone number, an IRC channel, or
anything else that happens to be the best option for the circumstances.
My ideal is for people like you to not mandate one-size-fits-all to the
detriment of customers, using fallacious, technophobic arguments against
automation that can improve response times and reduce error rates in key
parts of the process.


> 
> And I think that your provider-centric views are "weirdly
> anti-customer".  *shrug*

I think that you having started with word one to assign that
characterization to my argument that one size does not fit all,
especially when it's a size that doesn't usually scale well past a
two-person business if it gets any kind of real customer support volume,
is intellectually dishonest, hostile to meaningful discussion, and
insulting.

Yeah.  I'll shrug, too.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]



More information about the NCLUG mailing list