Adding two new metadata entries as part of the mobile Gnav redesign

[bandana147]

Hi Team,

We are currently developing the mobile Gnav redesign and plan to introduce two new metadata entries:

1. A flag to enable or disable the new design.
2. A flag to indicate whether the page includes a local navigation (localnav), allowing us to reserve space for it and prevent layout shifts (CLS).

Localnav page will have this Dropdown like in above - "Photography" is a dropdown ^

Would love some feedback from the you.
cc: @salonijain3 @narcis-radu @overmyheadandbody @mokimo

[mokimo]

A flag to enable or disable the new design.

This sounds fine, although should it even be opt in? I feel like that might lead to inconsistencies. Or is that just to slowly roll it out across consumers and then get rid of the flag?

A flag to indicate whether the page includes a local navigation (localnav), allowing us to reserve space for it and prevent layout shifts (CLS).

Putting CLS into authoring hands is a recipe for disaster. Can you not detect wether a localnav has been authored and then reserve the space?

[mokimo]

@overmyheadandbody do you have any smart ideas for this?

[sharmrj]

Of course, you're right that if someone uses a nav without thinking about it they're liable to make this mistake, and increasing the number of magic incantations and ifs and buts is not ideal.
But your comment about inheriting a nav reminded me of the dynamic gnav which makes potentially any given page liable to get CLS (or, in rarer cases, have a big empty block at the top of the page) since the gnav from one page is carried over to the next. That would take this approach from prone to failure to virtually guaranteed to fail for anyone navigating the site from a page with a dynamic gnav enabled.

[mokimo]

If there is no good enough solution IMO it's completely fine to give this back to design and PMs considering the engineering & authoring limitations and interactions with different features and simply call out this is:
A) Not feasible
B) An amount of pages might end up with a big white block or CLS which both severly hurt the user experience or aren't otherwise brand appropriate.

In my mind, both CLS or a big white block due to personalization or dynamic navs or whatever interference there is - should be considered a "blocker" from engineering for a certain design and needs more discussion with PM/Designers or just brainstorming for alternatives

[narcis-radu]

Would it help if we restructure content to differentiate between normal navigation and localnavs? I'm thinking about this setup where all normal navs would go in gnav/random.docx, while local navigations can stay in gnav/localnav/random-2.docx. We can technically rely on this information to see if we need to reserve space (given that the information is available early). To make sure we're handling human errors, we can compare whether the nav has actually been authored as a local navigation and output the result to LANA if we find issues, something like "nav from www.adobe.com/something/localnav/random.plain.html has been defined as a localnav, but doesn't contain any section menu". When the information is logged, we can go back to authors and request them to adjust content, this can also be part of the preflight performance tab.

[bandana147]

Yes, I agree on the LANA logging solution.

For the differentiation between normal nav and local nav. We initially considered this approach but encountered two issues:

1. We won't have the early hint of the path if the gnav source is not added in the metadata since we have another way of getting the gnav (here).
2. A significant amount of existing authored local navigation would need to be moved or restructured.