Closed Bug 95623 Opened 23 years ago Closed 13 years ago

Must differentiate between newsgroup-followup and email-reply

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: BenB, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

GNKSA requires:
<quote src="http://www.newsreaders.com/gnksa/gnksa.txt">
The software MUST provide separate, clearly distinguished commands to do
each of the following:
[...]
  b) Post a followup article, with Subject, Newsgroups, and References
     header lines derived appropriately from the original article.
                                             (see #5, #6, and #7 below)
  c) Reply by e-mail, with "Subject: " and "To: " headers derived
     appropriately from the original article.     (see #5 and #8 below)
</quote>

We are currently not very good at that. We have "Reply" and "Reply all", but it
is not clear (because you use it), which does what. We need better wording.

Bug 17796 will help, adding dependency.
Blocks: 76449
Depends on: 17796
Perhaps when we are in a newsgroup, the `Reply' and `Reply All' buttons could be
replaced by `Reply' and `Follow Up' buttons. However, lots of 4.x users will be
used to `Reply' doing `the usual thing' by now, so this would annoy them no end.
But, as I pointed out at various occasions, the current behaviour is completely
unlogical.
Under "Reply All", I would expect a followup to the newsgroup. Consequently, I
would expect a reply to the sender only under "Reply". But almost exactly the
opposite happens.
Also, if I want to followup to a mailing list, I need to press "Reply All",
while I have to press "Reply" to followup to a newsgroup.

I don't think that "Reply" and "Followup" are a good solution either, because
end-users will consider reply and followup to be synonyms.

I have no good proposal.
This also blocks the full GNKSA support metabug. Marking dependency.
Blocks: gnksa
Reply and Followup aren't exact synonyms and I don't think it takes much 
to educate users as to which is which.

This bug branched off a comment about the toolbar tips,  and what I would 
suggest would be "Reply" and "Followup" for the buttons and then toolbar 
tips of  "Reply by email" and "Followup to Newsgroups".  This means that 
the first time user won't know what "Followup" means until they put the 
mouse over the buttons, but I don't consider that a huge barrier, 
particularly not when compared to the payoff.

And I agree with the GNKSA that it is very helpful to have a word that 
means "2 billion people may see this message" and one that means 
"only the people in the headers will see this message".
And of course it isn't enough for the FollupUpTo icon to become a reply icon 
when the post has Followup-to: poster :-(
I agree with this bug; in fact, I would argue that it is currently the one major
usability problem in using Mozilla as a newsreader.

This is especially so when reading a newsgroup which is a gated mailing list,
since on such a list it is quite possible one ends up with two copies going to
the list if one hits "Reply All" by mistake...

Suggested wording:
Reply (e-mail)
Followup (newsgroup)

The parts in parenteses are meant to be part of the description.

pi
See also bug 144914, "[RFE] Reply to recipients but not to sender (Followup
feature for mail)"
*** Bug 146385 has been marked as a duplicate of this bug. ***
*** Bug 146380 has been marked as a duplicate of this bug. ***
Additional comment to comment #7:

I believe Tooltips should be used for the description. (Like I already said in
bug 146380, sorry for reporting that duplicate, and thanks to pi for pointing me
to this bug.)

Tooltips could be: "Reply to sender by e-mail" for the "Reply" button, and
"Followup to newsgroup" for the "Followup" button.
*** Bug 146385 has been marked as a duplicate of this bug. ***
No longer blocks: gnksa
shouldn't a proper Group reply for e-mail lists that don't use a "reply-to" be
what any good mail reader would do. I'm constantly being chatised on one mail
list that Group reply is what mutt can do. The Reply-All is not appropriate as
people receive duplicates.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: esther → message-display
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
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
Probably fixed in Thunderbird in bug 45715
Will this be in SM as well?
Ever confirmed: false
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
  
Depends on: 533077

    
    

    
  
Taking this for later. My idea is to make a newsgroup reply button in the message header that works like Reply List; i.e. by default, you'd have a dual-button for "Followup", with sub-items for "Reply All" and "Reply" (to sender), plus a separate "Reply" (to sender) button.

Regarding comment 2, I think that most people who would want to use NNTP would know the difference between replies and followups, but if not, they can hopefully learn pretty quickly by clicking on the buttons and seeing how the addresses get filled out. :)
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED

    
    

    
  
Hm, I see now that this is actually a Seamonkey bug. Perhaps I should clone it and make a new one for TB?

    
    

    
  
Currently the Reply button has a drop down with the following choices:
Reply to Newsgroup
Reply to Sender Only
With the default being reply to the newsgroup.

The Reply All button has a drop down with the following choices:
Reply to Sender and Newsgroup
Reply to All Recepients

I think this addresses most of the issues in Comment 0.

Please open a new bug for the remaining issues.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Compare bug 498448 for TB.

    
  
Assignee: squibblyflabbetydoo → nobody

          You need to log in
          before you can comment on or make changes to this bug.