Change Details

This spike is for engineers to answer questions we have around the notification content display: ===Question 1=== What information do we get from notifications API on each notification? **Answer**: This is not comprehensive, but I made a spreadsheet of many notifications that I was able to trigger and their structure, located here: https://docs.google.com/spreadsheets/d/1-vvFoO0gLWAPJfo80RlXuS1LE3fFZ8rMuc59Vua-JtQ Any additional or future notifications we can handle in a generic way as a part of https://phabricator.wikimedia.org/T287033 ===Question 2=== What do we need to fetch to fill out the content view in both the standard notification, the deep press rich content system notification and content in the app notification center, as well as quick actions for each notification type? (notifications API is [[ https://www.mediawiki.org/wiki/Notifications/API | here ]]) **Answer**: Much of this we can do with the standard notification response objects without any additional data. I will highlight the stuff that will be more difficult: - Section names ("[USERNAME] left a message on your talk page [in the section [SECTION NAME]]") - It will be difficult to pull this. we might be able to from the primary url, but I suggest we nix any mentions of section name. - Indicating that a reply was to **your** message ("USERNAME responded to your message on TALK PAGE TITLE [in the section SECTION NAME]") - We will be able to tell if a new topic or reply is on the recipient's talk page, so we can use the phrase "your talk page". But we can't tease apart that someone specifically replied to the recipient's message on a different talk page. So this would just need to be "USERNAME replied in TALK PAGE TITLE". - Indicating a reply on classic talk pages ("Reply from [Username]") - The data for a new topic and a reply look the same, so we won't be able to differentiate this with the copy we show. - Inline replying in notification center or OS quick action - Unfortunately we don't receive a section ID on classic talk page messages, so we can't easily post an inline reply. It will be a little easier for flow, but we still need to parse through the url for the topic identifier. I suggest we nix or wait to see how Android does it. - Indicating number of failed login attempts in a custom message - We can either use the full message that API response gives us (we will strip html) "There have been <b>5 failed attempts</b> to log in to your account since the last time you logged in. If it wasn't you, please make sure your account has a strong password.", or something generic "There have been failed attempts to log in.". We can't both shorten this text AND indicate number ("There have been 5 failed attempts to log in."). This is because we don't get a distinct failed number as a separate piece of data. - Page summary preview on thank, edit reverted and mention notifications - We can likely add a page summary in the rich notification view (still extra work, but not too bad), but it would be very difficult to add it to the app notification center cells because that data comes from a separate fetch. If you don't mind them being different we can only show it in the rich notification view and remove from the notification center view, or nix both. - Edit summary in Edit reverted, talk page mentions - similar to page summary above, we can do this (with work) within the rich notification view, but not in the app notification center view. - Login notify (new device) - I haven't been able to trigger this one, so just mentioning here that I don't have enough info to advise yet. 2. What formatting can we support in standard OS notifications and rich OS notifications? Can we support blue links in rich notifications? If on two separate lines (and vertically adjacent), is the tap target too difficult for users to hit? - We can't intersperse bold text or links in the standard OS notification view (the non-rich one). We have a Title, Subtitle, and Body text to work with. Title and Subtitle are on their own lines and bold. - We **can** intersperse bold text and blue links in rich notifications. Unsure about tap targets, but we can easily nix if they become too difficult. 3. Will we be able to tease out particular links (like the username or article title) from the API response for some of these notifications? ==Additional spike discoveries and sidenotes== - The agent can be anonymous on many of these notifications. We'll need copy and quick actions for anonymous users. ("An anonymous user left a message on your talk page", hide "go to [anonymous user];s talkpage" option, etc.). - We can ask the API to bundle up the notifications for us using the `notbundle=1` flag, but the structure looks painful to keep track of to me. I think it would be simpler for us to keep them all separate and coalesce the copy ourselves in the Notification Service Extension (app notification center will always show them broken out). - A nice surprise is that we **do** get some additional inline data that the mocks don't yet take advantage of. These are: 1. We get the edit summary content for the thanks and mention (in edit summary) notification types 2. We get the content of the edit for all of the new topic and reply notification types. If it's a new topic, we only get the body content, not the new topic subject/section name. 3. We get the content of the talk page edit that a user was mentioned in, for the mention (in talk page) notification type.

