rework sitewide menu navigation functionality

[ghwood]

Currently, site-wide navigation via top-of-page menus is implemented in a way that automatically builds drop-down menus using site page hierarchy.

This should be replaced with a megamenu approach, where menu elements are specified separate from site page hierarchy.

The megamenu structure should also allow for text and image content to be displayed in the megamenu element itself. Examples of the desired function include the NANOG, RIPE, and ARIN websites. (Images attached).

[cdanfon]

Hey @ghwood could you share specification requirements and a prototype that @mgax can work from? Thanks!

[rjsparks]

@cdanfon - I think Greg did supply those with the links above. If where he's trying to go is not clear, can you ask a specific question to help us identify what more needs to be provided?

[cdanfon]

Hi @rjsparks, in the above images and links, we can see 3 different examples: one has a callout link with a paragraph of text, one has a list of featured blog posts with images and one is just columns of links with headings.

The NNG recommendation provides the general concept but this could be applied in many different ways.

To give you some context, our developers tend to work from wireframes & a list of functional requirements.

Wireframes are designed by UX Designers. These tend to specify things such as design patterns, mobile & tablet views, and any animations or effects that the menu should follow - amongst others.

On another note, this comment from Greg:

The megamenu structure should also allow for text and image content to be displayed in the megamenu element itself

Prompts a few questions:

• what you're hoping to achieve with this?
• is it linking to featured content or providing an explanation of the section of the menu currently open?
• where does it sit on the menu?

The above list of questions is an example of what we would expect from a specification of functional requirements.

Before Alex starts writing the code he will provide a quick wireframe and a list of functional requirements for the menu. Once you have reviewed these and are happy with the approach we can start coding.

Hope that makes sense!

[ghwood]

@cdanfon and @mgax Here is a pointer to a Google Doc with a specification for the megamenu, and a related update to how Index, Topic list, and Event listing pages are built. Let me know if another format would be better to work with and whether you'd like to have these two elements broken into separate issues.

Here is a link to a Miro board with wireframes.

[cdanfon]

Hi Greg, this is great thanks so much. Alex is reviewing at the moment. If we have any questions we will comment in the Google doc if that's OK.

[mgax]

@ghwood thank you for the specification, I've read through it, and indeed we can implement it as-is. I'm assuming the intention behind the content schema changes, is to afford greater flexibility in defining content for the menus, but they somewhat go against the built-in logic of Wagtail's page structure. In the interest of finding the best possible solution, I suggest we explore a few more options:

• All pages have a show in menus flag. It's currently used to filter content for the right-side "siblings" box on leaf pages (e.g. https://www.ietf.org/about/groups/), but we can also use it to filter which pages show up on an index page (e.g. https://www.ietf.org/about/), and/or in the mega menu.
• It's possible to restrict which page types are allowed to be children of which other page types, or to loosen these restrictions, if they get in the way.
• To define the content of the mega menu, it's possible to set up a dedicated StreamField (either on the site's settings, or as snippets), or add an inline model to pages which make up the menu. This way, the mega menu can be edited independently of the page structure.

In short, I'm concerned we might be making the job of editing pages more difficult (e.g. by forcing editors to link new pages to an index page, instead of having that happen automatically) in order to account for the mega menu.

[ghwood]

Hi @mgax thanks for the thought and the options.

After some discussion, we prefer option 3: either a streamfield or an inline model so that the megamenu can be edited independently of the page structure (though see the note below about a Megamenu Page Template).

This would necessitate a change to the spec so that we can manually add multiple sections rather than have special functionality if an index page is added. It would also mean that we do not need “Related Links” added to any page templates as we can just manually add that as a section to a megamenu if we want to.

This still leaves the question of what happens to the underlying pages if they are referenced directly by URL. For example, if someone clicks on “About” on the Main Menu then we expect a megamenu to appear, but what happens if they directly type in www.ietf.org/about?

There are two possible behaviours here:

1. They are taken to the home page with the megamenu shown. We are not clear if this is possible, or common web design or if people will understand what has happened
2. Take them to a webpage. In this case we most likely cannot use an Index Page because the links on that page are restricted to child pages. We would instead need to create a custom page with the same set of links on it as the megamenu for consistency. However, if the megamenu and the page were created separately, this would mean maintaining the same information in two locations and the possibility of inconsistency between the megamenu and the webpage..To address this and the need for a source for the elements on a Megamenu (including the explanatory text), there should be a single source (manual entry is fine) of content for both the Megamenu and the directly-accessible page.

