Repository navigation
Site Editor: Utilise tabs for submenus on DataViews 'pages' rather than drilldown #73251
Description
Extracted from #72135.
- Removes drilldown navigation to reduce click fatigue and disorientation when moving between areas.
- Moves sub-navigation to tabs
- Improves mobile accessibility as tabs remain reachable without having to open the main navigation drawer.
- Important note: These are not a literal tabs pattern, they would be navigational and require a small new set of components (cc @aduth @mirka).
A little design work will be required to figure out which tabs make the most sense for the Patterns section which currently has many different pre-configured filters.
Activity
youknowriad commentedon Nov 13, 2025
Note that the experimental "posts" page is already using a similar pattern. It's missing the right component (using Tabs temporarily) and it doesn't have counts, I'm a bit concerned about the REST API calls needed to compute the counts though and its impact on performance.
jameskoster commentedon Nov 14, 2025
I don't think the counts are essential.
jameskoster commentedon Nov 14, 2025
For this part, I wonder if it would make sense to split Patterns and Template parts again. I still think a template part should just be a synced pattern in a certain category (header / footer) to simplify the concepts, but until there's full technical consolidation splitting them seems reasonable. Then we might configure like this:
Category would be a locked primary filter on the All patterns page to retain some of the existing discoverability.
oandregal commentedon Nov 17, 2025
@jameskoster how should the search and filter buttons be positioned if there are no tabs? Do we still want it to the left?
The design suggests that tabs are part of the DataViews component. For implementation, I wonder this could be absorbed as a new prop in the DataViews component. Something along the lines of
defaultViewsand just pass what the existing config. Since the introduction of "locked filters" that's all they are.youknowriad commentedon Nov 17, 2025
I'm thinking that this should be a "compose your dataviews UI" thing instead of multiple UI props.
jameskoster commentedon Nov 18, 2025
It would be nice to implement in a way that can be reused and maintained easily. Maybe there should be a component in the
admin-uipackage that handles 'DataViews admin pages'? Basically a wrapper that composes / configures the different pieces.oandregal commentedon Nov 18, 2025
👍 to having a new wrapper component that essentially exposes a defaultViews and composes DataViews sub-components, and it's used for all pages.
Though, I wonder: is this the way we expect "custom views" to be exposed? I suppose this could grow by adding a "+" icon for the user to save their own. If so, why compose and not offer the API? If we're unsure about the path forward, and we want to explore without committing or disrupting consumers, that sounds sensible. But if it's just the way we'd suggest this to work, it doesn't feel great: every consumer will have to do the same, which opens the door for inconsistencies, maintenance burden, more complex solution out-of-the-box, etc.
youknowriad commentedon Nov 18, 2025
I think a single wrapper is indeed needed but for me this is out of scope of the dataviews package. It's an implementation component that need to live either in admin-ui or in the views package.
And yeah! I see it as something that evolves to absorb creating of custom views as well.