Building the requirements
I’ve been doing some initial work on the app now and have built the basics stylesheets and database tables to let me develop the app and be able to see what I’m doing. It’s important to me to be able to see some meaningful output as I work, and the initial CSS only took half an hour or so to knock up. Plus, I find it easier to keep good HTML coding in mind if I have an output model to aim at - I know the structure of the markup I want to put out and I can change the look of it to something a bit more professional once I’ve built the basic framework of the code.
The requirements text looks like this so far:
Overview
Birding Record is a tool to help birders keep track of the birds they see, the venues they go to and the birding trips they make. The software should be as easy to use as a paper tick-list, but powerful and flexible enough to be able to analyse records in whatever way the birder needs to get the most out of their hobby.
What it is
Birding Record provides:
- as many lists as the birder needs to record the birds they see
- for non-year lists, a simple tick yes or no which records the date seen
- for year lists, a tick to record yes or no, plus a ‘first date seen’ and ‘last date seen’ field for recording migrant arrival and departure dates
- bird records provide space for notes, and for users to upload their own sound and image files for each species
- venue records let you record details for the places you go birding
- journal records let you record notes and bird counts for species seen on each trip, and these can be linked to venue records to build up a detailed record over time
What it is not
Birding Record does not provide:
- field guide notes to help identify species—the aim is for the birder to record their own notes as they go rather than to provide generic information for them
- venue information for where to see birds
- wider migration records for species (although it is hoped that, with a big enough user population, we could collate results on a central site)
My first big decision
I am stuck on how to associate bird records with the lists they appear on. For each bird I would like to be able to record a number of lists, with a simple true/false record to show if that bird should appear as ticked on that list. There appears to be two ways to do this:
- Record this value in the Bird table - nice and easy but will require a more substantial update to add new lists as I’ll need to update every record in the table
- Record these values in a separate table for the list and provide a separate table for each list with each row recording the bird id and date ticked. Makes the queries a level more complex, but would allow for recording extra data such as date last seen and count
Database good practice leads to the latter, only recording the data for birds you have seen. The extra flexibility of being able to record additional data for each tick is promising, the only downsides being slightly more convoluted queries and a bit of overhead to create the table in the first place as it will need to be created with 500-odd rows to initialise the data for each bird. This seems like a small price to pay though, so I’ll build the structure like this, at least to begin with.