From 4c7957a6d991c97bf6445bb3b3be6b9257ca052e Mon Sep 17 00:00:00 2001 From: Philip Sargent Date: Wed, 19 Feb 2020 16:07:29 +0000 Subject: [PATCH] New menu system - design options --- handbook/computing/menudesign.html | 259 +++++++++++++++++++++++++++++ handbook/manual.html | 6 + 2 files changed, 265 insertions(+) create mode 100644 handbook/computing/menudesign.html diff --git a/handbook/computing/menudesign.html b/handbook/computing/menudesign.html new file mode 100644 index 000000000..e87594a8f --- /dev/null +++ b/handbook/computing/menudesign.html @@ -0,0 +1,259 @@ + + + + +CUCC Expedition Handbook: Website menu design options + + + +

CUCC Expedition Handbook - Website menu design options

+ +

What, How and Why we need to do something with menus

+ + + +

Menus: Why we need a change now

+ +

Phones

+ +

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. + +

Higher level, lower-level menus and context

+

+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. + +

Another reason that users don't use the menus is inconsistency. This is partly 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. + +

Menus: Maintenance constraints

+

+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. + +

Menus: User mental model constraints

+

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. + + +

Menus: Proposal #1 - One Single Menu

+

Architecture

+ +

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. + +

Implementation

+ + +

Advantages

+ + +

Disadvantages

+ + + +

Menus: Proposal #2 - Different menus per "sector"

+

Architecture

+ + +

Implementation

+ + +

Advantages

+ + +

Disadvantages

+ + +

Menus: Proposal #3

+ +

Do Proposal #1 now. +

Do Proposal #2 later - if it turns out to be needed. (Probably by tag method not folder method.) +

  +

+

Appendix - Menus: What we have now

+ +

Today (February 2020) we have two separate menu systems which look identical: +

    +
  1. 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 +
  2. Auto-created menus constructed on the fly by troggle at the moment that a page is served by the webserver. + This happens for every single page of every type. +
+ +

Type A - static menus

+

The first type, the "static"menus, are created by HTML like this, with a +id="links" +tag attribute: +

<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>
+

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: +

<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>
+
+ +

Type B - dynamic (troggle) menus

+

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. +

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. + +

Appendix - Menus: Offline constraint

+

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? + +

Files for download as an alternative

+ +

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. + + +

+ + + diff --git a/handbook/manual.html b/handbook/manual.html index 2bf53ba8b..d98da954d 100644 --- a/handbook/manual.html +++ b/handbook/manual.html @@ -50,6 +50,7 @@ processes that a maintainer would want to do.

  • Updating cave pages
  • Updating expo year pages
  • Maintaining the survey status table
    • +
  • Cave pages and handbook menu system
    • Appendices: @@ -273,6 +274,11 @@ superseded in 2012).

  • This used to be generated by the script tablizebyname-csv.pl from the input file Surveys.csv +

    Cave pages and handbook menu design

    +

    See the menu design history and proposals +page on where we are and what we might do to improveand fix menus. + +