In navigation, add switch to turn off popular article links

[kavanagh]

For pages that are static HTML or have long cache set up, the navigation can take a long time to be updated. This is probably tolerable for most primary and secondary level navigation links, but for "popular articles" this can make the navigation seem confusing and out of date.

Adding an optional switch to turn these links off might be a good enough solution.

Perhaps another solution might be some way of broadcasting a navigation change event that lets apps update their navigation. This event could be used to rebuild pages or purge a Fastly cache.

[magsallen]

Hi @kavanagh could you add an example of a popular articles link? I'm not sure where this lives in our navigation

[kavanagh]

Yep, sorry. These things...

[magsallen]

What do we mean by 'switch off' the links?

We could add some logic to not render this section when building a static page, but that would leave the section empty, which is worse than stale imo. Or we could serve alternative content for these pages but I can't think right now what that would be.

Would shortening the cache length we set for static html pages be an acceptable solution? It's the least technical one I can think of. We'd bust the cache more often but it would limit how stale these links could get.

[kavanagh]

Switching off the meganav, as you’ve raised in #647, might be be a good solution also.

Although, it might be a bit unexpected to users familiar with the hover behaviour. It might seem broken.

Fetching these links could be done client side. You could get the most read links the first time you interact with the menu.

Another approach that’s a more significant piece of work is do away with the ‘most read’ links altogether. A couple of years ago Moshe, Arjun and I looked into this and it wasn’t a feature thats used much. We didn’t retire it because getting buy in to get rid of it was a faff and there were other higher priority things. Not having it would allow us to have a simpler architecture for navigation data.

[i-like-robots]

Not having it would allow us to have a simpler architecture for navigation data.

Yes! Adding types to it was a huge effort because the format was so haphazard. If we removed this we would be able to remove the whole navigation API service and use the Origami one directly IIRC.