Per-project e-mail subscribe page is confusing since it defaults to 'None' when the user has no preference

We also need to more clearly indicate if the user has no preference. Perhaps we should have a 4th radio here for "Use default" that's pre-selected if there's no per-project override for this project. If that's selected when the form is submitted, we delete the corresponding row from {project_issue_notification_project}

That would be the most intuitive approach for me, as a user of drupal.org.

If it were possible, this could be combined with "perhaps we should also include the user's site-wide default setting here" by labelling that 4th Radio: "User default (currently set to XXX)". Even hyperlink "set to" to point back to the global settings for the user.

My 2p (2c ;) )

Thinking about this some more, there's another way to do that page. I can't decide which is best from a UX point of view.

The alternative is to put a check-box labelled "Overwrite default behaviour for this module". If the box is checked, the 3 radio-buttons we currently see for each project's subscription option are enabled. The user can then choose between "none", "projects I follow" or "all". If the box is not checked, the 3 radio-buttons are disabled ("greyed-out") and it's then transparent that the default applies to this project too.

One more thought, which may work alongside or even instead of one of these two solutions, is a change to the Profile > Notifications page for a user. Currently, I can choose the "default" against one of 3 options, and click "save". There could be another button which is labelled "Save, and apply to all projects", which generates a warning before removing every project-specific subscription setting. That way, I can know that the default I see will be the behaviour of each project.

Another thing that's unclear on the Profile > Notifications page is whether the list of overridden projects is comprehensive or not. At the top is a default setting, then below that is a setting to override this for specific projects. There are no such projects showing in my profile, but I know for a fact that I set up subscription settings for some projects before this change was implemented. Presumably they should be listed there. If they are not, I have no way to see all the projects to which an override has been applied. The "remove all overrides" button suggested above would restore confidence that the user can now see every project that has its own specific settings.

I'd simply forget about that per-project page and link to the user account notifications page.

- Add some trivial $_GET['project'] query parameter handling for #default_value, so the project name is already filled in.

- Add a destination query parameter, so submitting the form redirects back to where the user was.

Given that caching issue, presumably it's then easier to leave the "subscribe to this issue" page as it is, but to put an option on that page (via an extra radio in the group, or via a checkbox, as outlined above) to set the subscription for that project to its default. As @dww said at the top, that would have to delete the relevant row. Provided the list of projects on the user's notification settings page exactly matches those projects that do not have the "default" setting on the project issue-subscription page, all is well.

I just been confused by that :)

I like the 4th radio idea.

I haven't got anything near a D6 site on which I can test the patch to review it, but the PNG looks spot on

Thanks - noted. I'll try and get this tested, then. Won't be for a few days, I'm afraid, so someone else might beat me to it, but I'll have a look

Image in #7 looks good though couple of questions:
- "Use site-wide default (currently xxx)" - will be default checked setting for all projects, until you override it, right?
- Do "(currently None)" and "user account" links go to same page?
- Will implementing this automatically fix current projects which have settings same as default and still show up on user profile page? Or we will have to manually edit each project? What I mean is - I used to have site-wide default "None" and for bunch of projects I chosen "Issues you follow", now I have site-wide default "Issues you follow" and a bunch of projects with same setting on my account page. Will they be removed automatically?

In general I think that to make it even more clear what is going on on this page it would be better to implement something similar to JamesOakley suggestion in #2, as in:

First you see 2 active radio-buttons:

- Use site-wide default (currently None)
- Choose specific settings for this project

After you choose 2nd radio-button the list of options gets available below:
- Issues you follow
- All issues

This list contains only 2 options which are different from site-wide default.

@dww thanks for your answers. To explain a bit my previous message - I did have site-wide default set to None after this functionality was introduced. And I did then went and choose for some projects per-project setting "Issues you follow" (which is definitely my problem). Some time later I changed site-wide default to "Issues you follow". As above mentioned projects now technically do not override site-wide default, I would expected them not to be show on my account page. So this was my question - will projects with the same setting as current site-wide default still show up on "My accounts" page or will they be removed automatically. Though I see how this can be complicated, as each time one changes site-wide default - list of projects to be shown on My accounts page will need to be changed accordingly. Anyway, I got your answer, just wanted to explain a bit.

As for the 2 phase UI, the reason I support it is because I find it a bit strange to see option "use site-wide default (currently: None)" next to option "None" in one list of radio buttons. As it is one list - it is supposed to have different options to choose from, and above mentioned options are basically the same. Though it is probably of minor importance also.

Can we move the "Use site-wide default" option to the top?

Reasoning: It's going to be the default option being selected for all non-configured projects. Thus, seeing it as first option pre-selected, would be more natural, I think.

Patch looks cool otherwise.

1. It's a bit clunky to see the default value repeated in this list. Could the additional options be filtered to exclude the one that duplicates the current default? That would make remove some new potential for confusion.

2. Alternatively I was also thinking this would need a two-step UI that tvn proposes, something like this:

Which might be a whole lot more work, I don't know.

@dww Actually my suggestion was to append the option that is the sitewide default, with (this is the current side-wide default).

But also the label change, yes.

....

I'm pretty sure these options are confusing because they don't make sense. What use is there for option to receive email for the 'Issues you follow' on a per-project basis? Receiving email for things you follow is not just the default behavior, it is pervasive and not optional (AFAICT). I haven't definitively tested this, but I suspect that 'None' and 'Issues you follow' are the same thing (code-wise). Otherwise, this would mean that on a per-project basis, you can choose /not/ to receive email for the issues you follow.

I think that if you want to subscribe to a project (automatically follow all issues), then that's a binary choice between one user and a project. If you want to stop that, then you discontinue following that project. The alternative to following a project shouldn't be 'None', 'No email', or 'Issues you follow'; it should be the opposite of whatever verb initiates the change. Follow, unfollow; subscribe, unsubscribe; track, stop tracking; etc. Not receiving emails for things you follow doesn't make sense and shouldn't be an option.

@mitchell: This entire UI is about managing e-mail notifications only. There are many people who are following issues without getting e-mail notifications, because they are using the d.o issue tracker pages for following/tracking/managing issues, and they don't use e-mails for that at all. We've introduced that capability along with the roll-out of the new Follow functionality on d.o, and a lot of people have been thankful for that. I personally can't relate to not using e-mails notifications either, but that doesn't change the fact that many other people can and want ;)

Moving this back to D7 since Drupal.org has upgraded now and #1560012: Port per-user issue notification email functionality to D7 is fixed.