Determine user's default email client

[Richard Cornford]

Richard Cornford wrote:
<blockquote cite="[email protected]"
type="cite"> <blockquote type="cite">Just because one lousy
piece of software is broken doesn't mean we should all avoid
the features it can't handle.<br> </blockquote>
<!---->It is one piece of software used by the entire (at least
non-manual/production) staff of companies.<br>
</blockquote>
It is a piece of crappy software that is usually forced down the
throats of unsuspecting and otherwise neophyte users who either
know no better or quickly learn that it's functionality is sub
par and if they are smart, use another application!<br>

Assessing the relative merits of Lotus Notes is of no value here. It is
a reality that entire companies use it exclusively (and their system
administrators will probably not allow users to install their own
software (licensing being only one reason for that). In the end it comes
down to a question of whether a web site wants to communicate with the
employees of those companies or not. Anyone in business would choose not
to lose potentially profitable customers, assuming that they were asked
the question instead of just letting themselves be lumbered with a
system that cost them business by some web developer who refused to see
the issues for themselves.

So Notes is broken (what a surprise!). Shall we code for the
lowest common denominator?

Nobody is proposing coding for the lowest common denominator. It is only
being proposed that a reliable alternative be put in place first (and
that reliable alternative will work with the lowest common denominator
because it relies on HTML and server-side scripting only).

Does your web site handle ASCII
browsers running on a hand held in Ethiopia?!?<br>

There is no reason for it not to.

<blockquote cite="[email protected]"
type="cite">People hide CSS from Netscape 4, if you could
detect the e-mail client similar possibilities would exist
for mailto:, but you cannot.<br></blockquote>
Some web sites hide CSS from Netscape 4. Some do not. It's not
practical to hide standards from non standard compliant software.

When something is trivial to implement declaring it "not practical"
sounds like idleness.

That's why there are standards. If we always coded for ever
odd situation to cover broken functionality of the various
applications then we might as well just do away with standards
altogether.<br>

The fact that there are accepted standards, and ever wider adoption of
those standards, is not an excuse for being blind to reality. After all
IE 6 isn't the most standards compliant browser, but no commercial
project is gong to be satisfied by a product that does not function on
IE.

Just about anything you use may fail with some esoteric
browser/application combo or configuration.

Absolutely, it is an important consideration for the design.

What's a coder
to do? Rely on standards! But when you rely on standards
some people will still complain! Argh!<br>

Relying on standards is not a practical proposition. Where scripting is
concerned there is no W3C DOM standard that says, for example, that the
ECMAScript global object will have a property called - document -, but
you won't get far with scripting without that document reference.

<blockquote cite="[email protected]"
type="cite"> <blockquote type="cite">And it provides visitors
with a much more user-friendly and flexible way of contacting
you, as I mentioned in an earlier post.<br>
</blockquote>
<!---->For the ones with e-mail clients fully configured and
conforming with the RFC.<br>
</blockquote>
Yes, as defined. Where's the problem? If people wish to use non
conforming applications and choose to not configure things
then they should expect it not to work.<br>

The user's expectations are not significant. It is the web site owner's
expectation that matters. If they expect to be able to easily
communicate with their visitors then it is the job of the web developer
to facilitate that, reliably. The web developer cannot know, anticipate
or influence to users situation with respect to e-mail software, but
she/he can still facilitate reliable communication regardless.

<blockquote cite="[email protected]"
type="cite">I have never said I did have a problem with that.
But what is important to understand is that it is the mail form
that provides the reliable communication. </blockquote>
Again, what mail <b>form</b>? I am not speaking of forms who's
purpose is to gather specific and limited information. I'm
speaking of a free form email message.<br>

In HTML terms reliably posting text (in any form) to a server will
involve a form.

Richard.

 

[Richard Cornford]

Andrew DeFaria wrote:
Richard Cornford wrote:

<!---->If Randy's description of his e-mail system is accurate (...

What? It would start the "compose an email to &lt;email
address&gt;" utility would it not? And that's all it's really
intended to do.<br>

Are you really proposing that when people put a mailto link on a web
site that their intention is no more, and no less, than to open an
unknown piece of e-mail composing software. I think you will find that
in reality mailto links are deployed in response to some sort of concept
of communication (misguided or otherwise). if it really was nothing but
a mater of starting software it wouldn't be too important that it isn't
reliable.

<blockquote cite="[email protected]"
type="cite">Given the extensive list of what you are dismissing
as "odd" and "misconfigured" systems in which mailto: will
certainly not work you are defining reliable as; works for an
unquantifiable subset of internet users.<br>
</blockquote>
Just like that unquantifiable subset of internet users who
don't have an email client! <span class="moz-smiley-s3">
<span> ;-)&nbsp; </span></span><br> <br>

