Posted: 19 April 2016 10:31
Back in 2014 I recorded in my blog that I was restructuring my data and revamping this website. Although a lot of hard work has gone into this since then, two years down the line the task is not yet complete.
However, the website that exists as I write this is an important step towards my goal, despite it only being a stop-gap measure. I had to make the jump now, or else I would pay for another year of web hosting that would not support the new website's technology. This is why I've been putting in a few 19-hour days to make the changeover as smooth as possible.
The site design has been simplified to make it accessible on a wider range of devices. This has been done using the Bootstrap framework. More information is available below in the long explanation.
I've also highlighted Placenames and Surnames in upper case in main page text. This is for two reasons. Firstly, it helps identify both faster on the page by making them stand out. Secondly it allows more precise searching of the database using the new search page.
There's still a lot of work to do across the entire site, but please bear with me!
This section is a heavy-going discourse on technology, web design and information management - if you're not well-read on these subjects, you may want to skip the rest of this page!
I have not carried over the Concrete Evidence database yet as I need to rethink how it works. The old version listed not only defence works within a particular grid square, but also incidents such as air raids. This has set me thinking in that the data is collectively about location rather than pillboxes and events.
In the same way, a model railway often starts out as a modest track laid out on the living room floor. Railway station buildings are then added to provide some context and a bridge for the trains to go under.
Then landscape formwork creates hills, valleys and rivers; a road gives context to the bridge. Houses line the road and a village is created; miniature scale figures populate this utopian settlement. Although the creator of all this will still proudly talk of their "model railway", what they have in fact created is a model world in which a model railway is one constituent.
My research essentially followed the same path; I started off with a focus purely on concrete structures. Pillboxes on their own, however, cannot tell much of the story. I needed to broaden my focus to non-concrete defence works and so slit trenches began to appear in the database. And then I needed to include features that no longer existed; this is where documentary research came in.
But even then, it was not enough to know where things were. I needed to know how the system of defence worked. This required me to research military units and aspects such as logistics, mobile reserves and artillery support.
This knowledge tells us far more about one particular period of time - but to tell the story, the same process needs to be applied for each time period. And so the project grows.
In so doing, we turn data into wisdom. Data is raw, essentially meaningless material and so we need to add context to it. For example, 135708 is a string of symbols that could mean anything. If we add context by associating it with a map, we have a location in the form of a grid reference. With context, the data becomes information.
If we add further context to this information such as recording a slit trench at that location, we have knowledge. We can then add other contexts such as a date, military units stationed in the area or perhaps a training exercise.
Using this knowledge we can begin to understand patterns and develop wisdom. For example, using both documentary and empirical evidence, I have the wisdom to know that upon finding a slit trench in the landscape, a wider search will often lead to finding more in the vicinity.
This new knowledge then goes into the database, adding further context and helping to build more of the picture.
It is the database at the heart of the project that allows us to record associations between pieces of data.
I launched this site in 2007; for one year beforehand, such data as I had on "pillboxes" (my coverage was exclusively concrete structures back then) was piggy-backing on what was then my main website, the now defunct nbcd.org.uk.
Moving to a dedicated domain left me with a problem in that my blog database remained on NBCD while most of my posts were devoted to pillbox things. At this point I was zinging data from NBCD using XML. To cut a boring story short, I shut down NBCD in 2009 as pillboxes had taken over my life. This meant that the blog database was moved over to join the many other databases on the pillbox server.
The pillbox thing was only ever envisaged to be a short-lived project, something liable to be killed off once my enthusiasm and ability to maintain the data subsided. To this end, I had originally created a database to hold data about pillboxes; it therefore had pretty specific field names relating to pillboxes. This database was known as Concrete Evidence and this was devoted to defence works of which I had photographs. I would then travel to sites and photograph what remained, which had been the dominant methodology of the Defence of Britain Project that was influencing me.
Then my subject interest broadened and I wanted to keep a database of war diary transcripts. This data didn't fit into a database structure designed to describe pillboxes, so another database table was created. (If you're not familiar with Access but know Excel, an Access database file equates to an Excel workbook; an Access table equates to a worksheet within a workbook.)
From this came yet another table, Documentary Evidence. This was a shadow of Concrete Evidence in that I was now using archive documents to list defences, not just those that I had photographed. As the transcripts table was in a separate database to Concrete Evidence, Documentary Evidence was created as a table in the Documentary Evidence database so the two could be easily linked using the relational model.
Now throw in a database for archive documents, and yet another to record the Order of Battle (ORBAT) and you have the nightmare that is being played out in the graphic at right.
Confused? This is the simple explanation! With this information nightmare I was getting bogged down. Each database needed its own data input/modify/delete functions and web pages to display the data.
Despite the 2010 reshuffle and reduction to just two databases (three, if you include the blog), things were getting overgrown, hence my spending a lot of time trying to rectify this mess.
From 2006, I was using Microsoft's Active Server Pages (better known as Classic ASP) to build my websites. ASP is a scripting engine that lets you hook up webpages to a database to serve dynamic data. My database was Microsoft Access.
ASP was what I was using at work at that time, so I had plenty of technical support in the office if I needed it. Despite ASP and Access being a bit of a dog's breakfast when used to build web applications, the technology has served me well for ten years.
However, ASP is antiquated and there's less support for it on the Internet since it was superseded by Microsoft's ASP .Net some years ago. The code is inefficient and over-complicated compared to PHP, which is an open-source technology. I now work in a WAMP (Windows, Apache (server), MySQL (database), PHP (server coding) environment.
PHP is a clean and simple coding language; my old ASP web pages used to require hundreds of lines of code. PHP achieves the same with far less. The PHP script used to build the webpage you're currently reading comprises about 70 lines of code and can display any record in the database; its ASP predecessor had 600 lines of code and only displayed blog posts.
I nearly made the jump to PHP in 2009 as my then job had me using it. Redundancy hit and my next job saw me back in an ASP environment, so it never happened until now.
As an open-source project, PHP has plenty of tutorials and support forums freely available online whenever I need help. The Apache server, MySQL database and PHP scripting language are completely free. Another big bonus is cheap hosting; my new package now saves me a massive £83 per year!
Back in 1998, my biggest web design problems revolved around making a website work in both the Netscape Navigator and Internet Explorer browsers. There was a secondary problem in working out what monitor resolution was most popular and therefore how wide to make your pages. 640x480 or 1024x768 pixels?
Nowadays, the problem is extended to mobile devices; your audience may be viewing your website on a 42-inch screen, a laptop, tablet or mobile phone.
There was an interim period where it was fashionable to create two versions of your website, a destop or mobile version. This could be achieved by duplication of your pages or by clever use of CSS (cascading style sheets) that determine style rules for page layout and presentation. Whichever method you opted for, you had your work cut out when trying to make a cross-platform, cross-browser, cross-device website.
For this reason, I've decided to forget trying to undertake a fully accessible and usable design myself, and have opted to use the Bootstrap framework instead. Bootstrap has been created by experts to provide a fluid web design that has a better chance of working across all devices than anything I'm likely knock up.
My design philosophy has been affected by mobile devices; the multi-column information-packed pages I used to produce are no longer relevant except on laptop and larger screens. The future is images stacked in columns with text, rather than newspaper layouts.
One of the key reasons for this revamp is consideration of the future. I've been amassing data for ten years now, and the project has become important in a way I could never have foreseen. Nobody else that I'm aware of is doing anything similar in East Sussex (or anywhere else for that matter) and people are telling me that my research needs to be preserved for the long term.
The move away from ASP/Access was necessary to avoid my data becoming lost in an unsupported legacy technology. The simplification of my data structure means that I no longer need to create extra databases; anything that can be described should be able to fit within the new schema. In other words, the data can now expand in any direction with minimal upheaval.
A large project run by the Council for British Archaeology (CBA) 1995-2002, collecting data on 20th century military structures submitted by a team of some 600 volunteers. The result was a database of nearly 20,000 records which is available online. The anti-invasion section of the database contains nearly 500 entries for East Sussex.
Generic term for a hardened field defensive structure usually constructed from concrete and/or masonry. Pillboxes were built in numerous types and variants depending on location and role.
Small, narrow trench designed to provide protection against shrapnel and other battlefield hazards. Technically distinct from a weapon pit (which was intended soley as a defensive position) slit trenches were also used as defence works.
A record of events kept by all units from the point of mobilisation. A diary's contents vary enormously from unit to unit; some give detailed entries by the hour on a daily basis while others merely summarise events on a weekly/monthly basis.
This site is copyright © Peter Hibbs 2006 - 2017. All rights reserved.
Hibbs, Peter Website revamp (2017) Available at: http://pillbox.org.uk/blog/244482/ Accessed: 30 May 2017
The information on this website is intended solely to describe the ongoing research activity of The Defence of East Sussex Project; it is not comprehensive or properly presented. It is therefore NOT suitable as a basis for producing derivative works or surveys!