BGR site update

In the BGR data thread I mentioned that there were some big updates on the way. Well some are here...

New ratification form

Since I took on the role of membership secretary, ratification has been via an Excel spreadsheet filled out by the contender and sent to myself. It evolved over the years but essentially it was still a spreadsheet and required about 250 - 300 different cells to be filled in with data - most of these were timings at each summit. A lot of work on the part of the contender.

From my viewpoint the spreadsheet was limited in that there was no way to enforce data validity - I couldn't use VBA macros since there was no guarantee that the user would actually use Excel to fill in the form. As a result the form had quite a lot of text stating things like: "Enter a list of membership numbers of those successful rounds you have helped on, no other text" and people would put "1234 leg 1"!! Not what was asked for, the excuse being "I thought it would be helpful". If it was going to be helpful we'd ask for it :mad:

Browsers have moved on (a lot) and many features that used to be provided by third party software are now built in. This allowed me to start afresh and build in traps for incorrect data etc and make it a lot easier for the user to enter data. A lot of the data (existing member info, prolific supporters, club names) is already available on the site, the form just needed to be able to access it.

The new form thus pulls in:

• Some personal data from the registration process
• Basic round info, again from the registration process
• Optionally lets the user upload GPX files or tracker data.
• Gives access to the membership list data and the supporter list data

Typically a user will only have to enter their age, postcode and club for personal data. Uploading tracker data or a GPX file fills in all their schedule data and completes the round info. Having access to the data lists means many only have to enter a membership number or surname and click a box or two to list their support team along with details of existing members they may have helped or are related to. A couple of clicks and the form is generated and downloaded.

Membership search

The search facility on the membership lists page was, to put it kindly, a little basic. It was what I could easily put together using the tools at the time and just let you search by year, surname and club name. When someone succeeds on the round I send them a questionnaire asking what worked, what didn't and what new features they'd like to see.

One feature requested by about half a dozen people was "I'd like to be able to see the entire membership list in one". This didn't make sense, even on a large screen I can only get about 40 rows at a time on screen. That's currently around 80 screens worth! Asking the terrible six just exactly what it was that they wanted, I got just one response which boiled down to: "a better search facility".

This was much easier than I anticipated - I'd already written some of the building blocks when doing the new ratification system - a couple of hours had the user interface mostly sorted and a further morning saw most of the back end stuff done. Each field/column has its own set of tests that make sense for the data. There's no limit to the number of tests that can be applied so you can really drill down into the data. The search "widget" also allows the user to sort the results how they see fit.

Then feature creep set in!

I added a similar facility for pacers/support.

The set of columns I'd chosen for the membership list results table was really just a "best guess". Some people might want different columns or different sets of columns depending on what their search was. No point in listing a club's name if your search was to look for a specific club, it's just using up screen width.

So a "User options" page was added. There's a few minor items but the main one is that the user can drag and drop columns to create the table they wish. Again they can save each configuration with a name which can be used to associate a specific table layout with each named search.

I added the ability to save searches with a suitable name. The code also automatically remembers a user's "last search" for them. That then ran into a problem - Apple Safari deletes a site's stored data after seven days if the user doesn't use the site. This is down to advertisers abusing the feature. That lead to looking at storing user's data on the server. There's no easy way to do this for simple site visitors but for registered contenders it's relatively simple.

So now the code automatically stores the user's data locally and, for registered users, copies it to the server (potentially sensitive data like email addresses and phone numbers are removed before being uploaded). When a user logs in, the code checks to see if their data is on the server and if so downloads it. This means that if a user logs in to a second browser or device they get data synchronisation.

Phew! Apologies for waffling on!