42038 - UI: AB - "Card for" dialog wording. "Prefers to receive rich text (HTML) mail"

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P2)

Description

[jglick]

Wording in the "Card for..." dialog (Address Book) should be "Prefers to receive 
rich text (HTML) mail" with the default unchecked.  It currently says "Send 
email as plain text (No HTML) and is checked.  

http://gooey/client/5.0/specs/mail/AddressBook/AddressBook.html#Cardfor

This wording was choosen (10/14/99 Issues Meeting) so that it would be parallel 
with the wording for the similar setting in Account Settings.  "Compose messages 
using HTML" (checked by default).

Could we get this fixed during UI polish?

Comment 1

[scottputterman]

moving to M18 for polish.

Comment 2

[robinf]

Adding myself to cc: list.

Comment 3

[scottputterman]

reassigning to chuang.

Comment 4

[scottputterman]

Candice, how much work is it to add this attribute and remove the plaintext
attribute? Can the plaintext attribute be reused?

Comment 5

[chuang]

I think I can still use the plaintext attribute, just need to make sure to set 
the correct attribute with the new wording.  The new wording is just the reverse 
of the current one, right?

Comment 6

[jglick]

Yes, the wording should be "Prefers to receive rich text (HTML) mail" and should 
be Unchecked.

Kevin, please verify this is still correct. Should we be saying "...rich text 
(HTML)" or just "HTML"?  I remember with Sol we had this big issue about "rich 
text" being accurate or not.

Comment 7

[scottputterman]

Varada convinced me that a conversation that Jennifer and I had yesterday might
be a better way to go.  Instead of choosing between html and unknown we could
have a 3 choice list box that would have: "prefers html", "prefers plaintext",
"don't know".

what are everyone's thoughts on this and Candice, could you replace the current
checkbox and database attributes pretty easily with 3 choices instead of 2?

Comment 8

[jglick]

If its not a huge amount of work, I think its a good idea.  That way we aren't 
combining "plain text" with the "don't know" option.  Users can purposely pick 
plain text for an AB entry and prevent having to get the "Ask me" dialog for 
some emails.

Comment 9

[jglick]

Attachment: Proposed screen shot

Comment 10

[jglick]

I'm not sure what the best wording label is.  I have 3 examples in the image.

1. Text format preferred:
2. Preferred format:
3. Send text as:

The choices are:
1. Plain text (no HTML)
2. Rich text (HTML)
3. "Unspecified"? or "I don't know"? or "Not defined"?

Default would be #3

Comment 11

[jglick]

When sending a mail message the order used to determine how to send the message:

1. Address Book card set to plain or html
2. HTML or Plain text domain Pref set
3. "When sending html messages to users not listed as being able to receive 
them" 

Comment 12

[scottputterman]

I'm marking this nsbeta1+ and moving to mozilla0.8

If we could do this soon that would be great.

How about something like "Prefers message sent as:"

"HTML"
"Plaintext"
"Don't know"

Comment 13

[jglick]

Robin, do you have wording recommendations?

Comment 14

[kmurray1115]

I circled back with Sol on this - the wording should still be "Rich Text (HTML)" 
wherever possible because we still don't want to depend on folks knowing what 
HTML mail is. "Rich Text," while not perfect, is a bit more descriptive than 
simply putting "HTML." 
Also, why wouldn't we simply default to HTML? I know for newsgroups, 
composing in HTML is bad, but we're talking about the AB Card defaults here.

Comment 15

[jglick]

Thanks Kevin. 

In account settings, the default for mail accounts is "Compose in HTML" (and 
plain text for news).  But the AB setting allows you to overide this on per card 
basis. If the user hasn't specified a setting for an individual, it uses the 
"When sending mail to people not listed as being able to receive html" Prefs 
(the famous "Ask Me" dialog).  If users set a pref for an individual in their AB 
card, it will look here first and do the right thing.

Comment 16

[Matthew T (active 1999-2002)]

> Also, why wouldn't we simply default to HTML?

Because making users explicitly tell Mozilla that they `don't know', every time 
they created a new address book entry, would make them feel bad.

Comment 17

[robinf]

What happens in the "don't know" case - does the user get the Ask Me dialog when 
 sending mail to this person?

How about "Prefers to receive messages formatted as:" for the label. And instead 
of "don't know", how about "Ask me when I send a message" (if "don't know" means 
Ask me).

Comment 18

[scottputterman]

cc'ing ducarroz.

I don't think it should be "ask me" because if the domain is set, then we won't
be asking them and in the "don't know" case if you put "ask me" that would imply
that it overrides the domain. At least that's how it would seem to me.

Comment 19

[jglick]

Robin, in the "Don't Know" case, Mail would first look at the domain settings 

Prefs. (If the user specified certain domains as preferring html or plain text). 

If nothing was set for domains, Mail then looks at the "When sending mail to 

recipients who are not listed as being able to receive them" Pref.  "Ask Me" is 

checked by default, but users can change this.  So "Don't know" really means look  

at the different Pref settings and do the correct thing.



Above is another reason why we wouldn't want "Ask me" as one of the options. So 

is "Don't know" ok?  "Unknown"?



 

Comment 20

[robinf]

Thanks for the clarification. I prefer "Unknown" to "Don't know" since "Don't
know" implies a judgement that the user should know but doesn't, whereas
"Unknown" is more neutral.

How about: "Unknown (Mail determines the format)".

Comment 21

[Matthew T (active 1999-2002)]

> How about: "Unknown (Mail determines the format)".

That's much too long for a popup menu item. (It would be ok for a radio button, 
but this arcanum doesn't deserve three radio buttons' worth of screen real 
estate.) See <http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
79.html#MARKER-9-39>, and the `Brevity' section of
<http://msdn.microsoft.com/library/books/winguide/ch14d.htm>. So just `Unknown' 
will probably have to do.

