1862483 - Add message action to block a message group

Status: RESOLVED WONTFIX

(Firefox :: Messaging System, task)

Description

[Shane Hughes [:aminomancer]]

User Story

As a PM, I want to be able to let a user choice choose “I do not want this message again” and we do not show they anymore message in that group.

For example, if they selected that on a VPN callout message, we should not be showing them VPN Spotlight or VPN moments pages.

Requirements:

• A message might have two or message groups; we will only block one (i.e. Callout - to control frequency and VPN)
• User will not see the message is that group (i.e. VPN)

Open Questions

Would a user ever want to reset and start seeing the messages again? (I doubt it)

Comment 1

[Shane Hughes [:aminomancer]]

Attachment: Bug 1862483 - Allow FxMS to block message categories. r=#omc-reviewers

Comment 2

[Punam Dahiya [:pdahiya]]

Requirement is bit ambiguous. How will a user know difference between Don't Show this message again or Don't show message from this group again (probably same as turn off all messages). Are there any designs to help clarify this usecase?

Comment 3

[Shane Hughes [:aminomancer]]

We should block something narrower than a message group. Right now I've written the patch to block a message group, but I think it makes more sense to add a new category property that messages can have. We agreed that blocking the cfr group is too drastic and has far-reaching consequences. Also, blocking a group/category will be irreversible, unlike toggling the CFR user pref. So we need to be more delicate.

The user is already able to block CFRs by changing the CFR user pref, and there will be an option to control that pref in the split dismiss button dropdown. So instead of blocking ALL messages in cfr group, user could block a narrower subset of messages specific to a domain — for example, a VPN feature callout could have an affordance to block future VPN messages. That's not a message group and may never be, but instead a message could look like this

groups: ["cfr"],
categories: ["vpn"],
dismiss_button: {
  action: { dismiss: true },
  label: ...,
  menu: [
    {
      label: ...,
      action: {
        type: "BLOCK_CATEGORY",
        data: ["vpn"],
      },
    },
    ...
  ]
}

We also considered that these smaller "categories" would contain a smaller amount of messages, like 3 messages for example. They could represent "series" in some cases, like a Fox Guide campaign run from Jan 2024 to Mar 2024, and the category ID would then be retired when the series is finished. So while we only have 6 message groups, we could in the future have dozens or hundreds of categories/series.

The reason to do this in general is that we don't necessarily know when we launch part 1 of a series what all the message IDs in that series will be. Right now, if you wanted to have an affordance to block a series, you'd need to plan everything out from the start so that your very first message gave an affordance to block part 2 and part 3 by ID. But in many cases things don't go according to plan, and ad hoc decisions are made, so it would be great if we only needed to plan what category ID we're going to use. And then allow all messages in the series to block the whole category at any time.

Comment 4

[Shane Hughes [:aminomancer]]

Punam, here's the new spec for user control:

https://docs.google.com/document/d/1Wn2Gd34CbY5p1b0_X1QDNEnrQyjOrAgAwDVT_eve4CM/edit

Comment 5

[Shane Hughes [:aminomancer]]

We can add an action item for next week to discuss modifying the copy from e.g. "Don't show this again" to "Don't show messages like this"

Comment 6

[Vtay]

I've highlight that as a challenge in the spec and we're working it out with our content team/Ux team

Comment 7

[Ed Lee :Mardak]

If what should be blocked is a per-message decision, could this be done with SET_PREF and adding targeting? E.g., !"messaging-system-action.block.vpn"|preferenceValue to check if a user clicked don't show that set block.vpn?

Comment 8

[Shane Hughes [:aminomancer]]

Sure, that would be possible without landing any changes. Aesthetically I'd prefer if we didn't swell up the targeting expressions with more pref getters, but I guess in the long run we will be using the forthcoming CMS, which can configure the actual targeting expression in the background with individual toggles like Experimenter does.

Comment 9

[Punam Dahiya [:pdahiya]]

+1 on simplicity of the fix using prefs to show/hide messages in a category via targeting. This approach is similar to hiding all feature recommendations using pref browser.newtabpage.activity-stream.asrouter.userprefs.cfr.features and if needed can be made a user setting on about:preferences.

For VPN might be worth looking into existing prefs to disable/enable VPN Promo to turn off all VPN promo messages

Comment 10

[Punam Dahiya [:pdahiya]]

Closing bug based off last few comments on direction of fix, please feel free to reopen if there is work needed for this ask. Thanks