Philosophy
Several deliberate design choices have been made in ZDN that may confuse new users. Here, I try to explain why those choices were made.
Why can't I delete diets or food items?
A core concept of ZDN is that these are institutional records. If your hippo used to eat apples, and now you don't feed anyone apples anymore, you still used to feed apples. It's part of your record for that animal. For the same reason, you can only inactivate animal diets, not delete them. Someone may need or want to know that you used to feed apples to your hippos. You may get a new hippo in the future and want to copy an older diet for it.
Likewise, consider carefully before "overwriting" data with different data. For example, if you used to feed Brand X Unicorn Chow, and now you feed Brand Y Unicorn Chow, it may be tempting to just rename the food Brand X to Brand Y and maybe update the nutrient data. However, this will overwrite the historical data for your unicorn herd. It will look like they've always eaten Brand Y. If you want to go back and understand your past decisions, you will not be able to recreate the knowledge about Brand X you had at the time. A better path would be to create a new food for Brand Y Unicorn Chow and make Brand X inactive.
No. It is bad data practice to store active data in more than one location. Your institution almost certainly has a system for tracking body weights, and you would end up with two animal weight histories in two locations, which may or may not be the same. While ZDN could certainly incorporate body weights in many ways, it is a deliberate choice to exclude it from this program to prevent discrepancies.
Can I change the nutrient analysis units to my preferred units?
Unfortunately, not at this time - not in ZDN itself, and not in the Excel analysis workbook. I'm working on how to make that possible and it is likely something that will be available in the future.
Why Microsoft Access? Why not a web platform?
There are several reasons why ZDN was begun in Access, and several more why I've intentionally chosen to keep it there (for the foreseeable future, anyway).
- It was started in Access because Access is a simple, easy to use, easy to learn database program that nearly every Microsoft Office user has at their disposal. Although there have been many rumors over the years that Access will be discontinued, it continues to be released in every version of Office including Office 365 (the latest Office), and is still updated (although much less frequently than the rest of the Office Suite). Access is a long way from being dead, but it admittedly not the most modern or feature-filled database platform out there.
- Troy and I initially created it for use at Busch Gardens Tampa Bay. As other zoos started using it, it quickly became clear that no two zoos run their feed operations the same way. Zoos all have very unique blends of centralized and decentralized, food prep schedules, specific diet sheet formats they like, their own queries and reports they want to run. Over the years, I've incorporated many different types of workflows into the software and it is now extremely flexible and should cover most institutions without much work on your own. BUT, eventually, your institution will almost certainly want to modify something or create a specialized report. Keeping it as an Access (and, for the tech savvy - as an uncompiled .accdb file) allows YOU, someone with potentially little to no database experience, to easily build your own reports and queries, modify the existing reports, and make new buttons to run these new reports. That flexibility just isn't possible on any other platforms.
- Access is easy to learn. It may look intimidating at first, but if you are reasonably familiar with Office products and regularly use Excel formulas (as most folks working in nutrition tend to be), it's actually quite easy to make changes and do some really cool things with it. I've worked with many folks over the years, and usually within an hour or less of instruction, they are able to get going with making the changes they want. There is no other platform that a non-programmer could make changes so easily while still retaining the depth of features.
- I hope that as more people use it and develop their own features, that they will give back to the community and allow those features to be included in future distributions to benefit everyone. That also would be much harder with a different platform.
- Finally, I have hopes that this will eventually become integrated into ZIMS and/or other zoo management systems. Much of the design has already been incorporated into the wonderful nutrition module and touchscreen interface of Tracks. If other systems adopt its design, ZDN will get rewritten, so there seems little point in writing it for a new platform only to have it get re-written AGAIN. That seems wasteful of everyone's limited time and resources.
I don't like creating diets, then assigning animals to diets. I want to create diets for each animal, rather than add animals to diets..
One reason for diets, rather than animals, being the central organizing principal is that this was started as a diet prep system, and largely still centers around that function. Using diets as the organizing unit is more flexible for managing diets because often our animals change more frequently than our diets do (internal moves, accessions and deaccessions, births and deaths). Another is that zoo nutrition teams are often asked to prepare diets for animals who don't yet or may never be accessioned into a formal records system. We may prepare diets for animals expected to arrive in the next day or two or who may not be accessioned yet. We may prepare diets for animals being temporarily held while in transit or wildlife rehab animals. We may prepare fruit bowls for display, food items for summer camp kids to turn into enrichment, or even create hypothetical diets for animals being considered for our collection so that we can get a cost estimate. In ZDN you can create diets without animals, and this gives a great deal of flexibility in managing things like diets for animals before they are formally accessioned, or non-animal-centered areas such as aquaria, mixed species exhibits, or public duck feeders.
While there is a mechanism to take notes in ZDN about diets (both history notes when you change diets, and longer free-form notes at any time), it is assumed that records relating to individual animals would make the most sense to live in your animal records system alongside medical, behavioral, and other notes.
Why are the days printed on the left on paper diet cards? We've always had them on the right!
We did a lot of work to evaluate the layout of the diet cards, both in print and on-screen. We found, with hundreds of hours of data collection to support us, that it is much faster to prep from "days on the left" because you only scan down one column (days) and move your eyes right only for the items that occur today. If you list the food first (on the left), then you read every food, even if you don't need that food today, and then must scan every line to the right to see if it should be prepped today. Fundamentally, "days on the left" is about 25-35% faster than "days on the right".
< Uses
