Design for on-page notifications

[folletto]

Breaking out from #1, in parallel to the on-hub notifications that are being explored in #23, this thread is to explore and discuss the design for the on-page messages.

As before this is meant to refer to the functional requirements.

It's important to note that the on-page and on-hub notifications are meant to build on the same subsystem, as per document.

[folletto]

Reposting this visual summary here for quick reference:

[folletto]

Building on the on-hub type of messages from #23, here's the proposal keeping the two aligned, i4:

Notes:

1. The design is here aligned with the same data structure and source as the on-hub notifications, so please cross-refer to these.
2. Notice that the design is meant to work well with a single notification as well as many: when it's 2 or more, a "Clear all messages" and an unread counter is shown at the top. This needs feedback if it's ok in terms of overall WP Admin design.
3. Notice that all messages here are always considered unread unless dismissed, thus there's no design without the dot.
4. Dismiss moves to provide a more intuitive layout when a button is present.

[folletto]

For reference, here are the various configurations for the on-page notifications:

[raaaahman]

I like the different designs on the variations.

However, displaying the "on-page" notifications like this doesn't seem to solve one of the initial issues: the visual cluttering of the admin pages. See how the actual page content is pushed down by the notification?

As a WordPress user, I would be perfectly fine if the "on-page" notification were actually displayed in the hub, and just filtered to appear or not on specific pages.

However, marketing experts might not really like this idea... What about building some kind of slider, so only one notification will be displayed at a time, and everyone will have a her moment to shine at the top of the screen?

[raaaahman]

Also, this makes me wonder about the logo: it seems to be fitting to have both a logo and an image for an on-page notification. However, when looking at on-hub notification, I thought that the logo was the image... And I wouldn't really add one more image in the little space that is remaining for on-hub notifications...

[folletto]

However, displaying the "on-page" notifications like this doesn't seem to solve one of the initial issues: the visual cluttering of the admin pages. See how the actual page content is pushed down by the notification?

Correct. But I think that's somehow unavoidable. The benefit here is to provide the quick counter + "clear all", as well as providing the backbone that later can be iterated.

It's difficult because:

1. If we hide some of them, plugin authors won't use them — nobody wants to have their option hidden, so they'll just keep rolling their own solution.
2. If we show them, the page is pushed down.

So, I reached the current compromise: show everything, but provide a clear all.

What about building some kind of slider, so only one notification will be displayed at a time, and everyone will have a her moment to shine at the top of the screen?

A good marketer knows that sliders are roughly equivalent as hiding content. ;)

Also, this makes me wonder about the logo: it seems to be fitting to have both a logo and an image for an on-page notification. However, when looking at on-hub notification, I thought that the logo was the image... And I wouldn't really add one more image in the little space that is remaining for on-hub notifications...

Yep, that's a tricky one. We could also just decide to not honor the display of the image if the notification is going to appea on-hub? Would that be bad?

[raaaahman]

So, I reached the current compromise: show everything, but provide a clear all.

🤔 Exposed this way, this sounds like the best compromise indeed.

Yep, that's a tricky one. We could also just decide to not honor the display of the image if the notification is going to appea on-hub? Would that be bad?

I've answered to this partly in the Design for notification in the admin bar issue.

I think we could make use of WordPress Media Library here, and display image with the size the more fitting to the actual display space. We could even add a default size setting for on-hub notifications... (Not sure how it would happen technically yet)

[folletto]

Here's the tweaked i5 from the feedback above, and resolving the "extra image" issue raised for the on-hub. Now there's no icon for the plugin, the image field is instead controlling the large image itself. I think it's still quite a clear distinction as it's a different call from an on-hub notification.

Check the mirror on-hub design i5 on #23 (comment).

[youknowriad]

Aside comment: looking at the screenshots here, I notice important work on "on-page" notifications. IMO, once of the biggest problems right now is that there's too many on-page notifications and plugin authors abuse these while I'd have preferred that all notifications were on a single page (notifications center). So my questions are:

• Do we really need on-page notifications?
• Can we instead of a nudge about "unread" notifications on the center instead? Isn't that enough and just educate the user about that. (though this is very common now)
• Otherwise, if we really can't live without these, are there plans to allow the user to opt-out of these (like mobileOS notifications where you can opt-out for different kinds of notifications).

[folletto]

I already answered both above and in the blueprint itself 😅

But let's say it in a different way, it can always be useful.

People use these spaces to market stuff and keep pushing for stuff. They create custom solutions to push their content at the top of the dashboard all the time. They are likely selling content, so they want their banner to be visible and up there. Thus:

1. A design that "hides", won't be for the most part an API that is going to be used. They see it hides their marketing, and they will keep rolling their own solution.
2. This means it won't be used for the most part. So we'd end up with now a system used by some, and STILL on top of that custom banners.

In short: any solution that "hides" them, is a solution that plugin authors won't use.

Unfortunately PHP, HTML and WordPress work in a way that means that we have no effective way to "lock" what shows up on screen like other platforms do. Unless anyone has a proposal on how to either create a "locked" solution (thus making the messages are the only alternative) or provide a proven alternative that plugin authors will be happy to embrace, I think our only hope for any form of adoption is a design like the above:

1. We show everything on page, so all plugin authors are happy.
2. We provide a quick way to clear all of them, so users are happy.

There are probably other alternatives, but these two criteria are key:

• Make something that plugin authors see as effective and makes them happy.
• Make something that users can manage quickly and consistently.

Thus, to answer your questions:

1. Yes we need to address on-page notifications => we want to provide a better way for authors
2. No, because that means effectively hiding them => authors will keep using their custom banner
3. No, because again that means effectively making them unreliable => authors will keep using their custom banner

[Clorith]

I agree, if they're not there, authors will find a way around it and add their own, these look nice, perhaps some way of having them be collapsed or similar is an alternative? So they're not taking the full screen straight away?

I'm also thinking there needs to be some kind of visual separation between each notification, the little dot on the side is more like a list item, so may be misunderstood that some of them are from the same source?

[folletto]

You mean something more like iteration 1 (#1 (comment))? Yeah we can probably go back to it, it's a compromise that might work.

Separation: yeah I kept going back and forth there. We can explore that further.

[hedgefield]

Nice work on these iterations @folletto! As much as I wish we didn't need 'em, I tend to agree with your conclusion that this form of notification is still smart to include.

I second @Clorith that maybe we can add a collapse arrow at the top next to 'clear all' to fold that whole section up? I'm thinking of sites with lots of plugins where users just leave 10 or 20 of these open, and then they'll eat up a lot of screen real estate. Maybe a user doesn't want to go through all of them right away, then at least they can fold it up. But I'm not sure, it might lead back into your original point if they don't have guaranteed visibility.

Thinking further of the scenario where there are 10+ of these, it might be good to include the plugin icon/logo like we do for the notifications in the hub. Makes it easier to spot what is what, without having to parse all the ad copy in each of these or scan for the little plugin name meta text.

Similarly, if there isn't an image included for the right side, could we put the actions over there? That might save some extra vertical space. Might also help make the placement of the Dismiss action more consistent.

Do we have any notable ones of these things with core WordPress messaging? The Welcome one is a dashboard widget right, and otherwise I think there are only error/warning notices? Should we move those into the notifications hub to ensure they don't get lost in the ads battlefield here?

[folletto]

As much as I wish we didn't need 'em, I tend to agree with your conclusion that this form of notification is still smart to include.

Same 😅

Maybe a user doesn't want to go through all of them right away, then at least they can fold it up. But I'm not sure, it might lead back into your original point if they don't have guaranteed visibility.

I think this is potentially a good use case. I think that as long as the collapse is temporary (i.e. it clears once the user navigates away from the page, and is open again the next time) then there shouldn't be a problem, and it would allow quick access to "everything below" without clearing.

Thinking further of the scenario where there are 10+ of these, it might be good to include the plugin icon/logo like we do for the notifications in the hub. Makes it easier to spot what is what, without having to parse all the ad copy in each of these or scan for the little plugin name meta text.

This creates a mismatch on the data model (#16): the image field is one. Here it's used for the image on the side, while in the hub it's used for the icon. I think it shouldn't be a problem as these are abstract, but I expect each plugin to include an illustration that makes sense for them — opportunely branded.

The alternative would be to have a way to "set" the icon as a separate data field (maybe like what we discussed here #24 (comment)), and the hub notifications ignores an image field if added.

That said, I did a bit of a flip-flop myself on what's better: a separate icon field? reuse of image? I don't have any strong argument in favor of either, but the currently agreed data model doesn't have icon.

if there isn't an image included for the right side, could we put the actions over there?

It's possible, but I'd say no for one reason: imagine having multiple items, it would make the actions to "jump" around: some left, some right. It would be not just visually sub-par, but also would break people expectations of where the button will be for each notification.

Unless, of course, we find a design that keeps the action location consistent.

Aside: we should also probably consider laaaarge screens? Maybe these should even be allowed to go in two columns, or the text limited to around 650px line length?

Do we have any notable ones of these things with core WordPress messaging? The Welcome one is a dashboard widget right, and otherwise I think there are only error/warning notices? Should we move those into the notifications hub to ensure they don't get lost in the ads battlefield here?

I don't think there's an answer here in abstract. If we have real examples, we can start testing them out. These examples could also be experiments with specific plugins. We might start to invite plugin authors to see if this would fit for them?

[hedgefield]

what's better: a separate icon field? reuse of image? I don't have any strong argument in favor of either, but the currently agreed data model doesn't have icon.

I would vote for having a separate field for an icon. It essentially adds meta data, similar to the plugin name and the time the notification was triggered, which has an impact on how and how quickly you parse a notification. Would be useful I think.

We might start to invite plugin authors to see if this would fit for them?

This sounds like a really good idea actually. I recently noticed Google Web Stories has quite a prolific banner after installing, and I'm sure we can think of a few others that we could ask if our template would work for them.

Unless we find a design that keeps the action location consistent.

Agreed, yeah the tricky thing is wherever we put it, the composition of elements can vary; dismissable yes/no, CTA yes/no, etc. I don't have a clear idea of what the holy grail would be here, but I'll keep thinking on it. Maybe as a small tweak to your initial idea, we put the Dismiss action next to the timestamp in every scenario? Its horizontal position won't jump around as much then at least.

[folletto]

Ok I bounced the question on the icon data field in the data model discussion here #16 (comment)

[EdithAllison]

This appears superseded by the new design approach tracked in #357, suggesting to close. @Sephsekla