15781 - Add interop warning to vcard pref

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Phil Peterson]

We should make sure that the words around the per-identity vcard pref are
sufficient for users to understand that vcards are attachments, and if the
recipient doesn't understand MIME attachments, they won't understand the vcard.

Obviously, this is a delicate wordsmithing issue, so I'll start with jglick to
help with the words, and cc alecf to do the actual work.

Comment 1

[mozilla.old.2]

See thread "Assuming "plain text" or "html mail" in n.p.m.mail-news

Comment 2

[jglick]

Tech pubs group is reviewing all dialogs to help with wording issues.
And where appropriate they are recommending placing smaller text below certain
items to provide further explanation.  Reassign to Simon Cox for her wording
expertise.

I believe this is about the "Account Settings" dialog.  The "Attach my vCard to
messages" checkbox item.  Please correct me if i'm wrong.  Some suggestions:

"Attach my vCard to messages (MIME attachment)" - not so wonderful.

"Include my vCard with messages as an attachment" - eehh

Or is smaller text below the "Attach my vCard to messages" checkbox, "the vCard
is included in the message as a MIME attachment"

My concern is that most users won't really understand the implications of this
so trying to explain it in the small space of a dialog might add more confusion?

Comment 3

[simone]

I'd prefer the text below the "Attach my vCard to messages" checkbox to read
"Include vCard in message as MIME attachment". I don't think there's a way to
make it less painful, and I'd rather err on the side of giving more information
(even though it may confuse some portion of users) than to not tell them at all
that vCards are MIME attachments.

Comment 4

[Ben Bucksch (:BenB)]

Has this option been removed completely, or am I just unable to find it? If the

former, is this temporary, or will we ship this way?

Comment 5

[Phil Peterson]

Adding vCard to outgoing messages and editing vCards are not yet supported. I
don't know if we'll get to that for Seamonkey or not. vCards are lower priority
than some other work items. In the meantime, we'll keep the ability to read
vCards in incoming messages.

Comment 6

[robinf]

Adding myself to cc: list.

Comment 7

[Matthew T (active 1999-2002)]

How about:
------
[ ] Add my address book card to outgoing messages
    (To use your card, recipients must be able to read vCard attachments)
------

[What's the bug for including this feature at all? This bug should be dependent 
on it.]

Comment 8

[Ben Bucksch (:BenB)]

Matthew, sounds too harmless IMO. vCards appear as clutter, if the recieving UAs
doesn't have special cases for them (i.e. displays them inline). Even within our
very own client, they appear as attachments (this is IMO a bug).

vCards are like attaching a business card to each and every letter you write,
using a paper clip. And that even multiple times to the same recipient. What's
wrong with the headers? IMO, we should let the "attach vCard automatically to
every msg"-feature die. But if we don't, we should at least make very clear what
it does.

Comment 9

[Matthew T (active 1999-2002)]

Sure, but I don't think `Include vCard in message as MIME attachment' addresses 
any of your concerns -- unless you're hoping that by obfuscating the wording the 
user will be too afraid to turn the feature on.

I agree we shouldn't have this feature in the long run (please CC me on the RFE 
you've filed to make combine Sender:, Organization:, X-URL:, etc headers as a
pseudo-card with the same addbook:-ability). But if we do, `Include vCard in 
message as MIME attachment' is not making `it very clear what it does'. Users 
don't know what a `vCard' is, or what a `MIME attachment' is. But they usually 
know what an `attachment' is, and often have some idea that some attachments 
cannot be read by some people.

Comment 10

[robinf]

Reassigning to me, since Simone is no longer here.

Comment 11

[robinf]

Marking invalid. According to Lisa Chiang, this bug doesn't apply to Seamonkey 
(this release) since there is not going to be vcard support (add/edit). We will 
display vcards that others send to us (using 4.x).

Comment 12

[Alec Flett]

it's not invalid, it should be futured. Just assign it a milestone of "Future" -
so that it isn't lost for a future release.

Comment 13

[robinf]

Resolving as later.

Comment 14

[Phil Peterson]

No, not later. Future

Comment 15

[robinf]

Sorry, but there's no "Future" choice under the "Resolve bug" radio button. 
Please let me know how to do this. Thanks.

Comment 16

[Phil Peterson]

The bug is already assigned to the Future milestone. No need to resolve it too.

Comment 17

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

re-assign to sspitzer

Comment 18

[Daniel Wang]

Attachment: patch

change pref text. leave the rest (Help file contents) to the documentation team
:-)

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 26

[Robert Kaiser]

Comment on attachment 132766 [details] [diff] [review]
patch

Mnyromyr, this patch is old but as a SeaMonkey bug, it's better if you take a look at it than some obsolete reviewer. Feel free to resolve the bug otherwise if this is not what we want.

Comment 27

[Karsten Düsterloh]

Comment on attachment 132766 [details] [diff] [review]
patch

>diff -u -r1.17 am-main.dtd
>+<!ENTITY signature.label "Add this signature to messages (as text):">

This doesn't apply anymore.
We have a textarea now which is labelled "Signature text" - should be clear enough.

>-<!ENTITY attachVCard.label "Attach my vCard to messages">
>+<!ENTITY attachVCard.label "Attach my vCard to messages (as an attachment)">

This is worth taking, though.

Comment 28

[Karsten Düsterloh]

Comment on attachment 132766 [details] [diff] [review]
patch

David, do you agree with comment #27?

Comment 29

[David :Bienvenu]

(In reply to comment #28)
> (From update of attachment 132766 [details] [diff] [review])
> David, do you agree with comment #27?

I don't, actually (or rather, I agree with the first part but not the second part). We're long past the days when e-mail clients can't deal with mime attachments, and I'm not sure that adding "(as an attachment)" really adds value for most users. And that change is a candidate for the department of redundancy department since the text starts off with "Attach my vcard..." :-)

But let's see what Bryan thinks...

Comment 30

[Ben Bucksch (:BenB)]

> We're long past the days when e-mail clients can't deal with mime attachments

Even so, our TB has an attachment detector and marks the email special in the thread pane. I find it highly annoying to have all the emails marked to have an attachment, making it harder to find the real attachment.
The vcard also shows up as attachment in the attachment pane - I find that annoying as well.

I still think that it's metadata and should be in the headers. It still feels like attaching a business card with a paper clip to every 3-sentence letter you send out.

That said "Attach my vcard (as attachment)" indeed sounds redundant. I'd actually favor a full-blown dialog (appears only once when the checkbox is activated) explaining the matter.

Comment 31

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 132766 [details] [diff] [review]
patch

I think, as pointed out, that the first part doesn't make sense anymore with the new sig editor.

I don't think it's necessary to clarify any further the 'Attach my vCard to messages' text.  We're already using the word attach and I don't think we overload that term very often if at all.  Also I can't see that the extra information brings greater clarity to the situation.

Do we have any other suggestions?  I'm not sure the current text is perfect either.

Comment 32

[rsx11m]

(In reply to comment #27)
> >+<!ENTITY signature.label "Add this signature to messages (as text):">
> This doesn't apply anymore.
> We have a textarea now which is labelled "Signature text" - should be clear
> enough.

While that's true, the label referring to the file option still reads "Attach the signature from a file instead" versus "Attach my vCard". In that sense, the term "attach" is used in two different meanings.

> >+<!ENTITY attachVCard.label "Attach my vCard to messages (as an attachment)">

You could make it "Add the signature from a file instead:" and "Add my vCard to messages as attachment" if you want to be more specific.

Comment 33

[David :Bienvenu]

Comment on attachment 132766 [details] [diff] [review]
patch

minusing based on redundant label...