FAQ

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.

Can I see my animal weights in Zoo Diet NaviGator?

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.

Why Microsoft Access? Why not a web platform?

There are several reasons why ZDN was started in Access, several more why I've deliberately 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, and their own workflows. 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 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. Another is that zoo nutrition teams are often asked to prepare diets for animals who don't yet or may never exist. 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.

Another reason is that ZDN is fundamentally a food prep and diet record system. If animals are fed as a group, then they are treated as a group in ZDN. Individual animal information would be kept in your animal records system, not here.

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

> Installation