The current system makes it very difficult to design menus that work on phone screens. Phones are now the primary access method and the current menus actively get in the way rather than provide useful function. They have to be fixed.
Secondly, we observe that many users never look at the menus. From using other websites they are used to seeing the important links in the text of the page they are reading. This is particularly true for pages documenting a sequence of operations such as the sketch-wallet-survex-drawings sequence. This is also how well-designed websites work these days: lots of white space and any necessary navigation clearly in the page.
An excellent guide is the gov.uk design principles web pages which practice what they preach. They have a "Related Content" menu to one side, breadcrumbs showing the page context, more remote organisation menu along the top of the page and two or three fine-print menus at the bottom of the page for potentially relevant standard stuff.
Users need "situational awareness" in that they like to know "where they are" in the system. This is not the same thing as a menu list of links to "places you might like to go to". But these two different things are both called "navigation". The gov.uk design guide separates these two things and we should too.
Another reason that users don't use the menus is inconsistency. This is partly because the menus don't match the mental model they have of how the system is put together and partly because maintenance difficulties have created an inconsistent system.
The menu system we created a decade ago was leading-edge in its time but user expectations have moved in a different direction.
Experience over the past 10 years shows that having menus embedded in each page (see What we have now) is unworkable long-term.
People create new pages typically by editing a copy of the last page they edited. This might have been from an entirely different part of the system. So we end up with "survey documentation" menus on a page which is in the middle of a "basecamp operations" set of pages. We cannot control the behaviour of page editors and we are very grateful to them so we don't want to add to their workload or make things messy or difficult.
See the Proposals sections below for how we might make this easier.
A maintenance constraint is that we should have a small number of different menus.
This is where we have a real problem. Even nerds editing the system have different ideas of how they visualise it.
Most users have no picture at all of the distinctions between "the handbook", the "local area", the "cave survey data", the "software maintainers guide" parts. Some people only interact with only one part of the system and are entirely unaware of the rest of the system.
Some pages which are definitely in the mental "how to do expo" category are not just hand-edited handbook webpages, for example some prospecting guides are generated from cave data.
Some pages have to be updated very differently fom others. The "cave descriptions" are particularly difficult for someone used only to interacting with an HTML editor or a wiki. But for most users this distinction is invisible.
The current set of menus suffer greatly from "bleed through" in that they mimic the hidden internal structure of the system rather than (as they should) the user mental model of how users want to interact with it.
A user mental model constraint is that menus should be predictable, so we should have a small number of different menus.
This will need quite a bit of thought and discussion as to what should be in the menu. We should test this with a variety of real users, or roll it out and be very responsive to change requests.
Do Proposal #1 now.
Do Proposal #2 later - if it turns out to be needed. (Probably by tag method not folder method.)
Today (February 2020) we have two separate menu systems which look identical:
The first type, the "static"menus, are created by HTML like this, with a id="links" tag attribute which creates the styling:
<!-- LINKS -->
<div id="menu">
<ul id="links">
<a href="index.htm">Handbook</a>
<a href="survey/index.htm">Surveying</a>
<a href="look4.htm">Prospecting</a>
<a href="rescue.htm">Rescue</a>
</ul>
</div>This text is conventionally at the bottom of each HTML file. (It does not have to be at the bottom, the CSS handles where on the page this appears visually, so this HTML fragment could be anywhere in the HTML file.)
The visual rendering of the menus is controlled by lines 120-215 in main2.css - thanks to a succession of clever and inventive people.
Here is an example of a more extensive menu. Note that changes to CSS over the years now mean that this overflows the menu box because the annotations are too long for the box width:
<!-- LINKS -->
<div id="menu">
<ul id="links">
<li><a href="index.htm">Expedition Handbook</a> - Intro
<ul>
<li><a href="survey/index.htm">Surveying guide</a> - Overview</li>
<li><a href="look4.htm">Prospecting guide</a> – Overview
<li><a href="rescue.htm">Rescue guide</a></li>
<li><a href="rig/rigit.html">Rigging guide</a></li>
<li><a href="photo.htm">Photography guide</a></li>
</ul></li>
<li><a href="../infodx.htm">Index to info/topics pages</a></li>
<li><a href="../indxal.htm">Full Index to area 1623</a>
<ul>
<li><a href="../areas.htm">Area/subarea descriptions</a></li>
</ul></li>
<li><a href="../index.htm">Back to Expedition Intro page</a></li>
<li><a href="../../index.htm">Back to CUCC Home page</a></li>
</ul>
</div>There are a few 546 pages (out of hand-edited 1,022 HTML pages) where the enclosing DIV tag is omitted. In these cases troggle inserts its own menu in addition to the static menu. The result is a confusion of two menus. These pages are in currently being identified and corrected.
This menu is a fragment of HTML inserted by troggle on the fly as the page is served to the user. It is inserted immediately before the closing </body> tag. It has one thing which cannot be done by static menus: it has the "Edit this page" link at the bottom which is the troggle (Django) wiki-style editing system:
<ul id="links">
<li><a href="/index.htm">Home</a></li>
<li><a href="/infodx.htm">Main Index</a></li>
<li><a href="/troggle">Troggle</a></li>
<li><a href="/areas.htm">Areas</a></li>
<li><a href="/indxal.htm">Caves</a></li>
<li><a href="/handbook/index.htm">Handbook</a></li>
<li><a href="/pubs.htm">Reports</a></li>
<li><a href="/handbook/menudesign.html_edit" class="editlink"><strong>Edit this page</strong></a></li>
</ul>
Note that the last line is different for every page and autogenerated.
The dynamic menu is rendered by exactly the same CSS id="links" as the static menu.
Note that there is no <div id="menu"> enclosing DIV tag. The DIV tag is only there to tell troggle that there is a static menu and so it shouldn't provide one.
For the past 3 years the static menus have been mostly removed from edited pages as the dynamic menu did the job, and often both would appear which was ugly. This page has both menus: Lengths and depths of caves in the 1623 area.
It is handy if a completely offline copy of the website - just the HTML files and CSS - still has a useable (if cut-down) menu system. (This used to be vital when the potato hut server troggle stopped but the server could still provide HTML files. Not any more.) But this is increasingly unnecessary for most of the people using it.
The most likely use-case would be someone on the plateau (or possibly underground) needing to read the handbook pages on rescue or first-aid procedures using a locally-stored copy of the entire handbook. Most people won't have done in this in advance of the need or wouldn't know how to do it anyway. If they can do this, they are not likely to be relying on the menu system to find what they want.
Can anyone think of other cases where menus for offline use might be useful?
We could meet this very specific requirement without messing with our menus. We could have a complete set of downloadable documents (e.g. PDF) of prospecting guides and safety procedures - including topcamp and basecamp phone numbers - which we encourage all expoers to download to their phone before they leave base-camp. We already have a number of these but some are in .odt format which is not phone-friendly. But that is another job to fix.