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

Introduce "Browser" and surface main navigation UI #36667

Closed
10 of 12 tasks
Tracked by #41241 ...
mtias opened this issue Nov 19, 2021 · 50 comments
Closed
10 of 12 tasks
Tracked by #41241 ...

Introduce "Browser" and surface main navigation UI #36667

mtias opened this issue Nov 19, 2021 · 50 comments
Labels
[Block] Navigation Affects the Navigation Block [Feature] Navigation Component A navigational waterfall component for hierarchy of items.

Comments

@mtias
Copy link
Member

mtias commented Nov 19, 2021

The latest work on the navigation block infrastructure has allowed us to isolate the inner link items of the navigation block into its own post type. This now allows us to have a focused interface for managing the site structure in addition to the presence of the navigation block on the canvas. This can take different views with the focused template part mode and the list view affordances native to the block editor.

We also have all the relevant tools implemented for the tree-view of links to be a viable management interface for pages and link items. It supports reordering, drag and drop, nesting, etc.

At the same time, the W menu has been one of the proposed destinations for managing templates. This issue proposes the combination of these features and an alternate exploration where they become top level items. The aim of this work is to allow prominent access to navigation structure regardless of the state of the site editor. (For example, if navigation is collapsed on an overlay menu, the page is scrolled beyond visibility, etc.)

image

Sorting flow in W menu


The list view trigger from the navigation menu (which formerly opened a modal) would open this panel instead, connecting the flows:

Open navigation from navigator


Finally, another option that avoids the confusion of the W menu behaving erratically between editors would be to expose this access as top level tools:

image

This might be a more palatable interim solution while the whole experience of the W menu is iterated upon and established across editors. The following video describes how it might work.

nav+templates.mp4

There's a few unattended details, like having a dropdown to select among different navigations used (in case a footer has a different one, etc), but it paints an idea of how it could work.

Thanks to @jameskoster and @jasmussen for exploring this idea with me.

Todo List:

@mtias mtias added [Block] Navigation Affects the Navigation Block [Feature] Navigation Component A navigational waterfall component for hierarchy of items. labels Nov 19, 2021
@pablohoneyhoney
Copy link

There’s also an opportunity to organize those taxonomies (Templates, Navigation, Styles) elevated to the persistent level of the W. Here are some explorations of what that could look and behave.

In one exploration (likely my preference) we can accommodate those architectural instances in a more visible UI that can be toggled and related more clearly. Here are some variants with slight permutations on how colors and positions can help link the W and the immediate navigational items.

Nav2

In another path, those higher level instances can be presented in a flyout when interacting (hover and click) with the W. This permits to keep the current simplicity of the top bar to arguably focus on the content controls. And it also surfaces more evidently the return to wp-admin. Various indicators can hint the presence of the flyout.

Nav

Templates and Navigation can trigger the correspondent left panel, while Styles can (for now) still open the right-side panel.

Nav3

Nav4

@jameskoster
Copy link
Contributor

I like the idea of dark areas of UI equalling global elements very much, it creates an environment for site settings to live as well. Exposing the site structure / navigation is particularly exciting because it means we can offer an intuitive way to navigate and edit different pages in the site editor.

The flyout approach solves potential scalability issues that may occur with the W button expanding horizontally. I explored a vertical approach as well, which adds another layer of abstraction and solves the scalability issues at the expense of 60px horizontal real estate.

vertical.mp4

@jameskoster
Copy link
Contributor

It occurred to me that Reusable Block management could live in this global UI region too :)

Screenshot 2021-11-25 at 16 03 36

@SaxonF
Copy link
Contributor

SaxonF commented Nov 26, 2021

Some overlap with the thinking here #32682

@SaxonF
Copy link
Contributor

SaxonF commented Dec 16, 2021

Thinking about this some more, navigation structure within the left sidebar does feel a little strange to me personally because it is so detached from the navigation itself. I would expect it to be part of the block settings on the right, consistent with other blocks. Technically navigation structures might be global, but I'm assuming you would rarely have one set used in multiple places on your site.

@jasmussen
Copy link
Contributor

One aspect I like about surfacing a dedicated navigation is that it provides an obvious default for the (presumably majority) of sites that have only a single navigation menu. Such a default can be loaded by default as well, for example in the navigation block.

@jameskoster
Copy link
Contributor

Centralised menu management is also useful when

  1. There are many menus – the one you want to edit next may not necessarily be on the current canvas.
  2. You want to work on a menu but not attach it to a template yet. Like a draft.

It does pose an interesting question though. If we say that the contents of global elements like menus are managed in a distinct interface separate from the canvas, do Reusable Blocks and Template Parts get a similar treatment?

@jasmussen
Copy link
Contributor

If we say that the contents of global elements like menus are managed in a distinct interface separate from the canvas, do Reusable Blocks and Template Parts get a similar treatment?

I imagine what we currently do for isolated template part editing being a pattern to be leveraged for a majority of UIs like these, reusable blocks, perhaps even for editing the contents of the navigation modal.

@SaxonF
Copy link
Contributor

SaxonF commented Jan 24, 2022

There are many menus – the one you want to edit next may not necessarily be on the current canvas.
You want to work on a menu but not attach it to a template yet. Like a draft.

@jasmussen @jameskoster Could I accomplish the above using re-usable blocks (containing nav block) edited/created in isolation? There are already so many concepts to grasp when it comes to global elements (template parts, templates, re-usable blocks) that I fear introducing yet another will be overwhelming.