This spike is for engineers to answer questions we have around the notification content display: 1. What information do we get from notifications API on each notification? What do we need to fetch to fill out the content view in both deep press of the system notification and in the app notification center, as well as quick actions for each notification type? (notifications API is [[ https://www.mediawiki.org/wiki/Notifications/API | here ]])===Question 1=== 2.What information do we get from notifications API on each notification? **Answer**: This is not comprehensive, but I made a spreadsheet of many notifications that I was able to trigger and their structure, located here: https://docs.google.com/spreadsheets/d/1-vvFoO0gLWAPJfo80RlXuS1LE3fFZ8rMuc59Vua-JtQ Any additional or future notifications we can handle in a generic way as a part of https://phabricator.wikimedia.org/T287033 ===Question 2=== What do we need to fetch to fill out the content view in both the standard notification, the deep press rich content system notification and content in the app notification center, as well as quick actions for each notification type? (notifications API is [[ https://www.mediawiki.org/wiki/Notifications/API | here ]]) **Answer**: Much of this we can do with the standard notification response objects without any additional data. I will highlight the stuff that will be more difficult: - Section names ("[USERNAME] left a message on your talk page [in the section [SECTION NAME]]") - It will be difficult to pull this. we might be able to from the primary url, but I suggest we nix any mentions of section name. - Indicating that a reply was to **your** message ("USERNAME responded to your message on TALK PAGE TITLE [in the section SECTION NAME]") - We will be able to tell if a new topic or reply is on the recipient's talk page, so we can use the phrase "your talk page". But we can't tease apart that someone specifically replied to the recipient's message on a different talk page. So this would just need to be "USERNAME replied in TALK PAGE TITLE". - Indicating a reply on classic talk pages ("Reply from [Username]") - The data for a new topic and a reply look the same, so we won't be able to differentiate this with the copy we show. - Inline replying in notification center or OS quick action - Unfortunately we don't receive a section ID on classic talk page messages, so we can't easily post an inline reply. It will be a little easier for flow, but we still need to parse through the url for the topic identifier. I suggest we nix or wait to see how Android does it. - Indicating number of failed login attempts in a custom message - We can either use the full message that API response gives us (we will strip html) "There have been <b>5 failed attempts</b> to log in to your account since the last time you logged in. If it wasn't you, please make sure your account has a strong password.", or something generic "There have been failed attempts to log in.". We can't both shorten this text AND indicate number ("There have been 5 failed attempts to log in."). This is because we don't get a distinct failed number as a separate piece of data. - Page summary preview on thank, edit reverted and mention notifications - We can likely add a page summary in the rich notification view (still extra work, but not too bad), but it would be very difficult to add it to the app notification center cells because that data comes from a separate fetch. If you don't mind them being different we can only show it in the rich notification view and remove from the notification center view, or nix both. - Edit summary in Edit reverted, Can we support blue links in rich notifications?talk page mentions - similar to page summary above, If on two separate lines (and vertically adjacent)we can do this (with work) within the rich notification view, is the tap target too difficult for users to hit?but not in the app notification center view. - Login notify (new device) - I haven't been able to trigger this one, so just mentioning here that I don't have enough info to advise yet. 2. What formatting can we support in standard OS notifications and rich OS notifications? Can we support blue links in rich notifications? If on two separate lines (and vertically adjacent), is the tap target too difficult for users to hit? - We can't intersperse bold text or links in the standard OS notification view (the non-rich one). We have a Title, Subtitle, and Body text to work with. Title and Subtitle are on their own lines and bold. - We **can** intersperse bold text and blue links in rich notifications. Unsure about tap targets, but we can easily nix if they become too difficult. 3. Will we be able to tease out particular links (like the username or article title) from the API response for some of these notifications? ==Additional spike discoveries and sidenotes== - The agent can be anonymous on many of these notifications. We'll need copy and quick actions for anonymous users. ("An anonymous user left a message on your talk page", hide "go to [anonymous user];s talkpage" option, etc.). - We can ask the API to bundle up the notifications for us using the `notbundle=1` flag, but the structure looks painful to keep track of to me. I think it would be simpler for us to keep them all separate and coalesce the copy ourselves in the Notification Service Extension (app notification center will always show them broken out). - A nice surprise is that we **do** get some additional inline data that the mocks don't yet take advantage of. These are: 1. We get the edit summary content for the thanks and mention (in edit summary) notification types 2. We get the content of the edit for all of the new topic and reply notification types. If it's a new topic, we only get the body content, not the new topic subject/section name. 3. We get the content of the talk page edit that a user was mentioned in, for the mention (in talk page) notification type.