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

Navigation Screen: consolidate top bar with the one used in the FSE #31241

Closed
Tracked by #29102
javierarce opened this issue Apr 27, 2021 · 34 comments
Closed
Tracked by #29102

Navigation Screen: consolidate top bar with the one used in the FSE #31241

javierarce opened this issue Apr 27, 2021 · 34 comments
Labels
[Type] Enhancement A suggestion for improvement.

Comments

@javierarce
Copy link
Contributor

javierarce commented Apr 27, 2021

I want to propose using the same top bar as we do in the Full Site Editor. Using the same bar will help us solve some responsive issues we have and, in the long run, make the interface more predictable and easier to understand and to update.

Here's the first proposal:

1

We could have this simple toolbar that gives access to:

  • Undo/redo
  • Switching menu
  • Save
  • Settings

Users switch menus or create new ones by clicking on the name of the menu, which I think is consistent with the Template editor, but we could make the options more explicit with a slightly different version:

2

The downside of this approach is that the bar is more crowded.

Finally, here's a simple example of how this new top bar would look on the page:

Example

@jameskoster
Copy link
Contributor

I love this initiative, all unification endeavours are a win imo!

So far in the Site Editor, the popover that is exposed when you click the entity name in the top bar reveals options and actions that can be applied to that entity. Resetting a template, for example:

Screenshot 2021-04-28 at 08 56 43

It looks like this heuristic may spread to the post editor as well via #27093.

So it may be that we can migrate the navigation settings here entirely, and reduce the reliance on the Inspector. What do you think?

For switching between entities, the Site Editor uses the sidebar menu (accessed via the W button):

Screenshot 2021-04-28 at 08 58 53

Do you think this could work for the navigation screen as well?

@javierarce
Copy link
Contributor Author

Thanks for bringing this up, @jameskoster!

I thought about using the sidebar menu, but I didn't suggest it because I felt that the title popover is lighter and could work better for the general use case (which I imagine it's a user with a small number of menus).

But the sidebar has some good features (like previews for each item, search and the add button) that could definitely work here. Plus, if the title popover evolves in a new direction, I think we should consider this idea and unify the interfaces completely.

@jameskoster
Copy link
Contributor

Yeah I think that makes sense. Unify, then refine holistically! 🚀

@jasmussen
Copy link
Contributor

For what it's worth, we've had a top bar, and one of the reasons we removed it was to avoid this looking like the block editor, and to look more like other wp-admin screens.

@jameskoster
Copy link
Contributor

@jasmussen very good point. This speaks to the purpose of this screen, which still confuses me even to this day :)

If it's not something we see it as a component of block-based site editing, maybe the alignment is not worth it.

@javierarce
Copy link
Contributor Author

I still think is a good idea to move forward with this change. It's not only about consolidating the two interfaces, but the FSE top bar offers a much better design than the current solution. And it's also a more scalable and organized way to offer important features.

We could definitely find an alternative third-way, but since we already have a nice solution, I'd say let's use it :)

@javierarce
Copy link
Contributor Author

javierarce commented Apr 29, 2021

Here's a first look at how the Nav Screen would look using the sidebar. This change would require removing the current sidebar. Also, it would be nice to render previews for each menu (in the following video, I'm just using fake placeholders).

Screen.Recording.2021-04-29.at.18.10.54.mov

We could also remove one step from the menu creation flow using a popover (this is similar to the FSE sidebar)

Screenshot 2021-04-29 at 18 25 22

Here's a link to the prototype above.

@javierarce
Copy link
Contributor Author

javierarce commented Apr 30, 2021

I updated the previous prototype with a new version that doesn't close the sidebars when the user creates the menu.

Screen.Recording.2021-04-30.at.13.05.33.mov

@draganescu
Copy link
Contributor

Howdy friends, it's not clear to me if there is enough consensus here to proceed with trying out such an UI update. Does this "unification" make things better for the block based Navigation editor? Does it matter that it's a completely different experience, compared to all WP-admin and even the new block based widgets editor? Thanks 🤝

@talldan
Copy link
Contributor

talldan commented Aug 10, 2021

It'd be good to get clarification on this.

I personally very much like the idea of unifying. The navigation screen is a similar initiative to the widgets screen which uses the same general interface as the site and post editor. This would ensure the navigation screen isn't the odd one out.

@jasmussen
Copy link
Contributor

It'd be good to get clarification on this.

Happy to take a stab. Much of this is spread across tickets and chats, so I'll recall as best as I can.

These screens are primarily meant to bring the diversity of blocks (and the benefits of the navigation block) to classic and universal themes. But they are also interfaces dedicated to widget and navigation editing, which comes with its own set of limitations that aren't necessarily present in the post or site editors. In other words, while these are technically block editors, they are different.

The argument then, has been, that using the same interface isn't necessarily beneficial: assumptions about how things work from having used the block editor might simply not apply here. Perhaps most importantly: design explorations for these screens shouldn't need to be be predicated on following block editor principles that might not be relevant.

