28735 - Need Better Text in "Ask Me" Dialog of HTML Intelligent Send

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, enhancement)

Description

[sol]

The dialog that appears where an end user is asked whether to send a message as 
HTML, plain text, or both, needs to be re-worded. The text that currently 
appears is not understood by most end users of the email client - most users do 
not understand what HTML is, and what the implications are of this choice.

In the 4.x Netscape client, the preferences panel for HTML intelligent send 
(Preferences | Mail & Newsgroups | Formatting) explain the options better than 
the Ask Me dialog.

Steps to reproduce:
1. Launch Mail (Tasks | Mail)
2. Open a Mail compose window ("New Msg" on toolbar)
3. Address message to a person not known to be capable of reading HTML
4. Include HTML formatting in the body of the message
5. Send the message ("Send" on Mail compose toolbar)

Note: The "Ask Me" dialog is displayed and includes text that is not very 
understandable for the average user:

Current text:
Some of the recipients are not listed as being able to receive HTML mail. Would 
you like to convert the message to plain text or send it in HTML anyway?

(*) Send in plain text and HTML
( ) Send in plain text only
( ) Send in HTML only

Proposed text:
You have included formatting (HTML) in this email message. While many users will 
be able to view the message as you have written it, users of some email software 
may have trouble viewing the formatting (HTML) in this message. Would you like 
to:
(*) Send in plain text and formatted text (HTML)
     Recipients will be able to read your message whether or not they have email 
software that understands formatted text (HTML), but uses more disk space
( ) Send in plain text only
     You may lose some of the formatting (such as bold text) when the message is 
converted to plain text
( ) Send as formatted text (HTML)
     Users of some email software may have trouble viewing the formatting (HTML) 
in the message

cc:ing jglick and simone for help with the wording here.

Comment 1

[Phil Peterson]

sol nominates for beta1

Comment 2

[sol]

Nominating for beta1, since no users in a focus group we conducted understood 
the current language, making this feature *not* particularly helpful for them.

Also, since this involves change to the text of a dialog, it should be low risk.

Comment 3

[simone]

Perhaps we should repeat the same text used in the pref dialog? Although 
Sol's suggestion is good and comprehensive, I think it might be way too much 
to read, given the context of when the dialog is displayed -- i.e., the user 
just clicked Send and really just wants to get on with the task; this might be 
construed as an annoying (albeit useful) interruption. I would favor 
brevity for this message as opposed to more explanatory text. 

Also, this message occurs when the Formatting pref is set to "ask me", so 
perhaps we should use this opportunity to remind the user of this setting, 
should they wish to change it. I don't know that there's really any elegant way 
to phrase all this, but here goes:

"You have requested to be notified whenever you send a message to a recipient 
that is not listed as being able to receive HTML (formatted) mail. Many email 
programs can display formatted mail, but some may not. Would you like to:
* Convert the message to plain text (may lose formatting such as bold text)
* Send the message as both plain text and formatted (HTML) text (this uses more 
disk space)
* Send the message as formatted (HTML) text (some email programs may have 
trouble displaying the message)

You can skip this dialog box in the future and set other options for handling 
HTML messages: choose Preferences from the Edit menu and then select Formatting 
from the Mail and Newsgroup category."

Comment 4

[leger]

Putting on PDT- radar for beta1.

Comment 5

[sol]

After further discussion, here's what we came up with:

This email message contains formatting (HTML). Many email programs can display 
formatted email, but some may not. Would you like to:

     (*) Send the message as both plain text and formatted (HTML) text
          This uses more disk space
     ( ) Convert the message to plain text
          May lose formatting such as bold text
     ( ) Send the message as formatted (HTML) text
          Some email programs may have trouble displaying the message

If you know a recipient can receive formatted (HTML) email, you can designate 
this in the Netscape Address Book (by clicking on the "Recipients" button below, 
or by opening the Address Book).

Note: We should not include the reference to the Recipients button until we have 
built this into the dialog.

Comment 6

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 7

[Matthew T (active 1999-2002)]

That last suggestion is better, but I see a couple of problems:
* it doesn't explain the root cause of the user getting the dialog in the first
  place (that one or more recipients aren't listed as being able to receive HTML
  messages)
* it refers to the message as an `email message', when it might be a Usenet
  message
* it uses the word `designate'
* it still uses `(HTML)' a bit too often.

How about ...

This message contains HTML formatting.                       } large system font

Some programs cannot display HTML formatted messages,        \
and not all of the recipients of this message are recorded   /
in your address book as being able to read these messages.   > small system font
(If you know that they can read HTML messages, you can       \
record this in the Address Book by choosing `Recipients'.)   /

(*) Send as plain text only                                  } large
    (formatting such as bold and colored text will be lost)  } small
( ) Send as HTML only                                        } large
    (some recipients may not be able to read the message)    } small
( ) Send plain text and HTML versions together               } large
    (will take more time and disk space)                     } small

