-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[ Block Navigator ] Discussion: bring the entire navigator into the editor #22706
Comments
I definitely think the block navigator should stop being merely a navigator (and also stop being called one) and continue to become more of an alternative editing interface, much like the Layers View in Divi. I think this kind of UI is the best way to handle adding/removing/moving blocks in complicated situations full of nested layers and blocks that may take up little (or even no) space on the screen by default. |
Cross-linking my related comment from another issue: #22705 (comment):
|
I commented in the other issue, but I think we should maybe focus on one as I don't want to get the conversation diverged. For now, I think we should pause and not get caught on the loop we are of constantly re-designing this experience, let's settle in and see what we have. I know that sounds quite a decision, but there are so many moving pieces I am incredibly reluctant to dive into yet another revision until we have all our pieces lined up. Now, that doesn't mean the door on exploring is closed, it does mean we need to get the experience complete before judging. I would suggest as far as navigation in wp-admin goes we should do that and then review. As I noted in the previous issue #22705, along the way we've created quite a few versions of this screen and one was actually the entire editor being there with one column. Perhaps, on experiencing this that might feel better to go back to, I think we need to judge it with fewer hitches though first. To be clear, if we do find we are reinventing the editor (which I don't think we are yet), then we should consider why and it's either a case that upstream changes need to happen or a re-think. I think I would gently nudge us to things we can do to get to a deciding point there. |
Until we figure our new features that require shifting the way this is implemented it is save to close this and, if the case is, reference it later. |
It seems like the navigator on the experimental screen is becoming more and more like the actual editor: it has movers, BlockSettings menu, edit mode, it will have all the same buttons as the BlockToolbar, drag and drop support is in progress. What is the endgame here? 1:1 feature parity with the BlockEditor? In other words - are we reinventing the BlockEditor here? If so, the navigator would always stay behind on the latest editor features such as the accessible drag and drop from #22453. Would it make sense to just make the that tree widget a part of the BlockEditor - perhaps as a new block or a different editor mode?
Case in point: #22705 issue explores how selection, focus, an edit mode could work in the navigator. How would an edit mode look like for the search block added in #22656? What about other blocks that may be supported in the future?
The text was updated successfully, but these errors were encountered: