-
HTML based email. What to do about non-html clients?
I'm curious to find out how others have handled sending out html-based email
(as in direct email marketing campaigns) while accounting for those who have
clients that don't support HTML. Is there a way to recognize whether the
client can handle email as the message is being loaded and then handle it
somehow? Are the stats on the number of users with HTML - enabled email
clients so high that it isn't a concern? Is there a way to hide the HTML
from non-html clients?
Thanks in advance for any information!
-
Re: HTML based email. What to do about non-html clients?
If your recipients are opting in then ask them when the sign up.
If your recipients are victims and you are sending Spam then don't send
anything.
If you don't want to ask up front or you are unsure about their clients,
send plain text
--
Bradley Dean
"J Barlow" <Jason.Barlow@apollogrp.edu> wrote in message
news:3a6f2837$1@news.devx.com...
>
> I'm curious to find out how others have handled sending out html-based
email
> (as in direct email marketing campaigns) while accounting for those who
have
> clients that don't support HTML. Is there a way to recognize whether the
> client can handle email as the message is being loaded and then handle it
> somehow? Are the stats on the number of users with HTML - enabled email
> clients so high that it isn't a concern? Is there a way to hide the HTML
> from non-html clients?
>
> Thanks in advance for any information!
-
Re: HTML based email. What to do about non-html clients?
Thanks for the quick response, Bradley. Just to clarify, we're in the situation
of having tens of thousands of email addresses from people who have inquired
about our product. Unfortunately, we didn't have the foresite to ask if
they want html or text responses. I believe html email can be so much more
effective that I hated to waste this opportunity to use it.
Thanks again.
"T. Bradley Dean" <Bradley.Dean@InfoDish.com> wrote:
>If your recipients are opting in then ask them when the sign up.
>If your recipients are victims and you are sending Spam then don't send
>anything.
>If you don't want to ask up front or you are unsure about their clients,
>send plain text
>
>--
>Bradley Dean
>
>
>"J Barlow" <Jason.Barlow@apollogrp.edu> wrote in message
>news:3a6f2837$1@news.devx.com...
>>
>> I'm curious to find out how others have handled sending out html-based
>email
>> (as in direct email marketing campaigns) while accounting for those who
>have
>> clients that don't support HTML. Is there a way to recognize whether
the
>> client can handle email as the message is being loaded and then handle
it
>> somehow? Are the stats on the number of users with HTML - enabled email
>> clients so high that it isn't a concern? Is there a way to hide the HTML
>> from non-html clients?
>>
>> Thanks in advance for any information!
>
>
-
Re: HTML based email. What to do about non-html clients?
I know how you feel. It can be much more effective!
However, Netiquette dictates plain text. There is no way to check
capabilities on the client side because that would have to done in HTML and
would therefore only work with HTML clients. Kinda a catch-22.
--
Bradley Dean
"J Barlow" <Jason.Barlow@apollogrp.edu> wrote in message
news:3a6f328e$1@news.devx.com...
>
> Thanks for the quick response, Bradley. Just to clarify, we're in the
situation
> of having tens of thousands of email addresses from people who have
inquired
> about our product. Unfortunately, we didn't have the foresite to ask if
> they want html or text responses. I believe html email can be so much
more
> effective that I hated to waste this opportunity to use it.
>
> Thanks again.
>
> "T. Bradley Dean" <Bradley.Dean@InfoDish.com> wrote:
> >If your recipients are opting in then ask them when the sign up.
> >If your recipients are victims and you are sending Spam then don't send
> >anything.
> >If you don't want to ask up front or you are unsure about their clients,
> >send plain text
> >
> >--
> >Bradley Dean
> >
> >
> >"J Barlow" <Jason.Barlow@apollogrp.edu> wrote in message
> >news:3a6f2837$1@news.devx.com...
> >>
> >> I'm curious to find out how others have handled sending out html-based
> >email
> >> (as in direct email marketing campaigns) while accounting for those who
> >have
> >> clients that don't support HTML. Is there a way to recognize whether
> the
> >> client can handle email as the message is being loaded and then handle
> it
> >> somehow? Are the stats on the number of users with HTML - enabled
email
> >> clients so high that it isn't a concern? Is there a way to hide the
HTML
> >> from non-html clients?
> >>
> >> Thanks in advance for any information!
> >
> >
>
-
Re: HTML based email. What to do about non-html clients?
Send out plain text for your first email message and include a link so users
can request future messages in HTML (or to cancel future messages
altogether).
"T. Bradley Dean" <Bradley.Dean@InfoDish.com> wrote in message
news:3a6f33d0$1@news.devx.com...
> I know how you feel. It can be much more effective!
>
> However, Netiquette dictates plain text. There is no way to check
> capabilities on the client side because that would have to done in HTML
and
> would therefore only work with HTML clients. Kinda a catch-22.
>
> --
> Bradley Dean
>
>
> "J Barlow" <Jason.Barlow@apollogrp.edu> wrote in message
> news:3a6f328e$1@news.devx.com...
> >
> > Thanks for the quick response, Bradley. Just to clarify, we're in the
> situation
> > of having tens of thousands of email addresses from people who have
> inquired
> > about our product. Unfortunately, we didn't have the foresite to ask if
> > they want html or text responses. I believe html email can be so much
> more
> > effective that I hated to waste this opportunity to use it.
> >
> > Thanks again.
> >
> > "T. Bradley Dean" <Bradley.Dean@InfoDish.com> wrote:
> > >If your recipients are opting in then ask them when the sign up.
> > >If your recipients are victims and you are sending Spam then don't send
> > >anything.
> > >If you don't want to ask up front or you are unsure about their
clients,
> > >send plain text
> > >
> > >--
> > >Bradley Dean
> > >
> > >
> > >"J Barlow" <Jason.Barlow@apollogrp.edu> wrote in message
> > >news:3a6f2837$1@news.devx.com...
> > >>
> > >> I'm curious to find out how others have handled sending out
html-based
> > >email
> > >> (as in direct email marketing campaigns) while accounting for those
who
> > >have
> > >> clients that don't support HTML. Is there a way to recognize whether
> > the
> > >> client can handle email as the message is being loaded and then
handle
> > it
> > >> somehow? Are the stats on the number of users with HTML - enabled
> email
> > >> clients so high that it isn't a concern? Is there a way to hide the
> HTML
> > >> from non-html clients?
> > >>
> > >> Thanks in advance for any information!
> > >
> > >
> >
>
>
-
Re: HTML based email. What to do about non-html clients?
HTML is more professional and it encourages more click throughs. Most people
today use Outlook 98 or Outlook 2000 and they both support HTML so I think
you should take advantage of it.
However for people that can only accept text then it is important they can
at least read the email. We have had a monthly email for many years now.
One problem that we have encountered was that we decided to include a dropdown
menu in the email. We finally found a plain menu that was at least readable
if they couldn't read HTML email
For an example of the current newsletter see
http://www.ssw.com.au/ssw/accessug/s...te/2001jan.htm
Copy the HTML source and modify as you like.
PS: You will notice that the menu is much plainer than the one at http://www.ssw.com.au
- that menu is not appropriate for a HTML email
HTH
Adam
HOT UTILITIES FOR ACCESS AND VB DEVELOPERS
AT www.ssw.com.au
BTW A little tip: I think it is better to keep each topic short to encourage
a click through if they are interested because:
* Doesn't piss people off with large emails,
* Saves your bandwidth on large email distributions
* Allows you to look at the stats and see what topics interested your readers.
"J Barlow" <Jason.Barlow@apollogrp.edu> wrote:
>
>I'm curious to find out how others have handled sending out html-based email
>(as in direct email marketing campaigns) while accounting for those who
have
>clients that don't support HTML. Is there a way to recognize whether the
>client can handle email as the message is being loaded and then handle it
>somehow? Are the stats on the number of users with HTML - enabled email
>clients so high that it isn't a concern? Is there a way to hide the HTML
>from non-html clients?
>
>Thanks in advance for any information!
-
Re: HTML based email. What to do about non-html clients?
you could send both versions, I've noticed in fact that's what I get sometimes
from devX one text, one html of the same thing.
"Adam Cogan" <adamcogan@ssw.com.au> wrote:
>
>HTML is more professional and it encourages more click throughs. Most people
>today use Outlook 98 or Outlook 2000 and they both support HTML so I think
>you should take advantage of it.
>
>However for people that can only accept text then it is important they can
>at least read the email. We have had a monthly email for many years now.
>
>
>One problem that we have encountered was that we decided to include a dropdown
>menu in the email. We finally found a plain menu that was at least readable
>if they couldn't read HTML email
>
>For an example of the current newsletter see
>http://www.ssw.com.au/ssw/accessug/s...te/2001jan.htm
>Copy the HTML source and modify as you like.
>
>PS: You will notice that the menu is much plainer than the one at http://www.ssw.com.au
>- that menu is not appropriate for a HTML email
>
>HTH
>
>Adam
>HOT UTILITIES FOR ACCESS AND VB DEVELOPERS
>AT www.ssw.com.au
>
>BTW A little tip: I think it is better to keep each topic short to encourage
>a click through if they are interested because:
>* Doesn't piss people off with large emails,
>* Saves your bandwidth on large email distributions
>* Allows you to look at the stats and see what topics interested your readers.
>
>
>
>"J Barlow" <Jason.Barlow@apollogrp.edu> wrote:
>>
>>I'm curious to find out how others have handled sending out html-based
email
>>(as in direct email marketing campaigns) while accounting for those who
>have
>>clients that don't support HTML. Is there a way to recognize whether the
>>client can handle email as the message is being loaded and then handle
it
>>somehow? Are the stats on the number of users with HTML - enabled email
>>clients so high that it isn't a concern? Is there a way to hide the HTML
>>from non-html clients?
>>
>>Thanks in advance for any information!
>
-
Re: HTML based email. What to do about non-html clients?
Absolutely, use a Multi part message.
We use that type of message in the Divorce-Online.co.uk newsletter. Outlook
and similar will display the HTML version of the message, whereas Pegasus
and the like will display the Text version (or at the worst, will display
the text version followed by the raw html in very old clients)
If you need help generating a multipart mail, e-mail me and I'll post the
answer here.
Antony
Mediasource
"bryan" <bry@itnisk.com> wrote:
>
>you could send both versions, I've noticed in fact that's what I get sometimes
>from devX one text, one html of the same thing.
>
>
>
>"Adam Cogan" <adamcogan@ssw.com.au> wrote:
>>
>>HTML is more professional and it encourages more click throughs. Most people
>>today use Outlook 98 or Outlook 2000 and they both support HTML so I think
>>you should take advantage of it.
>>
>>However for people that can only accept text then it is important they
can
>>at least read the email. We have had a monthly email for many years now.
>>
>>
>>One problem that we have encountered was that we decided to include a dropdown
>>menu in the email. We finally found a plain menu that was at least readable
>>if they couldn't read HTML email
>>
>>For an example of the current newsletter see
>>http://www.ssw.com.au/ssw/accessug/s...te/2001jan.htm
>>Copy the HTML source and modify as you like.
>>
>>PS: You will notice that the menu is much plainer than the one at http://www.ssw.com.au
>>- that menu is not appropriate for a HTML email
>>
>>HTH
>>
>>Adam
>>HOT UTILITIES FOR ACCESS AND VB DEVELOPERS
>>AT www.ssw.com.au
>>
>>BTW A little tip: I think it is better to keep each topic short to encourage
>>a click through if they are interested because:
>>* Doesn't piss people off with large emails,
>>* Saves your bandwidth on large email distributions
>>* Allows you to look at the stats and see what topics interested your readers.
>>
>>
>>
>>"J Barlow" <Jason.Barlow@apollogrp.edu> wrote:
>>>
>>>I'm curious to find out how others have handled sending out html-based
>email
>>>(as in direct email marketing campaigns) while accounting for those who
>>have
>>>clients that don't support HTML. Is there a way to recognize whether
the
>>>client can handle email as the message is being loaded and then handle
>it
>>>somehow? Are the stats on the number of users with HTML - enabled email
>>>clients so high that it isn't a concern? Is there a way to hide the HTML
>>>from non-html clients?
>>>
>>>Thanks in advance for any information!
>>
>
-
Re: HTML based email. What to do about non-html clients?
Antony
Please explain how you create a multi-part mail. I've a seen similar thing
from Installshield in their monthly newsletter and would love to use this
here.
Thanks
Rik
"Antony" <antony@mediasource.co.uk> wrote:
>
>Absolutely, use a Multi part message.
>
>We use that type of message in the Divorce-Online.co.uk newsletter. Outlook
>and similar will display the HTML version of the message, whereas Pegasus
>and the like will display the Text version (or at the worst, will display
>the text version followed by the raw html in very old clients)
>
>If you need help generating a multipart mail, e-mail me and I'll post the
>answer here.
>
>Antony
>Mediasource
>
>"bryan" <bry@itnisk.com> wrote:
>>
>>you could send both versions, I've noticed in fact that's what I get sometimes
>>from devX one text, one html of the same thing.
>>
>>
>>
>>"Adam Cogan" <adamcogan@ssw.com.au> wrote:
>>>
>>>HTML is more professional and it encourages more click throughs. Most
people
>>>today use Outlook 98 or Outlook 2000 and they both support HTML so I think
>>>you should take advantage of it.
>>>
>>>However for people that can only accept text then it is important they
>can
>>>at least read the email. We have had a monthly email for many years now.
>>>
>>>
>>>One problem that we have encountered was that we decided to include a
dropdown
>>>menu in the email. We finally found a plain menu that was at least readable
>>>if they couldn't read HTML email
>>>
>>>For an example of the current newsletter see
>>>http://www.ssw.com.au/ssw/accessug/s...te/2001jan.htm
>>>Copy the HTML source and modify as you like.
>>>
>>>PS: You will notice that the menu is much plainer than the one at http://www.ssw.com.au
>>>- that menu is not appropriate for a HTML email
>>>
>>>HTH
>>>
>>>Adam
>>>HOT UTILITIES FOR ACCESS AND VB DEVELOPERS
>>>AT www.ssw.com.au
>>>
>>>BTW A little tip: I think it is better to keep each topic short to encourage
>>>a click through if they are interested because:
>>>* Doesn't piss people off with large emails,
>>>* Saves your bandwidth on large email distributions
>>>* Allows you to look at the stats and see what topics interested your
readers.
>>>
>>>
>>>
>>>"J Barlow" <Jason.Barlow@apollogrp.edu> wrote:
>>>>
>>>>I'm curious to find out how others have handled sending out html-based
>>email
>>>>(as in direct email marketing campaigns) while accounting for those who
>>>have
>>>>clients that don't support HTML. Is there a way to recognize whether
>the
>>>>client can handle email as the message is being loaded and then handle
>>it
>>>>somehow? Are the stats on the number of users with HTML - enabled email
>>>>clients so high that it isn't a concern? Is there a way to hide the
HTML
>>>>from non-html clients?
>>>>
>>>>Thanks in advance for any information!
>>>
>>
>
-
Re: HTML based email. What to do about non-html clients?
You can try http://www.arsdigita.com/asj/mime/ where they describe the technical
principles, or an article on PHP Builder http://www.phpbuilder.com/columns/kartic20000807.php3
which should be easy enough to translate to ASP ?
Mark
"Rik" <rbysouth@vbug.co.uk> wrote:
>
>Antony
>
>Please explain how you create a multi-part mail. I've a seen similar thing
>from Installshield in their monthly newsletter and would love to use this
>here.
>
>Thanks
>
>Rik
>
>"Antony" <antony@mediasource.co.uk> wrote:
>>
>>Absolutely, use a Multi part message.
>>
>>We use that type of message in the Divorce-Online.co.uk newsletter. Outlook
>>and similar will display the HTML version of the message, whereas Pegasus
>>and the like will display the Text version (or at the worst, will display
>>the text version followed by the raw html in very old clients)
>>
>>If you need help generating a multipart mail, e-mail me and I'll post the
>>answer here.
>>
>>Antony
>>Mediasource
>>
>>"bryan" <bry@itnisk.com> wrote:
>>>
>>>you could send both versions, I've noticed in fact that's what I get sometimes
>>>from devX one text, one html of the same thing.
>>>
>>>
>>>
>>>"Adam Cogan" <adamcogan@ssw.com.au> wrote:
>>>>
>>>>HTML is more professional and it encourages more click throughs. Most
>people
>>>>today use Outlook 98 or Outlook 2000 and they both support HTML so I
think
>>>>you should take advantage of it.
>>>>
>>>>However for people that can only accept text then it is important they
>>can
>>>>at least read the email. We have had a monthly email for many years now.
>>>>
>>>>
>>>>One problem that we have encountered was that we decided to include a
>dropdown
>>>>menu in the email. We finally found a plain menu that was at least readable
>>>>if they couldn't read HTML email
>>>>
>>>>For an example of the current newsletter see
>>>>http://www.ssw.com.au/ssw/accessug/s...te/2001jan.htm
>>>>Copy the HTML source and modify as you like.
>>>>
>>>>PS: You will notice that the menu is much plainer than the one at http://www.ssw.com.au
>>>>- that menu is not appropriate for a HTML email
>>>>
>>>>HTH
>>>>
>>>>Adam
>>>>HOT UTILITIES FOR ACCESS AND VB DEVELOPERS
>>>>AT www.ssw.com.au
>>>>
>>>>BTW A little tip: I think it is better to keep each topic short to encourage
>>>>a click through if they are interested because:
>>>>* Doesn't piss people off with large emails,
>>>>* Saves your bandwidth on large email distributions
>>>>* Allows you to look at the stats and see what topics interested your
>readers.
>>>>
>>>>
>>>>
>>>>"J Barlow" <Jason.Barlow@apollogrp.edu> wrote:
>>>>>
>>>>>I'm curious to find out how others have handled sending out html-based
>>>email
>>>>>(as in direct email marketing campaigns) while accounting for those
who
>>>>have
>>>>>clients that don't support HTML. Is there a way to recognize whether
>>the
>>>>>client can handle email as the message is being loaded and then handle
>>>it
>>>>>somehow? Are the stats on the number of users with HTML - enabled email
>>>>>clients so high that it isn't a concern? Is there a way to hide the
>HTML
>>>>>from non-html clients?
>>>>>
>>>>>Thanks in advance for any information!
>>>>
>>>
>>
>
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Development Centers
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center
|