That's the back-story and context for what exists. It should only inform but not block things from moving forward, and of course if design explorations circle back and intentionally land there again, that's valid too. With the widget screen having shipped with a similar top-bar, there's plenty of reason to suggest the navigation screen could/should have a similar interface.

That said, and in my personal opinion, I'd suggest that if it were to be similar it should be more or less identical to the Widget editor, complete with not being fullscreen, and having an explicit label in the top left corner:

Screenshot 2021-08-10 at 10 54 13

@talldan
Copy link
Contributor

talldan commented Aug 10, 2021

That said, and in my personal opinion, I'd suggest that if it were to be similar it should be more or less identical to the Widget editor, complete with not being fullscreen, and having an explicit label in the top left corner.

Those things seem like a good compromise 👍

@draganescu
Copy link
Contributor

What I like of the direction in @javierarce 's designs (besides the fact they're very nice) is that we're pushing WP Admin closer to Gutenberg. "Contrary" to @jasmussen 's perspective above, I would make the widgets editor more like what's explored here and unify in this direction.

@jasmussen
Copy link
Contributor

As a counter counterpoint (😅) I would argue that the transitional nature of these screens makes it all the more important that it shares more DNA with their previous counterparts.

@javierarce
Copy link
Contributor Author

javierarce commented Sep 9, 2021

I've updated the top bar design with several new elements we've been discussing:

I also think we could remove the "Navigation" title that currently appears in the top bar because there are several other indications that inform users that they are in the navigation editor (like the left and right sidebars or the "new menu" link). If we made this change, we should probably replicate it at the Widgets navigation bar.

