Like most, I’m guilty of putting a contact form, for regular contact (not specific data gathering) on all my websites. But do we need to?
I recall the days when we all started doing this, it was mostly (as I recall) due to the fact that there was no easy way to have a one-click email option: The mailto command worked mostly on desktop, although I’m pretty sure it wasn’t that reliable. But on early devices just didn’t work as smartphone operating systems didn’t have the right sort of inter-connectedness between apps.
But all that is long in the past. Indeed, many operating systems don’t even need the mailto command now, they can recognise an email address and automatically turns it into a link to launch a new email window from the email app.
So, given this, and the fact that forms can often cause more problems that they solve with regards to spam, is it time to drop them?
On a personal level, I know I’m guilty of using a form over an email link on a website, not entirely sure why. I think in my head I still sub-consciously think a form has a better chance of getting read by the recipient, although I do of course also know it has more chance of getting spammed!
So maybe forms encourage the user to make contact? Although, if they only thing that pushes someone to make contact is a form, opposed to having a genuine interest or enquiry, you have to question the quality of the lead?
I too am re-evaluating the worth of contact forms in their current guise.
In fact once @tav has released his new navigation menu stack I will be closely looking at creating and integrating a simple email and video contact button into my nav bar that will appear on each page in order to simplify user engagement.
I stopped using contact forms about 18 months ago (around the GDPR panic station time) and have not had a single issue of reports of spam or the form not working. I think we all used forms because they had new look about them and if you used it in a sliding side panel then that added to the look. Siding side panels are now looking very dated to me.
In Source, I just drag a button into the nav CTA area, set to mailto:name@email.com and that is the end of it. This takes about 30 seconds to do and I must admit to having spent hours on old fashioned contact forms in the past. Using the web visitors email system to send emails removes the responsibility from the web site. As a backup, it is also worth adding in the footer, an obfuscated email address, also set to mailto:.
Putting an email contact button in the navigation is the best way to communicate how customers make contact IMHO.
I don’t know any other way to do it so simply. There may be other ways but I was just showing how easy it is to do in a freely available framework. Paul Rowe mentioned he was waiting for something to come along, but Source does it now and has been doing it for months. This type of thing was impossible or difficult until recently and usually took a load of fine tuning to get it right. If UIKIT can do this then great.
PS I have no connection with Stuart at Habitual, but just think he understands how to build web sites better than any other developer of frameworks, and he has taken a ground breaking fresh approach to code that framework efficiently.
To my knowledge, sticking the mailto command into any button works, don’t think this is unique to that framework.
And as we’re now banging on about our preferred frameworks, I think the UIKit form can be used to auto fill an email client new email window, opposed to sending the form via PHP. I’ve email Lucas to ask how.
So, if this works, you build the form exactly as you would using php: Name, phone (optional) subject and message, and the form takes this info and drops it into a new email for your installed email client.
I know this could be done using some simple code and css, but it’s just easier if the form does it.
Ya, I need to work out how to pass content added to the field, to the appropriate bit of code (mailto:, subject, etc.) and then have all the fields sent the data to the email client.
Apart from a CC and BCC field there are no other standard email fields. What you are now talking about is a form sent as email with custom pre filled fields which is beyond the scope of a Contact form.
I expect you will need something like FormsPlus or FormSnap.
Yes, I think that;s what I mean. Essentially I’m talking about using the Uikit form to create a form that instead of sending via PHP sends via the users mail app. Like the Doobox stack.
I know about how to create a email from the users email and add a standard subject/message, using the code above, but I’m talking about having the user add their own subject and message, then adding that to the code.
Maybe I’m over-thinking this. Brain not working too well today.
One benefit to using a form as opposed to a link is that the data is (or at least can be) saved to a database. Maybe this doesn’t matter to most people, but for some of my clients, they want the paper trail that the database provides.
Another benefit of forms that can come into play is logic. Say you have a client with three locations - but just one “Contact Us” link on the site. WIth a link, the emails generated are going to go to the same mailbox(s) each time. But, with a form, you can ask a question like: “Does your comment or question relate to Location 1, 2, or 3?” Then, depending upon which location was chosen, have the email go to person 1, 2 or 3.
All of this. The ability to use lists and direct email based on criteria makes forms invaluable, even for my small clients who have diversified responsibilities for replying to emails.
I had a really useful conversation with a user on here via messages about this. They haven’t posted to this thread so I’m going to assume, and respect, their wish not to get involved, but they made (for me) some very valid reasons why not to use a form to launch the mail app and continue with traditional forms.
Once you use the mailto method in a form (a la Doobox and my idea approach above) you are reliant on the users device being correctly setup and working. And you are relying on them completing the process. Many will click send in the form and as that’s the way 99% of forms work, will assume the mail has now gone. If after clicking send their mail app launches it’ll confuse them. Which leads to point 2…
99% of forms work how all forms work: You add your info, click send, job done. To tack on additional steps after this is going to confuse users.
I agree entirely with this.
Webdeers approach of not using a form and just having a link that opens the mail app is fine, as it’s working in a way most users will understand. Having a form that works via PHP is fine, as it’s working in a way most users will understand. Mixing these two methods: Having a form to gather the details and then sending them to the mail app is bad, as it’s confuse people.
A simple and clear advantage for me in using a form is that it hides your email address from spammers, who might otherwise harvest it from the website. It also enables us to set required information if needed.
Many years ago I just had an email link and it worked, but I always felt a well presented form looks more professional.
I wasn’t suggesting that you use a mailto link to submit forms but it was a response to your question really - I.e. Do we need to use contact forms anymore?
Also you should also provide an obfuscated visible email address for those who may not be able to use a mailto link.
There is no correct answer. For every non configured email system there are customers who demand a Captcha system that puts people off or a framework contact form that fails to work after a stack update.