expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-08 23:04:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Restructuring troggle notes and creation of troggle documentation directory in the handbook

Browse Source
This commit is contained in:
Philip Sargent
2020-04-02 14:25:58 +01:00
parent 1f24e303ef
commit a5447cf626
14 changed files with 519 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files

278
handbook/computing/menudesign.html
View File

@@ -1,278 +0,0 @@
<!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 : New 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>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.
<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">&lt;/body&gt;</span>
tag or at the beginning immediately after the initial
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;body&gt;</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 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
</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 which "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>&nbsp;
<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 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.)
<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>&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;
&lt;li&gt;&lt;a href="look4.htm"&gt;Prospecting guide&lt;/a&gt; &ndash; Overview
&lt;li&gt;&lt;a href="rescue.htm"&gt;Rescue guide&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="rig/rigit.html"&gt;Rigging guide&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="photo.htm"&gt;Photography guide&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../infodx.htm"&gt;Index to info/topics pages&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../indxal.htm"&gt;Full Index to area 1623&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="../areas.htm"&gt;Area/subarea descriptions&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../index.htm"&gt;Back to Expedition Intro page&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="../../index.htm"&gt;Back to CUCC Home page&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;</code></pre>
<p>There are <span style="text-decoration: line-through wavy red;">a few</span> 546 pages (out of hand-edited 1,022 HTML 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.
It is inserted immediately before the closing
<span style="font-family:monospace; font-size: medium; background-color: lightgray">&lt;/body&gt;</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>&lt;ul id="links"&gt;
&lt;li&gt;&lt;a href="/index.htm"&gt;Home&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/infodx.htm"&gt;Main Index&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/troggle"&gt;Troggle&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/areas.htm"&gt;Areas&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/indxal.htm"&gt;Caves&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/handbook/index.htm"&gt;Handbook&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/pubs.htm"&gt;Reports&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="/handbook/<font color=red>menudesign.html_edit</font>" <font color=red>class="editlink"</font>&gt;&lt;strong&gt;<font color=red>Edit this page</font>&lt;/strong&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</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>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>.
<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 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.
<hr />
</body>
</html>

369
handbook/computing/troggle-ish.html
View File

@@ -1,369 +0,0 @@
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Handbook Troggle Notes</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Troggle - what you may need to know</h1>
<p>Troggle runs much of the the cave survey data management, presents the data on the website and manages the Expo Handbook.
<p>You may have arrived here by accident when where you really need to be is <a href="../website-history.html">website history</a>.
<p>This page needs to be restructured and rewritten so that it describes these things:
<ul>
<li>Day to day troggle tasks - usually during expo. i.e. links to the "survey handbook"
<li>Annual tasks: preparing for next year, finishing last year (troggle & scripts)
<li>Architectural documentation of how it all fits together & list of active scripts
<li>How to edit and maintain troggle itself. The code is public on repository <a href="http://expo.survex.com/repositories/">::troggle::</a>
</ul>
<br />
<tt><em>Everything here should be updated or replaced - this page just records a lot of unfinished ideas.
Most people will not want to read this at all. This is for speleosoftwarearcheologists only.</em>
</tt>
<p>This page is mostly an index to other records of what troggle is and what plans have been made - but never implemented - to improve it.
<h3 id="troggle">Troggle - what it is</a></h3>
<p>
Troggle is the software collection (not really a "package") based on <a href="https://www.djangoproject.com/">Django</a>
originally intended to manage all expo data in a logical and accessible way
and publish it on the web. It was first used on the 2009 expo - see <a href="../../years/2009/report.html">2009 logbook</a>.
<p>Only a small part of troggle's original plan was fully implemented and deployed.
Many of the things it was intended to replace are still operating as a motley collection written by many different people in
several languages (but mostly perl and python; we won't talk about the person who likes to use OCamL).
<p>Examples of troggle-generated pages from data:
<ul>
<li><a href="http://expo.survex.com/caves">expo.survex.com/caves</a> - list of caves surveyed and links to guidebook descriptions
<li><a href="http://expo.survex.com/pubs.htm">http://expo.survex.com/pubs.htm</a> - reports, accounts and logbooks
<li><a href="http://expo.survex.com/expedition/2018">expo.survex.com/expedition/2018</a> - Members on expo 2018: . Scroll down for a list of all the data typed in from survey trips.
<li><a href="http://expo.survex.com/survexfile/caves/">expo.survex.com/survexfile/caves/</a> - List of caves with all the surveys done for each.
<li><a href="http://expo.survex.com/survexfile/caves-1623/115/cucc/futility.svx">expo.survex.com/survexfile/caves-1623/115/cucc/futility.svx</a> - Cave survey data from 1983 in Schnellzughohle.
<li><a href="http://expo.survex.com/survey_scans/">expo.survex.com/survey_scans/</a> - List of all scanned original survey notes.
<li><a href="http://expo.survex.com/survey_scans/2018%252343/">expo.survex.com/survey_scans/2018%252343/</a> - list of links to scanned notes for wallet #43 during the 2018 expo.
</ul>
Today troggle is used for only three things:
<ol>
<li>Reformatting all the visible webpages such that they have a coherent style and have a contents list at the top-left
hand corner. This is particularly true of the handbook you are reading now and the historic records of past expeditions.
<li>Publishing the "guidebook descriptions" of caves. The user who is creating a new guidebook description
can do this by filling-in some online forms. (And managing all the cave suvey data to produce this.)
<li>Providing a secondary way of editing individual pages of the handbook and historic records pages
for very quick and urgent changes.
This is the "Edit this page" capability; see <a href="../onlinesystems.html#editthispage"> for
how to use it</a> and <em>how to tidy up afterwards</em>.
</ol>
<h3>The first thing to do</h3>
<p>The first thing to do is to read: "<a href="../../../troggle/docsEtc/troggle_paper.odt" download>Troggle: a novel system for cave exploration information management</a>", by Aaron Curtis, CUCC.</em>
<p>Two things to remember are
<ul>
<li>that troggle is just one of several cave-survey management online software systems. CUCC EXPO is not the only caving expedition with a substantial nerd community.<br /><br />
<li>that troggle is part of a 40-year ongoing project and lives in a soup of several disparate scripts all working on the same data
</ul>
<h3>Troggle Login</h3>
<p>Yes you can log in to the troggle control panel: <a href="http://expo.survex.com/troggle">expo.survex.com/troggle</a>.
</p>
<p>It has this menu of commands:
<pre>
All Survex | Scans | Tunneldata | 107 | 161 | 204 | 258 | 264 | Expo2016 | Expo2017 | Expo2018 | Django admin
</pre>
<h3>Future Developments: Preamble</h3>
<p><em>Assumptions</em> (points to necessarily agree upon)
<ol>
<li>Let's NOT try to design a generic catalogue for storing all kind of data about caves of the whole world, intended for every kind of user (sports, exploration, science). Let's just settle for a generic framework. Let geeks in individual countries or individual communities write their tools operating within this framework.
<li>Let's try make it available for the layman, but still well-playable for the geeks.
<li>Let's rely on already existing, popular technologies. Let's keep it open source and multiplatform. Let's try not to reinvent the wheel.
<li>Let's not assume everyone has an Internet connection while working with their data.
<li>Let's version-control as much as possible.
<li>Let's support i18n - let's use UTF-8 everywhere and cater for data in many languages(entrance names, cave descriptions, location descriptions etc.)
</ol>
<p>Two page preliminary design document for <a href="../../documents/caca_arch2.pdf">'caca' (Cave Catalogue) rev.2 2013-07-26</a> by Wookey (copied from http://wookware.org/software/cavearchive/caca_arch2.pdf)
<h3>stroggle</h3>
<p>At one time Martin Green attempted to reimplement troggle as "stroggle" using <a href="https://www.fullstackpython.com/flask.html">flask</a> instead of Django at
<a href="https://en.wikipedia.org/wiki/Gitorious">git@gitorious.org:stroggle/stroggle.git</a> (but gitorious has been deleted).</p>
<p>A copy of this project is archived by Wookey on <a href="http://wookware.org/software/cavearchive/stroggle/">wookware.org/software/cavearchive/stroggle/</a>.
<p>There is also a copy of stroggle on the backed-up, read-only copy of gitorious on "<a href="https://gitorious.org/">gitorious valhalla</a>"<br />
<a href="https://gitorious.org/stroggle/stroggle.git/">stroggle code</a></br>
<a href="https://gitorious.org/stroggle/stroggle-gitorious-wiki.git/">stroggle-gitorious-wiki</a></br>
but note that this domain has an expired ertificate so https:// complains.
<h3>CUCC wiki on troggle</h3>
<p>CUCC still has an archive list of things that at one time were live tasks:
from <a href="https://camcaving.uk/Documents/Expo/Legacy/Misc/Troggle%20-%20Cambridge%20University%20Caving%20Club.htm">camcaving.uk/Documents/Expo/Legacy/Misc/...</a> and that page is reproduced in the table below (so don't worry if the URL link goes dark when CUCC reorganise their legacy pages).
<p>Troggle is a system under development for keeping track of all expo data in a logical and accessible way, and displaying it on the web. At the moment, it is [no longer] under development at <u>http://troggle.cavingexpedition.com/</u>
<tt>But note that this is Aaron's version of troggle, forked from the version of troggle we use. Aaron uses this for the <a href="https://expeditionwriter.com/new-expedition-to-mount-erebus-antarctica/">Erebus expedition</a>.</tt>
</p>
<p>Note that the information there is incomplete and editing is not yet enabled.
</p>
<table border="1" cellspacing="0">
<tr>
<th><p>Feature</p></th>
<th><p>Old expo website</p></th>
<th><p>Troggle: planned</p></th>
<th><p>Troggle: progress so far</p></th>
</tr>
<tr>
<td><p>Logbook</p></td>
<td><p>Yes; manually formatted each year</p></td>
<td><p>Yes; wiki-style</p></td>
<td><p>Start at the front page, <a rel="nofollow" class="external autonumber" href="http://expo.survex.com/expedition/2007">troggle.cavingexpedition.com/ [1]</a> and click to logbook for year. The logbooks have been parsed back to 1997. </p></td>
</tr>
<tr>
<td><p>Cave index and stats generated from survex file</p></td>
<td><p>Yes</p></td>
<td><p>Yes</p></td>
<td><p>Done; see <a rel="nofollow" class="external autonumber" href="http://expo.survex.com/survexfile/caves/264">troggle.cavingexpedition.com/survey/caves/264 [2]</a> </p></td>
</tr>
<tr>
<td><p>Survey workflow helper</p></td>
<td><p>Yes; minimal. surveys.csv produced an html table of whose surveys were not marked “finished”</p></td>
<td><p>Yes. Makes table of surveys per expo which shows exactly what needs doing. Displays scans. Integrated with survex, scanner software, and tunnel.</p></td>
<td><p>See it at <a rel="nofollow" class="external free" href="http://expo.survex.com/survey_scans/">troggle.cavingexpedition.com/survey</a> . Be sure to try a recent year when we should have data. Survex, scanner, and tunnel integration still needs doing.</p></td>
</tr>
<tr>
<td><p>QM lists generated automatically</p></td>
<td><p>Depends on the cave. Each cave had a different system.</p></td>
<td><p>Yes; unified system.</p></td>
<td><p>Done, but only 204 and 234 Qms have been imported from old system so far. No view yet.</p></td>
</tr>
<tr>
<td><p>Automatic calendar for each year of who will be on expo when</p></td>
<td><p>No, manually produced some years</p></td>
<td><p>Yes</p></td>
<td><p>Done; see <a rel="nofollow" class="external free" href="http://expo.survex.com/expedition/2007">troggle.cavingexpedition.com/calendar/2007</a> (replace 2007 with year in question)</p></td>
</tr>
<tr>
<td><p>Web browser used to enter data</p></td>
<td><p>No</p></td>
<td><p>Yes</p></td>
<td><p>Everything can be edited through admin, at <a rel="nofollow" class="external free" href="http://expo.survex.com/admin/">troggle.cavingexpedition.com/admin</a> . Ask aaron, martin, or julian for the password if you want to have a look / play around with the admin site. Any changes you make will be overwritten. Eventually, data entry will probably be done using custom forms.
</p></td>
</tr>
<tr>
<td><p>Cave and passage descriptions</p></td>
<td><p>Yes, manually html coded.</p></td>
<td><p>Yes, wiki-style.</p></td>
<td><p>Not done yet.<br />
</p></td>
</tr>
<tr>
<td><p>Expo handbook</p></td>
<td><p>Yes, manually html coded.<br />
</p>Maybe. Needs to be discussed further.</td>
<td><p><br />
</p></td>
<td><p>Not done yet.</p></td>
</tr>
<tr>
<td><p>Table of who was on which expo</p></td>
<td><p>Yes</p></td>
<td><p>Yes</p></td>
<td><p>Data has been parsed, this view hasn't been written yet. </p></td>
</tr>
<tr>
<td><p>Signup form, System for keeping contact, medical and next of kin info</p></td>
<td><p>No</p></td>
<td><p>Yes</p></td>
<td><p>Signup form should be ready by 20 Jan.</p></td>
</tr>
<tr>
<td><p>Automated photo upload and gallery</p></td>
<td><p>No; some manual photo galleries put together with lots of effort</p></td>
<td><p>Yes</p></td>
<td><p>Photo upload done, gallery needs writing.</p></td>
</tr>
<tr>
<td><p>Search</p></td>
<td><p>No</p></td>
<td><p>Yes</p></td>
<td><p></p></td>
</tr>
</table>
<h3>List of cave database software</h3>
from <a href="http://wookware.org/software/cavearchive/databasesoftwarelist">wookware.org/software/cavearchive/databasesoftwarelist</a>
<pre>
ckan is something like this - could we use it?
esri online
CUCC (troggle) http://cucc.survex.com/ - this site.
virgina caves database (access+arcgis) (futrell)
each country database
Austria (spelix) ( <a href="https://www.spelix.at/">www.spelix.at/</a>
UK cave registry
mendip cave registry: (access) <a href="http://www.mcra.org.uk/wiki/doku.php">www.mcra.org.uk/wiki/doku.php</a>
White mountains database (gpx + google earth)
Matienzo (?)
Fisher ridge (stephen cladiux)
hong meigui (erin) <a href="http://www.hongmeigui.net/"http://www.hongmeigui.net/</a> (ask erin later)
Wikicaves <a href="http://www.grottocenter.org/">www.grottocenter.org/</a>
multilingual, slippymap, wiki data entry. includes coordinate-free caves.
focus on sport-caving type info (access, basic gear list, overall description, bibliography)
e.g. australians only publish coordinates to nearest 10km
turkey <a href="http://www.tayproject.org">www.tayproject.org</a>.
<a href="http://www.uisic.uis-speleo.org/contacts.html">www.uisic.uis-speleo.org/contacts.html</a> change link. no-one looks for list of databases under 'contacts'
graziano ferrari northern italy list (access + google earth)
</pre>
<h3>Wookey's notes on things to do</h3>
from <a href="http://wookware.org/software/cavearchive/goliczmail">wookware.org/software/cavearchive/goliczmail</a>
<pre>
Generally I'd like to find some people (geeks) that share these technical
ideas: (1) store things in a file system, (2) use XML, (3) do not aim too high
(do not try designing a general system for handling all caving-related data
for the whole world).
If I could find some people that agree with this, then we could try to reach a
compromise on:
(1) how do we store our data in a file system,
(2) how do we use this XML (let's do a common spec, but keep it simple)
(3) how do we aim not to high and not end up dead like CaveXML :)
After we do that, everyone goes away to do their own projects and write their
own code. Or maybe we have some degree of co-operation in actually writing the
code. Normal life. But the idea is that all geeks working on "cave inventory"
and systems making extensive use of cave inventories try to adhere to this
framework as much as possible. So that we can then exchange our tools.
I think things like "which revision system do we use" or "do we use web or
Python" are really secondary. Everyone has their own views, habits,
backgrounds.
My idea is to work on this in a small group (no more than a few persons) - to
get things going fast, even if they are not perfect from the beginning. If it
works, we try to convince others to use it and maybe push it through UIS.
</pre>
<h3>Wookey's other notes on things to do</h3>
from <a href="http://wookware.org/software/cavearchive/troggle2design">wookware.org/software/cavearchive/troggle2design</a>
<pre>
forms
-----
1) members read/write folk.csv and year/members
2) cave read/write cave_data, entrance_data, surveys/pics
3) trips -> logbook , QMs, or surveys (more than one survey or location possible)
4) logbook reads/write year/logbook
5) survey
6) prospecting app
forms show who is logged in.
databases
---------
trips, read from
logbook entry
folder year#index
.svx files
description
QMs
members (cache from form)
caves
caves_data
entrance_data
storage:
expoweb
data/
cave_entrances
caves
descriptions
loser
foo.svx
</pre>
<h3>Yet more of Wookey's notes</h3>
from <a href="http://wookware.org/software/cavearchive/expoweb-design">wookware.org/software/cavearchive/expoweb-design</a>
<pre>
frontpage
---------
quick to load:
Links:
Caves number, name, location
Years
Handbook
Data Entry
Main Index
Slippy map:
Indexes to cave page
Cave page:
Access, description, photos, QMs, Survey
Years:
Logbooks/surveynotes/survexdata/people matrix
Documents
Data Entry:
Logbook entry
Survey data
Survey Notes
Cave description
QMs
Photos
New cave
Backend datafiles:
caves/
cave_entrance
cave_data
directory of info
years/
year/
logbook
pubs/
reports
admin/
lists
who_and_when
travel
jobs
surveyscans/
year/
index
#num
handbook/
(all static info)
Storage:
non-html or > 200K go in 'files' (PDF, PNG, JPEG, DOC, ODF, SVG)
convert small 800x600 version into website by default. (matching structure?
</pre>
<hr />
<ul id="links">
<li><a href="../index.htm">Expedition Handbook</a>
<ul>
<li><a href="../survey/index.htm">Surveying guide</a> - Overview</li>
<li><a href="../look4.htm">Prospecting guide</a> &ndash; Overview</li>
<li><a href="../rescue.htm">Rescue guide</a></li>
</ul></li>
<li><a href="../../index.htm">Expedition Intro </a></li>
<li><a href="https://camcaving.uk">CUCC Home </a></li>
</ul>
</body>
</html>