[wp-trac] [WordPress Trac] #43484: WordPress Notification Center proposal

[WordPress Trac]

#43484: WordPress Notification Center proposal
-------------------------------------+-------------------------------------
 Reporter:  hedgefield               |       Owner:  (none)
     Type:  feature request          |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Users                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  ux-feedback dev-         |     Focuses:  ui, accessibility,
  feedback needs-design              |  administration, rest-api
-------------------------------------+-------------------------------------

Comment (by hedgefield):

 Thanks to everyone for their input so far! Good discussion already.

 For starters, I think it’s important to remember that while a notification
 feed in the admin is the first and foremost usecase, we should also make
 sure to build this in such a way that it can support other forms of
 delivery in the future, like @schlessera says.

 He pointed me to the Slack API for messages, which is very well documented
 and describes a lot of their considerations for how they built it. I’m not
 much of a technical expert in this regard, but it seems like a good source
 of inspiration. If you want to take point on that @schlessera that would
 be wonderful.

 That said, the first and foremost usecase to explore for that API is of
 course the well-known notification center dropdown. This will be my focus.

 I’ve compiled a list of characteristics that the big notification center
 implementations have, so we can compare and contrast.
 https://docs.google.com/document/d/1q7MhBrTPkpSvnvyCmaf9sd6y27MXYI1QHq-
 lqsp6Wuc/edit?usp=sharing

 Based on all that I drafted a preliminary MoSCoW-style list of features
 that the API should support. For myself at least I found it a nice way to
 start framing the features in level of importance for MVP. Doesn't mean at
 all that this is the full list, it will likely expand as we drill down
 into this. Do let me know if you already feel something is missing or
 should be in a different order.

 **Must have**
 - ID
 - Sender (core, plugin, theme, user)
 - Destination (sites, roles, users)
 - Timestamp
 - Read status (read/unread)
 - Message body
 - Links in the message body
 - Dropdown to contain the feed

 **Should have**
 - Notification type/category icon/color
 - Settings page
 - Multiple channels (email, push, slack etc)
 - Email notifications
 - Sent status for all different delivery methods
 - Multisite support

 **Could have**
 - Basic markup (bold, italic etc)
 - Expiry date
 - Filters for specific topics
 - Settings to hide certain notification (types) away from certain user
 roles (don’t bother clients with upgrade notices and whatnot)
 - Ability to group notifications per day
 - Dedicated action buttons

 Then there are some specific points that I wanted to respond to:

 I am strongly in favor of limiting the word count for the messages in the
 notification center, but I can agree that sometimes you just really need
 some more space, be it for translations of to get an important message
 across, like the ServeHappy nag. So instead of limiting the notifications
 themselves, it makes more sense to limit their display in this usecase. As
 I saw in the research, most other notification feeds are limited to about
 100-150 chars, so 280 chars is a royal amount. Then if there is more text,
 we hide it behind a collapsible section, similar to what Facebook does for
 long posts. Alternatively, you could write a small ‘excerpt’ notification
 and link to a dedicated page where you put the rest of the info you want
 to convey.

 If we are going to restrict admin notices to the notification center this
 way, I feel like it might be fair to allow bold and italic. We could also
 semi-restrict it: Facebook for instance bolds the usernames and
 post/group/event names for extra emphasis.

 The simplest version of this thing would be one that only holds WP
 notifications. But I think before we launch we should make it possible for
 plugins to hook into this too. I don’t think we can move all of the
 notices there immediately, there are some that are huge that would need to
 be redesigned by their authors. But if we don’t give them access to the
 API from the get-go I think the adoption will be much more troublesome. As
 long as the WP ones are in there as inspiration we should allow third-
 party notifications I think. Then we can start drafting a roadmap for
 eventually disallowing them.

 The only admin notices allowed should probably be errors.

 Automatically marking messages as read is what I would prefer too, though
 I can imagine a usecase where you want to come back to something that you
 don’t have time for right now. But maybe we could solve that in a
 different way in v2.

 For some notifications a timestamp may not be needed, but for granular
 stuff like changing settings or publishing content you would want to see
 who did it and when, I’d say, at least so you can hold them up against
 analytics and spot trends or problems.

 Thanks @folletto for pointing me to that other ticket, as I’m now a
 component maintainer for the toolbar I’ll definitely take a look, though
 holy hell that’s a long one :D

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43484#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform