Review current designs and compare to Requirements document

[jonathanbossenger]

The WP Notify Requirements document needs to be compared to the original designs, and the designs updated as needed.

[hedgefield]

These mockups were made two years ago in support of Alain Schlesser's Notification Center proposal:

https://www.figma.com/file/pa2npjErKEkx4rZgo6ZWLs/WP-notification-center-mockup-v3?node-id=0%3A1

Let's review them against the new requirements doc, notification center best practices, UX design principles, and WordPress design sensibilities.

For starters, I'll note that these mockups only showed an example of front-end interaction with the notifications. They do not include any settings pages or more complex flows yet.

[folletto]

I did a first pass review. I think these are still a good start, we can refresh and polish but they are a solid start regardless.
However, they aren't covering everything in the requirements right now.

Specifically, we need to cover all the types covered in the Use Cases section. Reshuffling that section from a design angle, this means we need to have two types of messages:

• Notification — an item shown in an notification area
• On-page — a message shown on page

Both needs to allow for:

• Non-action — just a dismissable informational message
• Action — a message with attached a specific action

This translates to two active areas:

• some form of notification hub where to show the notification type
• the top area of the page where to show the on-page type

There's likely also a separate UI that needs to be able to show configuration settings, this is more TBD right now, as well as the specific data model for the content of the notifications.

Makes sense?
Anything missing?

[wittwitsan]

Here's preview from @hedgefield 's mockup. I created the prototype for reviewing.

https://www.figma.com/file/nzpcqxnW9q7zySdiPfLD5L/Initial-Mockup-for-v1?node-id=0%3A1

Now we only have the notification hub mockup as a solid start for the Notification type which we need more design of the On-page and digging into details of Action/Non-action as @folletto suggested.

One more thing to consider about the On-page design is the compatibilty with WP Editor (Gutenberg) design UX/UI - Gutenberg Snackbar which also have notification itself.

[daniloercoli]

This translates to two active areas:

....
the top area of the page where to show the on-page type

I'm curious to hear your thoughts @folletto about how the on page notifications could be integrated in the mobile native apps.

[folletto]

Good question, and... I think that's an open question right now.

My current take starts from the Requirements Doc, where we have:

On-Page messages: a local notification, shown only on a specific page, and contextual to the page content

And we have these use cases as on-page:

Onboarding: the plugin wants to provide guidance on a specific feature, i.e. “try this feature” (action, on-page)
State: the plugin changes its state, i.e. “settings saved” (no action, on-page)
Marketing: the plugin wants to advertise something or suggest an upgrade, i.e. “buy an upgrade!” (action, on-page)

This means that:

• Onboarding: this might show up in a "dashboard" equivalent on mobile native. Probably the main site menu?
• State: probably not shown on mobile native, as it's contextual to the currently loaded plugin. It could be mapped to the snackbar across systems, but given this, I'm not sure when something fires a snackbar type event that happens to be on mobile native too.
• Marketing: probably not shown on mobile, as it's likely to refer to an installed plugin asking to upgrade.

[daniloercoli]

Onboarding: this might show up in a "dashboard" equivalent on mobile native. Probably the main site menu?

Yes, the main site menu makes sense to me...another idea could be to reuse the Notifications screen, already available in the apps, and use it for both On-page (onboarding) and Notification types.

[folletto]

Yes, that's true — for mobile that could be enough.
I also wonder if the Notification API should be able to explicitly include/exclude native in its parameters — that's probably a separate discussion tho.

[folletto]

Today @ibdz and me spent some time pair-designing in Figma to lay down all the "main" parts that we need to surface. It's not meant to be in-depth, or cover all the cases and types of message, it's a first iteration to get a sense of the overall project. As such, it's meant to cover both notification type and on-page type, as well as their placement and format.

One is the notification, within the notification hub, providing both just informational messages, and messages with actions. It's mostly based on the original design by @hedgefield — functionally quite identical.

1. Changed to a dark tone to match the admin bar at the top, since that's the location of the notification hub indicator.
2. Notification hub indicator using a more "standard" icon+counter approach.
3. Introduced an icon at the bottom to have quick access to the settings screen.
4. Actions are handled via links inside the text.

This is the "new" bit. It borrows idea from all existing components, trying to strike a balance between standardization and use cases — especially for marketing. We tried to keep in mind that if these messages aren't "good enough" to provide information and a marketing push, they won't be used, so we would still have the problematic overlap of multiple banners we have today.

1. The component always shows the name of the plugin triggering it, so a plugin can't fake to be something else, and it's always clear for the user who generated a specific message.
2. The message contains other than a body, the following optional elements: title, image, action button.
3. The dismiss action is always visible.
4. When more than one message is on page, this design tries to strike a balance between visibility and organization. In the end, too many messages competing for attention won't work, but at the same time a pagination approach would also hide too much and plugins won't be too keen in using them. Thus we identified a mixed approach: show a collapsed view (from most recent to oldest) and use the accordion interaction pattern with the oldest message opened by default. This would make plugins visible, but also create a sense of clarity and a clear action for the user to get through them.
5. Status messages are simpler: either with or without action. We explored a lighter approach if there's no explicit action – with just "Dismiss" – but a more clear approach with buttons if there's an action attached.

Figma file for i1 here:
https://www.figma.com/file/nzpcqxnW9q7zySdiPfLD5L/Initial-Mockup-for-v1?node-id=48%3A10

Please note that this is just the first iteration: a lot of things are still to be added, refined, the settings screen needs to be designed, and so on. The most useful feedback at this point is a high-level feedback on the overall interaction approach, not much about the details or the visuals.

[folletto]

Addendum: the design exploration also raised a bit the question about the data model we want underlying these messages. The above i1 implies a high degree of flexibility for each message:

• all have body content
• some body content is HTML
• some have a title
• some have an action
• some have an image

This is probably something we want to review: do we want to be more strict in the standardization here, allow more flexible fields, or something in between?

[daniloercoli]

Addendum: the design exploration also raised a bit the question about the data model we want underlying these messages. The above i1 implies a high degree of flexibility for each message:

Just my 2 cents about the data model from a mobile native perspective.

• If we go with HTML content in the body, i hope it will be restricted to few tags, otherwise it could be hard to represent the body properly in a native web view.
• Action - What the button should do on mobile native? i guess the easiest approach will be to open a web view, both in app or on system browser, and take the user to the proper HTML page within wp-admin.

[folletto]

Data model discussion moved here: #16

[jasmussen]

Wonderful to see movement, I'm so excited for better notifications to land in WordPress. @folletto asked me to briefly look at this thread though the lens of having worked with the block editor project. For context, I also, back in the day, worked on WordPress.com notifications. Please see my feedback in that light, and forgive me if there's nuance that I'll no doubt be missing.

The aspect of the conversation happening here I love the most, is the high level goal to unify a system that is currently a bit all over the place. This goal of reduction and simplification is a torch I hope the project carries proudly to the end!

I would love to see that carried over to the design as well. I find that visual simplicity lets the content breathe:

• Reduction, overall. 3 colors are better than 6.
• Fewer borders. When borders are necessary, make them seen. When they aren't really necessary, do you really need it?
• Question every element. It might not be needed, and if it is, it can almost always be added when it proves itself necessary.

Around notifications specifically, WordPress users are probably unlikely to get as many unreads as they do on Facebook and Instagram. If we embrace that, perhaps we space things out to be more pleasant to read, more contrastful, and generally simpler overall. With that in mind, I took a quick stab at some mockups. Consider them ideas, and take what works and discard the rest.

Here's a simpler notification bell:

It's vertical to better work in context of increasingly vertical icons in the block editor. SVG if you want it:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M10.1 17.5c0 .2-.1.3-.1.5 0 1.1.9 2 2 2s2-.9 2-2c0-.2 0-.3-.1-.5h-3.8zm6.9-6V9c0-2.8-2.2-5-5-5S7 6.2 7 9v2.5c0 1.8-.3 3-2 3.5v1h14v-1c-1.7-.5-2-1.7-2-3.5z" /></svg>

Unread:

Here's a notification sheet that opens above all content:

This affords just a bit more whitespace, bigger margins, better spacing, and the ability to separate read from unread with more than a background color change.

I hope this was useful!

[hedgefield]

I'm loving how this is moving forward. Thanks @folletto and @ibdz for stepping up with a solid opening bid, and thanks for chiming in @jasmussen, I love the Gutenberg flavor you've brought into the playspace. I tend to be in favor of minimalism and breathing room in a design too, though I like both directions.

About the actions, I think it's a smart bet to work them into the text, that's what we do with most of our notifications at Yoast too. It feels more natural to work links into a sentence. Also saves us a headache around buttons and their layout and string length etc. I'll add to #16 if have more thoughts about that.

[jonathanbossenger]

Great work here everyone. Please do ping me if there is anything specific I can do to help this process along, I'm definitely not a designer, but I can poke folks as needed 😁

[jonathanbossenger]

This ticket has been quiet for about 2 weeks now. Should we post this to the make blog to help gain feedback, or do we just need to allow a little more time to finalize these questions.

[folletto]

I think there's enough feedback to do a i2 second iteration, but my main concern right now is to get clarity on #16 — the design informs the data model, but also requires the discussion on the data model to progress to a draft proposal, which then can be iterated in design and see if it works.

I'd suggest to have #16 with more feedback, and define the next draft of the data model we want to work with.

[jonathanbossenger]

Aha, thanks @folletto I will make a point to work on this during next weeks office hours!

[hedgefield]

I put together a little iteration on @folletto great design above with the latest ideas from the data model discussion in #16. I took elements from both his and @jasmussen's designs, mixed together in a dark and a light version. I'm not sure yet which one I like better.

https://www.figma.com/file/PIRT7PBfCYIxn4urohVInn/WP-Notify-design-v2-Tim?node-id=48%3A10

[raaaahman]

I like how the dark version matches the left sidebar. Black on white seems a little easier to read from a distance though.

Also, the various notifications you represented are nice examples about what could be displayed in the notification center.

[hedgefield]

I expanded the i2 mockups with a first setup for a settings page and an 'archive' page that lists all notifications chronologically, as mentioned in the requirements doc https://www.figma.com/file/PIRT7PBfCYIxn4urohVInn/WP-Notify-design-v2-Tim?node-id=48%3A10

The list of notification sources to toggle should probably be a table, and the wordpress/mail/phone toggles can be improved a bunch in the a11y area alone, but I just wanted to throw an idea down that we can iterate on. Haven't seen a lot of discussion or definition about the elements on these pages, or where they should live in the admin, so let me know what you think!

I think we've moved on from the original scope of this issue, which was comparing the designs from 2018 with the requirements doc from 2020. I believe we've done this to satisfaction and moved on to making new designs, so I've split those out into #23, #24 and #25 to focus discussion. With that I think we can close this issue?

[folletto]

I thought of adding a quick visualization here of the "types" from the Requirements Document. I tweaked "Notifications" to use "On-Hub" to avoid a bit of crossover terminology.

[folletto]

I think we can close this one: we have reviewed the existing designs, matched with the requirement docs, kicked off the data conversation (#16), and branched the next iterations:

• On-page: Design for on-page notifications #26
• On-hub: Design for on-hub notifications in the admin bar #23
• Settings: Design for the notifications settings page #24