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.

You care about WordPress and you don't have the time to contribute day to day, I'd love to hear your thoughts to get some inspiration about Phase 2 of Gutenberg, Site building, Customization… A tweet, a blog post, whatever works best for you. #gutenideashttps://t.co/Y7tod5DoB2

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.

Riffing on something @photomatt said at #SOTW#WCUS: To map out the future of themes / #Gutenberg 2.0 / #WordPress Next, maybe ship a Block Zen Garden type thing and asking designers / devs to create solutions, then work backwards to find a UI / UX to make that possible.

“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.”

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.

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….

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.