Thank you all for your inputs and farewell!

I have a close friend who would be willing and able to explain to anyone who's open to hear it, what you all need to do to make the NRGRR Website and Database a reality and a working tool for you all.

And if anyone is interested, email me and I'll be more than happy to connect you. She could explain the needs and help with a lot of the implementation in a matter of minutes, hours, days, weeks, instead of the four months since my last writing here.

You need to understand CRUD in order to continue. Without that concept, even piggybacking on Delaware will only lead you to a future of modifying their work in order to fit your own processes.

CRUD is an acronym that describes EVERYTHING that can, should and must be done to all of the DATA you deal with as an organization.

CRUD... Create, Read, Update, Delete.

People must be identified in the organization to have OWNERSHIP of every part of the database. They will need to "govern" their data... manage it from "womb to tomb"... who's allowed to Create new data, who's allowed to Read it (access it for for daily operations, reports or whatever), Update it (input changes edit, correct errors, etc.,) and Delete it when the data are truly not needed any more (can be a tough decision...).

To achieve CRUD operation, you will still need to identify any and all kinds of data that any of you will need to manage... to CRUD.

You'll need to do that whether you pay someone to create your own database connection to your website or end up with a clone of Delaware's.

There will be a learning curve period whether you adopt Delaware's implementation or create your own. My belief is that, even if you adopt Delaware's, you will need to allocate time and resources to modify their system to allow for differences between their day-to-day operations and yours. That's a normal expectation. Anyone who "buys a solution" or buys into someone else's inevitably will find things that "don't match up just right and will need to be changed." Please allow time and resources to do that.

Again, the basic purpose of the website-database system is to provide tools to make the NRGRR organization operate more smoothly and efficiently so that the organization, as a unit, can better achieve its goals. From my perspective and observations, the primary goal is: Rescue Golden Retrievers from bad situations and migrate them to better ones. Period.

Everything else is a process or tool or resource put in place to help you all achieve that one goal in the fastest, easiest, least expensive ways

I will continue to do what I can in support of the organization, and so will Claudia, despite the detour in our lives we're now handling, but if you think you want any assistance from us, we will do whatever we can to help the organization and every individual who is part of it. We proselytize it wherever we go and you'll be finding some new volunteers checking in often as a result of our ongoing desire to assist. Our "detour" will take about a year or so, and we hope to be able to continue to participate in any ways we can.

Feel free to copy any of the images or code from the pages I've created and linked, above. In Internet Explorer, selecting View | Source will let you copy any HTML you might fine useful, and the code will point you to the addresses of any images I've used to create the pages. I'll be removing them from my personal site in about a month. Thanks!

Thank you all for your inputs and feedback!

As I said before, THE critical element in the beginning is the collection of as many data elements as possible... the bits and pieces of information which are vital to volunteers' doing their jobs quickly and easily, and we've gotten a lot of great feedback on that.

Rather than create more "sample web screens" as I did on the following pages, I want to refer you to a spreadsheet I've put together as a collection of those data elements.

Again, if there are any missing data points, please email me at the link above.

Also, please do not consider this a finished product either! Your inputs are still wanted and needed. In terms of the design of the database and web pages for input screens, that will be between NRGRR and the database/web-page designer. My intention was to try to help by collecting as much information as possible to give to the designer and also to give the NRGRR volunteers an idea of what "the world could look like" as we move into the future with new tools.

Look through the spreadsheet, print it out, make notes and give feedback to me, Claudia and the NRGRR leadership.

If you think more free-form text fields are appropriate, say so and the database/web-page designer can do that. The next steps should be finalizing the choice of contractor to create the database and prototype screens for your approval. And the first screens you see probably won't look like the ones I've put up here, but your inputs will define the finished product, and that's the way it should be.

Click this link to view a copy of the Excel spreadsheet... It may be displayed in your browser or in Excel, depending on your settings.

Some months ago, I heard about the "Database Project" for NRGRR and took a personal interest in it. I've played with databases a little over the years and I'm, by a long shot, not a database expert, programmer or designer, but I have some knowledge of what they can contribute to an organization like NRGRR.

I've got lots of experience, though, with "user interfaces," from programs to internet web pages, and I've seen some good ones and some bad ones and some terrible ones and I hoped to be able to contribute my skills to helping NRGRR develop a web interface that would make life easier for all of the folks who might use such a web interface as part of their volunteer work with NRGRR.

