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

Data Views: better distinguish templates provided by theme, plugin, or user rather than grouping all under “author” #63324

Open
annezazu opened this issue Jul 9, 2024 · 11 comments
Labels
[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond Needs Design Feedback Needs general design feedback.

Comments

@annezazu
Copy link
Contributor

annezazu commented Jul 9, 2024

Right now, when managing templates, templates, plugins, or users are all listed as "authors" of templates. Rather than grouping them all is "authors", let's consider clarifying when something is theme, plugin, or user created. It's a bit confusing to call the author a theme name. Perhaps when it's a user, we say "author" but when it's a plugin or theme we say "source". cc @jameskoster for your thoughts!

@annezazu annezazu added Needs Design Feedback Needs general design feedback. [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Jul 9, 2024
@annezazu
Copy link
Contributor Author

annezazu commented Jul 9, 2024

Related to this, showing where fonts come from! #63211 Maybe we can have a shared experience here :)

@jameskoster
Copy link
Contributor

Agree "Author" isn't a great label in this context. "Created by" might be a better?

I'd be interested to hear more about the user story here, is there a specific flow where this is confusing (e.g. 'I want to see all user-generated templates'), or is it just a general observation?

Somewhat related, I wonder if bundled themes should communicate more clearly when they've been customised.

cc @mcsf as I recall you exploring a 'Source' filter in the past.

@annezazu
Copy link
Contributor Author

Some of it comes down to the term "author" being a role one can have within WordPress and how it's a bit confusing to see a theme presented as a user in many ways. There should be a way to distinguish between user created vs theme provided so folks know what might come with the theme vs what they themselves might have created. This gets more complex when you think about keeping templates from a first theme while using a second theme.

@jameskoster
Copy link
Contributor

jameskoster commented Jul 18, 2024

There should be a way to distinguish between user created vs theme provided so folks know what might come with the theme vs what they themselves might have created.

This is already possible though? User-created templates show the user name and circular avatar. Theme / Plugin created templates show an icon. Or do you mean it should be possible to filter to show only user-created templates?

The author field could be renamed to 'Source' and expanded like so:

  • Source
    • Plugin
      • Any
      • WooCommerce
      • Yoast
    • Theme
      • Any
      • Twenty Twenty-Four
      • Twenty Twenty-Three
    • User-created
      • Any
      • Admin
      • Another user

In the table, the Source column would contain values like Plugin: WooCommerce, Username, Theme: Twenty Twenty-Four. And the filter UI would allow you to filter to show templates supplied by plugins, themes, or users. Or templates supplied by specific plugins, themes, or users.


Another way to do it would be separate fields:

  • Author
  • Theme
  • Plugin

Each column should show the associated source. IE a theme supplied by TT4 would show Twenty Twenty-Four in the Theme column, and in the Author and Plugin columns.

A benefit to this approach is that you can easily show theme and plugin generated templates by adding filters for the Theme and Plugin fields.


This is a surprisingly tricky detail to get right. I'd love more thoughts and feedback.

@annezazu
Copy link
Contributor Author

This sounds right to me and I think will help in the future when thinking about transferring templates across themes #55595. A user will definitely want to see the source then.

@jameskoster
Copy link
Contributor

@annezazu just to clarify, you're referring to the separate fields approach, correct?

This would result in different columns for "Theme", "Plugin", and "Author" and enable users to quickly view all templates created by a specific theme, plugin, or author via bundled views:

fields

We could use the blue dot to indicate when theme or plugin templates have been customised.

@annezazu
Copy link
Contributor Author

I am torn about this now. It's a lot of fields in the interface to sort through. I lean towards the first approach with a source that shows plugin/theme/user but curious what others think.

@jameskoster
Copy link
Contributor

Yup, like I said it's a tricky one!

For a comparison here's how that would look:

source

I should point out that this is essentially what we have now, albeit with a different column header.

The main point of difference would be the field structure. Instead of it being flat, it would be layered:

  • Source
    • Plugin
      • Any
      • WooCommerce
      • Yoast
    • Theme
      • Any
      • Twenty Twenty-Four
      • Twenty Twenty-Three
    • User-created
      • Any
      • Admin
      • Another user

This would enable the creation of the views in the sidebar, and users would be able to manually filter like so:

Screenshot 2024-07-26 at 10 27 52

At this point we should probably seek technical feedback on the feasibility of this approach. cc @youknowriad @ntsekouras @oandregal.

@ntsekouras
Copy link
Contributor

Probably the new template registration API could help with that.. --cc @Aljullu

As Jay mentions the field and label of author should change to source though, not to create confusion.

@jameskoster
Copy link
Contributor

@ntsekouras do you mean that the new API would make the mockup above possible to implement?

@ntsekouras
Copy link
Contributor

ntsekouras commented Aug 22, 2024

@ntsekouras do you mean that the new API would make the mockup #63324 (comment) possible to implement?

Part of it (sidebar) possibly yes with the new API, if we replace author field with source.

My main concern would be the filtering UI(and therefore fields API) though. It would need some code exploration to see any challenges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

No branches or pull requests

3 participants