HTML based email. What to do about non-html clients?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 10 of 10

Thread: HTML based email. What to do about non-html clients?

Hybrid View

  1. #1
    J Barlow Guest

    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!

  2. #2
    T. Bradley Dean Guest

    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!




  3. #3
    J Barlow Guest

    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!

    >
    >



  4. #4
    T. Bradley Dean Guest

    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!

    > >
    > >

    >




  5. #5
    Russell Jones Guest

    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!
    > > >
    > > >

    > >

    >
    >




  6. #6
    Adam Cogan Guest

    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!



  7. #7
    bryan Guest

    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!

    >



  8. #8
    Antony Guest

    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!

    >>

    >



  9. #9
    Rik Guest

    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!
    >>>

    >>

    >



  10. #10
    Mark Guest

    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
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center