[NCLUG] html form to email cgi advice

[Anthony Foiani]

> 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.

> 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.)

>> 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".

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?

>> > 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.

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.

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.

> [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.

> 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.

> 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.

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.

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

(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.)

> 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."

> $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.

That's rude and lazy.

> 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.

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.

(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".)

> 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.

> 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.

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).

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

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

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.

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.

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

> 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.

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.

> 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.

> 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.

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.)

[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.]

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.

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

t.