[ ] Remember this choice for all future messages             \ 
    (you can change this in the `Messenger' category of the  } small
    Preferences dialog)                                      /

( Recipients ... )                    ( Cancel ) (( Send ))


You probably only want the `Remember this choice' checkbox if `Ask Me' is the 
default prefs setting.

Comment 8

[selmer (gone)]

Not beta2 stopper.  Marking M18.

Comment 9

[selmer (gone)]

Oops.  Really marking M18 now...

Comment 10

[Ben Bucksch (:BenB)]

> users of some email software 
> may have trouble viewing the formatting (HTML) in this message

(This is not proposed anymore, but I feel a need to clearify this.)

You can't force users to read HTML source code => Assume, that a user without a
HTML-capable mail client can't read the mail at all.

> May lose formatting such as bold text

Wrong. b(old), strong, i(talic), em(phasis), u(nderline) and code are converted
to the plain text correspondants (*bold*, *strong*, /italic/, /emphasis/,
_underline_ and |code|) during HTML->TXT conversion.
This is even recognized during display in Mozilla (TXT->HTML conversion) in most
cases. Otherwise, the info is still there and a lot of people, who use plain
text mail, understand it.

Same applies for links (a-elements), which are converted to "link text <URI>".
(In this case, there a *minimal* information loss, because you don't know, where
the a element started, but that's all. The URI is there.)

> Also, this message occurs when the Formatting pref is set to "ask me", so 
> perhaps we should use this opportunity to remind the user of this setting, 
> should they wish to change it.

This disables "Intelligent Send" (looking into the text, if formatting is needed
and proposing the best bet), that's why I wouldn't encourage this.

Many users propably think "This annoys me, but I don't want to loose formatting,
so I'll always send HTML (plus plain text maybe)" then, which is surely not the
thing, I want to encourage (at least not at this point in time). It causes too
much interop problems, which are liekly to result in flames.

With the new HTML->TXT conversion and back and format=flowed, HTML isn't really
needed in most of the cases.

Comment 11

[Matthew T (active 1999-2002)]

Well, ok, for `bold' read `font sizes', but otherwise leave my suggestion 
unchanged.

Comment 12

[Ben Bucksch (:BenB)]

> [ ] Remember this choice for all future messages             \

>     (you can change this in the `Messenger' category of the  } small

>     Preferences dialog)                                      /



*If* we insert this, we should as well give the option to always send HTML to

only these recipients ("Send HTML" in address book cards).



E.g. above the "remeber for all" th following:

[ ] Remember this choice for all recipients                  \

    (you can change this woth the "Send HTML" checkbox in    } small

    their address book cards)                                /

Comment 13

[Ben Bucksch (:BenB)]

see bug 38433.

Comment 14

[sol]

Added "nsbeta3" and "polish" keywords. However, we are not going to implement 
the "Recipient's" button, so the text referring to this function should not be 
added to the dialog.

Comment 15

[lchiang]

marking dup of 38433.  That bug talks about default and the wording of the 
dialog.

*** This bug has been marked as a duplicate of 38433 ***

Comment 16

[Ben Bucksch (:BenB)]

It's not really a dup, as I just used the existing wording. But I can include
some suggestions from this bug, as I touch the code anyway. I filed and own a
bug about the "remember this decision" checkbox.

Comment 17

[fenella]

If it is not a dup. Let's re-open this bug so that I can keep track of it.

Comment 18

[Ben Bucksch (:BenB)]

ok, taking bug.

Comment 19

[robinf]

Adding myself to cc: list.

Comment 20

[Ben Bucksch (:BenB)]

I'm not too happy with any of the suggestions (intend to add comments later).
Also, the world changed with bug 38433.

Comment 21

[Jean-Francois Ducarroz]

despite the new implementation of the askFormat dialog, the wording still not 
good (see bug 38433).

here are the current wording depending of the message content:

case 1)
Some of the recipients are not listed as being able to receive HTML mail.
Your message can be converted to plaintext without losing information.

Would you like to convert the message to plaintext or send it in HTML anyway?

case 2)
Some of the recipients are not listed as being able to receive HTML mail.
Your message can be converted to plaintext without losing important information. 
However, the plaintext version might look different from what you saw in the 
composer.

Would you like to convert the message to plaintext or send it in HTML anyway?

case 3)
Some of the recipients are not listed as being able to receive HTML mail.
However, you used formatting (e.g. colors) that cannot be converted to 
plaintext.

Would you like to convert the message to plaintext or send it in HTML anyway?

My concern is about the third case, first it said that we cannot convert the 
message to plaintext then we ask the user if he/she wants to convert the message 
in plain text!!!! Kind of confusing. It should rather say that we can convert 
it to plain text but that you will lost some of the important part of the 
message like colors and images.

Comment 22

[Ben Bucksch (:BenB)]

ducarroz, I had exactly the same concern. Suggestions welcome.

Comment 23

[Matthew T (active 1999-2002)]

Well, what happened to the wording I suggested in bug 38433? Here it is again, 
with minor fixes:

<!ENTITY windowTitle.label "Message Format">
<!ENTITY recipient.label "One or more of the recipients of this message are not 
recorded in your address book as being able to read richly formatted (HTML) 
messages.">
<!ENTITY convertibleYes.label "The message can be converted to plain text without 
any loss of information.">
<!ENTITY convertibleAltering.label "The message can be converted to plain text 
with only minor alterations to formatting.">
<!ENTITY convertibleNo.label "In the message you used formatting which Mozilla 
cannot represent in plain text.">
<!ENTITY question.label "How do you want to send the message?">
<!ENTITY plainTextAndHtml.label "As both plain text and HTML">
<!ENTITY plainTextOnly.label "As plain text only">
<!ENTITY htmlOnly.label "As HTML only">
<!ENTITY plainTextAndHtmlRecommended.label "As both plain text and HTML 
(recommended)">
<!ENTITY plainTextOnlyRecommended.label "As plain text only (recommended)">
<!ENTITY htmlOnlyRecommended.label "As HTML only (recommended)">
<!ENTITY recommended.label "(recommended)">

Comment 24

[Ben Bucksch (:BenB)]

> Message Format

I don't remember the original title, but this one sounds good.

> as being able to read richly formatted (HTML) messages.

Yes, I think, this part is better, but the first part isn't.

I would say "HTML (richly formatted) messages", because richly formatted does
not imply HTML (could be "Rich Text" (RTF), too).

> The message can be converted to plain text without any loss of information.

d/any
You loose the flowing information in some cases (well, 4.x did that without
warning, too, but the statement is still incorrect, strictly speaking).

> The message can be converted to plain text with only minor alterations to
> formatting.

Considering the objections "about adding content" (e.g. ">" or stars) (in part
from you!?!), I think, the warning is not strong enough.

> In the message you used formatting which Mozilla 
> cannot represent in plain text.

Same problem as ducarroz mentioned.

> How do you want to send the message?

This reduces redundancy, but I like the "anyway" in the original text. It sounds
more dangerous, and IMO rightly so.


My concern for *all* suggestions so far is that "Both HTML and plaintext" might
be interpreted as 2 separate msgs. Given 4.x had the same problem, but at least
had context-sesitive docs to back that up, and we don't need to copy problems.
(And no, we can't depend on knowledge from 4.x.)

Comment 25

[Matthew T (active 1999-2002)]

> You loose the flowing information in some cases

Flowing data isn't what a non-programmer human would regard as `information'.

> Considering the objections "about adding content" (e.g. ">" or stars) (in part
> from you!?!), I think, the warning is not strong enough.

That's a problem with the conversions, it's not a problem with the warning. `only 
minor alterations to formatting' *should* be right.

> > In the message you used formatting which Mozilla cannot represent in plain
> > text.
>
> Same problem as ducarroz mentioned.

No, because we're no longer saying that we can't convert the *message* to plain 
text at all, we're just saying that the *formatting* can't be converted.

So, changes to my previous wordings:

<!ENTITY recipient.label "One or more of the recipients of this message are not 
recorded in your address book as being able to read HTML (richly formatted)
messages.">
<!ENTITY convertibleYes.label "The message can be converted to plain text without 
any significant changes.">
<!ENTITY convertibleAltering.label "The message can be converted to plain text 
with minor alterations to formatting.">
<!ENTITY plainTextAndHtml.label "As both plain text and HTML in the same 
message">

Comment 26

[Matthew T (active 1999-2002)]

Gak.

<!ENTITY convertibleYes.label "The message can be converted to plain text without 
being significantly altered.">

Comment 27

[Ben Bucksch (:BenB)]

> However, you used formatting (e.g. colors) that cannot be converted to 
> plaintext.

I s/cannot/will not/, because the structs conversion is optional.

> It should rather say that we can convert 
> it to plain text but that you will lost some of the important part of the 
> message like colors and images.

Should I add: ", only the text itself and some of the formatting will be sent."
or similar? (rewordings welcome)

Comment 28

[Michael La Guardia]

We're beyond the UI freeze for internationalization.  I just checked this dialog
and I'm tempted to mark it worksforme, but I'm just marking it nsbeta3-

Comment 29

[Ben Bucksch (:BenB)]

-> Future until we have something to be implemented.

Comment 30

[fenella]

Assign it to Sheelar

Comment 31

[Sheela Ravindran]

reassign to esther

Comment 32

[boris]

If you think that it is too complicated for the user to understand what
implications their choice has, just implement a preview feature.

Actually I think that UI should follow the golden rules:
- Sentences should be no longer then 10 words.
- Max. 3 sentences per request/question.
- Never put more then three choices for one question (max: 5)
- If it needs more information have an option to get more details
- demonstration is the best way to explain

Comment 33

[Thomas D. (:thomas8)]

Bug 1727493 will remove "Ask me what to do", which makes this wontfix. This is a relict from the plain text vs. HTML era.
Zero interest here in the last two decades, because nobody in their right mind in 2022 would want to be asked every time by design for complex downgrading decisions about the formatted message which they just composed.