Hello MFPA,

On Sun, 15 Jun 2014 11:50:57 +0100 GMT (15-Jun-14, 17:50 +0700 GMT),
MFPA wrote:

>> Most emails (like the text messages here) do not
>> require HTML and should be sent as plaintext.

> I would say that no email requires HTML, only a very few emails
> benefit from it's use,

That either depends of the line of work you are in, or the century you
live in.

> and most of those would be better served by putting the formatted
> presentation in an attachment.

No, please do not send me attachments unless really necessary.

>> However, please do not put tables or small pictures in
>> the attachments. It is much more efficient to put them
>> into the body of the email.

> I disagree.

I see.

> For inserting into the email, the process is identical or very similar
> (in most email clients I have ever used) for attaching a file to a
> plaintext email or inserting it into an HTML email. So there is no
> efficiency gain or loss for the sender.

I was talking about the recipient of the message. I receive 200-300
emails in my business emails a day, and having to open attachments for
things that could be in the preview pane is highly inefficient.

> For the reader who views emails in plaintext, there is the ongoing
> efficiency gain of not wasting time looking at such attachments unless
> they find the message cannot be understood without: people often
> include such things without needing to.

I perfectly understand "attached kindly find the table as an Excel
file" when it consists of only two rows and two columns.

> And if the attachment needs to be seen, it is usually just a couple
> of mouse-clicks away.

Those mouse-clicks, and waiting for the application to open, waste
hours in a work day.

> When a sender includes pictures in their email body, this recipient
> finds them in their proper place as attachments, so no efficiency
> gain or loss.

The recipient doesn't need to open the attachment if the picture (for
example of the damages cargo) is already in the email body.

> When the sender has placed a formatted table in the message body, the
> recipient sometimes sees an unformatted mess of table entries one per
> line in their plaintext viewer, instead of an attachment.

Right. That's why TB! luckily has an HTML viewer, and we don't need
Outlook any more.

> One or two clicks and the recipient can be reading the table in
> their HTML viewer. No efficiency gain or loss between opening an
> attached table with a couple of clicks versus switching to HTML
> viewer with a couple of clicks.

It is a big efficiency loss. I wonder how many emails you receive per
day, and how often these have an attachment that could easily be
inserted into the body of the message. There is a *huge* difference in
efficiency, and that is my point.

> Placing the extras as attachments rather than inline in your HTML
> affords the same efficiency saving to your readers who view in HTML as
> are gained on an ongoing basis by those who choose to read emails in
> plaintext.

It is the same for the sender; it is the recipient who benefits - but
of course, only if he views HTML mails in HTML. If you insist on
viewing only in plaintext (as we did in the last century), you will
not understand it. Again my question: what line of business are you
in?

> It also makes your inserts appear more important, as the reader who
> clicks to open them is likely to pay attention than the reader who
> casts there eye over them when reading the body of an email.

Sure. Please do not try to make yourself important by making me waste
my time having to open attachments.

To make myself clear: I do not wish to receive messages in different
fonts or fancy colour, or with animated GIFs. However, HTML makes
sense in business, depending on what business you are in.

-- 

Cheers,
Thomas.

http://thomas.fernandez.hat-gar-keine-homepage.de/

Message reply created with The Bat! 6.4.6
under Windows 7 6.1 Build 7601 Service Pack 1


________________________________________________
Current version is 6.1.8 | 'Using TBUDL' information:
http://www.silverstones.com/thebat/TBUDLInfo.html

Reply via email to