I also suggest changing `Plain text (no HTML)' to just `Plain Text'. The
`(no HTML)' is unnecessary, makes the text twice as long, and makes the option 
look unnecessarily similar to `Rich Text (HTML)'. Also note that menu items 
should use title capitalization -- `Plain Text', not `Plain text'.

Comment 22

[Håkan Waara]

I don't think the HTML option should be "Rich Text (HTML)" since Rich Text is a
well-known Macintosh textformat, thus that wording is confusing.

Comment 23

[timeless]

Rich Text Format is actually a microsoft format iirc.  We should stay away from 
the phrase Rich Text if at all possible.  HTML allows graphics which is not 
obvious from the phrase. [RTF does too, but..]

Comment 24

[scottputterman]

I agree with the last few comments. I think HTML, Plain Text, and Unknown are
fine for the choices.  After all, the Ask Me dialog only mentions HTML (no Rich
Text as well).  

Comment 25

[jglick]

Sounds good to me.  Kevin, would you be ok with that?

Comment 26

[kmurray1115]

Again, 
>>because we still don't want to depend on folks knowing what 
HTML mail is. "Rich Text," while not perfect, is a bit more descriptive than 
simply putting "HTML."<<
Unless there is substantial evidence showing that users know what HTML mail is
without an explanation, I'm fine with that. But, what I think you'll discover is
we will need some descriptor for what HTML means in this case. 

Comment 27

[chuang]

Here's what I put on the dialog ->

Prefers to receive messages formatted as: 
1. Unknown
2. Plaintext
3. HTML

Unknown is the default.  Any objestion?  I'm almost done with this bug.

Comment 28

[jglick]

Robin, should "Plain text" be two words?

Comment 29

[robinf]

Yes, please make Plain Text two words. Thanks.

Comment 30

[chuang]

Attachment: Patch for the fix

Comment 31

[chuang]

The fix including removing the old attribute sendPlainText and use new attribute  
preferMailFormat for database.  Remove the checkbox and add a new menulist.

Comment 32

[(not reading, please use [e-mail] instead)]

comments:

1) were any changes required to the commercial build?  
2) did you log a bug on the issue where the menulist (when clicked) displays
incorrectly?
3) I don't think nsIAbPreferMailFormat needs to be scriptable

Comment 33

[Ben Bucksch (:BenB)]

> The fix including removing the old attribute sendPlainText and use new
> attribute preferMailFormat for database.

What about migration of the user's database?


Generally, having the option "unknown" in addition to plaintext and HTML is a
good idea IMO. However, IIRC, the backend doesn't behave that way. What is the
actual, functional difference between Plaintext and Unknown? Is there a bug
logged tracking the implementation?

Comment 34

[Scott MacGregor]

sr=mscott pending the answers to Seth's questions.

Comment 35

[chuang]

1) were any changes required to the commercial build? 

No, no one is using that attribute in commercial tree.  I have compiled the 
commercial tree yesterday.

2) did you log a bug on the issue where the menulist (when clicked) displays
incorrectly?

I tried again yesterday before I was ready to log the bug and it got fixed.  I 
tried on different themes and they all appears fine.

3) I don't think nsIAbPreferMailFormat needs to be scriptable

I changed it.  See the new patch for nsIAbCard.idl.

For Ben's
4) What about migration of the user's database?
 
The database won't get changed, it will just default to Unknown.  However, for 
migration form 4.x or import, we set the prefer mail format to HTML if specify 
to use Rich Text Mail and others all set to default.

Comment 36

[chuang]

Attachment: Patch for nsIAbCard.idl

Comment 37

[(not reading, please use [e-mail] instead)]

r=sspitzer on the new patch.

Comment 38

[Scott MacGregor]

can we change these lines to NS_LITERAL_STRING. This will remove 2 allocations
per line!
nsString(NS_ConvertASCIItoUCS2("1")).ToNewUnicode();
nsString(NS_ConvertASCIItoUCS2("0")).ToNewUnicode();

to 
aName = NS_LITERAL_STRING("1");

and make aName a const PRUnichar *;

This isn't part of your fix so feel free to check in your patch first. But if we
could go back and fix these up that would be cool. Just browsing through this
file showed me a lot of nasty string copying going on just to convert string
literals into unichar string literals.

your code looks great! sr=mscott

Comment 39

[chuang]

I have checked in my patch.  I tried to use NS_LITERAL_STRING in abSync.cpp as 
mscott suggested, it won't compiled since aName is used elsewhere in that 
function.  To use NS_LITERAL_STRING, I need to go through that function to clean 
up the code using aName.  I'll file a bug for it.

Comment 40

[chuang]

Bug66598 has filed for using NS_LITERAL_STRING in nsAbSync.cpp

Comment 41

[chuang]

Fix checked in.

Comment 42

[Ben Bucksch (:BenB)]

*** Bug 36878 has been marked as a duplicate of this bug. ***

Comment 43

[fenella]

QA-assign-to fenella.

Comment 44

[fenella]

Card dialog shows default is "unknown" using these builds
Linux (2001-02-20-12 mtrunk)
Win32 (2001-02-20-09 mtrunk)
mac (2001-02-20-12 mtrunk)