Having spent some time with Navigation Areas there is a concern that the concepts and UX we have introduced are going to be too complex.

In an informal discussion @mtias shared his concerns which I've attempted to summarise below along with a potential solution that he proposed.

Summary

The main problems are:

• Navigation Areas are mirroring a concept ("Menu Locations") that exists for classic Themes but which has less value in a world of block themes and global styles.
• The UX around Navigation Areas + Nav blocks + Nav CPTs is very confusing.

In the world of classic Themes, users switch themes in order to get new styles and visual appearance. In this world we have Menu Locations to try and allow us to map Menus from Theme to Theme. However, in practice this rarely works and the whole concept of Menu Locations has always been challenging for users to grasp.

In the world of block Themes, global styles will make it less likely users will need to switch Themes. After all colors, typography and more can be modified within any block Theme. Moreover you have near limitless layout flexible afforded via the block library in the Editor.

Whilst it is desirable to preserve menus when switching Themes, trying to use Navigation Areas to map the concept of "locations" into the block based world of the editor is not producing a great result. Indeed, it is bringing over concepts from the classic world that may no longer need to existexist. It is also producing a sub-optimal UX which requires the users to understand a number of complex concepts.

What is your the proposed solution?

Matias is proposing we retain the existing system of saving Navigation to a Custom Post Type. Decoupling presentation from data is a good idea. But...

Instead of burdening users with the concept of areas and locations, we should remove Navigation Areas and instead attempt to use a heuristic to automatically pick the correct Navigation CPT for a given Navigation block based on it's location within a template.

For example, imagine you insert a Navigation block into your Header Template Part on the Index template. That Navigation block should be automatically named as header-index-navigation. You then create some Nav items. This should create a Navigation CPT which a matching slug of header-index-navigation. This creates an implicit relationship between the block and its data via the slug.

Now in another Theme (let's called it B), the theme author has undertaken a similar exercise and therefore their header.html template part contains a Navigation block which has a slug reference of header-index-navigation (again this is based on it's template + template part location).

If I switch to Theme B then the Navigation block will attempt to look up Navigation CPTs with a slug matching header-index-navigation. As I created such a CPT in Theme A, the Nav block from Theme B will be able to pull through the correct navigation items by matching against the slug.

If there is no match then the Nav Block should fall back to a default output on the front end (Page List?), whilst within the editor a notice should be displayed prompting the user to resolve the Navigation block to select which menu they wish to display. It is key that the block should always output something sensible on the front end, but within the editor it is ok to prompt the user to take action.

This isn't a fully automated solution but it covers the 80% use case whilst also greatly simplifying the UX experience for users and authors within the Editor.

What do we think about this approach?