I tried to capture some examples on how we can surface these actions.

One of the challenges is to communicate the effects clearly for elements the user is not currently viewing (topic or board). So I tried to clarify that in the messaging:

• Mentioning that the action applies to the topic or the whole page (using the page name in the later for extra clarity).
• Using a bubble notification to inform of the effects with an option to go to the relevant elements.
  • For the case of the page, I thought it was important to mention that this won't affect individual topics the user may be watching in the page, since that overlap may be generate confusions.

A related question, is to which extent we know what the user is subscribed to. That is, if the user unwatches a topic/page, are we able to know it so that we no longer show the unwatch action for those notifications related to the same topic/page?

In T132975#2256292, @Pginer-WMF wrote:

A related question, is to which extent we know what the user is subscribed to. That is, if the user unwatches a topic/page, are we able to know it so that we no longer show the unwatch action for those notifications related to the same topic/page?

We don't currently have that on the frontend, but we could look at adding it to the API response.

This approach looks sound. Thanks Pau. I have some questions, just to make sure we nail everything down:

• If I stop watching a topic or page, what happens to prior notifications about that topic or page? Do they stay in my message queue or disappear, as happens when we change the sorting filters? (I think they stay, right?)
• Do page and topic names get truncated in the menu? If so, what are the truncation rules?
• Language: three of the messages talk about "the topic 'x'" or "the page namespace:pagename" But the fourth says "Stop watching new activity on namespace:pagename" If this were parallel with the others, it would say "Stop watching the page namespace:pagename" What's the reason for the difference?
• In the menu's subsidiary links, you link the words this topic and this page. I'm assuming that on click the user would go to the page and or topic? If so--which seems fine--then we're good. (If the intention is that clicking will change the setting, then we need to clarify.)

I also had one quibble: I worked out that the icon is a star with a slash through it, which makes sense. But it didn't read as that for me at first. I showed it to a few others who had similar experience. @Pginer-WMF, I'm not sure how to advise you on the solution, but would it be possible to have another go at that. (I think the issue, for me, has to do with that little stub of the star-point on the lower right. My eye gets tricked into reading it as a short line running parallel to the slash, rather than seeing it as what it is.)

In T132975#2258413, @jmatazzoni wrote:

This approach looks sound. Thanks Pau. I have some questions, just to make sure we nail everything down:

• If I stop watching a topic or page, what happens to prior notifications about that topic or page? Do they stay in my message queue or disappear, as happens when we change the sorting filters? (I think they stay, right?)

