Design System

[johnhooks]

The questions

How does the current design take into account the Gutenberg design? Can it be adapted to fit that design system? It is the new system and seems to be the direction the new Admin will be heading, see the Thinking Through the WordPress Admin Experience post on the Make WordPress Design blog. If this project introduces a new design system I feel we are just compounding the issue raise by Joost de Valk in his post WordPress’ admin UI needs to be better.

The proposals

• Use the WordPress Design Library.
• Use @wordpress/components where possible, and contribute back any components we design to help fill out the component library.
• Remove the concept of Dashboard notifications. How they are rendered is problematic (see Issue Layout shift on page load #183) and we should focus on rendering notifications out of the normal page flow. We can leave that type of admin alert to that old system, hopefully guiding everyone towards the new.
• Add toast and modal notifications. They would be good replacements for the traditional Dashboard notices. Toasts can display temporal information that doesn't have to persist on the server. Modals are helpful for notifications that require user attention at the moment they are emitted.

[paaljoachim]

The WP admin based on Gutenberg/Block Editor system is still a bit down the road. It might take another year before we see the various WP admin links in the Site Editor as mentioned here in the post by Matias: https://make.wordpress.org/design/2022/06/13/thinking-through-the-wordpress-admin-experience/

Right now one can think about these things in the back of the mind, but the foundation is not fully in place yet. Even though the Site Editor now has a link to Navigation, Templates and Template Parts there is still a lot of exploration needed before other types of screens are added. Next up might be pages and posts.

One can create a Notification foundation that can at a later time more easily adapt to Gutenberg/Block Editor. In the mean time the UI can instead focus on other existing aspects of WordPress. Such as the Site health and Privacy screens. As suggested in #281

The bottom line is that one needs to figure out how to present a lot of notification options, and using a kind of tab system as Site health and Privacy does currently is one way to go.

[johnhooks]

@paaljoachim the current notification drawer is made of custom React components, we were wanting to see what if @wordpress/components might also work well for this project, and possibly contribute back if there is interest in the React components we design.

[ciampo]

From what I'm aware, as of today there are not concrete plans of adding new components to @wordpress/components for dealing with notifications UI specifically.

Although this may change at a later point, if/when the focus is going to shift on WPAdmin.

@jasmussen, do you have any insights?

[jasmussen]

Depending on the design of a notifications system, I would think that a large part of it could hopefully be built using existing componentry — notices, buttons, tabs, segmented controls, etc.

I would also say that the Icon library is ready to receive new additions in the form of a bell or otherwise.

As far as adding new componentry for notifications, it's hard to grasp what might be needed. But an "unread dot" might be interesting, and for what it's worth I could see such could be useful beyond notifications. For example in the site view of the site editor, you might have unsaved changes in a particular section. I'm pretty sure I've seen such an unread-dot in various @WordPress/gutenberg-design mockups, this older query based one comes to mind but there are more. How technically that would work, is unclear.

Is that helpful?

[johnhooks]

@jasmussen yes it is. I agree there are components that we can already draw from. We would like to contribute back any components we need that aren't available. as long as everyone feels they belong in the component library.

Thought the big question is, should we be designing this feature using the traditional Admin interface or using the newer design system of the Block Editor?

My opinion, is to build the both the notification UI and notification settings page using React, the WordPress Design Library, and as many @wordpress/components as we can.

[jasmussen]

Big question. My personal take, and perhaps hope, is that the majority of a notifications system exists inside a panel, a modal overlay, a side panel, something like it. If that's the case, it gives a clean canvas on which to build upon in a modern way — yes, ideally reacty and using WordPress components. Such a panel would need to be invoked from a button, presumably a bell somewhere, and I suppose that bell could be implemented one way for existing admin, and somewhat simply refactored in a future refresh. Does that make sense?

[johnhooks]

@jasmussen yes thank you. We are getting really close to releasing a demo and it will be easier for you to see where the project is at. We do have a bell icon that is in the admin menu bar that opens the notification drawer. Right now we have only taken advantage of the Button component from @wordpress/components, but we'll be refactoring and looking for more that fit the system.

[jasmussen]

Sounds good. Might be good to loop in @youknowriad for general awareness or feedback, I know few stronger reacters!

[youknowriad]

I think @jasmussen all of my potential concerns/suggestions. It is fair to say that the design library and the components package is the "design system" of WordPress. It might not be perfect right now but the idea is that it's the base that we work on together. A reacty notification panel built on top of it is something that can be integrated within a future rectified admin or the current WP-Admin without big changes.

I also want to note that there's a number of other packages and APIs that a reacty WordPress notification panel should probably be using:

• For instance, if there's a need for a11y live message, it should probably rely on @wordpress/a11y
• If there's a need for frontend data API, it should probably rely on @wordpress/data
• If there's a need for keyboard shortcuts, it should probably rely on @wordpress/keyboard-shortcuts
• If there's a need for user preferences, it should probably be using @wordpress/preferences
• If there's a need for fetching data, it should probably be integrated into core-data (later is fine)

And I'm probably missing some.

[Sephsekla]

This is a really valuable discussion, thanks for raising it!

I'm conscious that a lot of the current UI came from the first proof of concept demo, which largely prioritised having a working prototype to show, so it would definitely be worth auditing to see where we can better integrate it with the existing wordpress packages.

[johnhooks]

@youknowriad We are already using @wordpress/data, @wordpress/shortcuts, @wordpress/escape-html and @wordpress/date, we will look into the rest. But yes, we really want this to be integrated with the existing systems and not rebuild what has already been done.

[mateuswetah]

I know this is hard to deal with, but I think there is a challenge here.

On one hand, the notifications feature is something that all of us have been eager for years and it is great to see how far things are going right now ❤️

On the other hand, I can see how important it is that this feature brings as much as possible of the new packages and overall UX from the Post and Site Editor Design Systems (which are, in my opinion being amazing so far). BUT, it is weird and a bit out of place, that this is done before or in somehow separated from a complete Admin refresh... I know this is already in the plans (🙌🏼), but from my understanding it is not something really clear for the next year.

Part of what sounds odd to me is that the notification icon (that would open the panel) is something that I wish to have access even when inside the Site / Posts Editor.

While I know this is not related to this topic, I can't help to express that some of the most recent features introduced to the Gutenberg project seems to mix things weirdly. For example, having the list of pages in the fancy sidebar is great for content creation flow... but isn't that somehow overlapping with the Admin Post listing? Am I confused when I say that the editor is "engulfing" the Admin, when the opposite should be the truth for a more integrated experience?

Anyways, not really a critic, more some thoughts I needed to expose.

[Sephsekla]

@mateuswetah you're entirely correct, there is often some overlap from a few different directions, and that's not always ideal. I think it's an inevitable consequence of community driven initiatives and open source development, and something we need to be mindful of.

With regards to the admin refresh, I think our UI would make sense within the updated dashboard, but we've also aimed to build it in a way that would work in the old dashboard. That being said, the most important goal of the project is the new API and persistent storage, so if our notification UI is eventually replaced then that's not a major issue.

[Sephsekla]

We now have a new design available at https://www.figma.com/file/sC0QzxbY1Azm6wtc2X6bXV/WP-Notify-design-blueprints-i6-(by-Nick-Heurter)?type=design&node-id=158%3A105&t=kODRNurZMamE3Fbz-1, which makes better use of existing components in WordPress Core and its desing system. I'd like to test out adding this to see how we can simplify things here.

I've added a ticket to track that work at #357.