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
SBisson | |
Feb 1 2016, 7:38 PM |
F3413871: Screen Shot 2016-02-24 at 12.54.36 PM.png | |
Feb 24 2016, 8:55 PM |
F3413862: Screen Shot 2016-02-24 at 12.22.56 PM.png | |
Feb 24 2016, 8:55 PM |
F3413867: Screen Shot 2016-02-24 at 11.37.06 AM.png | |
Feb 24 2016, 8:55 PM |
F3307016: flowboard-description-edited.png | |
Feb 3 2016, 11:41 AM |
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
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Add flow-description-edited notification | mediawiki/extensions/Flow | master | +235 -18 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T125653 Create new types of notifications | |||
Resolved | matthiasmullie | T125429 Create new notification type for when a board description changes |
PROPOSED DEFINITIONS: "FLOWBOARD-DESRIPTION-EDITED"
Here's my stab at helping to define this new notification type. Please comment.
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:
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
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
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
All specs seems to be in place - checked in betalabs.
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