Clean Menus

In my ‘pre­vi­ous’ Word­Plus life, I was rather slop­py with my menus. What does that mean? Word­Press knows key­words and cat­e­gories. But what are entries in a deep­er nest­ed menu hav­ing their own sub-entries? They can be regard­ed as cat­e­gories, too — because of their group­ing effect. But they are not what Word­Press means by ‘cat­e­go­ry’. Clean menus deal with them prop­er­ly, with­out mix­ing types and tasks:

To avoid con­fu­sion, I pre­fer not to speak of a (menu) cat­e­go­ry, but of a menu group­ing, when I refer to menu entries hav­ing sub-entries.¹

Where were we? Exact­ly. At my slop­py han­dling: I did­n’t think about whether my nest­ed menus were read­er-friend­ly, nor did I care about con­sis­ten­cy. Some­times the menu group­ings were linked to spe­cif­ic pages, some­times they did­n’t. And I did­n’t check whether such a menu group­ing page was acces­si­ble on smart­phones and tablets. If I had done it, I would have noticed that I could sys­tem­at­i­cal­ly select and dis­play these pages on the desk­top, but not on small devices. This time I should do it bet­ter:

Solution

• Enable the ‘Short­Codes in Menus’ fea­ture.
• Set in the Word­Press back­end under Settings/Permalink to Siteurl + %postname.
• Give all pages and posts a sim­ple slug as ID.
• Con­vert all menu group­ings (=menu items with sub-items) to cus­tom links.
• If such a menu entry was pre­vi­ous­ly cre­at­ed by a page with con­tent, append it with a suit­able name under the just-cre­at­ed cus­tom link.
• Enter the string [­myDomain] into each cus­tom link, which stands for a menu group­ing.
• Append to it — fol­low­ing the pat­tern [­myDomain]/slug — the slug of the post or page that should be dis­played to the user of a desk­top sys­tem when she clicks on the menu group­ing.

Background

The ‘prob­lem’ is caused by the fea­ture hover: In the brows­er of a desk­top machine, a HOVER sub-menu pops up auto­mat­i­cal­ly when the mouse point­er slides into the area of a menu group­ing. So you can also click on the menu group­ing and see the page ‘behind’ it.

hov­er on smart­phones or tablets is a prob­lem: it is not oper­at­ed there. Instead, the read­er has to click on a menu group­ing if she wants to reach the sub­group below. That’s why she can nev­er reach the page behind the menu group­ing: the next click already clos­es the sub-menu again.

Boot­strap - and thus also bootScore — fol­low the prin­ci­pal mobile first. Hence, they don’t incor­po­rate HOVER menus. Because big and small devices should offer the same user expe­ri­ence: If a menu item ‘con­tains’ sub-items, a click on it opens the sub-menu, oth­er­wise the respec­tive page or post.²

The desire for HOVER menus is great.³ We also want to try that here. But then we must not act as slop­pi­ly as I did in the past. We must pre­pare our­selves to embed HOVER menus into our site: We may not com­bine a group of sub-entries by a Word­Press page or post, but only by a cus­tom link point­ing to a page or post inside the group. If we do so, that referred page or post is dis­played on desk­top devices, if the read­er clicks on the respec­tive menu grouping. But on the small­er devices, the read­er her­self picks the page out of the sub-menu.

---

And how does this …

… sup­port our migra­tion to bootScore? Well, once a web design­er has tak­en the first gen­er­al steps and has checked SEO, she will soon turn to a real­ly thick board, her prop­er­ly clus­tered and pre­sent­ed menu with­out get­ting too fan­cy. Even­tu­al­ly, she is going to spruce and speed up the dis­play of fixed and scal­able images. This post talks about a part of this way.

---

1. For the tech­ni­cians among us — that is, all of us — a menu is a tree. And each non-ter­mi­nal node of this tree is then a menu group­ing. [↩]
2. This is a gen­er­al design deci­sion, that goes back to 2012. [↩]
3. They are offered as an exten­sion or plu­g­in on GitHub. [↩]