This opinion could just be because I'm used to working in design tools like Figma (with components) but Webflow takes a similar approach with their symbols and it just feels simpler.

@jameskoster
Copy link
Contributor

Funnily enough Joen and I were chatting about this last week and yes – you could accomplish this with reusable blocks, or template parts for that matter 😅

I have begun wondering whether "reusability" could be a more abstract concept. So rather than providing multiple elements that all essentially do the same thing, perhaps all blocks have a toggle to make them reusable or "synced". I'm sure there are many trade-offs to this, but on the whole I agree – adding more reusable elements only makes things more complicated for the end user.

@SaxonF
Copy link
Contributor

SaxonF commented Jan 24, 2022

I really love the thinking behind @luisherranz suggestion in the synced block thread you referenced and believe the same simplification/unification principle could apply here.

Taking the idea to the extreme you could even argue that a navigation block isn't even needed. Just create a pattern containing a row with a logo and some links. If you need a submenu, add a generic dropdown block to your row.

@jameskoster
Copy link
Contributor

Yes, if there was an option to mark patterns with semantic meaning (header, footer, navigation) then we could remove both the Navigation and Tempalte Part blocks.

@getdave
Copy link
Contributor

getdave commented Jan 26, 2022

You want to work on a menu but not attach it to a template yet. Like a draft.

This touches on the concept of "safe exploration" which I feel is a key use case driving the argument for some kind of standalone means to edit the "items" of a Navigation Menu (i.e. wp_navigation) in isolation from the Navigation block.

For example, I might have a variation of my primary navigation which I only wish to expose at a certain point in the future. With the current Navigation block that's going to be very hard to achieve.

If we afford a place where menu data can be safely created and manipulated in isolation from the site canvas, then that's going to make it much easier for users to create and manage menus.

Note: this isn't straying far from the direct manipulation paradigm - the primary means for creating menus can still be via the block - but it's important that we recognise the alternative workflows that we need to cater for.

@SaxonF
Copy link
Contributor

SaxonF commented Jan 27, 2022

@getdave the idea @jameskoster and I are discussing definitely goes beyond the scope of this particular issue but its worth mentioning because it would solve the same "safe exploration" problem, but for all blocks, not just navigation/menu.

In Figma you can create a library that is detached from your main design. You're free to add components (e.g. nav menu) and styles to that library without them actually being put to use. When you're ready, you can add these components from your library to your design, or replace existing components. The same mental model applies to Storybook (building components in isolation) and could apply here. We already take a similar sort of approach with templates.

Much like the mindset @luisherranz has, I do think there is an opportunity here to design a single solution that solves for multiple problems, not just for navigation. I realise there are complexities around backwards compatibility that need to be considered.

Might be worth a separate thread.

@gwwar
Copy link
Contributor

gwwar commented Feb 2, 2022

I'm going to try a small spike to see what issues I run into, let me know if folks have already started on this one.

@youknowriad
Copy link
Contributor

Some updates here:

  • we can now move the separator between the sidebar and the frame (we can resize the frame)
  • The "edit" mode is persisted in the URL, so you can refresh the page and keep the state.

@getdave
Copy link
Contributor

getdave commented Jan 10, 2023

Please note that Nav Offcanvas is looking to come out of experimental which may affect this effort.

@annezazu
Copy link
Contributor

annezazu commented Jan 23, 2023

Wanted to note feedback here that a few folks, including in the latest call for testing, have asked about having the three dot menu icon next to the templates and template parts while in browse mode. I both see designs that include that as an option and designs that don't along with this note "Move template search, save indicator to the sidebar (potentially clear customization)".

Here I expect to see 3 dots as can be seen in the Manage all templates screen. Perhaps these lists should be similar to the List View with the 3 dots and drag and drop.

@youknowriad can you clarify if this is being currently explored or whether it makes sense to open an issue for now otherwise in case it continues to come up? To be clear, talking about this:

Screen Shot 2023-01-22 at 11 36 05 PM

@youknowriad
Copy link
Contributor

@annezazu There's a todo item on the issue about this but so far management tasks like this has been considered to be "advanced tasks" that you can see in the "manage templates" page instead of the sidebar where it's mostly about navigation. I think at the moment, there are still uncertainties around this and I'm basically waiting for more clarity from designers.

@getdave
Copy link
Contributor

getdave commented Mar 17, 2023

@youknowriad Would you now consider this complete?

@mtias
Copy link
Member Author

mtias commented Mar 17, 2023

No, I think we need to still work on the nav structure setup which hit a lot of hiccups when integrating.

@getdave
Copy link
Contributor

getdave commented Mar 17, 2023

Ok thanks for clarifying. So this is only complete once the Navigation aspect of Browse mode has fully landed and is stable in the Plugin.

@annezazu
Copy link
Contributor

In trying to do a phase 2 update, it seems the remaining item to complete (Navigation aspect of browse mode) now has its own dedicated issue: #50396. In light of that and with no remaining work to be done here, can we close this out and defer to the dedicated issue?

@scruffian
Copy link
Contributor

I agree with @annezazu that this can be closed.

@pbearne
Copy link
Contributor

pbearne commented Mar 12, 2024

Can we add this ticket as feature request https://core.trac.wordpress.org/ticket/19867

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Feature] Navigation Component A navigational waterfall component for hierarchy of items.
Projects
Status: Done
Archived in project
Development

No branches or pull requests