Taking a step back, you notice it may be possible to instead combine much of this into a single interface, which has numerous benefits:
- Reduces the cognitive load – users only have to contemplate a single tool.
- Obfuscates template complexity – editing things like tags and categories directly becomes central to the experience, which is more intuitive than working with obscure templates like
- Features like the Blog are compartmentalised into a collection of templates. It’s easy to envisage this scaling up to a full-blown custom post type creation UI.
Here’s a video example that demonstrates the following flow:
- Adding a page (using a pattern to get started quickly)
- Moving that page into the main navigation menu
- Adding Blog section
- Viewing the blog archive (
- Viewing a single post (
- Viewing a post category (
- Adding a post category to main navigation menu
At any point it’s possible to edit the view in the frame on the right-hand side of the screen. This makes it very simple to update archives that are otherwise not surfaced in the UI.
One potential drawback to this approach is the placement of entities that are not included in the main navigation. The ‘Other pages’ section could get quite large on sites with lots of content.
Another consideration is how to handle the management of additional navigation menus. It makes sense for the main navigation to be the only one surfaced in this UI, but it should still be possible to add/edit other menus. An argument can be made that browse-ability makes it easy to locate and edit a menu directly, but menus aren’t always in use which means they still need a dedicated edit view. Alternatively, it may be time to consider making navigation menus template parts with a new semantic area. Much of the existing infrastructure exists to make this a reality, but the switch may not be trivial.