Dataviews: Improve the 'No results' view about gutenberg

[jarekmorawski]

The empty state is a slightly different use case (it appears without additional user input, like filtering), but I agree it'd use a similar treatment. Here's an attempt. The word pattern appears twice because it's good for the button to have a descriptive label.

It'd be nice to make the empty state extensible so third-party plugins could add extra elements, like buttons and buttons, without writing custom code.

[jameskoster]

In cases where no records exist, "No results found" reads a little strange, as does the accompanying text. In that scenario the messaging could be more focussed around adding the first $post_type.

[jameskoster]

I wonder if it would make sense to implement this as a dedicated component, cc @WordPress/gutenberg-components.

[ntsekouras]

I wonder if it would make sense to implement this as a dedicated component

I think if we did that, it would make sense to be in dataviews package and just be a think wrapper with some base styles (border maybe, etc..). We have to think about what consumer would want there and if lots of flexibility is needed, they should be allowed to pass a component of their own.

[keoshi]

I agree that we could build a unified design pattern, even if it's being shared between two different components:

• Empty state, for no existing content yet.
• No results found, for search/filtering.

Explored both of these in the context of A4A and have a few suggestions:

• In the case of the empty state:
  • Add a primary CTA so that it demands action.
  • Disable search/filtering and view options since none can be applied.
• In the case of the no results state:
  • Potentially add a “Reset X” as the default action.
  • Disable view options since none can be applied.
• Common:
  • Adding to option to include an illustration or an icon to the top.

Screenshots:

[tyxla]

I wonder if it would make sense to implement this as a dedicated component, cc @WordPress/gutenberg-components.

Sounds like a very niche use case that I wouldn't recommend a generic component for. I don't see a good need for it because there's little to no interaction going on inside it. Also, there's a high chance that adding structure and providing a certain API won't cover certain use cases, making the component either useless or too limiting.

[jameskoster]

I think if we did that, it would make sense to be in dataviews package and just be a think wrapper with some base styles

Sounds good to me. The motivation is to be consistent in terms of design across data views, but still offer some flexibility. Features would likely include:

• Slot for a graphic / icon (optional)
• Heading
• Description
• Single primary action (optional)
• Secondary actions (optional)

[ntsekouras]

Sounds like we need some mockups then 😄

[jameskoster]

Yup we should make a detailed spec, the concepts shared already by Jarek and Filipe seem like good starting points.