I've included an "options" button (the vertical ellipsis at the end of the menu) because we could use it to:

  • Show the keyboard shortcuts, a welcome guide (we'll need to design it), and a link to a help section.
  • Invoke the options menu, as we do in the Full Site Editor when the top bar is very narrow.

We don't need to implement this options button right away, and in the meantime, we can simply show the settings button.

image

Figma file

@jameskoster
Copy link
Contributor

I still have some slight reservations about re-using the title/dropdown in this context as a switcher primarily.

In the template editor this affordance reveals details about the template and offers no switching. In the site editor it also reveals details and offers a shortcut to view all templates (and switch) as a secondary function. Ideally global elements like this should exhibit consistent behaviour otherwise they can jeopardise the overall UX.

That's not to say that I don't like switching as a primary feature of this dropdown. It actually feels intuitive to me. So I guess my question is about the intent: if we adopt this approach for the navigation screen, should we do so as a test versus the implementation elsewhere? And if successful migrate it to other locations? Or are we happy to introduce the inconsistency acknowledging the fact that this screen exists somewhere in-between the wp-admin and gutenberg "layers"?

Small sidenote: assuming we run with this as designed, I don't think it's necessary to hide the "Create new menu" button in the dropdown on desktop. If we keep it visible then mobile-first folks will not have to search for that functionality when they're on desktop.

@javierarce
Copy link
Contributor Author

To me, having a way to switch navigations there feels intuitive, too (and has the side benefit of working well in narrower layouts). And even though the action in the Site Editor is secondary, it still feels consistent to me: users opening the dropdown will probably have the same intent (switching). I also think the introduction of the template mosaic view will also reinforce this behaviour.

So, to answer your questions, I'd say yes to implement this solution and see how well it works.

Small sidenote: assuming we run with this as designed, I don't think it's necessary to hide the "Create new menu" button in the dropdown on desktop. If we keep it visible then mobile-first folks will not have to search for that functionality when they're on desktop.

This sounds good to me 👌

@karmatosed
Copy link
Member

karmatosed commented Sep 10, 2021

I am just finding my feet in navigation and wanted to pop my head into this issue as it seems lively. One flow that caught my eye is potentially a little confusing, at least to me as I find my way was this:

2021-09-10 at 18 44


My biggest concern is multiple places for things and a fragmented experience for the same cognitive activity. Navigation has always ended up being more complicated than it should be.

I’d love to get my footing a little with navigation, so I really would appreciate being put on the right path as to what the current direction is, maybe a link to a prototype? I see some flat files, but things like this are always great to see the flow of.

My presumption is the latest design in PR is: #34619 but checking. It doesn't seem to have the work I linked above.

@javierarce
Copy link
Contributor Author


My biggest concern is multiple places for things and a fragmented experience for the same cognitive activity. Navigation has always ended up being more complicated than it should be.

I agree with you 100%, @karmatosed. However, that idea you mentioned was a super early exploration and wasn't really examined beyond that point.

There isn't really an official and comprehensive prototype. Still, you can find many designs and prototypes inside this Figma file. There's also a tracking issue that outlines and organizes the work towards removing the experimental flag here. And in any case, I'm happy to chat over Slack to solve any doubts.

@karmatosed
Copy link
Member

karmatosed commented Sep 10, 2021

@javierarce, thank you so much for catching me up and having patience as I tried to put the pieces together finding issues - I'll dive into that Figma. I had found that tracking issue, which is how I got here, so I agree it's a great central point. Appreciate the offer of continued discussion - it's always appreciated. I will also bring my thoughts to any issues or conversations as they come up in my exploration.

Quickly looking at the Figma, one thing that strikes me is the complexity of the amount for screens like this:

2021-09-10 at 19 26

If you consider what the eye would be doing and where the focus (things demanding attention) would be for the person experiencing it, you get a map like this:

2021-09-10 at 19 26

Similarly:

2021-09-10 at 19 28

The 'save' is disconnected, and so is the 'create new menu'. The '+' is also going to be very far away. A lot is also the same level of attention-demanding.

Am I missing some context or explorations of this being closer to the expected interface where someone is interacting with the menu? I don't want to presume things or comment without knowing the context fully and can't see it in this issue thread.

@getdave
Copy link
Contributor

getdave commented Sep 13, 2021

My presumption is the latest design in PR is: #34619 but checking. It doesn't seem to have the work I linked above.

That PR is literally just adding the global inserter. Refactoring the entire top bar is out of scope there but happy to look at that next 😄

@jameskoster
Copy link
Contributor

It seems to me that there is more value in positioning the [+] and 'Save' button in a manner that is consistent with other editor views. We don't want to keep 'moving the cheese' 😅

Would it also be fair to say that if you have actively opened the dropdown, then it's likely your focus will inherently be there rather than on other parts of the screen? 🤔

Am I missing some context or explorations of this being closer to the expected interface where someone is interacting with the menu?

I think the purpose of this issue is to simply align the top bar implementation with other editor views. Just as other landmark features (e.g. Inspector) are aligned.

@getdave
Copy link
Contributor

getdave commented Sep 13, 2021

+1 to aligning with other editors.

@karmatosed
Copy link
Member

That PR is literally just adding the global inserter. Refactoring the entire top bar is out of scope there but happy to look at that next

Oh, that's super helpful to know what to expect in what PR, thanks @getdave.

I think the purpose of this issue is to simply align the top bar implementation with other editor views. Just as other landmark features (e.g. Inspector) are aligned.

That makes sense in principle. The issue is that whilst you can say if you open the dropdown, your attention is there, with the way the interface is created - that's not the case. There's an overall problem with the current flow. Now, this might be aside from this issue, but it certainly is being made obvious by it, so worth exploring. Navigation has this habit of exposing any hitches.

@Mamaduka
Copy link
Member

The menu name/switcher consolidation PR is almost ready for review.

@javierarce, based on this discussion #31241 (comment), I removed the "Create new menu" item from the menu switcher dropdown.

Should we replace it with the "Delete menu" button? This is how "Template Mode" displays the delete action.

CleanShot 2021-09-13 at 17 08 13

@javierarce
Copy link
Contributor Author

javierarce commented Sep 13, 2021

@javierarce, based on this discussion #31241 (comment), I removed the "Create new menu" item from the menu switcher dropdown.

Oh, but we agreed to keep it visible at all times. I think adding a delete button that only appears when in Desktop mode could be confusing.

@Mamaduka
Copy link
Member

I thought it was agreed to keep direct action "New menu" visible at all times. Do we need to "Create menu" action buttons?

It's a small change so no problem to bring the Dropdown button back to the screen.

CleanShot 2021-09-13 at 17 23 57

@javierarce
Copy link
Contributor Author

javierarce commented Sep 13, 2021

Let me try to explain the whole thing 😅

My initial idea was to have "New menu" visible in the top bar and hide it if the viewport is very narrow. In that case, we would also show a "Create new menu" button in the dropdown… but James pointed out that we could instead show "Create new menu" at all times in the dropdown, which makes sense to me (and I think it will also make the implementation easier).

This Figma frame contains the updated version of the design.

@Mamaduka
Copy link
Member

It makes sense, and thanks for the explanation. I'm going to add "Create new menu" button back 😄

@talldan
Copy link
Contributor

talldan commented Sep 17, 2021

What's left to do on this one?

From what I can see there's no editor 'more' menu, but I think that can come a bit later.

@Mamaduka
Copy link
Member

I think that will be part of the #34859.

@talldan
Copy link
Contributor

talldan commented Sep 20, 2021

Could be good to close this if the only task left is now tracked by another issue.

I think #34859 needs prioritisation on the tracking issue and some design feedback. IMO, it's probably not a blocker for removing the experimental flag (the widget editors also had no settings while live in the Gutenberg plugin).

@Mamaduka
Copy link
Member

I agree with @talldan that we can close this one. The "Preference" panel issue doesn't need to have high priority.

@getdave
Copy link
Contributor

getdave commented Sep 20, 2021

Ok I"m going to close this one out. @javierarce let us know of any follow ups that you'd class as High.

@getdave getdave closed this as completed Sep 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

8 participants