Choosing one bug report subscription option changes all the options

[Matthew Paul Thomas]

1. Go to a bug report subscriptions page, e.g. <https://bugs.launchpad.net/launchpad/+bug/771217/+subscriptions>.
2. Choose "receive all emails about this bug".
3. Choose "only receive email when this bug is closed".

What you see:
1. Three options: "receive all emails about this bug", "receive all emails about this bug except comments", "only receive email when this bug is closed".
2. Four completely different options: "mute all emails from this bug", "stop receiving comments from this bug", "only receive email when this bug is closed", "unsubscribe from this bug".
3. One option changes places, another changes its name, a third disappears, and one of the original options returns: "mute all emails from this bug" and "unsubscribe from this bug", then "receive all emails about this bug" and "receive all emails about this bug except comments".

What you should see: To be understandable and visually stable, the options should be presented in such a way that selecting one does not change the presence, position, or wording of the others.

There are, probably, several ways this could be fixed. This is one possibility for how the options could be presented:

    Mail me when:
    (*) Changed or commented on
    ( ) Changed
    ( ) Closed
    ( ) Never

(Someone who is subscribed to one or more of the bug targets for this bug report could have an extra "Default" option, showing their default subscription for the chattiest of this bug report's targets, e.g. "Default (Changed)".)

Here's another possibility, more grammatical but possibly slightly less reassuring in the case where you're unsubscribed completely:

    [✓] Mail me when this report is:
    (*) Changed or commented on
    ( ) Changed
    ( ) Closed

Either way, the radio options could be presented in a <select> menu on the bug report page itself, so you would no longer need a separate +subscriptions page (or even a standalone subscription box separate from the list of subscribers):

    [✓] Mail me when this report is:
        [ Changed or commented on :^]

[Robert Collins (lifeless)]

(Note that while the dup may seem wrong, the issues in this bug are being addressed by the work on bug 772754)

[Gary Poster (gary)]

As Robert says.

The branch in question makes this better, according to my lights and others, but could stand more polish later. Specifically, while it is more visually stable, it not as stable as the radio button approaches described. It might be entirely appropriate to reopen this bug after the branch lands (sometime next week), or open a new bug based on the new behavior.

Note however that +subscriptions is a separate issue: its full analysis of "other subscriptions" is a unique feature, and its focus on only subscriptions is intended to make it uniquely appropriate for the link in bug emails inviting people to manage their subscriptions for that bug.

[Gary Poster (gary)]

I apologize. I was responding to this bug in haste, and on the basis of IRC conversations I was a part of.

This bug is entirely about the +subscriptions page. The work on bug 772754 addresses the UI on the bug page, not on the +subscriptions page. The work for that bug has nothing to do with this one. I have removed the dupe. My previous comment makes no sense.

I will triage this as low, but point Huw at it. He can decide if it is of higher importance.

I only have a few comments myself.

 - The primary point of this +subscriptions page in its original design was to give a target to emails: let people who receive an email get a page that exactly describes why they received it, and what they can do about it. The goal was to hold hands, and that is where the approach to verbiage, and the presentation of options, came. We user tested the design and got reasonably good feedback for it from that perspective.

 - The +subscriptions page has unique functionality that won't fit anywhere else, except possibly as a (potentially very large) overlay: the "other subscriptions" full analysis of why you might be getting the email. This is a power user feature, but has gotten some nice feedback, because it explains some situations that I and others find very confusing, and allows you to do something about them.

 - Because of that unique functionality, we thought linking to it from the main bug page was a good idea.

Someone could judge any or all of this as a mistake and necessary for correction, but that is the background.

[Gary Poster (gary)]

Note also that muting affects all subscriptions, not just direct subscriptions.

[Huw Wilkins (huwshimi)]

@gary
From what I understand of this page it pretty much controls the same as the "Add a mail subscription for this bug" and "Change your mail subscription for this bug" screens that we talked about recently. Like I suggested with those screens I think a radio button approach or similar would be a much better solution. However, I'm not sure with the scope of this work what the priority of this bug should be.

[Gary Poster (gary)]

@Huw
The only difference is that the focus of this page is supposed to be helping people understand and deal with their mail subscriptions--"unsubscribe in anger".

I'd be tempted to say that "other subscriptions" should be available from the main bug page dynamically so that the web interface never links to this page, and that this page only has to focus on the task of helping people understand why they got a particular email, and what they can do about it. OTOH, that's simply the original intent, which may no longer be relevant as time goes on.

That observation and opinion have nothing to do with whether or not we want radio buttons. To my mind, the subtleties that need to be conveyed beyond what mpt showed initially are the following:

- muting mutes all* your subscriptions.
- directly subscribing to the bug overrides all* your other subscriptions.
- unsubscribing is a gesture that makes your other subscriptions relevant again.

* "all" means "all except those that are via a team that has their own contact address, such as a mailing list".

I am sure that many UIs, some including radio buttons, could be used to convey these subtleties.

[Huw Wilkins (huwshimi)]

@gary

Thanks for that extra info.