[mgax]

Hi @ghwood, thanks for your reply. I agree we should avoid maintaining duplicate content. The challenge you describe seems to be poorly addressed by both NANOG and RIPE:

• NANOG has an empty page at https://www.nanog.org/program/; however https://www.nanog.org/outreach/ redirects to https://www.nanog.org/outreach/about-nanog-outreach/.
• The explanatory text on https://www.ripe.net/analyse differs from the version in the mega menu, which suggests out of sync duplicate content.

2. Take them to a webpage. In this case we most likely cannot use an Index Page because the links on that page are restricted to child pages.

Apologies for not having asked this up front, but could you give me some examples of pages that you would want linked on a top-level index page, like /about, /topics, etc, which are not child pages of that page? That seems counter-intuitive from an information architecture point of view. Perhaps the solution would be to move some pages to the right place in the hierarchy instead of arbitrarily linking them.

Is it perhaps the case that you'd want to show 2nd level index pages, and list their children, as described in the IETF Website Menu and Path Change Specification doc (Megamenus > 6., The “Menu Sections” panel has another section for each Index Page that is on the menu of the menu item that is clicked.)? We can certainly change the top-level index pages (e.g. /about) to list the children of 2nd level index pages.

There is also the option of unpublishing pages like /about (making them draft) and, in their place, setting up a redirect to some other page. No coding is needed for this change. Though I'm sure there are good arguments to keeping around index pages that people can link to, instead of relying on the megamenu.

• They are taken to the home page with the megamenu shown. We are not clear if this is possible, or common web design or if people will understand what has happened

This might be possible, but I'd argue against this option, it's certainly not common practice, and would confuse people.

[JayDaley]

Hi @mgax So what we want is to have menus that are independent of the page hierarchy because our menus need to evolve to meet changing needs with minimal impact on stable URLs. To give you four specific use cases (and the first one answers your question about /about child pages:

Top level URLs

There are multiple pages that we want to have a top-level URL (i.e. www.ietf.org/page-slug) but not have those as top-level menu items. So, under /about we want Liaisons to be www.ietf.org/liaisons but not a top-level menu item.

Freedom to move pages

The same Liaisons page is one that there are conflicting views about where it should go (one of a number of pages with this problem). We want these decoupled from the hierarchy so that we can test different locations (e.g. one month under menu A then one month under menu B) to determine a final location for it.

One page appearing in two places

As an example, we want our Sponsorship pages to appear both under a Support Us top-level menu and a Meetings top-level menu. This was one of the reasons we initially asked for "Related Links" to be added to some page templates on the assumption that would have to be the mechanism for adding a page in a second place.

Moving existing pages

We have a set of pages starting at /how/meetings and we now want to make Meetings a top-level menu item. There are two ways to do that: 1) Have a menu mechanism that is not tied to the page hierarchy and so be able to leave those pages where they are 2) Move those pages in the hierarchy and add in redirections. In this specific case we may end up having to do that, but we don't want to be forced to do it when we move our existing pages.

[mgax]

Thank you @JayDaley for the detailed examples, I'm better able to understand what we're trying to achieve.

I think a hybrid solution might cover most needs:

• Create a site setting to select and order pages for the main menu. Any page can pe picked, it doesn't have to be a direct child of the homepage.
• If the page is not an index page, display it as a link in the menu. Clicking it takes the browser to that page.
• If the page is an index page, show a mega menu, as described in the IETF Website Menu and Path Change Specification document (explanatory text, on the left, menu sections on the right).
• Add a "Related Links" section to index pages. These will be displayed both in the mega menu (as described in the doc, if they are chosen to be part of the menu), and on the page itself, below the listing of child pages.

This way, it's possible to link to arbitrary pages in the page tree, to experiment as needed. It also avoids duplication and keeps content management fairly straightforward. What do you think?

---

Edit: it's also possible to use the "show in menus" option to filter which child pages are shown on the index page itself and/or on the mega menu.

[JayDaley]

@mgax Thanks. As far as I can tell, this hybrid solution doesn't solve the issues as any page that is at the second level in the menu hierarchy would have to be placed there by locating it in a specific places in the page library and would get a URL determined by that position. Also, it would allow a page to be moved to the top-level without changing the URL but not to any other place in the menu hierarchy. Is that correct?

