branch subscriptions settings are hard to understand

[Barry Warsaw]

Two small problems with branch subscriptions on Launchpad.

1. The notification level description doesn't tell you what "branch attributes" are. You can't decide whether to get notifications for these or not if you don't know what you'll get.

2. The diff size limit should not control whether you get a notification or not. Diffs greater than the limit should be pruned but not suppressed. IOW, I should be able to still get a notification of a branch change, even if it only contains a partial listing, because I can always generate the full diffs locally.

[Tim Penhey (thumper)]

For point 1 I agree. It does need some better explanation.

For point 2, you do still get the email notifying you of a change, but it doesn't send the diff if the diff is larger than the limit specified. It does say something like "The diff length of 3546 lines was longer than the limit specified of 1000 lines"

[Barry Warsaw (barry)]

Thanks for the clarification of #2. Maybe the description text could be a little clearer about that. Or maybe it's just me that's confused. :)

If it said something like "Diffs greater than the specified number of lines will be suppressed, but the subscriber will still get a notification email." that would probably do it for me.

Thanks!

[David Allouche (ddaa)]

Confirmed bug, medium importance.

[Matthew Paul Thomas (mpt)]

The form controls now have captions that directly address the points in this bug report. But the captions are very long, which is usually a sign that the controls and/or their labels could be better-chosen (for previous examples see bug 174667 and bug 180644).

The "Notification Level:" menu has the caption: "Attribute notifications are sent when branch details are changed such as lifecycle status and name. Revision notifications are generated when new branch revisions are found due to the branch being updated through either pushes to the hosted branches or the mirrored branches being updated."

Here the menu controls boolean status for two notification types that (as far as I can tell) are actually independent, using 2 × 2 = 4 options, but space is not an issue. Therefore, two checkboxes would be more appropriate. Giving these checkboxes the combined heading "Mail me whenever:" would simplify the labels enough that we could list the "branch attributes" by name, so we wouldn't need to use the "branch attribute" term at all. Like this:

    Mail me whenever:
    [/] The branch status, name, ______, or ______ changes
    [/] The branch has new revisions

The "Generated Diff Size Limit:" menu has the caption: "Diffs greater than the specified number of lines will not be sent to the subscriber. The subscriber will still receive an email with the new revision details even if the diff is larger than the specified number of lines."

Here again a new term -- "Generated Diff Size Limit" -- is introduced and then defined, but it's somehow possible to have a generated diff size limit of "Don't send diffs". This can be fixed using more direct language:

    Mail me whenever:
    [/] The branch status, name, ______, or ______ changes
    [/] The branch has new revisions
        Include the diff:
        ( ) Never
        (*) If it is [ 1000 :^] lines or less
        ( ) Always

Here the change of controls (splitting the "Never" and "Always" options out into radio buttons) isn't compulsory. It would make sense while branch subscription is done on a separate page, as it is now, where there's plenty of room. But if the subscription form is moved onto the branch page itself, it might be necessary to keep the diff options as a single compact menu with "Never", "If ≤ 500 lines", "If ≤ 1000 lines", "If ≤ 5000 lines", and "Always" options.

[Jonathan Lange (jml)]

Matthew, I'm sorry, but I seem to be physically incapable of getting more than a sentence into your comment. :(

Would you be able to summarise with a list of things we need to do to close this bug?

[Matthew Paul Thomas (mpt)]

Sorry, I was trying to explain the redesign process. I guess I needed a whiteboard. :-)

Summary of principles:
* A long caption usually means the control or its label needs changing.
* Don't introduce new jargon (e.g. "branch attributes") if learning it takes more time than it saves.
* Avoid using a single option menu for controlling two options at once.

Summary of actions:
* Implement BranchPageTwoZero, where the branch subscription page is replaced by two checkboxes plus one option menu on the branch page itself.