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:
- **Some** section names - Some talk page and mention notification objects return a primary url with the section name as the fragment. We just have to extract that and remove the underscores, so this can be done. There may be other notification types (like flow) that do not have this data, so we should provide a fallback option without the section name if this happens.
- 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.
==Question 3==
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?
**Answer**:
- 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.
==Question 4==
Will we be able to tease out particular links (like the username or article title) from the API response for some of these notifications?
**Answer**: It depends. We get user information (in `agent` object) and article information (in `title` object) for notifications. So with that plus the notification type means we can construct almost any copy we want for recognized notifications. But one big caveat is we would then be relying on local translations to trickle in for any custom copy we construct. The alternative would be to use the text the Notifications API already gives us (which I think is what is displayed on Desktop), and will likely arrive to us already translated. The downside to that is we will have less freedom in the copy we use and how we format it.
**Followup**: We discussed this in planning, see notes here: https://phabricator.wikimedia.org/T284237#7240787.
==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 as a part of the "body" fields. 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.