Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dataviews: Improve the 'No results' view #61442

Open
jarekmorawski opened this issue May 7, 2024 · 9 comments
Open

Dataviews: Improve the 'No results' view #61442

jarekmorawski opened this issue May 7, 2024 · 9 comments
Labels
[Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.

Comments

@jarekmorawski
Copy link

When users apply filters or search using terms that yield no results in the data views, the app currently says No results. I believe we can make it more helpful to users by tweaking the copy to focus on solutions and tailoring the message's appearance so it's easier to read and interact with.

The button in the message would be contextual, meaning that it'd change depending on the context (Add new page, Add new post, Add new pattern, etc).

List

@jarekmorawski jarekmorawski added [Type] Enhancement A suggestion for improvement. [Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond labels May 7, 2024
@jameskoster
Copy link
Contributor

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.

@jarekmorawski
Copy link
Author

jarekmorawski commented May 7, 2024

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.

Empty

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
Copy link
Contributor

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

@ntsekouras
Copy link
Contributor

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
Copy link
Contributor

keoshi commented May 30, 2024

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:
image
image

@tyxla
Copy link
Member

tyxla commented May 30, 2024

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
Copy link
Contributor

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
Copy link
Contributor

Sounds like we need some mockups then 😄

@ntsekouras ntsekouras added the Needs Design Needs design efforts. label May 30, 2024
@jameskoster
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants