Upgrades to the Canoe-Camping Club Website

There have been several recent upgrades to the Club’s website. In the Spring of 2003 we introduced a Bulletin Board. This means that you can communicate easily with fellow members on topics like "for sale", "wanted", and on information about rivers.

In July 2003 we moved the website to a different host which was claimed to be 40 times faster. It may well be. It really is fast.

On the first of September 2003 I reset the counter, which clicks up by one on each visit.

In November 2003 we worked through all the web pages on the website – well over a thousand of them – with a fine tooth-comb, bringing the way the documents are constructed up to the best possible modern standards. This standard is called "xhtml", and that is what we are aiming at, though it took a few weeks before the process, which is quite arduous, was complete. The basic work took a good week.

The reason why there is now a definite and strict standard (called "xhtml"), is because the earlier internet browsers had only a simple task to carry out, so they could afford to be a bit easy-going. Since then browsers have been expected to be capable of all sorts of clever things, so they have had to introduce a little discipline. Reasonable enough, really. Luckily we can do it all without losing anything. To save people who would like to take over the job of webmaster having to ask me what the differences are I have appended the principal ones at the end of this web page. They are really very simple.

I have put on the Bulletin Board a notice explaining how you can use this vast collection of previous articles from our magazine to find – very quickly and easily – what our members have had to say in the past on rivers they have canoed, or on any other topic. This works as though a search engine was actually on our website, and is astonishingly powerful.

During the year 2003 we gradually expanded the use of Cascading Style Sheets, so that there is a distinct and common style to the text pages. A universal change in style can be made by changing perhaps one line in the style sheet. This move also makes the various text files shorter and quicker to load, so it is a good step forward.

Somebody at the AGM in early November 2003 questioned why we had so many articles on the website. The reason is because the information that somebody someday may require is in those articles, and we want them to be accessible. It is interesting to note that because some browsers are beginning to be a bit strict, some of the magazine articles on our website may not have been accessible recently, but we have now put that right.

In September 2003 I spent two weeks upgrading the Tower Hamlets Canoe Club’s website. This was approximately twenty to thirty times smaller than ours.

I am always looking for ways to make the whole website more easily navigable, especially by people who find the mouse a bit hard to use accurately. There are standards for improved disabled access to websites, and I have been working on bringing the whole website up to them.

In recent years, while creating the contents of the Club's quarterly magazine, I placed each article on the website as soon as it was ready to be seen. The Committee and a few others were notified, and enough of them read the articles and made comments for this to be really useful.

In January 2005 there was an incident in which a hacker gained access to the entire hosting computer. What s/he did was comparatively harmless, and only the index page of the bulletin board was affected. It was replaced with a strange but harmless image. Luckily I maintain backups of the Bulletin Board, and the website was quickly returned to normal. The other three websites that I manage were similarly affected, but one of them took some hours to repair because it relies extensively on index files, but otherwise all was well. The Hosting Company sent their apologies and took steps to ensure that hacks of this kind can never recur.

At the time of writing, March 2005, I have reviewed how we fit into the requirements that the Camping and Caravanning Club places on the websites of its sections. I am happy that we are within their requirements, but I consider that these requirements should have included the following further clauses:

The language used should be xhtml and not html. This is to be forward compatible with international requirements.
The website should not rely on Java, Javascript, or other languages and scripts. This is to avoid malicious and opaque code.
All filenames, and references to filenames, should be in lower-case.
A moderator should be appointed by the committee of the section.
If there is a Bulletin Board it should be protected as far as possible from attacks. For instance it can be placed in a folder not called cgi-bin.
The moderator and the webmaster should each review the Bulletin Board on a daily basis, if possible.
The webmaster should review the website's control panel on a daily basis, if possible, paying special attention to the error reports.
The webmaster should maintain daily (if possible) online backups of the Bulletin Board.
The webmaster should maintain monthly offline backups of the whole website.
The moderator should have immediate access to the maintenance panel of the bulletin board.
Every separate page should have a short but meaningful title, which will appear on the top of the browser screen.
Every effort should be made to ensure that disabled access is as easy as possible.
A copy of the original email from the Hosting company containing the username, the password, and other login information, should be held by a third party, other than the webmaster and the moderator.

There are about a dozen items to attend to when nudging a web page into xhtml. I can give you a short list of the most pressing ones here.

All markups to be in lower-case, eg <p> and not <P>.
All markups to have a matching end, for instance <p> ... </p>
All markups must close in the reverse order to that in which they opened.
Certain markups do not have a natural matching end, for instance <br>, <hr...>, <meta...>, <img...>. These must have a pseudo-end inserted, as <br />, <hr... />, <meta... />, <img... />
Between <html> and </html> there must be a <head>...</head> and <body>...</body>, but the latter may be substituted by the deprecated <frame> etc.
The first line must be a DOCTYPE declaration, as seen in my renditions.
The first item after <head> must be <title>...</title>
All qualifications, for instance those following <table must be in lower-case, and the values of the qualifications must be enclosed in double quotes.
If there is a qualification that does not have a value it must have a pseudo-value, for example value="value" — I have not come across one of these.
Control of how things are displayed should ideally be down to a cascading Style Sheet. This aquatic-sounding entity is actually much simpler than it sounds.
In order to have different display rules in different parts of the page, the body of the xhtml text should be divided into <div...></div> differentiated by the qualifications named class. For instance the ones I use are
<div class="dochead">...</div>
<div class="bodytext">...</div>
<div class="navigation">...</div>
<div class="signature">...</div>
<div class="toc">...</div> (table-of-contents, as used with frames.)
Internal references should use / and not \ when giving relative folders.
External references should always start "http://..." and should always be in lower-case.
Within the text 8-bit characters should be as £ and not as £.

There are a few more things, but the above are the most important and the easiest to grasp the meaning of.

Upgrades to the Canoe-Camping Club’s Website