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

[WordPress Trac]

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

Comment (by schlessera):

 I too think that there should be an API first, and the visual notification
 center in the dashboard would then be one specific use case of
 implementing this API.

 In general, a notification API should be a routing system, that allows to
 receive communication from a '''source''' and route it to a
 '''recipient'''.

 Valid types of '''sources''' are Core, plugins, users, server environment,
 cron jobs, ...
 The '''recipient''' can be either a specific user or a role/capability.

 The notification should have a '''type or group''', and the user should be
 able to define where they want to receive the individual types/groups. So,
 if a plugin reminds me for the 20th time that I should rate it 5 stars,
 I'd like to only have this shown in the notification center in the
 dashboard (or even not at all). But if my backup plugin wants to tell me
 that the backup failed, I want to receive this via email & Slack
 notification.

 So, there would be multiple '''destinations''' that a user can have
 enabled, and the user should be able to configure these individually, with
 sane defaults applied by default.
 Destinations can be dashboard notification center, email, Slack, HipChat,
 IRC, SMS, ... Basically, we provide an interface, and multiple destination
 providers can implement that interface.
 As a default setup (OOB experience), I could see having both a dashboard
 UI and an email as destinations, and showing everything in the dashboard
 UI, and only sending important/urgent notifications to the email.

 Regarding the '''message size''', I don't think limiting it to 280
 characters is a good idea. It will probably make translations an eternal
 struggle, with cut off messages all around. The reason why Twittter
 switched from 140 chars to 280 chars is because some languages couldn't
 make proper use of it with 140 chars. Now, those languages can use
 Twitter, but a limited version as compared to the others. There's no
 "character limit" that makes sense when applied across all languages.

 I'd rather prefer the ability to block certain sources, and to adapt the
 font size/compactness of the notifications instead, and then let the
 "market" figure out the rest.

 Regarding the '''state''' of the notification, I think it should also
 allow for some sort of "snooze" functionality. But that is certainly not
 something we should implement from the start. Just want to state this to
 make sure we don't turn the state into a boolean to mean unread/read. Who
 knows what other states we might need in the future.

 I don't think we should allow for an '''expiry''' of notifications, as
 that can only be provided in an "updateable" medium. If you send the
 notification via email or Slack, for example, you cannot expire it.


 The above API would then also have an impact on how the visual design of
 the dashboard UI works:
 - Every notification must clearly show a "source" in a consistent way.
 - Every notification may show a type/group in some way (not sure if or
 how).
 - There should be a link within the UI to configure the user's
 preferences.

 Also, notifications should not assume anything about the context in which
 they are being displayed.

 On the server side, the API could look something like this:
 {{{#!php
 <?php
 function delete_my_stuff() {
    // $this->stuff->delete();
    wp_notify(
       WP_Notify::SOURCE_CORE,
       get_current_user_id(),
       WP_Notify::TYPE_ALERT,
       __( 'Yikes! All your stuff has been deleted.', 'default' )
    )
 }
 }}}

 On the client side, the JS API could mirror this signature, and then use
 the REST API `/notifications` controller to execute this.

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