Add interop warning to vcard pref

NEW
Unassigned

Status

defect
20 years ago
10 years ago

People

(Reporter: phil, Unassigned)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
See thread "Assuming "plain text" or "html mail" in n.p.m.mail-news
Assignee: jglick → simone
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?
Status: NEW → ASSIGNED
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.
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?

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.
Adding myself to cc: list.
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.]
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.
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.
Reassigning to me, since Simone is no longer here.
Assignee: simone → robinf
Status: ASSIGNED → NEW
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).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Target Milestone: --- → Future
Resolving as later.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → LATER
No, not later. Future
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Sorry, but there's no "Future" choice under the "Resolve bug" radio button. 
Please let me know how to do this. Thanks.
The bug is already assigned to the Future milestone. No need to resolve it too.
QA Contact: lchiang → nobody
re-assign to sspitzer
Assignee: robinf → sspitzer
Status: REOPENED → NEW
Depends on: 14373
Posted patch patchSplinter Review
change pref text. leave the rest (Help file contents) to the documentation team
:-)
Attachment #132766 - Flags: review?(sspitzer)
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Priority: P3 → --
QA Contact: nobody → search
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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
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
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
Status: UNCONFIRMED → NEW
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
Status: NEW → UNCONFIRMED
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
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
Assignee: mail → nobody
QA Contact: search → message-display
Status: UNCONFIRMED → NEW
Attachment #132766 - Flags: review?(sspitzer) → review?(mnyromyr)
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.
Attachment #132766 - Flags: review?(mnyromyr) → review+
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 on attachment 132766 [details] [diff] [review]
patch

David, do you agree with comment #27?
Attachment #132766 - Flags: superreview?(bienvenu)
Attachment #132766 - Flags: ui-review?(clarkbw)
(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...
> 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.
Attachment #132766 - Flags: ui-review?(clarkbw) → ui-review-
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.
(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 on attachment 132766 [details] [diff] [review]
patch

minusing based on redundant label...
Attachment #132766 - Flags: superreview?(bienvenu) → superreview-
You need to log in before you can comment on or make changes to this bug.