diff --git a/handbook/troggle/trogdesign.html b/handbook/troggle/trogdesign.html
index 75b935fa0..1610486bb 100644
--- a/handbook/troggle/trogdesign.html
+++ b/handbook/troggle/trogdesign.html
@@ -7,9 +7,151 @@
</head>
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2>
-<h1>Troggle Design Decisions</h1>
+<h1>What Troggle Does Badly - Design Decisions</h1>
+<p>Practical use of troggle quickly shows up serious shortcomings:
-<p>Specific, immediate problems:
+<ul>
+<li><h4><a href="#fail">Things Troggle Doesn't Do</a></h4>
+<li><h4><a href="#badly">Things Troggle Does Badly</a></h4>
+<li><h4><a href="#change">New Things Troggle will need to Manage</a></h4>
+<li><h4><a href="#specific">Specific, Immediate problems</a></h4>
+</ul>
+<p><em>Updated: 11 March 2022</em>
+
+<h2 id="fail">Things Troggle Doesn't Do</h2>
+<p>Mostly these are not just a problem just with troggle, but things where expo procedures have never been
+properly created or applied, or where there was a procedure but it fell out of use because it wasn't easy
+enough to persist with.
+
+<h3>Finding and identifying entrances</h3>
+<p>This is abolutely crap. We have a manual, undocumented, probably incomplete offline set of scripts which
+produced a GPX file in 2019,
+which we have no easy way of delivering to a mobile device.
+The troggle pages for the cave and entrance descriptions do not have any location information on them, as it
+is generated quite separately from the survex files and fixed-points. And it is all in Austrian grid coordinates not WGS84 too.
+<p>We have no procedure whatsoever to capture photos of cave entrances and to get them associated witht he entrance data in troggle.
+
+<p>Our former prospecting guide has died of terminal obsolescence.
+
+<p>It should be perfectly possible to convert the entrance data as listed in the second table on
+<a href="/eastings">the troggle 'ents' page</a> into WGS84 and display it in the entrance description pages.
+<p>We really want a prospecting map showing entrances which are clickable,
+so that the entrance description pops up.
+<p>Our procedures for 'tag', 'exact tag', and 'other tag' are undocumented and need to be redone.
+
+<h3>Using Question Marks in active exploration</h3>
+<p>See <a href="scriptsqms.html">the current ugly situation</a>.
+
+<h3>Supporting Final Survey Preparation</h3>
+<p>We have no procedure for this. And also no proper procedures (or even agreed single final location) for rigging topos either. We have a bucket folder for final drawn-up surveys on expofiles.
+
+<h3>Use with Common Social Media</h3>
+<p>The 2019 expo was documented on two different blogs and the content has still not got copied into
+our own expo logbooks. One of these is UK caving, and for one post the caver used an ephemeral location for
+the illutrating photographs - which were very good. We have these archived on expofiles somewhere.
+<p>We seem to have lost the expo twitter account credentials.
+<p>We have an expo Facebook account.
+<p>We used to use Slack and (in 2022) use Trello for expo organisation. We have moved from Slack to
+Element, which we can archive ourseleves, and maybe we can use Kanboard (ditto) next year instead of Trello.
+
+<h2 id="badly">Things Troggle Does Badly</h2>
+<h3>Online Wallet Management</h3>
+<p>The results are not too bad, but some poor caver has to edit a JSON file in each online wallet on the
+<em>expo laptop</em>. It should be a straightforward job to move the code in
+<a href="scriptscurrent.html#wallets"><var>wallets.py</var></a> into
+troggle, create troggle reports to duplicate the 3 different types of pages produced by the script, and add
+an online form to create the equivalent to the JSON file.
+
+<p>The current script does only a single year at a time. When incorporated into troggle, we will be able to
+do all outstanding years worth of work.
+<p>We have all the wallets data for 1999 but it needs to be restructured into the modern file structure
+before we can run the script on it. (We have scanned survey logbooks for 1989-1998 and a wallet structure
+could be restrospectively created with a bit of data archeology. If we did that, we could then apply the same
+data consistency tools. This is only likely to be worthwhile if we need to seriously return to 1623/161).
+
+<h3>Writing Cave Descriptions</h3>
+<p>In 2022 we have a working online form to create or edit the cave and entrance descriptions. But the URL
+namespace of the form is different from where the cave description will be actually published, so getting
+the A HREF tags and IMG SRC tags correct for the referenced passage text and photos, and also to relevant
+bits of logbook, is unnecessarily convoluted.
+<p>This needs a small but significant re-design.
+
+<h3>Consistency Checking between Input Sources</h3>
+<p>We have a manual, offline, poorly-documented script <a
+href="scriptscurrent.html#survex">check-svx.sh</a> which does some checks on survex files' *ref wallet
+references. We have a similar thing <var>check-xml.sh</var> that checks Tunnel file references to survex
+files. We have the beginnings of a parser to do the same for Therion drawings. These are currently
+no better than proof-of-concept and need to be rewritten in troggle.
+<p>We could do with reports that identify survex files with no equivalent logbook entry (which would show
+up all the ARGE surveys, but we could filter those out).
+<p>We could do with finding drawn-up Tunnel and Therio files with no documented link to their source data
+in survex files.
+<p>We could do with better reports on survex files which have neved been drawn up ("tunnelled").
+
+
+<h3>API for Different Front Ends</h3>
+<p>We have proof of concept for <a href="/api/expeditions_json">one</a> of these: a simple list of
+expeditions. There are 61 different types of reports produced by troggle, some of which have complex
+internal structure which would need several API URLs. Nobody has attempted to produce any kind of alternative
+special-purpose front-end yet.
+
+<h3>Onboarding new People to Help</h3>
+<p>This is discussed on <a href="https://app.element.io/#/room/!wTGfwrwfiRMsZvzGZW:matrix.org">Element</a>
+and there are extensive previous discussions on <a href="https://app.slack.com/client/TQF95LK8T/CSCD0HW3S/thread/CQUM4L3HD-1579458900.001800">Slack</a>.
+
+<h3>Expofiles archiving</h3>
+The <a href="/expofiles">expofiles</a> folders are 40 GB of folders with no documnted archiving or backup procedures.
+Informally, several expo nerds have complete copies, but some better means of managing it are overdue.
+
+<h3>Fossil Software that needs Replacing</h3>
+<p>There are a lot of things where the troggle software mostly works, but is clunky or confusing, and where
+the maintenance is difficult because several different epochs of software techniques are munged together.
+So this makes future enhancement slower and more difficult as historic special cases need to be re-done.
+This is technical debt.
+<p>We import <b>cavers' names</b> in three separate places: the folk list, the names of the surveyors in
+survex files, and the names of expoers in the logbooks. These are inconsistently validated.
+
+<p>We have half a dozen different <b>logbook HTML dialects</b> for different eras of expo logbooks. These should be
+converted into one, simpler form. Then we can reduce the size of the logbooks parsers substantially.
+
+<p>We have the HTML folder structure for complex caves in the same <b>URL namespace as the cave descriptions</b>
+generated by troggle. This is a fossil from when the cave descriptions were actual HTML files (generated
+offline) and needed to be local so that they would have simple access to the linked photographs and passage
+description pages. This prevents us using "EditThisPage" on those complex descriptions, which thus adds
+another level of pain on doing this task which is already much more difficult than it needs to be.
+
+<h2 id="change">New Things Troggle will need to Manage</h2>
+<h3>Users with Only a Phone, No Computer</h3>
+<p>The possible alternative front-ends using the (in development) API would help.
+As would a complete alternative phone-centric design of the CSS and <a href="menudesign.html">menuing system</a>.
+
+<h3>GPS altitudes</h3>
+<p>GPS is currently great for route-finding and locating entrances, but it is much less useful in those
+parts where there are steep cliffs as the height accuracy is dreadful. When GPS fixes the altitude
+accuracy, it will open a new range of uses.
+
+<h3>3D Cave surveying</h3>
+<p>There are some wonderful demos of fly-through surveys which use visual flow, phone ultrasonic range
+detection and/or lidar. These will be big files and unsuited to being stored in a git repository - as we
+currently do for Tunnel and Therion Drawings.
+
+<h3>Geographic Software (GIS) and Terrain Model Integration</h3>
+<p>One-off attempts have been made at this for the past 15 years at least, e.g. the 3D view of the whole
+SMK ridge on <a href="/guidebook/areas.htm">the Areas page</a>.
+
+<p>Historic QGIS work is archived at <a href="/expofiles/qgis_resources">expofiles/qgis_resources</a>
+expofiles\qgis_resources
+
+<p>CaveView does a wondeful job of animating 3D survex centre-lines, and when this is restored to use it will
+make a difference.
+<p>Julian has a high-quality lidar of the whole plateau area but it has not been as useful as we hoped.
+
+<h3>Good Internet Access across the Plateau</h3>
+<p>Troggle is now sufficently portable that we can run the entire system on a laptop: it doesn't need
+internet access. We could design clever caching so that just an ordinary web browser could take effective a
+complete copy, but if universal internet access is coming anyway, any such work would be wasted.
+
+<h2 id="specific">Specific, Immediate problems</h2>
<ul>
<li>New systems for <a href="menudesign.html">website menus</a>
<li><s>Short-term note on "logon" <a href="trogregistr.html">django-registration</a></s>
diff --git a/handbook/troggle/trogindex.html b/handbook/troggle/trogindex.html
index f38a958b0..f8943bc34 100644
--- a/handbook/troggle/trogindex.html
+++ b/handbook/troggle/trogindex.html
@@ -18,7 +18,7 @@
<a href="trogmanual.html">Troggle - Maintenance</a> - list of maintenance tasks<br>
<a href="trogarch.html">Troggle - Architecture</a> - diagrams, files, structure<br>
<a href="datamodel.html">Troggle - Data Model</a> - syntax-coloured list of classes, instance variables and foreign keys<br>
-<a href="trogdesign.html">Troggle - Design Decisions for the Future</a> - open issues being worked on:<br>
+<a href="trogdesign.html">Troggle - What it does Badly</a> - Design Decisions for the Future<br>
<ul>
<li><a href="trogregistr.html">Troggle Login and user registration</a> - proposal to remove registration<br>
<li><a href="menudesign.html">Troggle Menu Design</a> - options for replacing the menuing system<br><br>