In this post, I talk about one of the absolute necessities of email, the attachment. Attachments are one thing that nobody wants to get rid of, even if they favor plain text mail. They were around long before most HTML email was thought of, and will likely be around for many years to come, at least until "the cloud" is truly ubiquitous and we can start passing links instead of attachments.
With this much riding on attachments, you might think it would be a hard thing to mess up. Unfortunately, you would be wrong, and as is becoming apparent with IBM mail to the outside world, there is always more than one way to mess up. It is hard to decide whether to use client or server based MIME rendering, as there are advantages and disadvantages to both. Incidentally, Gmail is used for this demo but the exact same results are seen with Outlook or other mail systems. Also, the rendering seen here is roughly the same in Notes 8 and previous versions.
Email created in Notes client with two attachments
Email received in Gmail after Notes 8.5 client rendering (attachments properly named, but with no indication of where they were originally)
Likely reply to email received back in Notes 8.5 (confusion about where attachments were originally)
Email received in Gmail after Domino 8.5 server rendering (indicator of where attachments were originally, but one attachment misnamed due to internal vs. external attachment names)
Likely reply to email received back in Notes 8.5 (confusion about what happened to document due to bad naming)
Email received in Gmail after iFidelity Beta 3 rendering (attachments named properly and original location indicated properly)
Likely reply to iFidelity email received back in Notes 8.5 (no confusion, and attachments even put back where they originally were)
Previous Topics in this series
In Part 1, I showed how IBM's rendering of MIME messages could lead your customers to think you were still running Notes R5, and how our upcoming iFidelity (sign up for the beta) would allow you to send out more professional looking email, rendered as it is in Notes. In Part 2, I showed how content rendered by Domino on the web was likely to make prospective customers think twice, or more, before buying Lotus Notes, and how CoexEdit could dramatically improve that default rendering. In Part 3, I showed how rendering is made even worse when the rich text is edited on the web, and how CoexEdit can improve that process as well. In Part 4, I showed how HTML signatures are prone to some of the same rendering issues (as well as different ones) as we have seen elsewhere. In Part 5, I showed how tabbed tables do not translate well through email, and how iFidelity could help. In Part 6, I showed how sections could lose titles after Notes client render, and how iFidelity could help there as well. In Part 7, I showed how checked and unchecked lists rendered badly, and how iFidelity could help.
Copyright © 2009 Genii Software Ltd.
Tags: Lotus Notes iFidelity