Here is some conversation we had today in Planning

• Notifications usability issue https://phabricator.wikimedia.org/T294369#7503373
• Is this connected to https://phabricator.wikimedia.org/T288538
• Theory that API was “improved” by Editing (?) for desktop which broke it for mobile
• May be possible to pull it based on username/timestamp. Something changed and there could be other APIs

Hi @JTannerWMF
I am still researching the best way to take the user to the correct section from a notification, but in the meanwhile, could you please expand on what this means ->

Investigate and record behavior of displaying user talk page messages as a list view

We are currently displaying them as a list:

Thank you :)

Yes sorry for any confusion, this basically means exposing some of the message as well and making it collapsible if possible

@JTannerWMF Thank you!

Findings from the spike:

Investigate and record behavior of displaying user talk page messages as a list view

It is technically possible to have a list view of sections and make them each a collapsable view that reveals the messages within that section. However, I feel it will increase the complexity of replying to messages, and might become too much of a scroll for cases where there are many messages per section/ many sections per talk page. I would suggest not going in this direction. Cc @Dbrant

Investigate and record behavior of exposing timestamps and user names for user and article talk pages

Timestamps are available on all api responses. this can be exposed per design.

Reach out to understand gaps in the API that is leading to the lack of consistency in passing back the right section

I have identified a couple hacks to deduce the section from the API responses:

1. We can parse the compactHeader in the notifications API response. I see that when a user starts a new section, we get @username left you a message, but when they message within a section, we get a strong tag, like ‪@username left you a message in \"<strong>‪@sectionName</strong>\" This happens dependably.

Or,

2. When we get the notifications API response, since talk page entry is basically an edit, we get a revisionId for it, and if we make another API call to get the details of that revisionid, under

parsedcomment we always get the section name. We will need to parse the parsedcomment and need to find a solution for duplicate section names, but it is always available..

However, in both cases duplicate section names will always need a work-around. Looks like @MattCleinman is talking to the API team to give us a more dependable and unique section identifier explicitly as part of the API response. I feel that should be the way to go, rather than hacking it in the above ways.

@schoenbaechler @JTannerWMF hope this helps. Please let me know if you have questions.

Thanks for this @Sharvaniharan. From a user’s perspective, the expectation is straightforward. Tapping a '...left a message on user/article talk page' notification should take the user to the corresponding message/reply in the corresponding talk page subject. Automatically scrolling to that message (e.g. with an #anchor) and highlighting it would be ideal. I’ll trust you and the engineers to decide what the best technical solution for it is. Long story short: I’m excited! ;)

Will move this to PM signoff, per our plans to discuss this with the editing team and then decide how to move forward.

I'll hold this until we have that conversation with the Editing team and know which approach to take

This issue is going to be resolved with work from the Editing team