mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-12-12 03:22:23 +00:00
260 lines
13 KiB
HTML
260 lines
13 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<title>CUCC Expedition Handbook: Website menu design options</title>
|
|
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
|
|
</head>
|
|
<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>
|
|
|
|
<ul>
|
|
<li><a href="#why">Why</a>
|
|
<li><a href="#whatold">What we have now (appendix)</a>
|
|
<li><a href="#maint">Maintenance constraints</a>
|
|
<li><a href="#user">User mental model constraints</a>
|
|
<li><a href="#prop1">Proposal #1</a>
|
|
<li><a href="#prop2">Proposal #2</a>
|
|
<li><a href="#offline">Offline constraints (appendix)</a>
|
|
</ul>
|
|
|
|
<h2 id="why">Menus: Why we need a change now</h2>
|
|
|
|
<h4>Phones</h4>
|
|
|
|
<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.
|
|
|
|
<h4>Higher level, lower-level menus and context</h4>
|
|
<p>
|
|
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 <em>sketch-wallet-survex-drawings</em> sequence. This is also how well-designed websites work these days: lots of white
|
|
space and any necessary navigation clearly <em>in</em> the page.
|
|
<p>
|
|
An excellent guide is the
|
|
<a href="https://www.gov.uk/guidance/government-design-principles">gov.uk design principles</a>
|
|
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.
|
|
|
|
<p>Another reason that users don't use the menus is inconsistency. This is partly 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.
|
|
<p>The menu system we created a decade ago was leading-edge in its time but user expectations have moved in a different direction.
|
|
|
|
<h2 id="maint">Menus: Maintenance constraints</h2>
|
|
<p>
|
|
Experience over the past 10 years shows that having menus embedded in each page (see <a href="#whatold">What we have now</a>) is
|
|
unworkable long-term.
|
|
<p>
|
|
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.
|
|
<p>See the Proposals sections below for how we might make this easier.
|
|
<p>A maintenance constraint is that we should have <em>a small number</em> of different menus.
|
|
|
|
<h2 id="user">Menus: User mental model constraints</h2>
|
|
<p>This is where we have a real problem. Even nerds editing the system have different ideas
|
|
of how they visualise it.
|
|
<p>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.
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>A user mental model constraint is that menus should be predictable,
|
|
so we should have <em>a small number</em> of different menus.
|
|
|
|
|
|
<h2 id="prop1">Menus: Proposal #1 - One Single Menu</h2>
|
|
<h4>Architecture</h4>
|
|
<ul>
|
|
<li>One standard menu used on every single page.
|
|
<li>Generated dynamically by troggle.
|
|
</ul>
|
|
<p>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.
|
|
|
|
<h4>Implementation</h4>
|
|
<ul>
|
|
<li>Entirely done in CSS as currently, and
|
|
<li>inserted by troggle either just before the final
|
|
<span style="font-family:monospace; font-size: medium; background-color: lightgray"></body></span>
|
|
tag or at the beginning immediately after the initial
|
|
<span style="font-family:monospace; font-size: medium; background-color: lightgray"><body></span>
|
|
tag.
|
|
<li>A bit of tricky awk required to remove all the tags with
|
|
<span style="font-family:monospace; font-size: medium; background-color: lightgray">id="links"</span>
|
|
attributes. But just an evening's work.
|
|
</ul>
|
|
|
|
<h4>Advantages</h4>
|
|
<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 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
|
|
</ul>
|
|
|
|
<h4>Disadvantages</h4>
|
|
<ul>
|
|
<li>No menus offline
|
|
<li>No fine-grained menu when in the middle of a complex part of the system
|
|
</ul>
|
|
|
|
|
|
<h2 id="prop2">Menus: Proposal #2 - Different menus per "sector"</h2>
|
|
<h4>Architecture</h4>
|
|
<ul>
|
|
<li>Every page in the system is identified (how?) as being "in" one of half a dozen "sectors", e.g.
|
|
handbook, handbook-emergency, final cave data, survey procedures, software documentation, software maintenance etc.
|
|
<li>troggle inserts the menu dynamically depending on the page "sector" id.
|
|
</ul>
|
|
|
|
<h4>Implementation</h4>
|
|
<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
|
|
</ul>
|
|
|
|
<h4>Advantages</h4>
|
|
<ul>
|
|
<li>Fine-grained menus potentially more useful (if users use them)
|
|
</ul>
|
|
|
|
<h4>Disadvantages</h4>
|
|
<ul>
|
|
<li>Will need visible flagging to users which "sector" they are in,
|
|
otherwise the different menus appearing may disorient them
|
|
<li>If implemented by folder restructuring: all links in to the website, e.g. in historic emails, all the Slack posts, all the UKcaving blog posts etc. etc.
|
|
will <em>break</em> unless we create a large redirection list in the apache configuration files.
|
|
<li>If implemented by manual tag insertion in every page: page editors will get it wrong sometimes (but each fix is easy)
|
|
</ul>
|
|
|
|
<h2 id="prop2">Menus: Proposal #3</h2>
|
|
|
|
<p>Do Proposal #1 now.
|
|
<p>Do Proposal #2 later - if it turns out to be needed. (Probably by tag method not folder method.)
|
|
<p>
|
|
<p>
|
|
<h2 id="whatold">Appendix - Menus: What we have now</h2>
|
|
|
|
<p>Today (February 2020) we have two separate menu systems which look identical:
|
|
<ol type=A >
|
|
<li>Menu links as HTML text on individual webposite pages, either hand-edited (handbook) or
|
|
generated as HTML pages by occasional offline scripts (such as the deep/long caves page) , or
|
|
<li>Auto-created menus constructed <em>on the fly</em> by troggle at the moment that a page is served by the webserver.
|
|
This happens for every single page of every type.
|
|
</ol>
|
|
|
|
<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><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></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.)
|
|
<p>The visual rendering of the menus is controlled by lines 120-215 in <a href="../../css/main2.css">main2.css</a> -
|
|
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><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>
|
|
</code></pre>
|
|
|
|
<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.
|
|
It is inserted immediately before the closing
|
|
<span style="font-family:monospace; font-size: medium; background-color: lightgray"></body></span>
|
|
tag.
|
|
It has one thing which cannot be done by static menus: it has the <font color=red>"Edit this page"</font> link
|
|
at the bottom which is the troggle (Django) wiki-style editing system:
|
|
|
|
<pre><code><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/<font color=red>menudesign.html_edit</font>" <font color=red>class="editlink"</font>><strong><font color=red>Edit this page</font></strong></a></li>
|
|
</ul>
|
|
</code></pre>
|
|
<p>Note that the last line is different for every page and autogenerated.
|
|
<p>
|
|
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>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>.
|
|
|
|
<h2 id="offline">Appendix - Menus: Offline constraint</h2>
|
|
<p>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.
|
|
<p>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.
|
|
<p>Can anyone think of other cases where menus for offline use might be useful?
|
|
|
|
<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 -
|
|
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.
|
|
|
|
|
|
<hr>
|
|
|
|
</body>
|
|
</html>
|