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

[annezazu]

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]

Related to this, showing where fonts come from! https://github.com/WordPress/gutenberg/pull/63211 Maybe we can have a shared experience here :)

[jameskoster]

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]

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]

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]

This sounds right to me and I think will help in the future when thinking about transferring templates across themes https://github.com/WordPress/gutenberg/issues/55595. A user will definitely want to see the source then.

[jameskoster]

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

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

[annezazu]

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]

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

For a comparison here's how that would look:

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:

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

[ntsekouras]

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]

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

[ntsekouras]

@ntsekouras do you mean that the new API would make the mockup https://github.com/WordPress/gutenberg/issues/63324#issuecomment-2252345811 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.