Test e-mail looks different than preview - and test looks different in each e-mail service

Options

Hi,

Does anyone know why when I preview the e-mail I've created it looks perfect, but when I send a test e-mail to my work address, gmail and hotmail, the following things occur to the HTML message:

Work inbox: message didn't arrive

Gmail: Most of the message is missing and there are three blue messages that say "Show quoted text" and when I click on that, the message appears but some of it is a different color than it should be.

Hotmail: Looks almost perfect, except the first 2/3 of the message is centered, when it should be left aligned.

I am brand new to Convio, so have no idea where to begin!

Thank you!

Tagged:

Comments

  • Andrea, there are two things at work here.

    First, each web browser and each email client have slightly different ways of interpreting HTML code. Small, negligible variations (such as a few pixels more space between two lines of text, for example) between them are normal. The different email clients and services also have all their own quirks: Thunderbird doesn't like some images when floated, Outlook removes colspan attributes from table data cells when forwarding, Gmail ignores classes assigned to heading tags in embedded stylesheets and breaks some table displays when rolling messages into conversations, Yahoo strips out margins on paragraphs inside tables and ignores some floats...the list goes on.

    Second, the HTML code Convio generates on both the CRM and CMS sides is abominable. It doesn't conform to any standard. Without verifiable, solid code on the backend, there's no way to plan for the normal changes between browsers and clients. Unfortunately, the only solution I've found to get around this issue is to hand code all of our more complex newsletters and set some of my less technical users up with code templates so that they can make small changes using Convio's UI after they paste HTML in.

    You can try making changes to your newsletter to mitigate these issues, but without getting your hands dirty with HTML, there may be no way to completely fix the issues you're seeing.

  • Jim Drey:

    Andrea, there are two things at work here.

    First, each web browser and each email client have slightly different ways of interpreting HTML code. Small, negligible variations (such as a few pixels more space between two lines of text, for example) between them are normal. The different email clients and services also have all their own quirks: Thunderbird doesn't like some images when floated, Outlook removes colspan attributes from table data cells when forwarding, Gmail ignores classes assigned to heading tags in embedded stylesheets and breaks some table displays when rolling messages into conversations, Yahoo strips out margins on paragraphs inside tables and ignores some floats...the list goes on.

    Second, the HTML code Convio generates on both the CRM and CMS sides is abominable. It doesn't conform to any standard. Without verifiable, solid code on the backend, there's no way to plan for the normal changes between browsers and clients. Unfortunately, the only solution I've found to get around this issue is to hand code all of our more complex newsletters and set some of my less technical users up with code templates so that they can make small changes using Convio's UI after they paste HTML in.

    You can try making changes to your newsletter to mitigate these issues, but without getting your hands dirty with HTML, there may be no way to completely fix the issues you're seeing.

    Thank you, Jim.

    I don't know HTML so I'm completely lost. I'll be taking a class but not until March!

    Do you think it's acceptable to send an e-mail that looks a little different in each email client and web browser?

    Thanks again,

    Andrea

  • Andrea Polonetsky:

    Thank you, Jim.

    I don't know HTML so I'm completely lost. I'll be taking a class but not until March!

    Do you think it's acceptable to send an e-mail that looks a little different in each email client and web browser?

    Thanks again,

    Andrea

    Most people will never know. If given the changes you see you find the display acceptable in the various clients, then I'd go ahead and send it. You're aware of this issue and you're already doing testing to see what's different, which puts you well ahead of many!

  • Jim Drey:

    Most people will never know. If given the changes you see you find the display acceptable in the various clients, then I'd go ahead and send it. You're aware of this issue and you're already doing testing to see what's different, which puts you well ahead of many!

    Okay, thanks again Jim!

  • Andrea Polonetsky:

    Okay, thanks again Jim!

    Hello, Andrea.

    I HEAR you and your concerns!

    I've been working with Convio since March and we've been live since September 2008, pretty new.

    I don't know HTML either, so using ANY of Convio is proving to be much more difficult than we were originally told when we bought Convio.

    What I've learned through sending e-mail blasts to our database is that it's very difficult to get any sort of sense what the real e-mail will look like. It does look differnt in preview, test e-mail and in each browser.

    Someone on this community site suggested to me that I "test" the e-mail message by sending it to people that can test it for me on the "reviewer" list before sending out the real version. I haven't tried this yet, but it might be useful for you.

    Let me know.

    Thanks.

    Tracie

  • Hey Andrea,

    Tracie mentions a fantastic testing best practice. As with any WYSIWYG editor it tries it's best to interpert what you are doing into the raw HTML. Sometimes it does very very well sometimes it doesn't. Since this is the reality of using a WYSIWYG over hand coded HTML there are three suggestions that I make.

    1. Don't try to recycle the same message indefinately.

    For instance if you have a weekly newsletter that goes out. Setup a template message that you will be swapping your content into. Copy that message to create each new week instead of copying last weeks which was copied from the week before and so on. The reason behind this is it prevents any dead wood html from accumulating over time (since you aren't really into HTML I won't go into the details of why this happens).

    2. Sign up for a bunch of different free email account.

    If you can try and get a sense of what email clients your constituents are using sign up for accounts on the most frequently occuring domains: Gmail, hotmail, yahoo, etc. Then create a test user for each test account in Convio. Make these test users your reviewer group for the message. This allows you to accomplish two things at once. You will get to see if the message is going to show differently in different clients and also fully test any personalizations you may have put in the message.

    3. Start downloading browsers.

    Not only do different email systems/clients render html differently but as the first commentor put it so do browsers. If you want to take your message testing to the next level see what the message looks like in different browsers when using each different email domain. This is also important testing when you are designing new webpages and is considered a best practice for web design.

    -Andrew

  • Andrew :

    Hey Andrea,

    Tracie mentions a fantastic testing best practice. As with any WYSIWYG editor it tries it's best to interpert what you are doing into the raw HTML. Sometimes it does very very well sometimes it doesn't. Since this is the reality of using a WYSIWYG over hand coded HTML there are three suggestions that I make.

    1. Don't try to recycle the same message indefinately.

    For instance if you have a weekly newsletter that goes out. Setup a template message that you will be swapping your content into. Copy that message to create each new week instead of copying last weeks which was copied from the week before and so on. The reason behind this is it prevents any dead wood html from accumulating over time (since you aren't really into HTML I won't go into the details of why this happens).

    2. Sign up for a bunch of different free email account.

    If you can try and get a sense of what email clients your constituents are using sign up for accounts on the most frequently occuring domains: Gmail, hotmail, yahoo, etc. Then create a test user for each test account in Convio. Make these test users your reviewer group for the message. This allows you to accomplish two things at once. You will get to see if the message is going to show differently in different clients and also fully test any personalizations you may have put in the message.

    3. Start downloading browsers.

    Not only do different email systems/clients render html differently but as the first commentor put it so do browsers. If you want to take your message testing to the next level see what the message looks like in different browsers when using each different email domain. This is also important testing when you are designing new webpages and is considered a best practice for web design.

    -Andrew

    This is very helpful, thanks for taking the time to send this Andrew!

  • Andrew :

    Hey Andrea,

    Tracie mentions a fantastic testing best practice. As with any WYSIWYG editor it tries it's best to interpert what you are doing into the raw HTML. Sometimes it does very very well sometimes it doesn't. Since this is the reality of using a WYSIWYG over hand coded HTML there are three suggestions that I make.

    1. Don't try to recycle the same message indefinately.

    For instance if you have a weekly newsletter that goes out. Setup a template message that you will be swapping your content into. Copy that message to create each new week instead of copying last weeks which was copied from the week before and so on. The reason behind this is it prevents any dead wood html from accumulating over time (since you aren't really into HTML I won't go into the details of why this happens).

    2. Sign up for a bunch of different free email account.

    If you can try and get a sense of what email clients your constituents are using sign up for accounts on the most frequently occuring domains: Gmail, hotmail, yahoo, etc. Then create a test user for each test account in Convio. Make these test users your reviewer group for the message. This allows you to accomplish two things at once. You will get to see if the message is going to show differently in different clients and also fully test any personalizations you may have put in the message.

    3. Start downloading browsers.

    Not only do different email systems/clients render html differently but as the first commentor put it so do browsers. If you want to take your message testing to the next level see what the message looks like in different browsers when using each different email domain. This is also important testing when you are designing new webpages and is considered a best practice for web design.

    -Andrew

    Andrea,

    I'd like to amplify one part of Andrew's post about the unpredictability of how HTML renders in email clients. The unfortunate reality is that there is no standard for how HTML should appear in email. HTML was not designed for use in email messages, only web pages. Even with concrete standards for how HTML should appear in web browsers, there is significant variation between how a page looks in one browser and the next. With email, all bets are off. If one email service decides that all links should appear in a bright pink, bold font, then that's as valid as any other way for them to look. JimDrey listed several quirks in how different email clients display HTML, and all of them are equally correct (or equally wrong). If you get your message to look the way you want in one email reader, there's no guarantee it will look similar when viewed elsewhere. Therefore, it's critical that you preview your message in many different email clients, as in Andrew's second suggestion.

    With all that in mind, there is one practice that I suggest looking into once you're ready to read and write HTML. Using inline CSS styles currently provides the most reliable way to design the appearance of your message. Clients like Yahoo! mail and Gmail may ignore styles in a block, but putting styles in the style="" attribute of your HTML tags should work more reliably. At least it'll work as reliably as any HTML in an email message.

    I expect most of the previous paragraph about inline styles doesn't mean anything to you yet, so don't worry about it for now. I applaud your choice to get training in HTML. The best way to understand how your content behaves is to read the code.

    Regards,

    Ben

  • Ben Breakstone:

    Andrea,

    I'd like to amplify one part of Andrew's post about the unpredictability of how HTML renders in email clients. The unfortunate reality is that there is no standard for how HTML should appear in email. HTML was not designed for use in email messages, only web pages. Even with concrete standards for how HTML should appear in web browsers, there is significant variation between how a page looks in one browser and the next. With email, all bets are off. If one email service decides that all links should appear in a bright pink, bold font, then that's as valid as any other way for them to look. JimDrey listed several quirks in how different email clients display HTML, and all of them are equally correct (or equally wrong). If you get your message to look the way you want in one email reader, there's no guarantee it will look similar when viewed elsewhere. Therefore, it's critical that you preview your message in many different email clients, as in Andrew's second suggestion.

    With all that in mind, there is one practice that I suggest looking into once you're ready to read and write HTML. Using inline CSS styles currently provides the most reliable way to design the appearance of your message. Clients like Yahoo! mail and Gmail may ignore styles in a block, but putting styles in the style="" attribute of your HTML tags should work more reliably. At least it'll work as reliably as any HTML in an email message.

    I expect most of the previous paragraph about inline styles doesn't mean anything to you yet, so don't worry about it for now. I applaud your choice to get training in HTML. The best way to understand how your content behaves is to read the code.

    Regards,

    Ben

    A couple other gotchas to point out here:

    1. You can only have ONE version of Internet Explorer running on any given Windows instance. That mean if you have IE 7 right now, you can't also install IE 6. Convio, in my experience, performs erratically at best under IE 8 BETA -- don't ever install Microsoft Beta software (er. any other *nix junkies out there who feel that's sort of a redundant statement??). I've used a program called Multiple IE () for years, but it's no longer supported or maintained and I've noticed in recent months it has a few problems likely due to Windows updates. I've already tried IE under WINE on Fedora and, weirdly, you can only have one there too -- I sure wish IE would just go away and leave us all alone.

    2. When you're building email stationary in Convio, step 2 allows you to develop a Style Sheet for the stationary. When you do this, you'll probably get a very pretty and tightly designed HTML template for your emails that look great in Preview, but then crash and burn in most HTML email clients. That's because the stationary tool in Convio drops those styles in as a <style> element. As Ben said, don't rely on that. In general, best practices indicate you shouldn't use inline style attributes ever, although they are valid under even the current strict XHTML 1.0 and are also valid in the XHTML 2.0 strict proposals. The idea is they are useful and necessary sometimes, but should be avioded. The problem is, HTML email clients haven't kept up with web browsers, and, more to the point, when you are using a web page to view HTML, it's possible for the CSS in the email to affect the layout of the web-based email client itself when styles are used outside of the element scope (that means the style="" attribute on a tag, rather than the <style> block element). So.... you don't really have a lot of choice... CSS is better than not, so use what works.

    Some of this is probably techno-babble to you right now, but if you're planning to take a class in HTML, most of what I mentioned should be more clear.

  • Ben Breakstone:

    Andrea,

    I'd like to amplify one part of Andrew's post about the unpredictability of how HTML renders in email clients. The unfortunate reality is that there is no standard for how HTML should appear in email. HTML was not designed for use in email messages, only web pages. Even with concrete standards for how HTML should appear in web browsers, there is significant variation between how a page looks in one browser and the next. With email, all bets are off. If one email service decides that all links should appear in a bright pink, bold font, then that's as valid as any other way for them to look. JimDrey listed several quirks in how different email clients display HTML, and all of them are equally correct (or equally wrong). If you get your message to look the way you want in one email reader, there's no guarantee it will look similar when viewed elsewhere. Therefore, it's critical that you preview your message in many different email clients, as in Andrew's second suggestion.

    With all that in mind, there is one practice that I suggest looking into once you're ready to read and write HTML. Using inline CSS styles currently provides the most reliable way to design the appearance of your message. Clients like Yahoo! mail and Gmail may ignore styles in a block, but putting styles in the style="" attribute of your HTML tags should work more reliably. At least it'll work as reliably as any HTML in an email message.

    I expect most of the previous paragraph about inline styles doesn't mean anything to you yet, so don't worry about it for now. I applaud your choice to get training in HTML. The best way to understand how your content behaves is to read the code.

    Regards,

    Ben

    Hi Ben,

    Thanks so much for the explanation. You're right. This doesn't mean much to me now, but I will reread your message in a couple months after my class and I'm sure it will be very helpful.

    Thanks very much,

    Andrea

  • Michael :

    A couple other gotchas to point out here:

    1. You can only have ONE version of Internet Explorer running on any given Windows instance. That mean if you have IE 7 right now, you can't also install IE 6. Convio, in my experience, performs erratically at best under IE 8 BETA -- don't ever install Microsoft Beta software (er. any other *nix junkies out there who feel that's sort of a redundant statement??). I've used a program called Multiple IE () for years, but it's no longer supported or maintained and I've noticed in recent months it has a few problems likely due to Windows updates. I've already tried IE under WINE on Fedora and, weirdly, you can only have one there too -- I sure wish IE would just go away and leave us all alone.

    2. When you're building email stationary in Convio, step 2 allows you to develop a Style Sheet for the stationary. When you do this, you'll probably get a very pretty and tightly designed HTML template for your emails that look great in Preview, but then crash and burn in most HTML email clients. That's because the stationary tool in Convio drops those styles in as a <style> element. As Ben said, don't rely on that. In general, best practices indicate you shouldn't use inline style attributes ever, although they are valid under even the current strict XHTML 1.0 and are also valid in the XHTML 2.0 strict proposals. The idea is they are useful and necessary sometimes, but should be avioded. The problem is, HTML email clients haven't kept up with web browsers, and, more to the point, when you are using a web page to view HTML, it's possible for the CSS in the email to affect the layout of the web-based email client itself when styles are used outside of the element scope (that means the style="" attribute on a tag, rather than the <style> block element). So.... you don't really have a lot of choice... CSS is better than not, so use what works.

    Some of this is probably techno-babble to you right now, but if you're planning to take a class in HTML, most of what I mentioned should be more clear.

    Michael, you can run a modified version of IE6 standalone. Try the EOLAS-patched version here:

    http://browsers.evolt.org/?ie/32bit/standalone

    It has some issues: it won't load flash and pops up a box for content activation (stupid patent trolls...) but it will get you a look at your content in IE6.

    Or, if you're the adventurous type, here's how to roll your own IE standalone:

    http://labs.insert-title.com/Multiple-IEs-in-Windows_article795.aspx

    Or, if you want to go all out, there's always Sun's Virtualbox or VMware server (both free).

  • Jim Drey:

    Michael, you can run a modified version of IE6 standalone. Try the EOLAS-patched version here:

    http://browsers.evolt.org/?ie/32bit/standalone

    It has some issues: it won't load flash and pops up a box for content activation (stupid patent trolls...) but it will get you a look at your content in IE6.

    Or, if you're the adventurous type, here's how to roll your own IE standalone:

    http://labs.insert-title.com/Multiple-IEs-in-Windows_article795.aspx

    Or, if you want to go all out, there's always Sun's Virtualbox or VMware server (both free).

    I don't think anyone has mentioned Campaign Monitor's guide to how email clients treat CSS in this thread so I wanted to post the link.  It's an easy reference chart.  They recently updated the guide on August 6, 2009 to include 7 mobile email clients.  The website and chart includes the 10 most popular email clients, and the PDF you can download has 23.

    Here's the link:

    http://www.campaignmonitor.com/css/

  • Sally Heaven:

    I don't think anyone has mentioned Campaign Monitor's guide to how email clients treat CSS in this thread so I wanted to post the link.  It's an easy reference chart.  They recently updated the guide on August 6, 2009 to include 7 mobile email clients.  The website and chart includes the 10 most popular email clients, and the PDF you can download has 23.

    Here's the link:

    http://www.campaignmonitor.com/css/

    I've heard a few questions lately about email formating issues from clients so I thought I'd search the community and see what discussions have been posted here already.  I was glad to find this active discussion.  A couple more links that I'll share that some people may find helpful:

    http://www.email-standards.org/

    and there's a checklist for email messages of things to check for in your messages before sending to you audiences.  That can be found here:

    http://community.customer.convio.com/servlet/JiveServlet/download/1982-1-1290/QAChecklist_EmailMessage3-1.doc and I'll also attach it to this post.

  • http://litmusapp.com/

    This site is kind of like BrowserShots, except for email clients. You submit your content, and the site produces screen shots of your content on various clients so you can see where it fails. Its not free, but I think I'm going to give them a whirl.

    Snip from their site...

    For your email newsletters, Litmus tests your emails on all these email clients:

    Desktop email clients

    • Apple Mail 3
    • Apple Mail 2.1
    • Lotus Notes 8
    • Lotus Notes 7
    • Lotus Notes 6.5
    • Outlook 2007
    • Outlook 2003
    • Outlook 2002/XP
    • Outlook 2000
    • Thunderbird 3.0 Beta
    • Thunderbird 2.0

    Web-based email clients

    • AOL Mail
    • Gmail
    • Gmail (older version)
    • Live Hotmail
    • Mail.com
    • Mobile Me
    • Yahoo! Mail
    • Yahoo! Mail Classic

    Spam filters

    • Barracuda
    • Brightmail
    • MessageLabs
    • Postini
    • SpamAssassin
  • By the way, Browsershots is here...

    http://browsershots.org/

    They are getting kinda slow with the free service lately, so I might try the pay account. Still, pretty neat idea. You submit a link, and in a few minutes (15-20 really) you start seeing screen snapshots of your site on all kinds of browsers. Once in a while there is a glitch on some shots, but you still get a great preview of your content on up to 50 different web browsers.

  • One more point to make.

    I just went this same thing with my first html email blast. Ugh. (Thats why I searched for a Browsershots for email clients.)

    I read in my research that Outlook uses the MS *WORD* html rendering engine rather than the Explorer engine. Don't ask why they chose to do that, but I bet this is where many of our problems are coming from.

    A good rule seems to be to design your email's html like its 1998 rather than 2009. Easy on the styles. Layout with tables. That kind of thing.

    Bleah.

  • Hi Andrea,

    This is a lengthy article on the subject, but probably the best one I've seen:

    http://articles.sitepoint.com/print/code-html-email-newsletters

Categories