We know that it is more than none, but when you have an option to cope
with 100% reliably the exact numbers don't matter. You only need to know
the numbers when you are trying to justify not using the reliable
approach.

It is reliable for it's intended purpose - which is to initiate
a free form email through the configured email client "helper"
application, if present. <br>

So you don't believe that communication is the intended purpose
(intended by the site owner, and possibly web developer if they are not
realistic enough to see where it cannot work)?

If you don't have an email client configured to send email
then to expect to be able to send email is expecting too
much. Yes some (actually more and more) web sites provide
a sub par way of getting around this problem by doing the
email itself. I think that's a bad way to handle it.<br>

You believe that it is bad to provide the user with something reliable?

<!---->Some other not-so-well-lit location?<br>
</blockquote>
Nope. I just have a difference in opinion - something that
*you* seem to have a problem with.<br>

You can have opinions as foolish as takes your fancy, but if you post
them to a public forum you should expect your fallacies to be pointed
out.

Richard.

 

[Lee]

Philip Ronan said:

1. User clicks mailto link.
2. No email client appears

3. User says "this site is broken", and moves on.

 

[Philip Ronan]

3. User says "this site is broken", and moves on.

Uh, yeah. Like, nobody would assume there's something wrong with the browser
set-up or anything, would they?

You want to see a broken site?

<http://www.coxmedia.com/contact.html>

Was I supposed to download a plug-in to use this page, I wonder? All I get
is a big blank box. It looks even more lame in Lynx:

<http://www.delorie.com/web/lynxview.cgi?url=http://www.coxmedia.com%2
Fcontact.html>

1. User clicks on "Contact Us" link
2. User presented with empty screen
3. User says "this site is broken", and moves on.

I thought the US had a law against blatant accessibility issues like this?

Not your handiwork, I hope (?)

 

[Andrew DeFaria]

Assessing the relative merits of Lotus Notes is of no value here. It
is a reality that entire companies use it exclusively (and their
system administrators will probably not allow users to install their
own software (licensing being only one reason for that).

That's exactly the kinds of users I don't want as customers! And what
sort of licensing do you think is required for Mozilla/Thunderbird?

In the end it comes down to a question of whether a web site wants to
communicate with the employees of those companies or not.

Well you saw my answer!

Relying on standards is not a practical proposition.

That's an interesting statement. So then what is the practical
proposition in your opinion?

In HTML terms reliably posting text (in any form) to a server will
involve a form.

I'm not talking about reliably posting text to a server, I'm talking
merely about sending an email. I think that that is where we differ.

 

[Andrew DeFaria]

Are you really proposing that when people put a mailto link on a web
site that their intention is no more, and no less, than to open an
unknown piece of e-mail composing software.

Exactly. What are you talking about?

We know that it is more than none, but when you have an option to cope
with 100% reliably the exact numbers don't matter.

I have not found web based form email pages to be 100% reliable. In fact
I've seen many times when they've failed.

So you don't believe that communication is the intended purpose
(intended by the site owner, and possibly web developer if they are
not realistic enough to see where it cannot work)?

The communication happens in the email client based on what the emailer
then composes (i.e. free form).

You believe that it is bad to provide the user with something reliable?

I feel it's bad to limit people to what you think email is by
reinventing email at each web page.

You can have opinions as foolish as takes your fancy, but if you post
them to a public forum you should expect your fallacies to be pointed out.

I don't see them as fallacies - just other opinions.

 

[Lee]

Philip Ronan said:

Uh, yeah. Like, nobody would assume there's something wrong with the browser
set-up or anything, would they?

Of course many people will, but not all, and your goal is
(usually) to reach as many people as possible.

You want to see a broken site?

<http://www.coxmedia.com/contact.html>
...

Not your handiwork, I hope (?)

I don't work for Cox.
One of my email addresses happens to be hosted by them.

 

[Andrey]

That's exactly the kinds of users I don't want as customers! And what
sort of licensing do you think is required for Mozilla/Thunderbird?

That's funny, man. Good joke.
You obviousely don't have your own business, with sucn an approach.
But no doubt, if you'd tell your boss that you don't like some category of users as your customers
you'd get your ass fired faster that your Pentium 586/90 reboots

Ok. i understand, you are preying standards, that's no bad at all.
But didn't you think of hundreds of thousands users of yahoo mail, google mail etc, who don't have a
"luxury"(need) of configuring/using a mail client? You don't like them as your customers, do you?
I myself use only those two mentioned email providers, google and yahoo, and i'm perfectly fine with
them, so how do you want me to configure my Firefox for an email server which doesn't have a
pop3/smtp access?

Anyway, the universal solution is mailto: + web form.

Now, go complain.


MuZZy

<... heh ...>

 

[Andrey]

Exactly. What are you talking about?


I have not found web based form email pages to be 100% reliable. In fact
I've seen many times when they've failed.

Anndrew, it's not a web based form fails, it's the programmer who didn't bother testing it/doesn't
have skils to programm it. All the forms i've ever made in perl/php/python/asp.net are working fine
while used hard(not hardly ), maybe couple times a year a form fails because of SQL Server locks,
or smth like that. But you give any customer a chance to communicate with you - from internet cafe,
from lynx browser, from PDA, etc.

I just don't understand - are you against forms at all, or just stand for mailto: ?

 

[Andrew DeFaria]

That's funny, man. Good joke.

I'm glad I have managed to amuse you.

You obviousely don't have your own business, with sucn an approach.

To the contrary - I do have my own business. I don't have traditional
sales though.

But no doubt, if you'd tell your boss that you don't like some
category of users as your customers you'd get your ass fired faster
that your Pentium 586/90 reboots

Being that I'm my own boss I find that hard to believe! Wait a sec... Uh
huh... Right. Well I just checked with myself and I told myself that I
would not fire myself. I feel better already!

Ok. i understand, you are preying standards, that's no bad at all. But
didn't you think of hundreds of thousands users of yahoo mail, google
mail etc, who don't have a "luxury"(need) of configuring/using a mail
client?

If they don't have the need then why is there an issue at all?

You don't like them as your customers, do you?

Truth be told 99.999% of them will never end up being my customers or
will be able to handle email with a real email client in the first
place. Or, they could easily pick up the phone and dial. Remember those?
A lot of business is still being done in that fashion.

I myself use only those two mentioned email providers, google and
yahoo, and i'm perfectly fine with them, so how do you want me to
configure my Firefox for an email server which doesn't have a
pop3/smtp access?

I"m not quite sure. Firefox is a browser! ;-)

Why would you be trying to configure a browser to do pop3/smtp?!?

Did you mean Thunderbird? ;-)

Anyway, the universal solution is mailto: + web form.

If you include the mailto link then fine.

Now, go complain.

I prefer just to comment.

 

[Andrew DeFaria]

Anndrew, it's not a web based form fails, it's the programmer who
didn't bother testing it/doesn't have skils to programm it. All the
forms i've ever made in perl/php/python/asp.net are working fine while
used hard(not hardly ), maybe couple times a year a form fails
because of SQL Server locks, or smth like that. But you give any
customer a chance to communicate with you - from internet cafe, from
lynx browser, from PDA, etc.

I assure you I've had more than a couple times a year of failure myself.
From a user perspective it doesn't really matter if the real reason is
the back end, out of disk space, DB currently being backed up or
whatever. It simply failed.

I just don't understand - are you against forms at all, or just stand
for mailto: ?

I'm against email based web forms where the user is limited to what the
designer thinks email should be like and/or that obscures the recipients
really email address thus allowing companies to hide behind a close of
anonymity.

 

[Andrey]

I'm glad I have managed to amuse you.

I would say - entertain

To the contrary - I do have my own business. I don't have traditional
sales though.

Then i see...

Being that I'm my own boss I find that hard to believe! Wait a sec... Uh
huh... Right. Well I just checked with myself and I told myself that I
would not fire myself. I feel better already!




If they don't have the need then why is there an issue at all?

What is an issue then is mailto: - in this case they need web form

Truth be told 99.999% of them will never end up being my customers or
will be able to handle email with a real email client in the first
place. Or, they could easily pick up the phone and dial. Remember those?
A lot of business is still being done in that fashion.

