95927 - Subscribe should not have `Subscribe' and `Unsubscribe' buttons

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Matthew T (active 1999-2002)]

Build: 2001081704, Mac OS 9.1

To reproduce:
1.  Open the Subscribe dialog.
2.  Look for `Subscribe' and `Unsubscribe' buttons.

What you see:
*   They exist.

What you should see:
*   They don't exist.

Rationale: Not counting access from pulldown menus, it's a bad idea to have two 
ways of doing the same thing with the same input device. The small amount of 
time users save from having multiple access points for a function are 
invariably outweighed by the time they waste dawdling between those access 
points, wondering which one would be the quickest to get to for this particular 
occasion.

Therefore, there should only be one method of subscribing to (or unsubscribing 
from) a folder or group with the mouse, and only one method with the keyboard. 
With the mouse, the quickest method is to check the checkbox in the relevant 
row; using the `Subscribe'/`Unsubscribe' buttons takes longer, as it requires 
clicking on the item then clicking on a button some distance away. Similarly, 
with the keyboard, the quickest method is to check the checkbox in the row by 
pressing Space; using the `Subscribe'/`Unsubscribe' buttons takes longer, as it 
requires typing an accesskey combination rather than hitting the biggest key on 
the keyboard.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

Um, when we implement multiple selection, the subscribe/unsubscribe buttons will
be very useful.

Comment 2

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

we already have multiple selection in subscribe, so those buttons are useful.

I plan on marking this wontfix, but feel free to continue to debate the issue here.

Comment 3

[Håkan Waara]

I really doubt anyone would select a few rows and *then* click "Subscribe"
rather than just checking the checkbox instead of the selecting it on all rows.

Let's remove the duplicate buttons.

Comment 4

[Blake Ross]

Multiple selection doesn't work for me in Subscribe, but anyways, unless I'm
just misunderstanding, I also don't understand why anyone would select the rows
and then clicking the buttons instead of just selecting the checkboxes.

However, I don't think it's immediately obvious to the average user how they
subscribe to newsgroups without these buttons.

Comment 5

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

ah, the tree view isn't doing multiple selection (whoops, that regressed) but
the search view is.  I'll go fix that.

to get to the search view, type in some text in the "show items that contain"
text field and then try multiple selection.

Comment 6

[[e-mail] (gone - use [e-mail] instead)]

Seth, multiple selection is bug 72869.  

Comment 7

[Håkan Waara]

The checkboxes will work alright. BTW, I filed a bug the other day about
centering these checkboxes in trees.

This will clean up the subscribe dialog's interface tremendously.

Comment 8

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

I fixed the multiple selection bug, so now those buttons have a use in the tree
view, 

I'm following the spec (although it is known to be old and out of date, those
button are there.)

http://www.mozilla.org/mailnews/specs/subscribe/

wontfix, but feel free to continue the discussion.

Comment 9

[[e-mail] (gone - use [e-mail] instead)]

Verified per the spec.

Comment 10

[Jonas Jørgensen]

Just saw someone in the user newsgroups who couldn't understand why "nothing
happened" when he pressed the Subscribe button, "no matter how many times I
click it". When people see a button, they expect something to happen when they
press it -- more than just having a checkbox toggle.

If the current behavior follows the spec, the spec is wrong. You cannot WONTFIX
a bug which claims that the spec is wrong on the grounds that the spec says that
the existing behavior is correct; WONTFIXing a usability bug because the
existing behavior "is what the spec says" makes as little sense as WONTFIXing a
topcrash bug because the existing behavior "is what the code does".

Comment 11

[jglick]

I think the points made here for removing the buttons are valid. As far as 
multiple section, i agree subscribing/unsubscribing to one newsgroup at a time 
is much more common than subscribing/unsubscribing to multiple newsgroups. Also, 
a similar dialog, Message Filters, has an Enable column but does not have 
Enable/Disable buttons. Reopening and will update spec shortly.

Comment 12

[Stefan Borggraefe]

Attachment: Removes the buttons

Comment 13

[Stefan Borggraefe]

Taking bug.

Comment 14

[[e-mail]]

Comment on attachment 137778 [details] [diff] [review]
Removes the buttons

... although I would prefer it if the buttons were correctly dynamically
disabled which would make it clear when they were actually usable.

Comment 15

[Stefan Borggraefe]

> ... although I would prefer it if the buttons were correctly dynamically
> disabled which would make it clear when they were actually usable.

Me, too. But this would be another bug and the Stop-Button doesn't really work
currently (see Bug 229077). So there are more changes to be made in this area.

Comment 16

[Stefan Borggraefe]

Attachment: Same change for Thunderbird

This needs to be applied to Thunderbird to prevent it from breaking when the
Seamonkey-patch gets checked in. This patch removes the buttons from
Thunderbird, too.

Comment 17

[Stefan Borggraefe]

Comment on attachment 137778 [details] [diff] [review]
Removes the buttons

David, could you check this and the patch for TB in, if you're okay with the
patch?

Comment 18

[David :Bienvenu]

now that multiple selection works, I think the subscribe buttons add some
(albeit small) value...

Comment 19

[Stefan Borggraefe]

David: Well, I just stumbled over this bug and thought this is one I could
easily fix. I don't have anything to add to the arguments already given in the
other comments here. See comment #11 concerning the multiple selection. I
personally agree with the arguments given to remove the buttons.

Feel free to mark this bug as WONTFIX if you prefer to preserve these buttons.
You are a module owner after all. ;-)

Comment 20

[Matthew T (active 1999-2002)]

(Clutter in Free Software exemplified: Sometime, somewhere, someone *might* 
want to do things the slow way, by selecting then clicking "Subscribe", rather 
than just checking the checkboxes. Therefore, we must retain "Subscribe"! Feh.)

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]

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 27

[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 28

[Wayne Mery (:wsmwk)]

don't think it makes sense for thunderbird to take this, but I could be wrong.
never got sr+
wontfix?

Comment 29

[Joshua Cranmer [:jcranmer]]

(In reply to comment #28)
> don't think it makes sense for thunderbird to take this, but I could be wrong.
> never got sr+
> wontfix?

I'll go with whatever SM devs decide (it's their bug after all). CC'ing SM UI person.

Comment 30

[[e-mail]]

You expect me to remember what I was thinking when I reviewed 5 years ago?

Comment 31

[Wayne Mery (:wsmwk)]

I think comment 14 and 18 sum it up

Comment 32

[David :Bienvenu]

Comment on attachment 137778 [details] [diff] [review]
Removes the buttons

I'm sure this is bit-rotted, but I'm ok with this for SM, if Neil is....

Comment 33

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

Comment on attachment 137881 [details] [diff] [review]
Same change for Thunderbird

The checkboxes seem pretty obvious by themselves.   Though I might actually appreciate column headers for the list.

| Folder   | Subscribed |

Comment 34

[Karsten Düsterloh]

Removing the buttons is a good idea. They should work (enable etc.) correctly, of course...
This is WONTFIX on the SeaMonkey side.

Comment 35

[Karsten Düsterloh]

> Removing the buttons is a good idea.

*argl*
Removing the buttons is NOT a good idea.

JFTR...