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

WordPress Trac noreply at wordpress.org
Wed Mar 7 15:56:49 UTC 2018


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

Comment (by hedgefield):

 Thanks for the feedback feedback so far!

 For this PoC, I looked at the wordpress.com notification center, Facebook,
 Google, Meistertask, Instagram and in general my mental modal of
 expectations for a notification center. Speaking for myself, I generally
 prefer simplicity, so the filtering and second expanding sidebar on .com
 are a bit much, and I appreciate being able to clear the badge asap on
 facebook, which is why I added the Mark As Read. But hopefully for WP the
 notifications will be a lot more useful and relevant, so I can see that we
 move that somewhere else, or just remove it for MVP and make it depend on
 whether you take action on a notification or maybe look at it for 3-5
 seconds. A settings icon would be useful too I'm sure, left it out in the
 PoC as I didn't have any settings in mind yet.

 I'll make a more detailed breakdown of pros and cons of other notification
 centers, so we can have informed discussions about the separate features.

 It may indeed be a good call to start off giving just WP itself access to
 this. This gives plugin authors time to think about how they can integrate
 without having to scramble right away because their admin notices now look
 crappy when frankensteined into that sidebar. That's what I mean with
 backwards compatibility: introducing the notification center once it has
 been fully thought out also requires an exit strategy for admin notices,
 since those can be huge and filled with custom styling and whatnot, which
 wouldn't translate 1-to-1 to the new notification properties per se.

 Regarding the more technical side of notifications, Riad said (in relation
 to his PoC plugin):


 > As a V1, I built as a client-side API trying to provide a compatibility
 layer with existing notices. So client-side code could trigger
 notifications but without any persistence. I think we should make this
 step work well to catch all the plugins notifications etc. I was thinking
 of checking the way these notifications are generated right now in PHP and
 if there’s APIs and common ways to do it, and try to provide some kind of
 backwards compatibility with this plugin.

 > Once this work well, I think we can start thinking about a backend API
 and a persistence layer. Something like “keep the last 100 notifications
 persisted”, “Provide a way to trigger notification from the backend”,
 “Client-side code could also create and persist notifications” (REST
 API?). => this could be the V2.

 I know Alain Schlesser and John Billion have ideas about this too. I'd say
 we first focus on the higher level concepts and architecture here, maybe
 defer some experimentation and prototyping to the plugin's repository.

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


More information about the wp-trac mailing list