Page MenuHomePhabricator

Create new notification type for when a board description changes
Closed, ResolvedPublic

Description

When a board description changes, notify the watchers of the page and the talk page owner if the board is a talk page.

TBD: Language, links, icons, bundling rule

Event Timeline

SBisson raised the priority of this task from to Needs Triage.
SBisson updated the task description. (Show Details)
SBisson added subscribers: Aklapper, StudiesWorld, SBisson.

PROPOSED DEFINITIONS: "FLOWBOARD-DESRIPTION-EDITED"
Here's my stab at helping to define this new notification type. Please comment.

  • Proposed name: flowboard-description-edited
  • Icon: "topic-renamed"
  • Header Text:
    • single: The description of PageName was edited.
    • Plural: The description of PageName was edited multiple times.
  • Body Text: excerpt of the description (if feasible)
  • Primary Link: View Page > Go to the page
  • Secondary Links:
    • View Changes > The diff of the description
    • The username of the user who edited the description > Links to the user page of the user

QUESTION: What does Matthias's note about a "bundling rule" refer to?

Icon (Maybe the same as flow-post-edited?)

For icon, I'd suggest the same as "flow-topic-renamed". It is similar but it represents the bigger container by using a single speech bubble instead of representing a specific conversation.

The rest, looks good to me:

flowboard-description-edited.png (90×452 px, 10 KB)

QUESTION: What does Matthias's note about a "bundling rule" refer to?

I guess it refers to the rules by which we should turn similar events into a single notification.
In this case I think it makes sense to group all the edits for the same page into a single notification, and using the "plural" text version proposed ("The description of PageName was edited multiple times.") seems good for that.

Change 268164 had a related patch set uploaded (by Matthias Mullie):
Add flow-description-edited notification

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

Bundling is indeed how to decide (if at all) which things to group together.
I gather that we'll roll multiple edits to the same board description into 1 grouped notification (=bundle)

The proposed text for that currently says: "The description of PageName was edited multiple times."
Since we know the exact amount, shouldn't we make it say so? E.g. "The description of PageName was edited 3 times." (where 3 is the exact amount)

Also, similar to other notifications, do we also want a different message if the description was updated on your own user talk page? E.g.:
"The description of PageName was edited on your talk page."

@matthiasmullie asks:

The proposed text for that currently says: "The description of PageName was edited multiple times."
Since we know the exact amount, shouldn't we make it say so? E.g. "The description of PageName was edited 3 times." (where 3 is the exact amount)

I'm guessing that if we said "three times" what we'd be talking about would be the number of times someone pressed the Save button? If that's the case, I don't think that is helpful, since all three Saves might, practically speaking, be part of one "edit." It's not like getting 3 replies, which are distinct things... This message is based on the message for flow-post-edited, which similarly does not try to count the edits.

@matthiasmullie also asks:

similar to other notifications, do we also want a different message if the description was updated on your own user talk page? E.g.:
"The description of PageName was edited on your talk page."

Interesting question. I'll ask one in return: what is the difference between creating a variant of this message, as you suggest, vs. creating a new notification type? Here's why I ask: The message "A post in “Rapa Nui” was edited on your talk page" is not a variation within flow-post-edited; it's the message for the newly minted notification type flowusertalk-post-edited.

So, to rephrase my question: What's the difference between the two approaches (new notification type vs. message variant), either of which would seem to do the job. E.g., is one easier than the other? Do we get needed flexibility? Etc.

Actually, in code, flowusertalk-post-edited doesn't exist. It is just a flow-post-edited, rendered with that slightly different text if it is on the user's talk page (because doing it that way was easier than creating a new notification type and having to cancel out the other flow-post-edited notification that could also be sent to that user)

flowusertalk-post-edited doesn't exist.

OK, now you're messing with my mind. So the answer, I suppose, is that it doesn't matter how I record this. Big picture, yes, let's go ahead and do it. I think the message can be slightly simpler than what you suggest above, since the "Pagename" in this case actually is the talk page, i believe. So the message would be: "The description was edited on your talk page."

Let's go ahead and call this a variation of the feature under discussion here, flowboard-description-edited. So that feature definition, which I'll add to the spreadsheet, now looks as follows. Folks, does this look right?

REVISED DEFINITION: "FLOWBOARD-DESRIPTION-EDITED"
Here's what now looks like an approved definition

  • Proposed name: flowboard-description-edited
  • Icon: "topic-renamed"
  • Header Text:
    • single: The description of PageName was edited.
    • Plural: The description of PageName was edited multiple times.
    • User talk page: The description was edited on your talk page.
  • Body Text: excerpt of the description (if feasible)
  • Primary Link: View Page > Go to the page
  • Secondary Links:
    • View Changes > The diff of the description
    • The username of the user who edited the description > Links to the user page of the user

The language, icons and links for this have been documented as of today in the spreadsheet V 2.0 Notifications -- Showing Updated Text and Links

Change 268164 merged by jenkins-bot:
Add flow-description-edited notification

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

All specs seems to be in place - checked in betalabs.

  • single: The description of PageName was edited.

Screen Shot 2016-02-24 at 11.37.06 AM.png (217×558 px, 39 KB)

  • Plural: The description of PageName was edited multiple times.

Screen Shot 2016-02-24 at 12.54.36 PM.png (193×579 px, 32 KB)

  • User talk page: The description was edited on your talk page.

Screen Shot 2016-02-24 at 12.22.56 PM.png (182×554 px, 35 KB)

Hi @Etonkovidova, looks good but I'm noticing what looks like a time maybe (?) in a second line of text in the excerpt for this example.

What is that?

@jmatazzoni - It's just a template {{CURRENTTIME}} which is a part of the text in the board description.

Of the timestamp on its own line in this screenshot, Elena writes:

It's just a template {{CURRENTTIME}} which is a part of the text in the board description.

So, if I understand correctly, that time stamp is part of the excerpt. It's on a second line in the body because there was a carriage return in the actual description. @Etonkovidova, is that right?

If so, I don't think this is displayed properly. My interpretation of the excerpt spec and truncation rules is that the excerpt should only ever be on one line. So the question would be: in cases where the first paragraph of the text we're excerpting is very short, should we: a) just show the first paragraph, no matter how short or b) show one line's worth of text but remove any carriage returns so that the text displays all on one line? I assume we want the latter, otherwise we're going to have a lot of message excerpts that say just "Hi Bob" and nothing more. This would apply to all excerpts, BTW.

@Pginer-WMF, am I interpreting the design correctly? And what do you prefer?

@Pginer-WMF, am I interpreting the design correctly? And what do you prefer?

Your interpretation is correct. We should avoid excerpts forcing the notifications to be taller than necessary. At the same time, we want to keep in that line as much info as possible so skipping new lines is the way to go.
I created a ticket capturing these considerations based on an example I found recently: T128062: Keep notification excerpts compact and meaningful

Closing this bug based on the existence of T128062, which should answer the issue about the excerpt appearing on more than one line. (@SBisson, please speak up if that issue needs to be solved on a per-notification-type basis instead of overall.)

Closing this bug based on the existence of T128062, which should answer the issue about the excerpt appearing on more than one line. (@SBisson, please speak up if that issue needs to be solved on a per-notification-type basis instead of overall.)

It's indeed going to be fixed overall.