But for as long as I've been interested in this, the one major issue I've always seen is that databases are often designed by database experts without sufficient input and feedback from the real users who'll have to deal with it on a regular basis.

Living with, talking to and hearing some of the issues you deal with from Claudia, my wife, I've realized that, in order to create a successful system, the database must contain as much of the information or data elements as possible that you all need, while the user interface should present the user with a way to enter new data into, and retrieve any and all needed information from the database as easily as possible.

In my never-so-humble opinion, this is best accomplished by starting with a LOT of feedback and documentation from the real users as to what data do they need and how do they use it as part of their volunteer work. But the data aren't all. When you start to create a list of what information is used and needed, it soon becomes apparent that there are data that are connected or related to other kinds of data in such a way that a well-designed database and user interface can take a lot of the work and pain out of bringing it all together.

So, I'd like to suggest a starting point or process that I believe will help NRGRR implement a friendly, effective combination of database and web-based interface.

First a few words about the ingredients, for those not familiar with them...

A database is a computer program. It manipulates pieces of data stored on a disc or in computer memory according to rules that it's been programmed to follow. The database designer sets up the rules based on what pieces of data are related to each other and how they're related.

You actually know how a lot of the data are related based on your experience in doing your volunteer work already. But that knowledge and experience has to be translated into a collection of "how all those things are related" for the database designer. It's a grind to start that up, but well worth the investment of time and effort.

Next, the "user interface" is something most of us have seen on a regular basis... it's the screen or screens we see on our computer screens when we go to any website.

But the user interface is just "another program" which does nothing but display stuff on your screen as it's delivered to your computer from its internal disc or memory or over the internet.

And the browser that "paints the picture on the screen" simply takes what it gets from the computer and translates it into what you see.

Call it, if you will, a "display engine." It's smart enough to interact with the database, though, so if you enter a name into a text field or click on a button or a pop-down menu, the interaction may actually communicate with the database software to serve up the current information for you.

Oh, and while the browser runs on your desktop or laptop, the database and all other programs can run on any computer anywhere, so long as it's connected to the internet. That's all that "cloud computing" really means. Years ago, in the infancy of the Internet, computer networking people would draw a fluffy cloud to represent the Internet, because as long as a computer could connect to and "talk to" any other computer on the Internet, it didn't matter (and still doesn't matter) where it is. It can be next door or halfway around the world.

So, now what? I suggest that leaders from each and every function in NRGRR get together with Claudia and their teams to go over what kind of information you use in your volunteer positions. Each and every kind of bits of information you use, when you use them, which ones are needed at certain times and in which order, and how they relate to each other.

Collecting and organizing that information will be the basis of the design of the database as well as a great starting point for the programmers to design the screens you'll be seeing, too.

Some information will be used by some people and others will have no need to see or interact with that data in performing their jobs. Much of the information will be useful and should and must be shared and made available to a range of users. You will all get to define what those rules and limits are.

For example, the database and other software will save and protect all necessary bits of information used during the Intake, Foster and Adoption processes for all dogs, and lots more.

Privacy and security of the data will be provided, yet allow members to access the data, as appropriate to their roles in the organization.

A lot of paperwork and phone calls to verify, share or track down information should be reduced when the system gets rolling.

There might even be a few new pages on the web site that will allow folks outside the organization to fill in applications or provide information directly which is now done by mailing and photocopying paper forms. Almost nothing you can think of is impossible to implement if it's already part of what you do.

Now for the nuts and bolts... There is a lot of planning needed to lay the foundation for the database and user interface.

Basically, every major process of the organization must be described in detail, defining what information is needed at any time during events like Intake, Fostering, and so on. Each piece of information needed at each step must be identified, as well as who should have access to it in order to Input it, View it or Change it.

As the various steps in each process are listed, they can be translated into web pages where the data can be Input, Viewed, or Modified, as needed.

The database and its associated software can "fill in the blanks" with some data if it's already known or provide the means to enter new data as it becomes available.

Contact information for resources can be displayed with a few clicks of a mouse.

You will be invited to provide your knowledge and experience to make sure no data points or vital steps in any process are missed and that the web page screens are User-Friendly and complete.

And the whole thing will be open to modifications and improvements in the future!