Affects Me Too should also subscribe

We should really do this - either by providing a checkbox to choose that or simply doing it by default.

+1 on just doing it. In the rare cases where a user wants to say "this affects me" but doesn't want to be subscribed, they can still unsubscribe manually (which would not change the "affects me" status).

Funny UI notes:

Since this bug affects me :-), I just clicked on both "Email me about changes to this bug report" and on the "change" button next to "this bug doesn't affect me". Well, sort of: first I got confused about how the email-me checkbox differs from subscribing. Then, after deciding they probably mean the same thing even though they have completely different UIs, I clicked the email-me button first followed by the affects-me button... unfortunately, the latter reloads the page, so I lost the comment I had just typed. Didn't see that coming. Did everything over again, except that now I didn't have to click the affects-me button because it was already checked.

I wonder if there's already some bug filed for "Clicking on anything that doesn't look like it should navigate away from the page should also never reload the page, so that other (potentially unsaved) inputs on the page are not lost."

2009/2/18 Karl Fogel <email address hidden>:
> +1 on just doing it. In the rare cases where a user wants to say "this
> affects me" but doesn't want to be subscribed, they can still
> unsubscribe manually (which would not change the "affects me" status).
>
> Funny UI notes:
>
> Since this bug affects me :-), I just clicked on both "Email me about
> changes to this bug report" and on the "change" button next to "this bug
> doesn't affect me". Well, sort of: first I got confused about how the
> email-me checkbox differs from subscribing. Then, after deciding they
> probably mean the same thing even though they have completely different
> UIs, I clicked the email-me button first followed by the affects-me
> button... unfortunately, the latter reloads the page, so I lost the
> comment I had just typed. Didn't see that coming. Did everything over
> again, except that now I didn't have to click the affects-me button
> because it was already checked.
>
> I wonder if there's already some bug filed for "Clicking on anything
> that doesn't look like it should navigate away from the page should also
> never reload the page, so that other (potentially unsaved) inputs on the
> page are not lost."

That's a good point, but this problem will go away when we move to
in-page, ajax controls. The implementation we currently have (which
reloads the page) is not a pattern we have anywhere else, and we
should avoid it in the future.

On Wed, Feb 18, 2009 at 04:08:23PM -0000, Karl Fogel wrote:
> +1 on just doing it. In the rare cases where a user wants to say "this
> affects me" but doesn't want to be subscribed, they can still
> unsubscribe manually (which would not change the "affects me" status).

I think we need to be careful about how much spam the person might
actually be buying into if we did this.

Note that there's a reasonable middle ground that is unfortunately a bit
of a special case: only sending notifications to users if the bug gets
fixed or marked incomplete.

On Feb 18, 2009, at 11:08 AM, Karl Fogel wrote:

> I wonder if there's already some bug filed for "Clicking on anything
> that doesn't look like it should navigate away from the page should
> also
> never reload the page, so that other (potentially unsaved) inputs on
> the
> page are not lost."

I don't know if there is, but there should be. And this should be set
in stone in our UI checklist. It's the #1 gripe I have about web
sites. Oh thanks for losing that last hour of work!

I can't tell you how many websites have a hidden keyboard shortcut
that interferes with, say C-a or C-e (you know what I mean Karl :).
You can't turn them off and they do something that loses your work.
That muscle memory is so deep /I/ can't turn it off. There are many
dents on my keyboard from the frustrated pounding whenever that happens.

On Feb 18, 2009, at 11:18 AM, Tom Berger wrote:

> That's a good point, but this problem will go away when we move to
> in-page, ajax controls. The implementation we currently have (which
> reloads the page) is not a pattern we have anywhere else, and we
> should avoid it in the future.

BTW, when we go to this, please please please continue to give me a
text box that It's All Text can recognize. I'm still going to want to
use my external editor because it's the only thing that ever really
implements text editing correctly. :)

Kiko,

Good point (in https://bugs.edge.launchpad.net/malone/+bug/330550/comments/4). I like that middle ground: if I say a bug affects me, then I want to know when it's fixed or changes state in some significant way. But I don't necessarily want to follow every last comment.

Under the hood, it sounds like different kinds of subscription profiles are needed, with this one being implemented as a low-traffic, only-notify-on-major-events profile. (?)

On Wed, Feb 18, 2009 at 04:52:28PM -0000, Karl Fogel wrote:
> Under the hood, it sounds like different kinds of subscription profiles
> are needed, with this one being implemented as a low-traffic, only-
> notify-on-major-events profile. (?)

Yeah. The thing I struggle with here is making this obvious to the
end-user -- how do we tell him when he says "me too!" that we're going
to email him only on these situations, how do we communicate to him and
others that this bug is emailing them on these situations, and how do we
allow them to shut up the bug if they want to.

On Feb 18, 2009, at 11:52 AM, Karl Fogel wrote:

> Good point (in
> https://bugs.edge.launchpad.net/malone/+bug/330550/comments/4). I
> like
> that middle ground: if I say a bug affects me, then I want to know
> when
> it's fixed or changes state in some significant way. But I don't
> necessarily want to follow every last comment.

Agreed.

> Under the hood, it sounds like different kinds of subscription
> profiles
> are needed, with this one being implemented as a low-traffic, only-
> notify-on-major-events profile. (?)

Yes! We need a mail hub. :)

On Feb 18, 2009, at 12:03 PM, Christian Reis wrote:

> On Wed, Feb 18, 2009 at 04:52:28PM -0000, Karl Fogel wrote:
>> Under the hood, it sounds like different kinds of subscription
>> profiles
>> are needed, with this one being implemented as a low-traffic, only-
>> notify-on-major-events profile. (?)
>
> Yeah. The thing I struggle with here is making this obvious to the
> end-user -- how do we tell him when he says "me too!" that we're going
> to email him only on these situations, how do we communicate to him
> and
> others that this bug is emailing them on these situations, and how
> do we
> allow them to shut up the bug if they want to.

Shutting up is easy: they unsubscribe from the bug.

2009/2/18 Christian Reis <email address hidden>:
> On Wed, Feb 18, 2009 at 04:08:23PM -0000, Karl Fogel wrote:
>> +1 on just doing it. In the rare cases where a user wants to say "this
>> affects me" but doesn't want to be subscribed, they can still
>> unsubscribe manually (which would not change the "affects me" status).
>
> I think we need to be careful about how much spam the person might
> actually be buying into if we did this.

We could include a link to unsubscribing in a message that appears
after clicking me too.

> Note that there's a reasonable middle ground that is unfortunately a bit
> of a special case: only sending notifications to users if the bug gets
> fixed or marked incomplete.

I think that this will complicate the notification system and make it
less usable. Users should be able to predict what emails they're going
to get.

KIko,

Maybe in this case we don't have to communicate it to the user? If a reasonable thing happens by default, we don't have to warn about that. User indicated that the bug affects them; user receives email when the bug is closed. That's reasonable, and therefore we don't necessarily need to warn them it's going to happen. Only the unexpected needs to be warned about.

As for how they shut it up: the email they get could tell them how, at the bottom. Also: if they uncheck the affects-me box, then obviously that "subscription" goes away. And clicking Unsubscribe could either unsubscribe from all notifications, or drop down into a menu in which one can slide one's subscription from "none" to "all events", and the slider would already be on one of the low-traffic settings.

Er, I think all that may sound more complex than it is. The user isn't confronted with the complexity until they're actually trying to do something, at which point it confronts them with just the complexity needed to do what they want.

...although, the more I think about it, the more I wonder: what is our exact motivation for having the affects-me-too button in the first place?

@karl

The motivation is this. It's all to do with psychology.

1. I have a problem with (say) Ubuntu.
2. I go to Launchpad to report it as a bug.
3. I type in the summary, and Launchpad gives me a list of likely bugs that have already been reported.
4. I check out a likely bug, and see that it does indeed apply to me.

What do I do next?

I have been through an involved process and I'm left feeling like "oh well... I did all that and I don't get to *do* anything"

In this situation, some users will deal with it and think "yeah, great, it's already been reported, so that saves me some time".

Some users will feel that need to write a "me too!" comment. We don't want this because it reduces the signal-to-noise ratio for everyone.

Some users will not write a "me too!" comment, and will do nothing, but will have an irrational feeling that they just wasted 5 minutes writing a bug summary for a bug that will never get filed.

To avoid these feeling of wasted effort, and to avoid the noisy "me too!" comments, we provide a "this affects me too!" button that the user can press to indicate that the bug does affect them. This gives some information about how many people would have filed duplicates but did not do so. So, comparing it to the number of duplicates in Launchpad, over time, can give us an idea of how effectively we are preventing duplicates being filed through our bug filing process.

It's also psychologically important to provide something for the user to do or see at the end of this bug filing process, and to allow them to feel there has been a dialogue, that they have put effort into using Launchpad correctly, and that effort has been rewarded by something listening to them. Having them click "this bug does indeed apply to me", and having Launchpad acknowledge that, neatly finishes the process that was started when the user wanted to file the bug. "Yay, someone is interested in listening to the fact that I had this problem!"

@Steve

I'm sold. Thank you for the detailed explanation.

I think the "Affects Me Too" button should be made more prominent when the bug is accessed through the search that is performed when reporting a bug. That is, the user attempts to report a bug, Launchpad provides a list of similar bugs, the user chooses one that he thinks is the same as what he was trying to report, and a nice, big "This bug affects me, too" button shows up for him to press.

For me, the user should be able to subscribe or not subscribe, with a default value . Maybe with something like it's proposed in the bug 644153, or in the bug 701022.