Talk:Requests for comment/Notifications in core

Moving the "Reply to" template into software

One additional task that needs to be done is that the functionality of the {{Reply to }} template (also known as the ping template), should be moved into the software somehow so that it isn't necessary to actually have a "reply to" template in order to ping people in discussions. Perhaps it should be implemented as a parser function or something similar. Kaldari (talk) 22:20, 1 March 2016 (UTC)

• The RfC says mention notifications would be left in the extension. --Krenair ^{(talk • contribs)} 22:24, 1 March 2016 (UTC)
• It's already not necessary to use the template. However, User:Legoktm has a proposal to introduce a parser function for this, rather than links. There are pros and cons. Probably mostly a win. Mattflaschen-WMF (talk) 23:33, 1 March 2016 (UTC)

For skins

Please don't just put it in core as is. Please. Fix the interface problems when you do, as echo is currently very, very difficult to skin around, and putting it in core will force this and probably break quite a few existing skins. Go all-out and at least break them all with actual improvements that are not going to need to massively break again later.

As a skinner, the main thing I'm familiar with is the badges that appear in the personal tools menu, which pretty much just assume your skin is vector and that's it. That doesn't work.

• For any skin that collapses the personal tools into a dropdown menu or similar, this requires some pretty silly code in their BaseTemplate to work around and move them out after the fact (timeless).
• For responsive skins that display p-personal inline on desktop and only collapse it when it doesn't fit anymore for mobile, you're basically just screwed. More on this later if I can come up with a 'reasonable' workaround for monobook, though.

We need some way for skins to specifically place the notifications (maybe some sort of BaseTemplate::getNotificationsToggles), with perhaps inserting them into the personal list as a default if nothing else is specified (no call to the above, as calling it inside that would probably be kind of hard in the first place). We need the handler and display of notifications to be standardised and expected such that they can be effectively and consistently worked with regardless of what layout folks are even using, or even such that extensions can hook into it following this format for their own notifications replacement instead if they want, and still have it work with skins.

Other issues also include:

• That none of echo itself appears to be responsive and will just go off the side of the page and become inaccessible if it doesn't fit, including on mobile devices or if the personal menu is just in a weird place it doesn't expect (can probably be fixed later with minimal disruption)
• That the badges render using different css rules before and after being clicked on (appearance doesn't change, just the rules used to make that appearance) (may or may not be fixable later with minimal disruption)
• That there's always two badges means they take up valuable screen real estate, when on smaller resolutions it probably matters more that there's any, rather than which kind they might be; may also want to be able to support more than two, such as allowing extensions to add their own (may be fixable later with minimal disruption if future variance is at least properly accounted for now)
• That the badges themselves are unclear as to their meaning and distinction, and cannot be overridden by skins based on that meaning to use different icons (can probably be fixed later with minimal disruption)
• That skinners may not even want badges at all - mobile monobook uses a user icon for the personal dropdown toggle, and just putting the number on top of that instead of on a badge, and then having fulltext links in the dropdown itself as well could be another viable approach.

Honestly I'd kind of recommend doing a full assay of the landscape around this to figure out what the problems and expectations are currently and what the needs and targets are that need to be addressed overall, because I'm probably missing some obvious things here. (Re)do the design research, but this time focusing more on how it interacts with skins/extensions and their overall UX including it, essentially. -— Isarra ༆ 16:00, 9 May 2018 (UTC)

But, uh, definitely actually do this, because seriously echo being an extension is just making all the above problems even harder to deal with because first we have to check if it's even there and then we still have to fix all that in every single skin individually. I just don't want more than one messy transition here, as it's going to be one. -— Isarra ༆ 16:05, 9 May 2018 (UTC)

I think your conclusion is sensible. Should we make a list of some skins that the refactor should cover, to get at least the 95 % of cases right? Whoever proposes to work on this could branch the various skins and extensions to test their compatibility with the branched core including notifications. --Nemo 19:54, 11 June 2018 (UTC)