WordPress Designers Explore Ideas for Moving Navigation to a Block Interface

Creating a block for navigation menus is one of the nine projects Matt Mullenweg identified for 2019 that will make a big impact for WordPress users. It’s also one of the most challenging from a UI perspective. At WordCamp US’ contributor day, the design team explored ideas for what a navigation block might look like in the new editor.

The team’s designs for a navigation block are still in the rough sketches stage, but it’s interesting to see different approaches as the project develops.

“If the Nav block could live in a container block (columns perhaps), then the settings for it could be tweaked in the sidebar,” XWP designer Joshua Wold said. “A further problem comes up when you try to figure out how much of the design of the nav should be controlled by the theme vs the Gutenberg editor.”

This is an important question  that will need to be answered in the near future – not only for navigation but also more broadly for the future of the role of themes in WordPress. We will be exploring this in more depth in future posts.

Designer Mel Choyce and Riad Benguella (one of the leads for Gutenberg phase 2), are currently soliciting ideas from the wider WordPress community about how the project should tackle the upcoming customization focus.

One of the chief complaints about the first phase of the Gutenberg project was the lack of public discussion about the goals and the process of creating the editor. The Gutenberg team’s willingness to collate ideas across multiple mediums demonstrates a strong effort to seek out more diverse perspectives for phase 2. Ideas have already started rolling in.

“Rather than starting with the back-end UI, we can start with the front-end result and build a UI to make the building of that front-end possible without messing up the accessibility and resilience of the root HTML document,” Morten Rand-Hendricksen said. “At the root of this would be CSS Grid as the main layout module to allow drag-and-drop style block layouts without making changes to the HTML source order.”

Many of the ideas that are coming in so far relate more broadly to site customization. These include questions about what role the Customizer will play and requests for features like creating custom widths on the fly and the ability to drag content across columns. If you have ideas about how navigation can be implemented in a block, take some time before the end of the year and drop your comments on the make/design post or write your own post and leave a link for others to share feedback.


14 responses to “WordPress Designers Explore Ideas for Moving Navigation to a Block Interface”

  1. All this block stuff is one big scam for full employment of wordpress employees and volunteers. A nightmare for wordpress developer clients. Not one but two languages the hackers can use to hack a wordpress site.

    • Yes it’s possible that one of the side-effects of Gutenberg etc could be to improve the business-footing of those offering development services. Efforts, eg, to regrade the learning-curve at Drupal have remained unimpressive, in part because the challenges keep developers busy.

      I would not say that that makes it a scam, though. Themes are such a field, too (long-time, in WP). But in all these cases and a rich ecosystem of (modern) homologies, all the Docs you could ask for are honestly provided. If you like sweat-etquity, you’re free – and encouraged! – to buckle up a tool-belt and go to it. No, nothing necessarily hinky about this dynamic (which in fact has been prevalent back into the computing Stone Age), and no whiff of nefariousness here, that I’m noticing.

      But what I do suspect is, it’s partly motivated by an approaching monopoly situation. As WordPress becomes even more successful, it will verge into “prohibitive dominance”. The cure for excessive success, is Competition (even if you have to prop ’em up).

      To the extent that a towering IT actor needs to ‘make room’ for & support other actors who provide … “See; we do too have competitors”.

      Since the Block system is accorded dummy-ware status by development-insiders (at best self-interest, and more accurately, a frank fallacy) … and dummy-CMS projects already use it to ease the curve for their target-audience (this & other signs telling us for some while now that WP is no longer the easy-option that gained it fame) … Blocks at WP should have the myriad of not-officially-dead Blog & CMS projects licking their chops.

      Blocks are inherently semantic & parsing-friendly. This means that translation, porting and migration all become clearer & smoother. I predict a surge across the field of (barely) surviving major-CMS projects, and the dozens nay hundreds of tiny projects spanning great variation (which suffers under the Drupal/WordPress ‘hegemony’).

      And I daresay, having watched him since the days when Drupal and phpNuke and the rest of the Boys laughed in his face and brayed like jackasses at WordPress … that Matt Mullenweg is the kind of person you want leading this process, and that he has steadily learned & can handle the load.

  2. One of the biggest challenges is deciding if the nav is controlled by theme or editor? Really, that’s the challenge?

    A theme based nav comes with constructions, a WP/block controller nav allows for customization. Seems pretty obvious what the answer is.

    But if you ask me the bigger issue is widgets. They are garbage. The entire customization interface is garbage. Ide like to tweak my footer more than the nav right now. Ide like to add two widget colums next to each other above the footer. The widget interface SUCKS

    There are way more other limitations that need addressed rather than the nav….

  3. Wait…it’s in sketch form only now?

    I thought this whole time the grand plan was at least started before, well, acting on it. That’s a little scary.

    That’s like, “Welcome to phase 1, where we’re all kind of just dealing with how we laid out the rooms of the house. Tomorrow, phase 2. Anyone got any idea for what a roof could look like?”

    Also, let’s not and say we did as far as CSS grid support: https://caniuse.com/#feat=css-grid

  4. Holy mother of GOD, how do I get back my 4.9.9 EDITOR!!!!
    I have no idea where even the SAVE button is! This is beyond terrible….the owner is going to kill me for installing 5.0.2!

    Please someone tell me I can put a setting in to return to the old editor interface!!!

  5. I installed the WP Downgrade plugin to take one of my sites back to 4.9.9 (I never upgraded the others). I will continue using this version on all my sites until the forked WordPress (known as ClassicPress) releases their first fully stable and working version.

    I really believe moving Gutenberg to core at this point was a huge mistake. Folks over at WP don’t appear to understand that or are in denial. Gutenberg should have remained a plugin. I don’t understand the rush to get it into core.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: