This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Site Ratings & Reviews > August 2005 > OT - Objections to use of Contact form?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
OT - Objections to use of Contact form?
|
|
| Chris Beall 2005-07-21, 7:32 pm |
| Someone, I believe here, put together a nice list of objections/concerns
with using an HTML form (with appropriate server code) as a way to avoid
the limitations of mailto:. I can't find it.
Can someone restate the concerns? (My main concern with mailto:, or
rather the client's, is the ease with which mailto: addresses can be
harvested and used for spamming).
Thanks,
Chris Beall
| |
| Philip Ronan 2005-07-21, 7:32 pm |
| "Chris Beall" wrote:
> Someone, I believe here, put together a nice list of objections/concerns
> with using an HTML form (with appropriate server code) as a way to avoid
> the limitations of mailto:. I can't find it.
>
> Can someone restate the concerns? (My main concern with mailto:, or
> rather the client's, is the ease with which mailto: addresses can be
> harvested and used for spamming).
1. Email applications are far more sophisticated than your average web
form. They can check your spelling, they can automatically add a
sig to the end of each email, and they can add other email headers
to indicate, e.g., the importance of a message or additional
recipients.
2. Just about every web form is different. That means users have to
work with a different interface every time. This does not aid
accessibility.
3. If users have to type in their email addresses for you to contact
them, then mistakes will occur. Email software fills in this
information automatically so it is more likely to be correct.
4. Most web feedback forms have a limited view of what constitutes a
valid email address. For example, "John Doe <j.doe@example.com>" is
correctly formatted but unacceptable to most web forms.
5. It can be difficult (and is often impossible) for people to send
attachments. This is a problem if you are expecting people to send
you work for quotations, etc.
6. Senders do not usually get to keep a copy of any email they send
you.
7. If you *do* automatically send a copy of each email to the sender,
a spammer could conceivably use this as a means of emailing
thousands of people anonymously at your expense.
Having said that, unprotected mailto links are definitely a liability.
--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/
| |
| Adrienne 2005-07-21, 7:32 pm |
| Gazing into my crystal ball I observed Chris Beall
<Chris_Beall@prodigy.net> writing in
news:OKRDe.2399$fx4.1804@newssvr17.news.prodigy.com:
> Someone, I believe here, put together a nice list of
> objections/concerns with using an HTML form (with appropriate server
> code) as a way to avoid the limitations of mailto:. I can't find it.
>
> Can someone restate the concerns? (My main concern with mailto:, or
> rather the client's, is the ease with which mailto: addresses can be
> harvested and used for spamming).
>
> Thanks,
It depends on how you are using mailto. If you are trying to use it for
a form action, don't. Some of the reasons are A) the user must have an
email client, B) some browsers/emial clients choke on it, C) will not
work for visitors using Web based email, at an Internet Cafe, library,
someone else's computer, etc.
Use a server side form instead. There are many available depending on
your language of choice.
I always include a mailto address anyway, for visitors who want to use
their email client and don't want to fill out a form.
Yes, there are dangers of email harvesters spamming the mail box, but
those can always be filtered out.
--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
| |
| Chris Beall 2005-07-24, 4:42 am |
| Philip Ronan wrote:
> "Chris Beall" wrote:
>
>
Philip,
OK, I'm going to explore each of these individually. First, let me
state that my primary interest at the moment is a simple initial contact
form, allowing the user to provide only a return e-mail address and a
text message.
[color=darkred]
> 1. Email applications are far more sophisticated than your average web
> form. They can check your spelling, they can automatically add a
> sig to the end of each email, and they can add other email headers
> to indicate, e.g., the importance of a message or additional
> recipients.
For the simple contact form I don't perceive any of these to be a real
issue. The recipient can either compensate for errors in the message
text or request clarification. The only CRITICAL piece of data is the
user's return e-mail address.
> 2. Just about every web form is different. That means users have to
> work with a different interface every time. This does not aid
> accessibility.
Again, true for forms with radio buttons, select lists, etc. for which
the user might need training, but probably not a problem for simple text
fields.
Are there any accessibility issues with <input type="text"... or
<textarea...?
> 3. If users have to type in their email addresses for you to contact
> them, then mistakes will occur. Email software fills in this
> information automatically so it is more likely to be correct.
Yes. I propose to address this by:
1. Reminding the user that an incorrect e-mail address will prevent
any return communication and cautioning them to double-check what
they've typed. I am not deceived regarding the probability that this
will always be effective.
2. Minimal syntactical checks on the address that is entered
(something like PERL /\w+\@\w+\.\w+/), with appropriate feedback to the
user if they fail.
3. Perhaps additional syntactical checks, with a warning to the user
that the address "looks odd" and options to either send it as-is or
modify it.
> 4. Most web feedback forms have a limited view of what constitutes a
> valid email address. For example, "John Doe <j.doe@example.com>" is
> correctly formatted but unacceptable to most web forms.
I would retain the limited view. It's my belief that most users of the
web would understand what is being requested. Perhaps an example prompt
would be useful, such as "mailbox@domain.tld", though I suspect many
would be confused by 'tld'. Maybe a dummy address, like
"fred@provider.net" would work better.
> 5. It can be difficult (and is often impossible) for people to send
> attachments. This is a problem if you are expecting people to send
> you work for quotations, etc.
Not a problem for making an initial contact. All followup communication
would be via conventional e-mail clients that would provide this function.
> 6. Senders do not usually get to keep a copy of any email they send
> you.
Major concern for me. I hate it when I feel the time for receiving a
reply has gone by and I can't recall when, much less what, I sent. As I
see it, the only option is to allow the user to request a copy sent back
to the e-mail address they provided.
> 7. If you *do* automatically send a copy of each email to the sender,
> a spammer could conceivably use this as a means of emailing
> thousands of people anonymously at your expense.
"expense" in this case meaning:
- You would be perceived as the originator of the message and
- You would get one copy of the message for each recipient attacked by
the spammer, i.e. lots of them (the good news being that you'd probably
detect what was happening rather quickly).
Obviously I want to avoid this. Some thoughts:
1. Instruct the site owner to respond to all messages ASAP, even if
only to say, "I got your message and will reply shortly." and copying
the complete text of the incoming message. This puts human eyes on the
incoming messages (and thus isn't 'automatic'), allowing bulk mailing or
inappropriate content to be nipped in the bud.
2. Require user interaction before a return copy is sent. Depending
on how this was done, it might outright prevent, or at least raise the
cost of, spammer-driven messages. Would a spammer find it economical to
fill in the form, send it, wait for a response screen, and then respond
to that, just to send one piece of mail?
> Having said that, unprotected mailto links are definitely a liability.
As I've noticed...
Thanks,
Chris Beall
| |
| Chris Beall 2005-07-24, 4:42 am |
| Adrienne wrote:
> Gazing into my crystal ball I observed Chris Beall
> <Chris_Beall@prodigy.net> writing in
> news:OKRDe.2399$fx4.1804@newssvr17.news.prodigy.com:
>
>
(snip)[color=darkred]
>
> I always include a mailto address anyway, for visitors who want to use
> their email client and don't want to fill out a form.
>
> Yes, there are dangers of email harvesters spamming the mail box, but
> those can always be filtered out.
Adrienne,
Filter accuracy becomes a problem. All it takes is one real message
shunted off to the spam folder to ruin your day. Using a form and
back-end CGI allows legitimate mail to be uniquely tagged, thus ensuring
that it will be seen.
Thanks,
Chris Beall
| |
| kchayka 2005-07-24, 4:42 am |
| Chris Beall wrote:
> Adrienne wrote:
>
This is the best way to go, IMO. I hate those bloody mail forms myself
and would just as soon forget about contacting the site at all rather
than use one.
[color=darkred]
>
> All it takes is one real message
> shunted off to the spam folder to ruin your day.
But it's not about you, the site owner. It's about your visitors and
what is best for them. Give them the choice between mailto and a form
and they will be more likely to actually contact you.
You're going to get spam. There is no way around it. And every now and
then a piece of legitimate mail will end up in the spam folder. That
will happen, too. That's no reason to punish your visitors.
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
| |
| Leonard Blaisdell 2005-07-24, 4:42 am |
| In article <3kdop7Ftpl60U1@individual.net>, kchayka <usenet@c-net.us>
wrote:
> But it's not about you, the site owner. It's about your visitors and
> what is best for them. Give them the choice between mailto and a form
> and they will be more likely to actually contact you.
I may have misinterpreted this, but I believe that you aren't arguing
against mailto. I have read this thread with interest, because I've used
a bare mailto for ten years and, although burdened with easily
controllable spam and a ten-year available legitimate address for
spammers to use as an address, I don't believe I've missed an email to
my site because of my nonuse of a form. Some people might not have an
email client. Who would they be? I'm perfectly capable of turning a
simple ***@***.*** into a form. See my header to fill in the blanks. I
have asked for critique on my site, and all anyone has ever said was
that I ought to use a form to "facilitate" site viewers and that the
site was ugly. Bah!
Forms instead of mailto has been a highhorse that most have ridden for
several years. I generally jump on highhorses. But not that one. Not for
a simple email commenting on my site. And especially now.
If I had multiple choice, database driven, money making stuff on my
site, I'd use a form.
> You're going to get spam. There is no way around it.
Amen. Ten years naked on Usenet with mailto :-) Wouldn't change a thing.
Of course, I use a Mac.
leo
--
<http://web0.greatbasin.net/~leo/
| |
| Spartanicus 2005-07-24, 4:42 am |
| Leonard Blaisdell <leo@greatbasin.com> wrote:
>I don't believe I've missed an email to
>my site because of my nonuse of a form.
About 80% of the email I get from my sites that use both a mailto link
and a form is sent using the forms. This doesn't mean that the form
users otherwise would not have sent email, but at the very least it
indicates a strong preference for the form method amongst my visitors.
--
Spartanicus
| |
| Leonard Blaisdell 2005-07-24, 4:42 am |
| In article
<7cp3e1ldav740ntbef2n4hdd6012ctj9t9@news.spartanicus.utvinternet.ie>,
Spartanicus <invalid@invalid.invalid> wrote:
> Leonard Blaisdell <leo@greatbasin.com> wrote:
>
>
> About 80% of the email I get from my sites that use both a mailto link
> and a form is sent using the forms.
Why do you use both?
> This doesn't mean that the form
> users otherwise would not have sent email, but at the very least it
> indicates a strong preference for the form method amongst my visitors.
OK, but I'll be damned if I know why. Perhaps a form impels people to
fill it out. Perhaps a link is confusing although it's far older in it's
general, though maybe not proper, implementation.
leo
--
<http://web0.greatbasin.net/~leo/
| |
| Spartanicus 2005-07-24, 4:42 am |
| Leonard Blaisdell <leo@greatbasin.com> wrote:
>
>Why do you use both?
So as not to disenfranchise those that do not have access to an email
client, and to offer the choice to those that can use both, both methods
have specific advantages and disadvantages.
--
Spartanicus
| |
| Chris Beall 2005-07-24, 7:32 pm |
| kchayka wrote:
> Chris Beall wrote:
>
>
>
>
> This is the best way to go, IMO. I hate those bloody mail forms myself
> and would just as soon forget about contacting the site at all rather
> than use one.
kchayka,
Now we're cooking. "Hate" is a pretty strong word. WHY do you hate
them? Do you hate all forms or just contact forms? If the latter, what
distinction is there in your mind?
At this point it may be useful to separate the FORM, which is just some
displayed input fields, and the CGI script that processes the form.
Since your e-mail client has the same input fields as a contact form,
I'll assume (until you tell me I'm wrong) that it isn't the form you
hate, but rather something about the CGI script. If my assumption is
correct, can you describe a CGI script (in functional terms) that you
would NOT hate?
Thanks,
Chris Beall
| |
| Chris Beall 2005-07-24, 7:32 pm |
| kchayka wrote:
> Chris Beall wrote:
(snip)
>
>
> But it's not about you, the site owner. It's about your visitors and
> what is best for them. Give them the choice between mailto and a form
> and they will be more likely to actually contact you.
>
> You're going to get spam. There is no way around it. And every now and
> then a piece of legitimate mail will end up in the spam folder. That
> will happen, too. That's no reason to punish your visitors.
All,
I should probably clarify something. In the specific instance that got
me looking at this, I am not the site owner. The site was using a
mailto:. The site owner was getting lots of spam AND either had a
genuine bad experience or became concerned about the potential to miss a
piece of real mail hidden in the spam folder. A contact form was
requested and has been installed. One feature of the form is that,
under the covers, it inserts fixed strings into the e-mail it sends to
the site owner, which allows filters on the owner's mail client to route
that mail to a "hot contact" folder where it will be promptly seen. The
client is happy.
BUT, I remembered that there were objections here to using contact
forms. Rather than ignore that, I decided to gather more information on
the specifics of those objections, then see if I could design a
technical solution that would address them. Thus I perceive this to be
a technical discussion about how to make contact forms a thing of great
beauty FOR THE USER, rather than a philosophical discussion about the
relative merits of forms versus mailto:.
I don't know if this will help to focus the discussion, but at least now
you know where I'm coming from.
Regards,
Chris Beall
| |
| Adrienne 2005-07-24, 7:32 pm |
| Gazing into my crystal ball I observed Chris Beall
<Chris_Beall@prodigy.net> writing in news:LUCEe.3267$fx4.3203
@newssvr17.news.prodigy.com:
> Thus I perceive this to be
> a technical discussion about how to make contact forms a thing of great
> beauty FOR THE USER, rather than a philosophical discussion about the
> relative merits of forms versus mailto:.
>
Here's some things that I don't like about forms:
1. Forms that do not clearly show what fields are required
2. Forms that lose information on an error
3. Forms that do not clearly show what kind of error you made
4. Forms that depend on javascript for functionality, especially when the
javascript is not written correctly for my default browser, and I have to
open another browser get what I want.
When I design forms, I group fields into fieldsets, and each fieldset has
a legend to tell the user what is needed in that area. I also clearly
show which fields are required, and I use a little javascript to fill out
the field with example text (users with no javascript available have to
erase the data).
If the user misses a required field, then the form comes back with all
the data the user had already put it, and whatever is in error is clearly
marked. I use CSS to change the appearance of the label and input
elements of the erroneous value. The error message also clearly shows
what the errors is, eg. "Email addresses must contain the @ character".
I do validation server side, to make sure I'm getting good data, and
thwart SQL injection attempts (test for ' in a field name).
--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
| |
| Spartanicus 2005-07-24, 7:32 pm |
| Adrienne <arbpen2003@sbcglobal.net> wrote:
>When I design forms, I group fields into fieldsets, and each fieldset has
>a legend to tell the user what is needed in that area. I also clearly
>show which fields are required, and I use a little javascript to fill out
>the field with example text (users with no javascript available have to
>erase the data).
If you use javascript to fill a field with a prompting text then why do
users without js need to erase it?
--
Spartanicus
| |
| Adrienne 2005-07-24, 7:32 pm |
| Gazing into my crystal ball I observed Spartanicus
<invalid@invalid.invalid> writing in
news:kti6e11q75glmklhstastvkvkfc9nbhrp4@news.spartanicus.utvinternet.ie:
> Adrienne <arbpen2003@sbcglobal.net> wrote:
>
>
> If you use javascript to fill a field with a prompting text then why do
> users without js need to erase it?
>
I don't use javascript to fill in the field, I do that server side. Hey!
That's a good idea! Wow! I'm going to go off now and figure out how to
do it client side. Thanks!
--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
| |
| Adrienne 2005-07-24, 7:32 pm |
| Gazing into my crystal ball I observed Adrienne
<arbpen2003@sbcglobal.net> writing in
news:Xns969D1BEA0A74Earbpenyahoocom@207.115.63.158:
>
> I don't use javascript to fill in the field, I do that server side.
> Hey! That's a good idea! Wow! I'm going to go off now and figure out
> how to do it client side. Thanks!
>
Yippie! Got it working nicely. Of course, users without js will not have
the fields prefilled, but that a PITA having to erase anyway.
--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
| |
| Chris Beall 2005-07-24, 7:32 pm |
| Adrienne wrote:
> Gazing into my crystal ball I observed Chris Beall
> <Chris_Beall@prodigy.net> writing in news:LUCEe.3267$fx4.3203
> @newssvr17.news.prodigy.com:
>
>
>
>
> Here's some things that I don't like about forms:
> 1. Forms that do not clearly show what fields are required
> 2. Forms that lose information on an error
> 3. Forms that do not clearly show what kind of error you made
> 4. Forms that depend on javascript for functionality, especially when the
> javascript is not written correctly for my default browser, and I have to
> open another browser get what I want.
Adrienne,
Great! The forms you are talking about clearly go well beyond the
simple contact form that I was thinking of, but this gives us some
design points for ANY form:
The displayed form itself:
1. Should provide the user with a clear indication of any syntactic
restrictions on the data to be entered into a field (min-max length,
numeric-only, etc.) ['Required' is another way of saying 'minimum length
> 0'.]
The code (both client and server-based) which processes the form:
A. Should retain and redisplay all data entered by the user until either:
- the form has been successfully processed.
- the user has abandoned submission of the form.
B. Should clearly identify what is wrong with data that was entered
incorrectly.
Both the form and the underlying code:
I. Should minimize their dependence on a specific user environment
(presence of JavaScript, window size, etc.).
Thanks,
Chris Beall
| |
| Leonard Blaisdell 2005-07-24, 7:32 pm |
| In article <HKPEe.405$gt5.14@newssvr17.news.prodigy.com>,
Chris Beall <Chris_Beall@prodigy.net> wrote:
> The displayed form itself:
> 1. Should provide the user with a clear indication of any syntactic
> restrictions on the data to be entered into a field (min-max length,
> numeric-only, etc.) ['Required' is another way of saying 'minimum length
Easily expressed in HTML and enforced with server-side interpreters.
[color=darkred]
> The code (both client and server-based) which processes the form:
> A. Should retain and redisplay all data entered by the user until either:
> - the form has been successfully processed.
> - the user has abandoned submission of the form.
Easily done as above.
> B. Should clearly identify what is wrong with data that was entered
> incorrectly.
Generally easily done by regular expressions. Have you ever seen
Abagail's email validation regex for Perl? It's huge and needs to be to
conform to the RFC.
> Both the form and the underlying code:
> I. Should minimize their dependence on a specific user environment
> (presence of JavaScript, window size, etc.).
Variable manipulation should be done server-side. Dependence on
client-side languages should not be assumed.
My original argument was for using mailto for "simple" feedback which
the majority of personal websites would be perfectly comfortable with.
No fields. No variables. No regular expressions. No script manipulation.
That, of course, excludes sites that seek to easily manipulate
information in the post.
leo
--
<http://web0.greatbasin.net/~leo/
| |
| Chris Beall 2005-07-24, 11:49 pm |
| Leonard Blaisdell wrote:
> In article <HKPEe.405$gt5.14@newssvr17.news.prodigy.com>,
> Chris Beall <Chris_Beall@prodigy.net> wrote:
(snip)
>
>
> Generally easily done by regular expressions. Have you ever seen
> Abagail's email validation regex for Perl? It's huge and needs to be to
> conform to the RFC.
I'm not aware of this, but I'd be interested. Got a pointer?
I've looked at the RFC. While it might be prudent to validate addresses
against the complete RFC, for a simple site contact form I think it is
grotesque overkill. For example, you definitely don't want to allow
multiple e-mail addresses. That would encourage spammers. And I'll bet
the number of people-in-the-street who know about the imbedded comment
part of the rfc is close to zero...
If you set expectation correctly, in this case by providing an example:
address@provider.whatever, then I think you are justified in enforcing
that syntax and allowing no other. Nonetheless, if you reject the
address, you should state why.
(snip)
Regards,
Chris Beall
| |
| Leonard Blaisdell 2005-07-24, 11:49 pm |
| In article <QHVEe.516$gt5.76@newssvr17.news.prodigy.com>,
Chris Beall <Chris_Beall@prodigy.net> wrote:
> Leonard Blaisdell wrote:
> (snip)
>
> I'm not aware of this, but I'd be interested. Got a pointer?
Well, crap! It appears he's turned it into a module
<http://search.cpan.org/~abigail/RFC...-1.5/Address.pm>. It
doesn't do the original raw regex justice by casual viewing. But it's
far more elegant, and it sure makes it simple to use in a PERL program.
I don't have, and couldn't find the original code in clpm. I looked for
about five minutes. Use the module, Luke :-) It is said to be slow by
the author.
> I've looked at the RFC. While it might be prudent to validate addresses
> against the complete RFC, for a simple site contact form I think it is
> grotesque overkill.
I agree from my limited viewpoint. But then again, it's a module for
Perl aficianados. Not too tough to implement if you are one. I haven't
checked if there is an appropriate one for PHP. Just checked. Yup.
> If you set expectation correctly, in this case by providing an example:
> address@provider.whatever, then I think you are justified in enforcing
> that syntax and allowing no other. Nonetheless, if you reject the
> address, you should state why.
The address doesn't agree with what you think an email address should
be? The rfc is the arbitrator. I admit I subscribe to your
interpretation, but then again, I'm not doing serious business where
bogus or incorrectly composed email addresses will do me any harm.
Actually, I've learned something from this. There are PERL and PHP
solutions to validate email addresses which are among the toughest stuff
that can be validated. And they're free. Free, I tell you! Mwaahahaha!
leo
--
<http://web0.greatbasin.net/~leo/
| |
| kchayka 2005-07-27, 8:13 pm |
| Chris Beall wrote:
> kchayka wrote:
>
> "Hate" is a pretty strong word. WHY do you hate
> them? Do you hate all forms or just contact forms?
Forms such as for online shopping are not at issue, just contact forms.
I don't send messages to just anyone. If it is important enough for me
to bother sending a message, then it is important enough to get a copy
of said message filed in my own mailbox. Those mail forms don't permit
that. I might as well not send one at all, because I'll have no record
of it. Please don't suggest I copy and paste the message in a text
editor and file it manually, because that's way too much trouble and
doesn't integrate well with my mail client.
The degree of loathing mostly depends on the particular site. I
grudgingly use contact forms at trusted businesses, mostly because there
is sensitive info involved and I know I'll get a reply, like at my bank.
If there is no mailto: link I *might* use a form if I don't care about
getting a reply, but that is a rare occasion. I don't even remember the
last time I did that.
Given a choice between a contact form and not sending anything at all,
usually I just hit the back button and go on my way, especially if said
form requires info the site has no legitimate reason for having.
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
| |
| Chris Beall 2005-07-27, 11:19 pm |
| kchayka wrote:
> Chris Beall wrote:
>
>
>
>
> Forms such as for online shopping are not at issue, just contact forms.
>
> I don't send messages to just anyone. If it is important enough for me
> to bother sending a message, then it is important enough to get a copy
> of said message filed in my own mailbox. Those mail forms don't permit
> that. I might as well not send one at all, because I'll have no record
> of it. Please don't suggest I copy and paste the message in a text
> editor and file it manually, because that's way too much trouble and
> doesn't integrate well with my mail client.
>
> The degree of loathing mostly depends on the particular site. I
> grudgingly use contact forms at trusted businesses, mostly because there
> is sensitive info involved and I know I'll get a reply, like at my bank.
> If there is no mailto: link I *might* use a form if I don't care about
> getting a reply, but that is a rare occasion. I don't even remember the
> last time I did that.
>
> Given a choice between a contact form and not sending anything at all,
> usually I just hit the back button and go on my way, especially if said
> form requires info the site has no legitimate reason for having.
>
kchayka,
Thanks for the detailed reply. My reading of this is that for a contact
form to be acceptable to you, the code behind it (adding to the
requirements defined elsewhere in this thread):
C. Should provide the user with the option of retaining a record of the
communication, in a way that integrates gracefully with the user's mail
client.
Is that an accurate statement of your requirement?
Would the following interface be an acceptable implementation of the
requirement?
System: Displays form, which is followed by text stating something like,
"After your message has been successfully sent, you will be given the
option of receiving a copy."
User: Fills out form, Clicks on 'Send' button.
System: Acknowledges that message has been sent and asks if user would
like a copy sent to the e-mail address which the user entered on the form.
User: Responds by clicking a 'Yes' or 'No' button.
System: If the response was 'Yes', sends a copy of all of the data
entered on the form, along with a preface that identifies the site to
which the information was submitted, to the user's e-mail address.
Regardless of the response, displays a "Thank you" page; if the response
was 'Yes', the "Thank you" page includes a confirmation that the copy
has been sent.
(In all cases, error conditions would result in appropriate messages to
the user.)
Thanks,
Chris Beall
| |
| Leonard Blaisdell 2005-07-28, 7:40 am |
| In article <hrXFe.1154$aT1.989@newssvr19.news.prodigy.com>,
Chris Beall <Chris_Beall@prodigy.net> wrote:
> Would the following interface be an acceptable implementation of the
> requirement?
>
> System: Displays form, which is followed by text stating something like,
> "After your message has been successfully sent, you will be given the
> option of receiving a copy."
> User: Fills out form, Clicks on 'Send' button.
> System: Acknowledges that message has been sent and asks if user would
> like a copy sent to the e-mail address which the user entered on the form.
> User: Responds by clicking a 'Yes' or 'No' button.
> System: If the response was 'Yes', sends a copy of all of the data
> entered on the form, along with a preface that identifies the site to
> which the information was submitted, to the user's e-mail address.
> Regardless of the response, displays a "Thank you" page; if the response
> was 'Yes', the "Thank you" page includes a confirmation that the copy
> has been sent.
> (In all cases, error conditions would result in appropriate messages to
> the user.)
And in all cases, trivial to script in Perl. And probably in PHP though
I haven't done it in PHP. That sure isn't my complaint. My complaint is
using forms for trivial communication when mailto, with all it's
supposed faults, works in damned near all situations. Again. For
correspondence not using variables for any reason.
I never understood the email client-browser voodoo that has been thrown
around with abandon for so many years regarding mailto. If it was ever
valid, it was more then than now.
Forms are always a great marketing tool though. If correct markup was as
aggressively sold to a client, we'd have a better Internet.
leo
--
<http://web0.greatbasin.net/~leo/
| |
| Ben Measures 2005-07-28, 11:59 pm |
| Philip Ronan wrote:
> "Ben Measures" wrote:
>
>
> On my main business website (not the one in the sig), I have a contact page
> with a form and an email link. The overwhelming majority (~90%) of initial
> contacts come via the form, so customers obviously prefer it.
If you dig deeper there's always something more to the story: your main
business website doesn't have a mailto: link. It has some javascript
obscuration instead. Thus your statement should've been:
> The overwhelming majority (~90%) of initial contacts come via the form,
> so customers obviously prefer it [to my javascript mail launcher].
The importance of this is that the way in which your mail link operates
doesn't match users' expectations of what they at first assume to be a
mailto: link.
The most notable and quite frankly alarming difference was the
unexpected appearence of a dialog box asking me if I really wanted to
send you an email. No thank you. It reminds me of a "Are you sure you
want format drive C:" dialog box - if it's important enough to ask for
confirmation I'd better say no.
One of the attractions of mailto: links is that they're familiar - they
work exactly as you've gotten used to. Unfortunately, your script breaks
expectations and as such may provide users with a fright.
--
Ben M.
| |
| Spartanicus 2005-07-29, 4:16 am |
| Ben Measures <saint_abroadremove@removehotmail.com> wrote:
>
>If you dig deeper there's always something more to the story: your main
>business website doesn't have a mailto: link. It has some javascript
>obscuration instead.
As I stated earlier in the thread I see a similar percentage on my 3
main sites (quite different audiences), and I only use character
references as "protection" against harvesting. Character references are
afaik supported by all browsers and configurations.
--
Spartanicus
| |
| Philip Ronan 2005-07-29, 7:52 am |
| "Ben Measures" wrote:
[color=darkred]
> Philip Ronan wrote:
>
> If you dig deeper there's always something more to the story: your main
> business website doesn't have a mailto: link. It has some javascript
> obscuration instead. Thus your statement should've been:
Touché :-)
Although the ratio used to be the same before I started using the Javascript
technique.
(What's so scary about a dialog box anyway?)
--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/
| |
| Ben Measures 2005-07-29, 7:52 am |
| Spartanicus wrote:
>
> As I stated earlier in the thread I see a similar percentage on my 3
> main sites (quite different audiences)
I'm surprised you get any emails considering your email link is broken:
http://www.spartanicus.utvinternet.ie/web_mail.htm
Given that 80% use the form, this suggests up to 20% of users would
prefer to manually copy your email address into their mail client.
--
Ben M.
| |
| Spartanicus 2005-07-29, 7:52 am |
| Ben Measures <saint_abroadremove@removehotmail.com> wrote:
>
>I'm surprised you get any emails considering your email link is broken:
>http://www.spartanicus.utvinternet.ie/web_mail.htm
Oops, I've changed that to another address a few days ago and broke it.
No such mistake on my other 2 sites.
--
Spartanicus
| |
|
| Spartanicus wrote:
[snip]
> As I stated earlier in the thread I see a similar percentage on my 3
> main sites (quite different audiences), and I only use character
> references as "protection" against harvesting. Character references are
> afaik supported by all browsers and configurations.
>
I was using Character references on my sites - then I noticed I was
getting a bunch of 404s - "mai&" - & being the beginning of the letter
"L". I do not know what browsers/configurations were the problem.
--
TK
http://www.wejuggle2.com/
Still Having a Ball
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
..
----== Posted via codecomments.com - Unlimited-Uncensored-Secure Usenet News==----
http://www.codecomments.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| Philip Ronan 2005-07-29, 7:24 pm |
| "Terry" wrote:
> I was using Character references on my sites - then I noticed I was
> getting a bunch of 404s - "mai&" - & being the beginning of the letter
> "L". I do not know what browsers/configurations were the problem.
Badly programmed spambots, most likely.
--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/
| |
| Leonard Blaisdell 2005-08-01, 4:24 am |
| In article <PCaGe.600$gQ5.524@newssvr33.news.prodigy.com>,
Chris Beall <Chris_Beall@prodigy.net> wrote:
> Leonard Blaisdell wrote:
[color=darkred]
[color=darkred]
> 2. Allows unique tagging of incoming contacts from the site, thus
> allowing the filtering of pre-existing spam.
> The current form is dirt simple and meets the clients needs. But I knew
> there were other issues with forms expressed on this group; I'm now
> trying to come up with a more comprehensive design which will make just
> about everyone happy.
When you do, post it, or hell, patent it. I'd be happy to conform to a
solution that makes everyone happy. I'm happy with mailto on simple
sites. Again, forms are the only way to go if you want to actually glean
information for further processing. I concede that.
> My e-mail address is
> quite public, often harvested, and generates copious spam, 99.9% of
> which is shunted aside by my ISP.
Mine too. Ain't server side spam filters that you can augment great!
It's that damned mailto and my bare email address on Usenet, I tell you.
Well, of course it is, but it's easily manageable.
Some would say that I'm allowing spammers to waste bandwidth. I don't
think they care. They'd run it into a lake if they thought there was a
cognizant fish in it.
leo
--
<http://web0.greatbasin.net/~leo/
| |
| Chris Beall 2005-08-03, 11:26 pm |
| Chris Beall wrote:
> Someone, I believe here, put together a nice list of objections/concerns
> with using an HTML form (with appropriate server code) as a way to avoid
> the limitations of mailto:. I can't find it.
(snip)
>
> Thanks,
> Chris Beall
>
Thanks to all who contributed to identifying issues related to the use
of Contact forms (and forms in general). The following list provides a
set of requirements which, if implemented, would resolve most of the
concerns raised. Two concerns were not addressed:
1. Reliance on the competence of the user to correctly provide their
own e-mail address. I believe resolving this would require an
architected interface to the user's address book, which is not present
on systems today.
2. Spellcheck of user-entered data. Although this is certainly
possible, it would require significant server-side resource for a
spelling dictionary.
The defined requirements are:
1.0 The page displaying the form itself:
1.1 Should provide the user with a clear indication of any syntactic
restrictions on the data to be entered into a field (min-max length,
numeric-only, etc.) ['Required' is another way of saying 'minimum length
> 0'.]
1.2 Should inform the user that the option to receive a copy of the
completed form is available.
2.0 The code (both client and server-based) which processes the form:
2.1 Should retain and redisplay all data entered by the user until either:
- the form has been successfully processed.
- the user has abandoned submission of the form.
2.2 Should clearly identify what is wrong with data that was entered
incorrectly.
2.3 Should provide the user with the option of retaining a record of
the communication, in a way that integrates gracefully with the user's
mail client.
2.3.1 The implementation should discourage misuse by spammers.
3.0 Both the form and the underlying code:
3.1 Should minimize their dependence on a specific user environment
(presence of JavaScript, window size, etc.).
These requirements should provide a useful guideline to anyone
implementing Contact (or other) forms on a website.
Chris Beall
| |
|
| Chris Beall <Chris_Beall@prodigy.net> wrote:
> Chris Beall wrote:
> (snip)
>
> Thanks to all who contributed to identifying issues related to the use
> of Contact forms (and forms in general). The following list provides a
> set of requirements which, if implemented, would resolve most of the
> concerns raised. Two concerns were not addressed:
> 1. Reliance on the competence of the user to correctly provide their
> own e-mail address. I believe resolving this would require an
> architected interface to the user's address book, which is not present
> on systems today.
> 2. Spellcheck of user-entered data. Although this is certainly
> possible, it would require significant server-side resource for a
> spelling dictionary.
>
> The defined requirements are:
Too freaking complicated.
Offer both mailto: and a form.
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|