We actually have hired Mr. Usborne for various projects in the past and well aware of him.
What I am trying to understand is if someone has any insight as to any 'cons' to using the multipart alternative and scraping the process of choosing text or html as separate settings. I seriously doubt any sizeable chunk of the population are filtering emails because images may mean a sales message. We have done HTML emails for several large retailers (GAP.com, Nordstrom.com, Levis.com and Disney.com) and I can tell you, based on the results, they will never again use straight text email. The science behind the numbers is clear... text is good, images are better and multimedia kicks a$$. However, each has their own place. We use TEXT for basic daily newsletters and wireless messages, HTML for direct response (sale or lead generation) emails, and now getting more and more into rich emails (flash) and seeing response rates that go through the roof. The bottomline for us is: Is there just one thing that would make it a bad decision to go with multipart alternative and allow the settings of the client to determine HTML or Text. We send more than 20,000,000 emails per month for our clients and if I can remove 50% of the code - which would quicken the processing the file that creates and distrubutes the .mail and .mbx files across our POST cluster - I will save a ton of money and time (time is money). ***** Is there even one reason why you would not use multipart alternative and send TEXT and HTML formats letting the client application determine the view? ***** Matt Boyce -----Original Message----- From: [EMAIL PROTECTED] (paul smith) [mailto:[EMAIL PROTECTED] (paul smith)] Sent: Wednesday, February 20, 2002 4:12 PM To: inFusion Support List Subject: Re: [iMS] questions on email format part duex Recent discussions I've seen on Marketing Lists suggest the tide has turned over the last year or so and the vast majority of users accept HTMLed messages without complaint. However, they do recommend that, at least for marketing messages, it's better to confine the HTML to basic stuff, and no images. Some claim images are an immediate tip off to subscribers that they are going to get a hard sell and they are more likely to delete without hesitation. (Interestingly, I recall my reaction was this same way when the Iconocast list went HTML many months ago.) Nick Usborne has some interesting disagreements with this, particularly for AOL subscribers. But copywriting email is an art unto itself. I wish I could do it well. I recommend "net words, Creating High-Impact Online Copy" by Nick Usborne. best, paul At 03:42 PM 2/20/02 -0600, you wrote: >Ya'll, > >What is the overall opinion of moving toward sending multipart alternative >(with a text and html format) for all emails versus, making a specific text >and specific html format? > >Our email system is becoming too difficult to manage and I am looking for >ways that we can consolidate code and streamline our process. > >If we went with multipart-alternative we could eliminate about 50% of the >code in file that processes our email as it also needs to contain the code >for processing plain text and html only emails and in three different >formats (cfx tag with no dynamic content, cfx tag with cfloop and dynamic >content, and our homegrown cffile and cfloop system - used about 90% of the >time - for highly dynamic emails with personalized tracking images and >tracking links). > >The "Pros" of multipart-alternative are obvious, but what are the deal >stopping "Cons"? > > >Matt Boyce > > > ==^======================================================= This list server is Powered by iMS "The Swiss Army Knife of Mail Servers" -------------------------------------- To leave this list please complete the form at http://www.coolfusion.com/iMSSupport.cfm Need an iMS Developer license? Sign up for a free license here: http://www.coolfusion.com/iMSDevelopers.cfm List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/ Note: You are subscribed as [email protected] ==^=======================================================
