Many thanks to all those who took the time and trouble to respond.
My recollection of Biobase was that it was simple, but rather inflexible and reporting was limited and that the main data file was vulnerable to being overwritten
I'm not interested in other taxonomic groups on Biobase.
As far as improvements go, it infuriates me when most of the information I want to keep in the "header" when I select SAVE HEADER disappears.
Basically there are a number of BDS recorders using BioBase and it is still the preferred data capture software for us. It mimics the recording card we use for all the life stages. However it is showing its age compared to other programs such as MapMate which are user friendly and enable multiple taxa.
As I see it the recording community need simple to use software for personal use that enables lots of records to be entered quickly whilst maintaining accurate data. This software needs to have good export and import facility to and from other packages along with possibility to query and report on the data. Recorder 2002 and 6 will form the main means of consolidating data at a regional or national level with exchange of data with NBN and Gateway.
Since ******* fell out with Recorder there has been issues with data exchange. I believe there is a Niche in the market for a front end software to Recorder. This is where BioBase could fill the gap.
Since 2001 I have been unable to view my distribution maps since an error message reading: A RUN TIME ERROR OCCURRED IN MODULE: FORM.DMAP_EXPORT occurred. I contacted Mike Thurner ON 2 October 2001 with the problem but received no reply. I have tried re-installing but to no avail. Can you suggest a remedy?
A lesser problem occurs when I initiate a new recorder No. It defaults to 30 then I need to change it manually. I have never been able to transfer data to Recorder!
Basically I use it to log mammal and herpetological records but I would consider using it to log more site details.
We use BioBase in two ways, as a system for local input and for our national databases. The requirements for these are similar, but for local use the emphasis must be on ease of use while for the national databases performance and the ability to input and extract large volumes of information are the priority. Compatibility with Recorder 2002, Recorder 6 and the NBN Gateway are becoming increasingly important. With Mike Thurner, we have put a lot of work into resolving issues with both uses of the system and it is now close to meeting our requirements, but there are still a few problems:
Installation - the installation procedure is too complicated and more than half our potential users never achieve a successful installation. The computer illiterate give up, and even if I install the system for them they are defeated by subsequent upgrades. I now issue the system on CD, together with our own user guide and installation instructions, but the failure rate is still far too high.
Installation to c:\access - this prevents some installations, where systems do not have space on the c: drive or have the hard disk configured to another drive letter.
Database management - switching between databases is risky as it is easy to make a mistake when copying biodata.mdb files in and out of c:\access\biobase, and at present I am the only lichen user who dares use multiple databases. The dos program used by new users to go live after using the test system is particularly dangerous, almost every user thinks it hasn't worked the first time and runs the program two or three times, resulting in the loss of one or other database. Many of our users never backup their databases because they are baffled by Windows Explorer (no, I can't see the problem either!), so any database corruption is a major disaster. Automated database backup and switching would make the system safer and less scary to use.
Performance - this drops off rapidly once the database reaches a moderate size, with any function that runs a query before bringing up a screen taking a very long time to get into. It is surprising which functions run a big query before even doing anything! On a small or elderly PC it just hangs. A non-Access version, equivalent to Recorder 6, may be needed if the system is to run large national databases, but there must be performance improvements that could be made within the present design?
Database size - most Access-based systems include the standard functions for compacting and repairing the database, and BioBase urgently needs these.
Scale habitats - these are very important in lichen recording but inputting them to BioBase is a real problem, most records with scale habitats have to be imported from spreadsheets. The process of selecting a scale habitat on input is time-consuming, an all too often the program crashes and BioBase has to be restarted. Editing a scale habitat on an existing record is even worse, as on a large database it can take a minute or more from clicking on the field to getting the input screen up. If the user gets impatient and clicks again, or moves on to another field, BioBase crashes.
Survey notes - some users have reported that the survey notes entered with records have later disappeared. This is happening so often to one user that he has to take a copy of Recmain out to a spreadsheet at the end of each session of work, so that he can use that as the reference rather than BioBase.
Multiple recorders - the requirement to identify a record with a primary recorder is reasonable but so much lichen recording is done by two or three people working together that an additional field to hold the other record Ids would be a great help. At present we have to put them into the survey notes, but this causes problems
Export - local users export their records to me on a regular basis, but they lose track of which records they have sent. If their systems could keep a note of the site and card numbers exported, with the dates, it would save a lot of wasted time.
Import - we do most of our bulk input to spreadsheets so we use the BioBase import functions intensively. More informative error messages would save a great deal of time investigating import failures, for instance a "duplicate record" message with a skip option rather than automatically splitting the card, and for any error a message giving the site ID, recorder, date and species code so that the offending line in the spreadsheet can be traced.
Record length - the restriction to 256 characters record length for import/export causes a lot of problems. Individual fields such as survey notes and record notes have the same restriction, so it is possible to input a record to BioBase that is valid within the database but causes the export or import to fail. The error message is "invalid number of fields in record", meaning that the end of the record line has been chopped off. If the export and import could handle a 512 character record, or even 1024, it would save me having to remove important information from records to cut them down to size.
BioExt is a powerful tool and I use it regularly, but it has defeated all but one of our users. I have run training sessions but without much success, and I can't see that we will ever get the less computer literate to use it. More standard reports, specifically for lichen recording, are needed. The Card List needs an additional column to show the number of species on each card.
The BLS lichen species list is updated frequently and I have to keep the central copies of BioTab in line with the changes. I have no idea what changes need to be made to the NBN table so the two are now out of step.
We have an export to Recorder2002 but it is so slow and produces a file so huge that I have never been able to test it, let alone use it for real! We need to define a procedure for exchanging records between the two systems using spreadsheets. This may be largely a Recorder issue, but if we could develop a standard spreadsheet output in the format required by Recorder that would help. I could probably do this using BioExt but haven't had time to look at it yet.
It would be very useful to be able to record Road Traffic Accidents and be able to retrieve them for each species and be able to segregate individual recorders records to enable me to produce mapping for them.
Rapid input - there is some interest in having a cut down site and record input function to use on a palm top. It would be used in the pub after a day out, rather than in the field, and could be a good selling point for the system. A similar rapid input function within BioBase for use on a laptop could also be popular.
In both cases the input should resemble a record card, with site and survey details at the top and then a checklist of species to be ticked if they were present, with adjacent fields to input substrate and scale habitat codes. We have a number of standard species lists for different habitats, such as maritime, woodlands, churchyards etc. If, like the Recorder rucksacks, these species lists could be customised for local use, even better.
I would like to see it link more readily with GIS software such as MapInfo as these are packages used by some who might benefit from access to or want to use the info. I tend to think records are more meaningful in a context that other data can bring.
Easier and more versatile import export procedures. I realise that the present options are not taxing but I find they do not always work and adapting data from other systems seems to be more difficult than I like.
Basically there were too many codes, which meant when creating import
options from spread sheets there was too much room for error and I seem to be very human!
Since talking to you I have had a look at your site and think some of my potential comments are already part of your thinking and I look forward to hearing of your proposed updates/ or redesign.
One significant change that you might find quite challenging is to persuade CCW and that may need to include JNCC that Recorder is not the only Option for SNCO's. Improving GIS compatibility could help with that but it is challenging prospect.
Another that could have come about, but I have overlooked since I last raised it with someone, is the use of OS mapping. Users of Recorder can get copies of 1:50K OS maps at a reasonable rate that facility may be of benefit?
Ability to import directly from spreadsheets.
More analytical capability.
A proper Windows Setup installation with Registry entries and an Uninstall procedure
Proper Windows Help files (with text from the existing User Manual)
Field data entry via Palm Top with location entry via GPS
Option of location entry from a map
Other location standards (e.g. Lat/Long) as well as present UK OS Grid and UTM.
A more modern looking user interface
A Recorder 2002 / NBN import procedure
Integral mapping with optional thematic set-up
Printing species labels for invertebrate collections
Run from other folder than c:\access\biobase
Run over network
Multiple District, Habitat, Recorder
Species entry using Synonyms
Coding for Absent (i.e. surveyed by standard method and not found)
Record duplicate detection and purge
Access to species lists to update changes of nomenclatures.
A more flexible system for altering or deleting records.
Adit produce a number of software packages used in wildlife recording and mapping, and you can find out more about these by following this link
AditSite