Right, i do too. But when i can't access them by phone (battery died, no reception, nobody's
responding, hold on line for 30 min etc.) i email them thru a web form on their web site

I"m not quite sure. Firefox is a browser! ;-)

Why would you be trying to configure a browser to do pop3/smtp?!?

Did you mean Thunderbird? ;-)

Oops, yes

If you include the mailto link then fine.

Here we go - i'm not against mailto:, i'm just saying it should be extended by existance of a web
form. So now we are on the same page!

 

[Andrew DeFaria]

What is an issue then is mailto: - in this case they need web form

Let's look at this a little more in depth. Aside from people at Internet
Cafe's where configuration/availability of an email client at all is
questionable (and really what sort of business trolls for customers
through Internet Cafe's?) let's take the web based email user who's on a
friend's computer or has purposely given up on using an email client on
their computer. They are at a web page. There is a mailto link, again,
intended to allow a free form email message to be kicked off. He clicks
it and it fails utterly to do what it was supposed to, that being start
up the client's configured email composition tool because it either is
not configured or not available. What can the poor user do? Well what
exactly stops him from copying and pasting the email address into his
configured and preferred email "client" of choice?!? After all that's
all that the mailto link is doing anyway!

Right, i do too. But when i can't access them by phone (battery died,
no reception, nobody's responding, hold on line for 30 min etc.) i
email them thru a web form on their web site

Such is life! The power might go out in the Internet Cafe too! Or the
internet connection may be down. Things happen.

Here we go - i'm not against mailto:, i'm just saying it should be
extended by existance of a web form. So now we are on the same page!

As I've said, I'm against two things in general. 1) the hiding of the
recipients email address and 2) the limiting of the full capabilities of
a good email client.

 

[Randy Webb]

As I've said, I'm against two things in general. 1) the hiding of the
recipients email address

So are most email spammers.

 

[Andrew DeFaria]

So are most email spammers.

Yeah, and so? Are you trying to imply that I'm a spammer? I am not.

There are very legitimate reasons to want to know the contact
information of the people you are emailing if for no other reason than
following up.

Spam, unfortunately, is a way of life and there's not much you can do to
stop it. Instead get something to protect yourself against spam and to
block/filter it.

 

[Randy Webb]

Yeah, and so? Are you trying to imply that I'm a spammer? I am not.

I was not implying anything. I made a statement of my own opinion, much
as you have been doing this entire thread.

There are very legitimate reasons to want to know the contact
information of the people you are emailing if for no other reason than
following up.

Typically, in a larger business, there is one email address that
recieves all the email, its forwarded to people who reply to it, and
then you get the follow up. If not, then you are still stuck with the
original address which is of no use to you because you won't get the
same person twice. Telephone Tech Support is the same way.

Spam, unfortunately, is a way of life and there's not much you can do to
stop it. Instead get something to protect yourself against spam and to
block/filter it.

And the reason a lot of spam gets generated is email harvesting software
that searches pages for, among other things, mailto: links. I have yet
to see a spammer be able to get my email address from a contact form.

Either way, its irrelevant as mailto: always has been and is currently
*Broken*.

 

[Richard Cornford]

Richard Cornford posted :

Polaris, the pole star, is a good half a degree away from the
pole itself; its circular motion would be observable with the
simplest of equipment, such as described.

The tube is described as 3/4 inch diameter by 3 foot 6 inches long. That
gives about 2 degrees of potentially observable sky. A rigorous observer
should have spotted the anomaly (at least over time) but as they say;
"There's none so blind as those that will not see", and in all things
Edgell observed only what he wanted to.

If you are interested in understanding Mr Edgell's shortcomings in this
respect you can have a look at his book. I have resurrected the web page
transcripts of it:-

<URL: http://www.litotes.demon.co.uk/dTeR/doesTheEarthRotate.html >
(about 240Kb with immages/diagrames)

Richard.

 

[Richard Cornford]

Richard Cornford wrote:
<blockquote cite="[email protected]"
type="cite">Are you really proposing that when people put a mailto
link on a web site that their intention is no more, and no less,
than to open an unknown piece of e-mail composing software.
</blockquote> Exactly. What are you talking about?<br>

I am responding to your assertion that the point of putting a mailto
link in a web page is to open an e-mail client, rather than to
facilitate communication.

