When developing a new piece of software ― as I’m doing with my Marked Birds Database ― there are always various features that the application has to have: the so-called ‘must-have’ features. Without these, the application is of not much value.
Further down the ranking are ‘should-have’ features which are not as essential as the ‘must-haves’ but still pretty important.
Lastly, the ‘nice-to-have’ features are exactly that: it would be nice to have them included but without them the software works just as well.
Over the last few weeks I have implemented 2 ‘should-have’ features and 2 ‘nice-to-have’ features in my database.
The should-haves are:
- Support for adding/copying/displaying up to 4 Markers
- Marker Templates with dynamic preview
The nice-to-haves are:
- Search by Marker: searching for birds of a particular project
- Submitted/received status indicators for an observation
4 Marker support
One of the actions of adding a bird to the database is specifying the number of Markers (usually rings) that the bird is fitted with. To keep things simple, I limited this to a maximum of 2 in the first version of the database. Any additional Markers had to be added in separate steps.
I knew that I had to increase this to at least 3 because that is the number of Markers used for a Dutch gull project of which I observe birds on a regular basis. I decided to actually increase this to 4 Markers because it seemed like a nice even number and it would make sense to simply duplicate the steps involved for upgrading the database while I was at it.
This change is most visible in the Bird Overview screen where all Markers that the bird is fitted with are now shown at the top of the screen. This makes it much clearer what bird you are looking at, especially when browsing the database.
Shown here is a Lesser Black-backed Gull fitted with 2 color rings (one coded, one un-coded) and one metal ring:
The other screen where support for 4 Markers is visible is in the screen for adding a bird, observation, Markers and Marker Events. It now has 4 tabs for adding 4 different Markers, so this basically means that when adding a bird (manually or by using a template — more about those later — or by copying an existing bird) data for up to 4 Markers can be entered.
This hugely increases the efficiency of the database because it means less steps to perform manually.
Marker Templates with dynamic preview
Using templates for adding birds and Markers to the system is a huge time saver and I was eager to get this feature implemented.
The use case is as follows: I regularly observe gulls that are fitted with rings of known projects, especially during the breeding season when visiting various gull colonies.
So when I need to add these birds to the database I know that I already have a lot of data available: the species, the colors and position of the rings, usually the name of the person who fitted the rings, and sometimes even the date and location where the rings where fitted.
It wouldn’t make sense to have to repeatedly keep entering the same information for each bird: it is inefficient, time consuming, open for errors and boring.
And even though it is possible to save time by copying the details of an existing bird, it involves having to search for it and possibly having to strip some data that does not apply.
It is therefore much more efficient to use templates with data that is already filled in.
The implementation of this feature could be broken down into 2 parts.
The easy part was creating a form for entering the data because that is basically what a database is for. It is also very easy to do in FileMaker.
The challenge however turned out to be in keeping the screen easy to read. The first version only contained text fields but that made it very difficult to scan the screen and to find the template that I was after. Because it is much easier to scan images than text, I included an option to add a photo as an example of what the fitted rings actually looked like.
This worked, but only up to a point: I did not have photos of every project that I wanted to create a template for and the photos that I had varied in quality.
I therefore wanted something much more generic looking, so I investigated if this could be solved through scripting.
There were 2 challenges to solve: showing a Marker in the color and position that is entered in the form, and showing the reading direction of the code on the marker (up, down, or horizontal).
Showing the color and position of the Marker was relatively straight forward by making use of some default functionality of FileMaker (conditional formatting, with which the color of a field can be changed based on data entered somewhere on the form).
The major challenge lay in displaying the reading direction. I found this a hard nut to crack but I am really pleased with the way it turned out.
It is best to just show you.
In the following video, a template is created and used for entering a new bird to the system.
In the next video, a bird is entered to the system by first searching for a template.
Searching for all birds of a particular project
The nice thing about buiilding your own database is the ability to create custom functionality as and when you need it.
This feature is a good example: at one point I quickly wanted to see all birds that were fitted with rings of a particular project. There are various easy ways of doing this in FileMaker, but I knew that this was going to be a returning task so I decided to build in an easy way of creating and finding these custom searches. Also, it allowed me to visualize the markers by using colors.
The feature is nothing more than a form in which criteria can be stored for performing a search for all birds that:
- Are of a particular species
- Have a marker of a particular color
- Have a marker with a particular inscription color
- Have been fitted with a marker by a particular ringer
- Have the marker fitted at a particular location
Any combination of these criteria is possible.
Here is a video showing how it works:
Submitted/received status indicators for an observation
After having observed a ringed gull, the observation needs to be sent to the ringer or ringing organization. In return, they send back the details of where and when the gull was ringed and sometimes they also send an overview of when and where it was observed.
When receiving this information, I like to update the database with it.
The more observations I make (to give you an idea: in 2013 I made nearly 1600 observations), the more time I need to spend in keeping track of which observations I still need to sent out and for which observations I am still waiting on a reply.
To this end I added 2 fields to the database that allow me to quickly see the status of an observation: one field named ‘Submitted’ and another named ‘Received’. For each observation they can both be given one of two states: Yes or No. Simple and effective.
To visualize both states, the text of the labels is automatically colored green when the state is set to Yes and red when the state is set to No. This makes these labels states stand out more when scanning the screen.
That is it for this update, I’m already working on some new features…