Is the following alternative approach possible?

• Create a new "Megamenu Page Template" that allows any number of sections of links be added to it. (or if that is not possible then just two sections of links, a main one and a related links.
  • This displays as a Megamenu when it is used a top-level menu link and as an index page when visited by URL
  • Those links can be any page, url etc as with the current related links section.
• Plus the change you suggested to the top level menu to allow any page to be chosen and if it is not based on the Megamenu Page Template then clicking on it goes straight to the page

[mgax]

As far as I can tell, this hybrid solution doesn't solve the issues as any page that is at the second level in the menu hierarchy would have to be placed there by locating it in a specific places in the page library and would get a URL determined by that position. Also, it would allow a page to be moved to the top-level without changing the URL but not to any other place in the menu hierarchy. Is that correct?

@JayDaley Yes, that's right. The intent was to have the Megamenu mirror the website's information hierarchy. If we're willing to break with that constraint, may I suggest a similar approach, which does not involve creating pages solely for the sake of managing Megamenu content:

• Define a new snippet type, MainMenuItem, where each snippet instance maps to a top-level item in the main menu. The snippet would have the following fields:
  • Page, which may be any page in the site. Its title serves as the menu item's label.
  • Content, which is a StreamField, configured to acomodate sections as described in IETF Website Menu and Path Change Specification (Megamenus section, items 5 through 7). It would be possible to create a block for each section, with a custom title, and sub-items for page links, organised independently of the actual page hierarchy.
• If the Content field is empty, the menu item simply links to the Page. Otherwise it expands to a Megamenu, with the "Explanatory Text" panel filled from the Page's introduction field, and the sections defined in the Content StreamField.

We can tweak this approach to e.g.

• Always render the first (main) section from the children of the Page, instead of defining it in the Content StreamField, if that makes more sense.
• Allow external links in the Content streamfield, not only to pages in the site.
• Add a Label field to the MainMenuItem snippet to display instead of the title of the Page.

Unfortunately, snippets in Wagtail are currently not orderable, so we'd also have to add a numerical Order field, to manually specify a sort order, but hopefully this will be a temporary solution.

I was actually working on a prototype of this approach before we received the specs; using snippets has the nice property of allowing for a live preview of the expanded Megamenu while it's being edited:

[JayDaley]

That works for us. Thanks

[mgax]

I'm currently working on the megamenu implementation, and before leaving for the weekend, I wanted to share an update of what it's looking like so far.

There are some loose ends to fix, like the mobile layout, and optimising database queries, and then I'll tidy up my branch and submit the PR.

[ghwood]

@mgax Thank you for this. It looks to be shaping up nicely. I am able to match up the contents of the menu with the current website, except for the image. Is that independently defined or is it linked to one of the pages in the menu? For example, I was thinking it might be the "Feed image" from the Page element of the MainMenuItem snippet but I don't find that in the production version of the "standards" page.

[mgax]

@ghwood I'm glad you like it!

I am able to match up the contents of the menu with the current website

The content is indeed based on the current website, but actually, the RFCs and Standards process sections are editable independent of the page structure. They were copied over to have some useful initial content. The Internet standards is the "main section" though, and it's sourced essentially like the menu items on the current production website. I'm preparing a more formalised write-up of how the Megamenu content is put together and we can review if it makes sense or needs adjustments.

except for the image. Is that independently defined or is it linked to one of the pages in the menu?

It's defined independently, when you edit the Main menu item. It could also be pulled from the selected page's Social image if that makes more sense.

[mgax]

@ghwood I've written up the logic of how the menu is displayed on the pull request description: https://github.com/ietf-tools/wagtail_website/pull/367.

On a related note, what should we do about the IAB layout: should it also receive a megamenu, or should it keep its old single-level menus on hover?

[rjsparks]

cc: @cindymorgan

[mgax]

On a related note, what should we do about the IAB layout: should it also receive a megamenu, or should it keep its old single-level menus on hover?

The IAB website is relatively smaller than the main IETF website. Its styling and templates have also somewhat diverged from the templates and styles shared with the main website. Therefore, it seems that the best choice all around is to keep the main menu on IAB as-is. I've updated the PR and marked it as "ready to review".