[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