The idea is for those to stay. I think that produces the less surprise (it's equivalent of visiting the page/topic and click on the star icon there). The only problem with that approach is what to do with the unwatch action on those notifications: hide it, show it disabled to communicate that you are no longer watching those or provide the opposite action. I'd start with the simple approach and not show the action in those cases.

• Do page and topic names get truncated in the menu? If so, what are the truncation rules?

If I recall correctly we were not truncating the actions in the menu since they have their own space. I think there was a max-width defined in which they would wrap if needed. This is just one more action to that menu.

• Language: three of the messages talk about "the topic 'x'" or "the page namespace:pagename" But the fourth says "Stop watching new activity on namespace:pagename" If this were parallel with the others, it would say "Stop watching the page namespace:pagename" What's the reason for the difference?

A page (or flow board in this case) contains topics. When unwatching the page there are two valid interpretations on how that will affect the topics you are watching on that page: topics remain watched or get unwatched too. A user may wonder: will I still get information on the specific topics I participated?

So, for the case of the page (due to this container aspect) I tried to add some clarifications. The "new activity" makes reference to the notification of new topics which is the notifications you get about topics you didn't subscribed because you are watching the page.

• In the menu's subsidiary links, you link the words this topic and this page. I'm assuming that on click the user would go to the page and or topic? If so--which seems fine--then we're good. (If the intention is that clicking will change the setting, then we need to clarify.)

Yes, they point to the topic/page. They provide a path to undo the action if you realise that the topic/page you unsubscribed was important.

I also had one quibble: I worked out that the icon is a star with a slash through it, which makes sense. But it didn't read as that for me at first. I showed it to a few others who had similar experience. @Pginer-WMF, I'm not sure how to advise you on the solution, but would it be possible to have another go at that. (I think the issue, for me, has to do with that little stub of the star-point on the lower right. My eye gets tricked into reading it as a short line running parallel to the slash, rather than seeing it as what it is.)

This icon was not yet in the official repo, I'll do some polishing to it.

#1, LANGUAGE -- I have a few clarifications and comments about this spec. The first is about language.

Re. the language in the screenshot above, Pau explained why he used the words "new activity":

...there are two valid interpretations on how [unwatching the page] will affect the topics you are watching on that page: topics remain watched or get unwatched too. A user may wonder: will I still get information on the specific topics I participated? So,... I tried to add some clarifications. The "new activity" makes reference to the notification of new topics...

@Pginer-WMF, I see why you tried different language here. But I don't think the language is doing what you hoped it might. Which is to say, the talk about "activity" won't clarify that unwatching a page will not unwatch the topics in the board. However, I think your idea of clarifying that in the confirmation dialog works well, so I think we are OK on this point. Meanwhile, as discussed online today, unwatching the page means both the talk page and the article. So with all that in mind, here are my language recommendations:

STOP WATCHING TOPIC

• Menu language: Stop watching this topic.
• Confirmation dialog:
  • You are no longer watching "how the moai moved?"
  • You can watch this topic any time.

STOP WATCHING PAGE

• Menu language: Stop watching this page.
• Confirmation dialog:
  • You are no longer watching Moai
  • This won't affect individual topics you may be watching. You can watch this page any time.

#2, WHAT MESSAGES GET WHICH OPTION?

I went through all the Flow messages to clarify which ones should a menu option to stop watching a page or a topic. You'll find the results on the new "UNWATCHING OPTIONS " tab of the old V2.0 Notifications spreadsheet. As you'll see, each Flow notification is labeled as either "Stop watching this topic," "Stop watching this page," or "na". Please have a look and leave questions or comments there; when we have consensus, we can copy the results here.

In considering this issue, a few general rules suggested themselves—or, really, one general rule with three flavors, which I here relay for your enjoyment:

• Keep it simple by showing only one option per message. E.g., there's at least one case—flow-new-topic—where you could offer to let people stop both the topic and the page. But that would, among other things, get us into having to manage bundles/non-bundles separately, about which see below.
• Keep it simple by not differentiating bundled messages: I don't see any instances where we need to differentiate between bundled and unbundled messages. The links can be the same, and I see nothing wrong with having all instances in a bundle repeat the same option (since the option is inside the dotdot menu, about which, see below).
• Keep it simple by always putting this option inside the dotdot menu: I.e., don't try to surface this message in some cases (where we have 0 or 1 secondary links) and bury it in others. Always put it in the menu.

#3, CONFIRMATION MESSAGE STYLE

Regarding the confirmation messages illustrated on the right side of this mockup:

@Pginer-WMF suggests using the elegant bubble notification style to present this message. But here's my concern: On the notifications page, in particular, the user might be directing her attention to a message in the queue at the bottom of the screen. But the I believe the bubble notification always appears at the screen's top-right? In which case, I'd be worried the user might not notice the confirmation. Pau, what do you think?

In T132975#2298757, @jmatazzoni wrote:

#1, LANGUAGE -- I have a few clarifications and comments about this spec. The first is about language.

Sorry for contributing earlier to the confusion.

The proposed language makes sense in general. My only concern is that I won't be surprised if people assume that "Stop watching this page." refers to the talk page only. If we find the confusion is common we may want to be more specific in advance ("Stop watching Moai"). Otherwise users may stop getting updates about the page for which they thought they have only muted its talk page.

In T132975#2298961, @jmatazzoni wrote:

#2, WHAT MESSAGES GET WHICH OPTION?

The list of actions for each notification type makes sense to me. Just one comment: For notifications about the user talk page, we probably don't want to provide quick actions to unwatch that page, but it may make sense for topics on the talk page still. Is there a reason for not including those?

Regarding the rules you mention, I agree with them, but I wanted to add some context ot the first one:

• Keep it simple by showing only one option per message. E.g., there's at least one case—flow-new-topic—where you could offer to let people stop both the topic and the page. But that would, among other things, get us into having to manage bundles/non-bundles separately, about which see below.

With Flow new topic you get notifications because a topic is created in a page you follow. You are not following those topics when they are created. You may follow them later, but it won't be surprising if notifications about the creation of such topics don't provide actions about that.

There is one action that could make sense which is to facilitate the subscription to new topics that just by the name you already found interesting. But when we tested that with users, was more confusing than helpful ("if I'm not watching the topic why I got the notification?").

In any case, I agree it makes sense to only show the option to stop watching the page in this context.

In T132975#2298971, @jmatazzoni wrote:

#3, CONFIRMATION MESSAGE STYLE
@Pginer-WMF suggests using the elegant bubble notification style to present this message. But here's my concern: On the notifications page, in particular, the user might be directing her attention to a message in the queue at the bottom of the screen. But the I believe the bubble notification always appears at the screen's top-right? In which case, I'd be worried the user might not notice the confirmation. Pau, what do you think?

Transient notifications like the "bubble notifications" try to take advantage of the ability of detecting movement in our peripheral vision. So these are better evaluated in motion. I used the same pattern in this video, although the timing was too short to read it could help to illustrate the effect.

Since "bubble notifications" are the standard MediaWiki component for lightweight notifications, I considered using them before inventing a custom solution for this specific case. But we can research and explore further in this area if needed.

Regarding language for stop watching this page, Pau notes that

we may want to be more specific in advance ("Stop watching Moai").

I think this might be helpful, so let's do it (though it increases the chance of the item needing to wrap).

I'll add the new spec to the description.

Pau wrote:

Since "bubble notifications" are the standard MediaWiki component for lightweight notifications, I considered using them before inventing a custom solution for this specific case. But we can research and explore further in this area if needed.

I just wondered if there was a different dialog/info box we could use that would be more centrally located. But if you think the animation will catch users' eyes, let's try it. Thanks.

In order to avoid increasing the visual language, as discussed with @RHo and @Volker_E we can start by using the empty star icon for this action (the icon named "Star" in the repo).

If we find confusion in practive (e.g., empty star triggering different actions in different contexts), we can consider using a specific icon describing the action (as proposed in T134752).

In T132975#2433018, @Pginer-WMF wrote:

In order to avoid increasing the visual language, as discussed with @RHo and @Volker_E we can start by using the empty star icon for this action (the icon named "Star" in the repo).

If we find confusion in practive (e.g., empty star triggering different actions in different contexts), we can consider using a specific icon describing the action (as proposed in T134752).

Everywhere else (desktop and mobile, standard pages and Flow topics), empty star (Star) means status ("it is currently unwatched; click to watch"), and vice versa for filled star (UnStar).

There are various different approaches to take here, but I strongly recommend we do not start with empty star meaning "it is currently watched; click to unwatch" since that is the exact opposite.

Hi @Mattflaschen-WMF – Since @Pginer-WMF is on vacation until Aug 10, I can outline the reasons for using the unfilled star icon.

Tl:dr; there was a lot of thought put into the decision, but per Pau's comment this is something that can be revisited if it is indeed shown to be confusing in practice.

Long summary below:
In pages where the star is shown on its own, it is a toggle filled/unfilled icon to indicate the status of that page (as being unwatched or watched). However, in this particular instance the icon is used to help indicate the action being taken, that is, 'to unwatch' the notification. So the icon used here could either show the action itself, or represent the status.

Option 1: Icon communicates the action
The initial proposal was to use a third icon—star with slash through it—to indicate 'the action of unstarring'.
Why we decided against this approach:

• Additional visual complexity – using two icons to indicate binary states like Watched/Unwatched, Read/Unread, Like/Unlike, etc, is far simpler than having to introduce additional icons to represent the action of triggering each state.
• Action text is the main focus here – if there was only an icon used to represent the action then an additional 'action' icon would make sense, but here the action is always explicitly written right next to the icon, and the icon merely acts as an auxiliary prompt as to what the action text relates to, so creating extra action-specific icons is somewhat excessive.

Option 2: Icon communicates the status
This option means using one of the two star icons.
i. Indicate the current status of the item by using the filled star
ii. Indicate the resulting status using the unfilled star

The decision was made to go with the unfilled star as more slightly indicative of what will occur upon the action being taken, and is the more commonly used convention.

A couple of examples of where this is used other sites (icon on action menu) is
(a) Google Drive – the filled star on the specific item indicates the status, and the action menu shows the unfilled star besides the "Remove star" action.

(b) Gmail (on iPhone app) - note the 'mark as read' uses the opened envelope (the resulting status).

If I understand correctly, the technical part of this depends on:

1. Adding 'what am I subscribed to' piece to the API response for notifications that are related to Flow boards -- is the user subscribed to the topic, the board, or neither, so we can allow the user to toggle that state. It would even be better if we create the subscribe link on the server-side, like we do for Flow.
2. Adding an interface to display and toggle these options.

Do we add one or two subscription options? For example, if I receive a reply to a topic, am I able to unsubscribe from the topic, or will I also be able to subscribe from the board this topic is in?

In T132975#2517448, @Mooeypoo wrote:

Do we add one or two subscription options? For example, if I receive a reply to a topic, am I able to unsubscribe from the topic, or will I also be able to subscribe from the board this topic is in?

I think this is specified in the task. I agree with that it should only allow you to unsubscribe to the one that triggers the notification.

Proposed approach from a conversation between @Mooeypoo , @Mattflaschen-WMF and myself:

• Add an action property to the secondary links data structure (would be set to watch, unwatch, flow-watch, flow-unwatch, thank or something)
• Make these secondary links backwards compatible (with a URL that works)
• Have consistent handling in the Echo front-end for all these actions, using templated i18n message names (e.g. echo-secondary-action-$action-confirmation-title) for the confirmation bubble and the link text after the action
• Have extensions register these actions with $wgEchoDynamicSecondaryActions[] = 'flow-watch'; or maybe add this as a property to the notification type definition
• Create a dynamic ResourceLoader module in Echo that exports all the echo-...-$action-... messages

Change 303314 had a related patch set uploaded (by Mooeypoo):
[wip] Add dynamic secondary actions to items

https://gerrit.wikimedia.org/r/303314

Change 303315 had a related patch set uploaded (by Mooeypoo):
[wip] Allow watching and unwatching of boards from Flow notifications

https://gerrit.wikimedia.org/r/303315

Action item: We need to get those icons into ooui.

In T132975#2486366, @RHo wrote:

• Action text is the main focus here – if there was only an icon used to represent the action then an additional 'action' icon would make sense, but here the action is always explicitly written right next to the icon, and the icon merely acts as an auxiliary prompt as to what the action text relates to, so creating extra action-specific icons is somewhat excessive.

That's a good point. Since it's not only the icon, most people should not get confused. If people still get confused, I agree a specific action icon (different from Star/UnStar) makes sense.

A couple of questions were raised while working on this feature, and I could use clarification. Pinging @Pginer-WMF

First, on the engineering side, we decided to make sure that these type of actions are relatively generalized to allow other extensions (like Flow in this case) to define "dynamic actions" in secondary links. This specific case has watch/unwatch action, but I can see how other extensions may need other dynamic API actions that Echo can display in the notification action menu. This affected some of the questions that are below.

I hope I manage to make these questions clear and organized -- please let me know if I need to clarify any of them.

• Confirmation message: Just to make sure, is the confirmation message "you are no longer watching the topic..." appearing instead of the watch button, or is it a popup confirmation?
  • If it's a popup confirmation - what happens to the 'unwatch' button? Is it swapped with 'watch' (see point below for more about that) ? Does it disappear?
  • If it is a replacement of that button text, what happens when I refresh the page or reopen this menu - do I always see "you are no longer watching..." from now until I physically go to the remote topic/board and watch it? Or, does it switch to 'watch' action when I refresh the page?
• Related - Reversible / opposite actions: This ticket only discusses 'unwatch' action. Do we purposefully ignore the opposite action - 'watch' ? Do we not want to display it? There are several cases where that action can be useful; for example, if I have a new topic notification, but I decided to 'unwatch' the board, I will stop getting new 'new topic' notifications, but the old ones remain. Should these not have a "watch new activity on the page" instead of the 'unwatch' (and now unusable/unclickable) confirmation sentence?

I can see how we would want to allow for reversible actions - watch transforms into unwatch, or whatever it may be - or non-reversible, where the state is either a one-time action (like in the 'unwatch' case in case we don't want to offer 'watch' or in future 'thank the user' that is a one-time action) or a single action that can be repeated (some extension can define some 'automatic reply' to the user's page, or some other action you can repeat but has no necessary confirmation.)

We would like to allow extensions to support sensible suite of options, so the code will likely have some provisions for these, but it will be much easier if I know what the intent was for this specific action, whether it is reversible, and where the confirmation message appears.

Also tagging @jmatazzoni

A couple of answers to @Mooeypoo's questions

Reversible / opposite actions: This ticket only discusses 'unwatch' action. Do we purposefully ignore the opposite action - 'watch' ? Do we not want to display it?

I don't think it's our intention to turn Notifications into a hub for controlling what you watch. The idea of adding these unwatch features was to allow very active users to reduce the notifications they are receiving. So, I'd say no, we don't add a "watch" function. The function just disappears after showing the confirmation

what happens when I refresh the page or reopen this menu - do I always see "you are no longer watching..." from now until I physically go to the remote topic/board and watch it?

That's a good question, but my instinct is that we don't need to sign up for the job of informing people about all the stuff they no longer do. If we do it here, it could create an expectation. Curious what Pau thinks.

In T132975#2529662, @Mooeypoo wrote:

Action item: We need to get those icons into ooui.

After discussing with the designers (details perfectly captured by @RHo in T132975#2486366), we decided to use the empty star icon for this action (the icon named "Star" in the the repo).

I'll update the mockups at the description to avoid confusion.

In T132975#2545813, @Mooeypoo wrote:

A couple of questions were raised while working on this feature, and I could use clarification. Pinging @Pginer-WMF

First, on the engineering side, we decided to make sure that these type of actions are relatively generalized to allow other extensions (like Flow in this case) to define "dynamic actions" in secondary links. This specific case has watch/unwatch action, but I can see how other extensions may need other dynamic API actions that Echo can display in the notification action menu. This affected some of the questions that are below.

This is a specific action for Flow notifications. It is true that other notifications may have similar actions in the future, and it is good to make it easy for them to do so (especially if it does not imply a big development overhead). However, if we are thinking on a general solution for volume control that works across all kinds of notifications, T115264 is the ticket to consider, and non-trivial generalisation efforts may be better spent there. In short, I'd like to avoid a situation where we pick the specific solution to provide a quick answer to user needs in a reduced scope and we spend an effort there we could have used to complete the general approach that benefits all notifications.

• Confirmation message: Just to make sure, is the confirmation message "you are no longer watching the topic..." appearing instead of the watch button, or is it a popup confirmation?

It is a popup confirmation. In T132975#2256292 I suggested using bubble notifications. I know bubble notifications do not have exactly the same look as in the mockup and there may be technical limitations in laying out the information there (so it is ok for the result to diverge from the spec), but I think it was more important not to reinvent the wheel (we may be able to improve them in the future).

• If it's a popup confirmation - what happens to the 'unwatch' button? Is it swapped with 'watch' (see point below for more about that) ? Does it disappear?

The idea is to provide only the action to "unwatch" and provide only when it applies. If the user wants to watch again, they can do so from the flow topic/board (and we indicate so in the bubble notification).

• Related - Reversible / opposite actions: This ticket only discusses 'unwatch' action. Do we purposefully ignore the opposite action - 'watch' ? Do we not want to display it? There are several cases where that action can be useful; for example, if I have a new topic notification, but I decided to 'unwatch' the board, I will stop getting new 'new topic' notifications, but the old ones remain. Should these not have a "watch new activity on the page" instead of the 'unwatch' (and now unusable/unclickable) confirmation sentence?

For now we are focusing on allowing to unwatch. The main scenario is about a user getting too many notifications from a given discussion and having a quick way to stop getting notified.

The scenario you described (deciding to get further updates about a new topic) makes perfect sense. This was an action that I included in one of our notification panel prototypes and it resulted highly confusing for users (when viewing an action about watching a topic they assumed it was not being watched and was confusing, why they were getting the notification in the first place). My conclusion was that understanding what was going on required some internal knowledge on how Flow works, and we need to iterate on how we present such action to make it more clear. Therefore, I think further actions may deserve their own ticket to be considered at a later stage.

We would like to allow extensions to support sensible suite of options, so the code will likely have some provisions for these, but it will be much easier if I know what the intent was for this specific action, whether it is reversible, and where the confirmation message appears.

I hope the above clarifies. In summary, we are aiming to provide a specific one-time action for a specific type of notifications. The main goal falls under the general volume control idea (T115264), but applied to one specific case where the need for it may be more urgent.

Awesome, this clarifies things for me. Thank you both!

Added for the requested models:

Unwatch board

• flow-new-topic
• flowboard-description-edited (not if in the user's talk page)

Unwatch topic

• flow-post-reply
• flow-post-edited
• flow-topic-renamed
• Flow-summary-edit (not if in the user's talk page)
• Flow-topic-resolved (and reopened) (not if in the user's talk page)

Change 303315 merged by jenkins-bot:
Add unwatch topic/board dynamic action for Flow notifications

https://gerrit.wikimedia.org/r/303315

Change 303314 merged by jenkins-bot:
Add dynamic secondary actions to notification items

https://gerrit.wikimedia.org/r/303314

Checked the general functionality according to the specs (incl the checklist by @Mooeypoo).
Aside from @Pginer-WMF's observations that will be addressed , i.e.

• the star icon should be empty
• phrasing in the pop-up when referring to a topic should say "You can watch this topic any time" (for topics)
• the option 'unwatch' should be provided for bundled new topics (as for the whole bundle) notifications (as it is for bundled replies)

@Pginer-WMF and @jmatazzoni, please take a look at the screenshots below decide whether more adjustments are needed or all is fine for the first iteration:

(1) Monobook display

• is it ok for the option to be that small?
  
• the dotdotdot menu is not aligned?

Regarding the huge topics - We should probably send the truncated version of the title to the message rather than the full one

In T132975#2584910, @Mooeypoo wrote:

Regarding the huge topics - We should probably send the truncated version of the title to the message rather than the full one

That makes sense. The purpose of mentioning them in the confirmation is to connect the points, but the users already know which topic are they acting on.

As suggested by @Mooeypoo, two cases were checked and all looks good.

1. no-js - works as expected.

2. Right-click

a) the right-click on the dotdotdot menu will give the option to open it in the different tab/window - the topic will be opened there.
b) the right-click on the "Stop waching ..." option does not give options of a different tab/window

Change 307023 had a related patch set uploaded (by Mooeypoo):
Change 'unwatch' icon to an empty star

https://gerrit.wikimedia.org/r/307023

Change 307027 had a related patch set uploaded (by Mooeypoo):
Style and text fixes for unwatch actions

https://gerrit.wikimedia.org/r/307027

Change 307023 merged by jenkins-bot:
Style changes for unwatch actions

https://gerrit.wikimedia.org/r/307023

Checked in betalabs

• the specs for the star icon are in place

I'm running into a technical problem: Right now, there's no way to tell -- from the 'actions' point of view -- whether a notification item is inside a bundle or not. This means that adding an action to an item adds it to all cases of this item - both when it is outside and when it is inside a bundle.

I can add the 'unwatch' action to the bundle itself, but if I then remove the action from individual items, they won't show this action when they are outside the bundle ('standalone' items) either, which is not helpful.

So until we figure out a better way to do this, should I add it to the bundle itself, or leave it as part of the individual notifications?

Change 307440 had a related patch set uploaded (by Mooeypoo):
Notification title fixes

https://gerrit.wikimedia.org/r/307440

Change 307440 merged by jenkins-bot:
Notification title fixes

https://gerrit.wikimedia.org/r/307440

In T132975#2592976, @Mooeypoo wrote:

I'm running into a technical problem: Right now, there's no way to tell -- from the 'actions' point of view -- whether a notification item is inside a bundle or not. This means that adding an action to an item adds it to all cases of this item - both when it is outside and when it is inside a bundle.

I can add the 'unwatch' action to the bundle itself, but if I then remove the action from individual items, they won't show this action when they are outside the bundle ('standalone' items) either, which is not helpful.

So until we figure out a better way to do this, should I add it to the bundle itself, or leave it as part of the individual notifications?

I'm confused as to what the problem/question is.

At beta cluster, I see the "unwatch" action is available for:

• Flow-reply (standalone)
• Flow-reply (bundle)
• Flow-reply (item within a bundle)

That seems like a good setup, and appears to be consistent and non-troublesome, UX-wise.

What is the problem we are needing to solve? or, what are the alternative configuration options?

In T132975#2593261, @Quiddity wrote:

In T132975#2592976, @Mooeypoo wrote:

I'm running into a technical problem: Right now, there's no way to tell -- from the 'actions' point of view -- whether a notification item is inside a bundle or not. This means that adding an action to an item adds it to all cases of this item - both when it is outside and when it is inside a bundle.

I can add the 'unwatch' action to the bundle itself, but if I then remove the action from individual items, they won't show this action when they are outside the bundle ('standalone' items) either, which is not helpful.

So until we figure out a better way to do this, should I add it to the bundle itself, or leave it as part of the individual notifications?

I'm confused as to what the problem/question is.

At beta cluster, I see the "unwatch" action is available for:

• Flow-reply (standalone)
• Flow-reply (bundle)
• Flow-reply (item within a bundle)

That seems like a good setup, and appears to be consistent and non-troublesome, UX-wise.

What is the problem we are needing to solve? or, what are the alternative configuration options?

I may have misunderstood, but in the request I got from Pau, I understood that the 'unwatch' action should only be in the "parent bundle" itself (not in the sub-items)

@Pginer-WMF can you chime in here? Is the 'unwatch' behavior (where it appears) good enough, or would you like it to change, and if changed - please read the comment above since I am having technical issues with splitting things up -- what should I do?

In T132975#2593274, @Mooeypoo wrote:

@Pginer-WMF can you chime in here? Is the 'unwatch' behavior (where it appears) good enough, or would you like it to change, and if changed - please read the comment above since I am having technical issues with splitting things up -- what should I do?

I'm totally fine with items inside the bundle to provide the action. We don't need to remove that. I was asking for the action to be added to the parent bundle item too. I captured the inconsistency in the screenshot below:

As you can see, the second item has an option to unwatch, while the first does not. I'd expect both of them to have such option.

I'm adding User-notice, because most of wikis targeted by TN are using Flow, sometimes as a Beta feature.

Checked in betalabs:

• the popup message about a topic that is unwatched has been corrected.

• truncation for long titles is done

@Pginer-WMF Note: no truncation is needed for titles in the dotdotdot menu?

Change 307627 had a related patch set uploaded (by Mooeypoo):
Followup I7ad9dd5b436: Truncate title in item label

https://gerrit.wikimedia.org/r/307627

In T132975#2595895, @Etonkovidova wrote:

@Pginer-WMF Note: no truncation is needed for titles in the dotdotdot menu?

Oops. That was not supposed to happen. Fix added and waiting to be merged.

I am now going to fix the 'unwatch' in bundled items as per @Pginer-WMF's comments above, after which I believe the issues will be per spec again.

Change 307627 merged by jenkins-bot:
Followup I7ad9dd5b436: Truncate title in item label

https://gerrit.wikimedia.org/r/307627

Change 307633 had a related patch set uploaded (by Catrope):
Followup I7ad9dd5b436: Truncate title in item label

https://gerrit.wikimedia.org/r/307633

Change 307633 merged by jenkins-bot:
Followup I7ad9dd5b436: Truncate title in item label

https://gerrit.wikimedia.org/r/307633

Change 307027 merged by jenkins-bot:
Add unwatch actions to bundle items

https://gerrit.wikimedia.org/r/307027

Removing user-notice. Not that important. But it would have been totally in scope of the future Collaboration newsletter.

Re-checking for - all looks good

• truncation for long titles

A long page title - Special:Notifictions page

• the 'unwatch' option for bundled notifications is present now for new topics also.