<blockquote cite="[email protected]"
type="cite">We know that it is more than none, but when you
have an option to cope with 100% reliably the exact numbers
don't matter. </blockquote> I have not found web based form
email pages to be 100% reliable. In fact I've seen many
times when they've failed.<br>

The general circumstances where form mail will fail, network failures,
power cuts, server failures, etc, have an equal impact on normal e-mail
traffic. But apart from those conditions we are still left with a list
of conditions under which mailto will certainly fail where normal
HTTP/HTML forms/server-side scripting will be 100% reliable.

There is always potential for the implementers of a form mail system to
screw something up and render the reliable unreliable. That is a result
of the lamentable average quality of web developers. It should not be an
excuse for never using reliable communication mechanisms.

<blockquote cite="[email protected]"
type="cite">So you don't believe that communication is the
intended purpose (intended by the site owner, and possibly
web developer if they are not realistic enough to see where
it cannot work)?<br>
</blockquote>
The communication happens in the email client based on what
the emailer then composes (i.e. free form).<br>

Communication requires transmission in addition to composition.

<blockquote cite="[email protected]"
type="cite"><!---->You believe that it is bad to provide the
user with something reliable?<br></blockquote>
I feel it's bad to limit people to what you think email is by
reinventing email at each web page.<br>

There are no limitations imposed by facilitating reliable communication.

Richard.

 

[Richard Cornford]

Richard Cornford wrote:<br>
<blockquote cite="[email protected]"
type="cite">Assessing the relative merits of Lotus Notes is
of no value here. It is a reality that entire companies use
it exclusively (and their system administrators will probably
not allow users to install their own software (licensing being
only one reason for that). </blockquote>
That's exactly the kinds of users I don't want as customers!

If you don't want those customers that is your business (literally), but
most web authoring is done as a service to business and it is not the
web developers place to be turning away other people's business for them
(at least without explicit and informed permission).

And what sort of licensing do you think is required for
Mozilla/Thunderbird?<br>

The point is to prevent the users from being able to install software
that would need a licence without the knowledge and permission of the
administrators. That stops them installing any software but it is the
safer policy.

<blockquote cite="[email protected]"
type="cite"> <blockquote type="cite">What's a coder to do?
Rely on standards! But when you rely on standards some
people will still complain! Argh!&lt;br&gt;<br> </blockquote>
<!---->Relying on standards is not a practical proposition.
</blockquote> That's an interesting statement. So then what
is the practical proposition in your opinion?<br>

Normal cross-browser scripting gets as much from any browser as it is
capable of delivering. While the formal observance of the DOM standards
reduces IE6's capabilities to little more than form validation and image
roll-overs.

<blockquote cite="[email protected]
" type="cite">In HTML terms reliably posting text (in any form)
to a server will involve a form.<br>
</blockquote>
I'm not talking about reliably posting text to a server,
I'm talking merely about sending an email. I think that
that is where we differ.<br>

You appear to be talking about you personally sending an e-mail. But in
the context of web development the significant concept is communication.
Once reliable communication is facilitated then additional action to
accommodate individual preferences can be considered, but sacrificing
reliability for individual convenience would be negligent.

Richard.

 

[Andrew DeFaria]

I am responding to your assertion that the point of putting a mailto
link in a web page is to open an e-mail client, rather than to
facilitate communication.

You're being obtuse! You put a mailto link in a web page to open an
e-mail client to facilitate communication and you know that!

The general circumstances where form mail will fail, network failures,
power cuts, server failures, etc, have an equal impact on normal
e-mail traffic. But apart from those conditions we are still left with
a list of conditions under which mailto will certainly fail where
normal HTTP/HTML forms/server-side scripting will be 100% reliable.

As you have a list of conditions under which a form based email will
fail where a mailto will succeed. What's your point?

There is always potential for the implementers of a form mail system
to screw something up and render the reliable unreliable.

Observed actually

That is a result of the lamentable average quality of web developers.
It should not be an excuse for never using reliable communication
mechanisms.

And you can have the web server fail or run out of space whereas the
mail server is churning out and in emails. There are many possibilities,
none of which you've considered.

Communication requires transmission in addition to composition.

Obviously. Again, what's your point? I'm assuming that the person can
indeed send email. You're assuming the person can indeed browse.

There are no limitations imposed by facilitating reliable communication.

Sure there is! Open up your mind a little bit!