Setting Up a Plant Record System: the Bristol Zoo Gardens, U.K.
Volume 3 - June 2003
Bristol Zoo Gardens (BZG) was created in 1836 to study zoology, horticulture and arboriculture. In recent years our horticultural focus has widened from ornamental displays to include more conservation and education work and help achieve our mission:
to maintain and defend biodiversity through breeding endangered species, conserving threatened species and habitats and promoting a wider understanding of the natural world.
We grow a variety of plants for amenity, conservation and education purposes and hold the National Collections of Hedychium and Caryopteris (under the auspices of the UK National Council for the Conservation of Plants and Gardens). In our 1997 Gardens Department Strategy we highlighted the need for an effective plant record system. This was vital if we were to develop our botanical collections to the existing high standards of our amenity displays. At that time many of our Garden staff had limited formal horticultural training or understanding of plant nomenclature and we lacked the necessary PC facilities and skills to operate a computer-based system. Since then we have made good progress in addressing these problems.
A record system is the whole process of collecting, recording and producing plant data in a methodical and structured manor and not an “off the peg” piece of software. As with any system the setting of standards and continual monitoring are important.
The software we chose was BG-Recorder, which is supplied free to members of BGCI. We began work in 1997 with their DOS-based system and consequently were one of the first users of the BGCI Microsoft Access Windows-based system in 1999. The DOS system was not easy to use but we learned a great deal during that time which helped later with the Windows version. We know now that new users of plant record databases seem to struggle and commonly encounter some problems. This became apparent at the First PlantNet Plant Records Conference in May 2001 (The Plant Collections Network of Britain and Ireland). Several speakers including myself talked about various software packages and their associated merits. It was interesting that in all the packages the same problems kept emerging:
- the packages available are designed for a wide user-base so tend to be quite complicated to cover all needs;
- users found that they had made basic errors when selecting their plant mapping/location method (e.g. what is best - a bed or grid system?);
- users may need to update and change their packages as their needs change;
- poor documentation of changes made to the package causes problems for later users;
- resources needed to manage plant records were often underestimated by organisations new to plant record keeping e.g. time, training;
- poor manuals and lack of back-up support are a problem-especially when things go wrong.
The only two institutions in the UK which were satisfied with their databases had independently designed systems, while those using standard software packages complained that they were not easy to use. This is probably because the database packages were designed for a range of users with differing needs, which is bound to make them more complex than a dedicated system. However, plant record database programmes such as BG-BASE and BG-Recorder ensure a degree of standardisation. For instance, they use the International Transfer Format for Plant Records which ensures compatibility with other organisations or systems.
Refining the System
My conclusions were:
- if we were to have a quick easy to use database, we would have to do some development work ourselves;
- we needed to make some organisational changes to our Gardens Department.
On the strength of these conclusions we made the following changes.
Development of BG-Recorder is something that BGCI encourages so we decided to create a new interface to filter out and include information as required. By using BG-Recorder we saved valuable development time and kept the international standards and adaptability. We analysed our information needs and therefore what we wanted to record. Our needs are fairly simple so we arranged all the input information on one form (form on one screen); we then did the same with the output. By doing this we have saved operator time, as previously we had to input information on several different forms which proved very time-consuming. We were ruthless about what to include and only added information specific to the Zoo, such as poisonous plant information and a camera icon with a unique number which shows if pictures of the plant are available. We separated information on dead plants to create a plant virtual “dead book” that is accessed from the main menu, as we are generally more interested in our living specimens. Finishing touches involved writing manuals describing how to input and retrieve basic information and personalising the look of the system that we re-named Bristol Zoo Gardens Plant Register.
We obtained basics such as a dedicated PC, office space and allocated time to operate and develop our Plant Record Keeping activity. We chose a PC operator and a number of staff received basic training in both Microsoft Access (on which BG-Recorder is based) and basic PC skills. In addition some staff visited BGCI for a day to gain more information on the system.
We selected a suitable mapping system and developed a method of plant name checking. Then ensured everyone involved with the Plant Record System knew their responsibilities within the system. We changed staff job descriptions to reflect this and began the never-ending process of Plant Record System refinement and staff education.
So Far So Good
Continued commitment to the system and maintaining a focus for its intended use has been vital during the development process. The process of refining the plant record software is problematic and can be extremely frustrating. There is nothing worse than spending a great deal of time on something and then finding you must back track as happened on a number of occasions during software development. At the time this seems like wasted effort but on reflection it is a necessary part of the development process. The results are encouraging, as we are now happy that the system works well for us and we still have the reassurance that BG-Recorder is intact behind our new user interface. In our case it was worth the effort as there is no other practical alternative available to achieve what we wanted.
Thanks are due to Sarah Horne, Mike Adams and Andrew Gardiner for developing the software changes.