[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 folletto):

 > Must have

 I think a must have is some sort of configuration panel, even if minimal
 for the first release, accessible from the dropdown. The reason is that we
 want to make sure users can CONTROL the notifications. We can discuss what
 is sensible to have in the first release, but given how easily
 notifications can be abused (and I don't mean by plugins and themes
 necessarily, sometimes we are at fault too with overloading users by
 accident) it's something that is important to have as a statement of the
 direction this is going.

 > Sender (core, plugin, theme, user)

 Connected to the above: if "sender" includes "which plugin" the settings
 screen could start with a simple list of on/off switches for each
 category:

 * System and Updates (core)
 * Plugins (all, or name of plugin)
 * Theme (just the active one)

 I'm not sure on "User" as sender. Can you expand on this?

 > 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

 I'm strongly in favor of limiting this too. And I'd prefer to have a
 strict character limit. Notifications are meant to be short messages that
 lead somewhere else. Quick.
 Having to "open" a collapsed view, or cutting some text to make it fit,
 would defeat the primary reason of effectiveness of a Notification,
 doubling the amount of interactions needed.

 While I understand the problem with translations, I think we can find a
 good number of chars that would work across languages. If something has to
 be rewritten to fit, it's just the same amount of work that already
 happens in any primary language to make it work. It's not different,
 right?

 For important notices I think it's the same: if it's something important,
 lead to a page with the proper page of an extended explanation instead of
 trying to make fit everything there.

 > 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.

 I understand why this can seem a good idea, but I'd reserve any styling to
 be functional, not stylistic. As you mention, usernames for example can be
 made bold, but bold shouldn't be available just as a way to highlight the
 content.

 If we zoom out from the individual notification message to the whole
 stream, not having too much styling going on eases readability on the list
 as a whole. :)

 > But if we don’t give them access to the API from the get-go I think the
 adoption will be much more troublesome.

 I agree, a lot.
 I'd push this even further – even if I'm aware this might be what you
 already meant: first the API, and then both Core and Plugins will use the
 same API. Right? ;)

 > 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.

 "Automatic" can be tricky in dropdown situations. What I could suggest
 here, also mirrored in the mockup above, is to mark something as read with
 these conditions:

 1. If the notification is clicked
 2. If the "Mark all as read" is clicked

 We can refine this later to make it more automatic, but I feel this could
 be a good starting point.

 I'd also add that we can differentiate "read" from "seen", as some
 notification systems do. The difference is:

 1. A new notification arrive, it's signalled in the toolbar icon with a
 red dot
 2. The user clicks, but then doesn't either click on the notification nor
 "Mark all as read"

 This will leave the individual notifications as "unread", but the toolbar
 dot will disappear.

 Why? In this way we have a two-tier system that allow more flexibility.

 That said... we might not want to do this in the first version as it adds
 a layer of complexity.


 > 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.

 This is a good point. I'm neutral on the subject as I see both advantages
 and disadvantages. I'd say we can start with. ;)


 > { Designs }

 As far the designs go, I'd go probably for the first. It's the simplest
 and feels cleaner.


 A couple of extra things:

 I'd suggest to **not show the number of notifications in the toolbar**,
 but just a red dot. The counter adds mental pressure, and the red dot is
 already enough for most use cases: if one can check notification, will
 check notifications regardless of how many they are. Remembering the
 number has just went up from 1 to 2 is... hard. And seeing a larger number
 can just put off people that will stop caring about it at all "Too many
 events, I'll just stop looking".

 In a way, a dot without a counter is a more "calming" kind of interface,
 which is something we should strive for in principle, right? :)

 As for the icons, we should provide either the ability to use any
 Dashicons, or, do something like Gutenberg is doing, which is also
 allowing a plugin to load any SVG inline.  This should allow ease of use
 (I can just type a Dashicon name) but also flexibility (I can inject any
 icon).

 Then again: this is probably a feature to be added in a future release.
 It's easy enough to detect SVG code and enable the feature later.

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