correction <div id="menu">

This commit is contained in:
Philip Sargent 2020-02-19 19:43:57 +00:00
parent 4c7957a6d9
commit 90e877f818

View File

@ -8,7 +8,7 @@
<body>
<h2 id="tophead">CUCC Expedition Handbook - Website menu design options</h2>
<h1>What, How and Why we need to do something with menus</h1>
<h1>What, How and Why : New menus</h1>
<ul>
<li><a href="#why">Why</a>
@ -24,7 +24,7 @@
<h4>Phones</h4>
<p>The <a href="whatold">current system</a> makes it very difficult to design menus that work on phone screens.
<p>The <a href="#whatold">current system</a> 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.
@ -41,7 +41,9 @@ web pages which practice what they preach. They have a "Related Content" menu t
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.
<p>Another reason that users don't use the menus is inconsistency. This is partly the menus don't
<p>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.
<p>Another reason that users don't use the menus is inconsistency. This is partly because the menus don't
match the <a href="#user">mental model they have</a> of how the system is put together and partly
because <a href="#maint">maintenance difficulties</a> have created
an inconsistent system.
@ -108,7 +110,7 @@ attributes. But just an evening's work.
<ul>
<li>Excellent predictability for users
<li>Simple to implement: minimal changes to the existing system.
<li>No effort whatsoever on page editors
<li>No effort whatsoever on page editors and content typers
<li>No conflicting menus from different sources appearing on the same page
<li>"Edit this page" can appear or not depending on user authorisation or (for generated pages) entirely absent.
<li>Universal single update: change once changes menus for whole system
@ -133,7 +135,7 @@ handbook, handbook-emergency, final cave data, survey procedures, software docum
<ul>
<li>All programmed within troggle
<li>page editors will need to insert an identifying tag, OR
<li>we restructure the folders completely and have troggle use the folder structure to decide whcih "sector" is which
<li>we restructure the folders completely and have troggle use the folder structure to decide which "sector" is which
</ul>
<h4>Advantages</h4>
@ -169,13 +171,16 @@ generated as HTML pages by occasional offline scripts (such as the deep/long cav
<h4>Type A - static menus</h4>
<p>The first type, the "static"menus, are created by HTML like this, with a
<span style="font-family:monospace; font-size: medium; background-color: lightgray">id="links"</span>
tag attribute:
<pre><code>&lt;ul id="links"&gt;
&lt;a href="index.htm"&gt;Handbook&lt;/a&gt;
&lt;a href="survey/index.htm"&gt;Surveying&lt;/a&gt;
&lt;a href="look4.htm"&gt;Prospecting&lt;/a&gt;
&lt;a href="rescue.htm"&gt;Rescue&lt;/a&gt;
&lt;/ul&gt;</code></pre>
tag attribute which creates the styling:
<pre><code>&lt;!-- LINKS --&gt;
&lt;div id="menu"&gt;
&lt;ul id="links"&gt;
&lt;a href="index.htm"&gt;Handbook&lt;/a&gt;
&lt;a href="survey/index.htm"&gt;Surveying&lt;/a&gt;
&lt;a href="look4.htm"&gt;Prospecting&lt;/a&gt;
&lt;a href="rescue.htm"&gt;Rescue&lt;/a&gt;
&lt;/ul&gt;
&lt;/div&gt;</code></pre>
<p>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.)
@ -184,7 +189,9 @@ thanks to a succession of clever and inventive people.
<p><p>
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:
<pre><code>&lt;ul id="links"&gt;
<pre><code>&lt;!-- LINKS --&gt;
&lt;div id="menu"&gt;
&lt;ul id="links"&gt;
&lt;li&gt;&lt;a href="index.htm"&gt;Expedition Handbook&lt;/a&gt; - Intro
&lt;ul&gt;
&lt;li&gt;&lt;a href="survey/index.htm"&gt;Surveying guide&lt;/a&gt; - Overview&lt;/li&gt;
@ -204,7 +211,11 @@ overflows the menu box because the annotations are too long for the box width:
&lt;li&gt;&lt;a href="../../index.htm"&gt;Back to CUCC Home page&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</code></pre>
&lt;/div&gt;</code></pre>
<p>There are a few pages where the enclosing
<span style="font-family:monospace; font-size: medium; background-color: lightgray">DIV</span>
tag is omitted. In these cases troggle inserts its own menu <em>in addition to</em> the static menu. The result is a confusion of two menus. These pages are in currently being identified and corrected.
<h4>Type B - dynamic (troggle) menus</h4>
<p>This menu is a fragment of HTML inserted by troggle on the fly as the page is served to the user.
@ -230,6 +241,14 @@ at the bottom which is the troggle (Django) wiki-style editing system:
The dynamic menu is rendered by exactly the same CSS
<span style="font-family:monospace; font-size: medium; background-color: lightgray">id="links"</span>
as the static menu.
<p>Note that there is no
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;div id="menu"&gt;</span> enclosing
<span style="font-family:monospace; font-size: medium; background-color: lightgray">DIV</span>
tag. The
<span style="font-family:monospace; font-size: medium; background-color: lightgray">DIV</span>
tag is only there to tell troggle that there is a static menu and so it shouldn't provide one.
<p>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:
<a href="http://expo.survex.com/dplong.htm">Lengths and depths of caves in the 1623 area</a>.
@ -247,8 +266,8 @@ to do it anyway. If they can do this, they are not likely to be relying on the m
<h4>Files for download as an alternative</h4>
<p>We could meet this very specific requirement without messing with our menus. We could have
downloadable documents (e.g. PDF)of prospecting guides and safety procedures - including topcamp and basecamp phone numbers -
<p>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.