I have been asked to add some email addresses to individuals personal portfolio galleries on a site I designed.
There is already a very visible email form that customers can use, but it only goes to one address. Then the master email recipient has to forward the email to the intended recipient. When the business started there was only one master recipient. But now there are 5 or 6 artists and the shop is growing.
My first thought was to put href="mailto:" links on everyone's personal page. This would not be convenient for customers without a configured email client, but copy and paste would be fine. Also, The customer is worried about spam, but I think email filters would be more effective then some obfuscation technique.
Then I read this which says using mailto "screams 'this web site has been developed by a beginner.'I don't really agree. The author advocates using server side forms. I already have made a PHP form and could easily add a drop down of recipients (maybe not so easy, but it could be done) or have the recipient field auto fill on a certain persons page.
My real question(s) is/are threefold:
Does using mailto demonstrate some kind of beginners ignorance?
What would be the best practice to easily allow an average website user to email an individual from a small group?
And is email obfuscation critical?
BTW I've already ready a found a little data that suggests that obfuscation is (sort of effective), but the article seems dated.
Disadvantages of using mailto: links:
Show the recipients email address (unless obfuscation is used)
Users need to have a working email client installed on their computer. Nowadays more and more users only use a web based email client, which won't work with mailto: links.
Personally I'd go with a server created contact form.
Does using mailto demonstrate some kind of beginners ignorance?
Not at all, mailto: and a mail icon is state of the art if you display a mail address. It's a UX and accessibility fail if you declare it as regular text. Especially for mobile users.
Using a contact form instead provides some benefits, but may also make your page vulnerable to mail spamming or even getting hacked if you don't watch out and update regularly.
What would be the best practice to easily allow an average website user to email an individual from a small group?
That's hard to say, it depends on the design and use case. I would recommend using a simple AJAX contact form with as few fields as possible ("Ask me a question:") and a ReCaptcha v3, but a simple mailto: link with a predefined subject is also fine.
And is email obfuscation critical?
I had to research this today and it seems to still be necessary. Most bots search for common patterns in the page source and don't use JavaScript.
You could add the href and insert the # symbol using JS after the DOMContentLoaded event: <a class="uncrypt">user???example.com</a>. But this is just one way of many.
Bots that use JS could still get the address, but that's hard to avoid anyway and I personally think it's more important to create a good UX for all users than making your page bullet proof to spammers.
But you don't have to protect generic addresses (like info#<domain>) as spammers will try those anyway.
Follow the leaders
Having simply an email link on a site isn't an especially good indicator of a high quality site. Quite simply, this is because high powered sites, sites with millions of users per day (microsoft.com, stackoverflow.com), or multinational corporations like Amazon do not do that. If they did, that persons email would probably be buried in a day.
Pros of the mailto: link:
Simple
Trivially understandable
Cons:
Exposes contact information directly
Not flexible
Not what the pros do
Email mailto links cause bad user experience *
Here are a few additional approaches that provide more professionalism:
- If anonymity is a goal, a generic contact form. No user is exposed, could be 10 it people ready to respond to it, could be 1, could be 100. Submit to a back-end, forward to 10 people on the back-end if you like.
- If you want to put a face to the contact, or you want to allow users to contact specific individuals, use user profiles with avatars of their faces, clicking a button also displays a contact form, perhaps in a modal.
When you click a link and your email spins all 8 of your cpus as you wait for the world to end, you can see how the user experience suffers with having to open an unrelated email client
Related
Although I know a lot of email clients will pre-fetch or otherwise cache images. I am unaware of any that pre-fetch regular links like some link
Is this a practice done by some emails? If it is, is there a sort of no-follow type of rel attribute that can be added to the link to help prevent this?
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.
This effectively makes all one-time use links like login/pass-reset/etc useless.
(Users of my service were complaining that one-time login links don't work for some of them and it appeared that BingPreview/1.0b is hitting the URL before the user even opens the inbox)
Drupal seems to be experiencing the same problem: https://www.drupal.org/node/2828034
Although I know a lot of email clients will pre-fetch or otherwise cache images.
That is not even a given already.
Many email clients – be they web-based, or standalone applications – have privacy controls that prevent images from being automatically loaded, to prevent tracking of who read a (specific) email.
On the other hand, there’s clients like f.e. gmail’s web interface, that tries to establish the standard of downloading all referenced external images, presumably to mitigate/invalidate such attempts at user tracking – if a large majority of gmail users have those images downloaded automatically, whether they actually opened the email or not, the data that can be gained for analytical purposes becomes watered down.
I am unaware of any that pre-fetch regular links like some link
Let’s stay on gmail for example purposes, but others will behave similarly: Since Google is always interested in “what’s out there on the web”, it is highly likely that their crawlers will follow that link to see what it contains/leads to – for their own indexing purposes.
If it is, is there a sort of no-follow type of rel attribute that can be added to the link to help prevent this?
rel=no-follow concerns ranking rather than crawling, and a no-index (either in robots.txt or via meta element/rel attribute) also won’t keep nosy bots from at least requesting the URL.
Plus, other clients involved – such as a firewall/anti-virus/anti-madware – might also request it for analytical purposes without any user actively triggering it.
If you want to be (relatively) sure that any action is triggered only by a (specific) human user, then use URLs in emails or other kind of messages over the internet only to lead them to a website where they confirm an action to be taken via a form, using method=POST; whether some kind of authentication or CSRF protection might also be needed, might go a little beyond the context of this question.
All Common email clients do not have crawlers to search or pre-build <a> tag related documents if that is what you're asking, as trying to pre-build and cache a web location could be an immense task if the page is dynamic or of large enough size.
Images are stored locally to reduce load time of the email which is a convenience factor and network load reduction, but when you open an email hyperlink it will load it in your web browser rather than email client.
I just ran a test using analytics to report any server traffic, and an email containing just
linktomysite
did not throw any resulting crawls to the site from outlook07, outlook10, thunderbird, or apple mail(yosemite). You could try using a wireshark scan to check for network traffic from the client to specific outgoing IP's if you're really interested
You won't find any native email clients that do that, but you could come across some "web accelerators" that, when using a web-based email, could try to pre-fetch links. I've never seen anything to prevent it.
Links (GETs) aren't supposed to "do" anything, only a POST is. For example, your "unsubscribe me" link in your email should not directly unsubscribe th subscriber. It should "GET" a page the subscriber can then post from.
W3 does a good job of how you should expect a GET to work (caching, etc.)
http://www.w3schools.com/tags/ref_httpmethods.asp
There are couple of ways for a website to know where a user comes from, like search engine, social platforms, email newsletter, etc. Great way to monitor traffic and assess campaigns.
If a website sends regular newsletter, it also gives the option of managing subscriptions. One clicks on the link and can choose to set the frequency or entirely stop letters altogether among other settings.
But what if, for eg, A sends the newsletter to her friend B, B somehow decides to stop receiving any mails from A decides to unsubscribe! But effectively A gets screwed.
So is there anyway for a website to know that the request to get unsubscribed actually came from another email account and not its original subscriber?
I am not aware if Mailchimp or other services know how to handle this, so pls guide me so.
Of course there are couple of other ways to authenticate like to login and then change but I have seen many newsletter straight away unsubscribing without even confirming the request. I am not aware if they do some sort of check before doing that. But this can also be used to tell something to the website about its letter, like A forwarded to B but B did not like.
Thanks.
The only way you can expect to be able to identify a user in this way is to see of they have a cookie previously issued with a session, that you can associate with the user's account, that was authenticated by a login on your site.
Alternately, you can ask users to email the word "unsubscribe" in a message from the original account instead of depending on a link.
I'm trying to figure out the different skills and technologies necessary to develop webpage personalization apps that allow users to input and edit text/images/links on a webpage. About.me and Flavors.me would be the most advanced examples of what I'm talking about. Thanks in advance for any guidance.
#tim, they're database driven apps. The user enters information into a database (or Facebook profile, etc) and it's then pulled back out via a scripting language and presented on the page. The page layout is also stored in a DB and brought together with the user's profile information for what becomes the page layout you see. About.me seems to take it a step further by creating an email account that's tied to the user account.
Technology-wise, just about any back-end language could be used. Facebook is written in PHP, though they have a language-agnostic API that could be talked to from .net, java, php, etc. You'll need a database, and that probably would either be MySQL, Sql Server or Postgres, though there are certainly others. Finally you'd probably want to make use of the API's I spoke about including Facebook, Google, LinkedIn, etc. to aggregate information the user already has entered in different locations.
Examples of this type of site are varied and all over. Mint.com does it for financials. Grooveshark will tie into facebook and others to communicate and share your music collection. Linked in will tie into others as well. Integration is actually a very lucrative segment of the programming business right now. An app that talks to others has good marketable value.
I just realized that I don't have a answer to this question, when I'm talking some friends we can't find the best simple solution to do this.
Can I send a dynamically body, from a form with a prefixed subject? My question is about the most simple solution.
[]'s
You cannot do this in general without some server side help.
Plain html does not offer support for it.
Usually a link as proposed by Simon will do the trick, but this will not work for everyone.
Javascript and Java client scripting suffer from the "same origin" limitation, meaning that you have to deliver to the same server, unless the user jumps through hoops to allow the script to connect to other hosts.
There are many scripts available to do this.
You can launch the user's email program using a mailto link along with several paramaters:
mailto:foo#example.com?subject=hi&body=hello,%20world!
However, a lot of people use webmail nowadays, for which it won't work - so the best option is to avoid using email. If you want feedback and don't want to host such a script on your own server, you can use a service such as PollDaddy or SurveyMonkey for this. If you want to encourage users to share a page with friends, ShareThis supports email.
I'm looking for web applications that users can use without registration, just by visiting the site, and make you register later after you spent some time.
Any good examples?
Stack Overflow; question an answer sites.
Google News; blogs and newsfeeds.
Apple's iTunes Store, Amazon; anything where you have a shopping cart.
:-)
There's this site called StackOverflow.com
Sometimes when you are looking for example sites that you've seen in the past, it is just to increase your own confidence that you are doing it right. If you have a good idea of the advantages of this style of progressive registration, why not take a moment to write down & plan out how it should work for your site?
Edit content without registration (but create a pseudo-account using IP address):
wikipedia
Register with your email address, optionally password protect your account later:
http://www.instapaper.com/
Registration as a side effect of paying for a product
Amazon (if I remember correctly)