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

NEW
Assigned to

Status

MailNews Core
Composition
P3
normal
18 years ago
5 years ago

People

(Reporter: sol, Assigned: BenB)

Tracking

(Blocks: 2 bugs, {polish})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-][nsbeta3-])

(Reporter)

Description

18 years ago
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.

Updated

18 years ago
OS: Windows NT → All
QA Contact: lchiang → fenella
Hardware: PC → All

Comment 1

18 years ago
sol nominates for beta1
Keywords: beta1
(Reporter)

Comment 2

18 years ago
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

18 years ago
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

18 years ago
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
(Reporter)

Comment 5

18 years ago
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.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 6

18 years ago
Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.
Target Milestone: M15 → M16

Comment 7

18 years ago
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

18 years ago
Not beta2 stopper.  Marking M18.

Comment 9

18 years ago
Oops.  Really marking M18 now...
Target Milestone: M16 → M18
(Assignee)

Comment 10

18 years ago
> 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

18 years ago
Well, ok, for `bold' read `font sizes', but otherwise leave my suggestion 
unchanged.
(Assignee)

Comment 12

18 years ago
> [ ] 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)                                /



(Assignee)

Comment 13

18 years ago
see bug 38433.
(Reporter)

Comment 14

18 years ago
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.
Keywords: nsbeta3, polish

Comment 15

18 years ago
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 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 16

18 years ago
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

18 years ago
If it is not a dup. Let's re-open this bug so that I can keep track of it.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 18

18 years ago
ok, taking bug.
Assignee: ducarroz → mozilla
Status: REOPENED → NEW

Comment 19

18 years ago
Adding myself to cc: list.
(Assignee)

Comment 20

18 years ago
I'm not too happy with any of the suggestions (intend to add comments later).
Also, the world changed with bug 38433.
Status: NEW → ASSIGNED
Target Milestone: M18 → ---
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.
(Assignee)

Comment 22

18 years ago
ducarroz, I had exactly the same concern. Suggestions welcome.

Comment 23

18 years ago
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)">
(Assignee)

Comment 24

18 years ago
> 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

18 years ago
> 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

18 years ago
Gak.

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

Comment 27

18 years ago
> 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

18 years ago
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-
Whiteboard: [PDT-] → [PDT-][nsbeta3-]
(Assignee)

Comment 29

18 years ago
-> Future until we have something to be implemented.
Keywords: beta1 → nsbeta1
Target Milestone: --- → Future

Comment 30

18 years ago
Assign it to Sheelar
QA Contact: fenella → sheelar

Comment 31

17 years ago
reassign to esther
QA Contact: sheelar → esther

Updated

17 years ago
Blocks: 104166

Updated

16 years ago
Blocks: 168902
(Assignee)

Updated

16 years ago
No longer blocks: 168902

Comment 32

15 years ago
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

Updated

15 years ago
Depends on: 222746
Product: MailNews → Core

Updated

10 years ago
Assignee: mozilla → nobody
Status: ASSIGNED → NEW
QA Contact: esther → composition
Product: Core → MailNews Core
(Assignee)

Updated

10 years ago
Assignee: nobody → ben.bucksch
Target Milestone: Future → ---
Blocks: 889315
You need to log in before you can comment on or make changes to this bug.