Talk:Events Database

Quick and Dirty Roadmap

To echo Richard - writing the code will be the easy part. Making decisions about form, functionality and features will be much more difficult since they will take careful consideration and will evolve as the project nears completion. (JTE)

Easy is a relative term. I think the planning can be focussed and completed in a relatively short period of time. It is crucial to do right, however, and all the stuff that comes later relies on it. At Free Geek, getting people to follow through and finish writing the code has been the more troublesome thing to accomplish. -- RfS

There are three code deliverables:

1. The web interface that the public will use to signup/request information/etc. This will require several web pages but will be the easiest to build because the options the user has will be relatively simple. It's important to get this done first because of the relative simplicity on the "front-end" of the front-end.(deciding what form it should take and what it should do).

Requests coming from outside FG don't have access to our internal database, but it'd be nice to have this (whole project) integrated into our current database (to access contact information, etc.) Therefore, there might be a public form that sends a request to someone at FG, and an internal form that talks to our database for actual scheduling. --RfS

2. A data-query tool to run reports, harvest contact info, add notes, etc. While this could be a web-app, it wouldn't be a pretty one. I envision a stand-alone GUI with A LOT of controls given the specs that have already been outlined. The query-tool will have two parts - the design of the interface and once that's decided, implementing functionality (hooking it up to the db).

Web apps for this kind of thing aren't all that inappropriate, IMHO. The difficult thing to do with web apps is provide a nice user experience for data entry. --RfS

3. The database. Designing the database will be much easier once the first objective and the design of the second objective are settled. There's a BIG difference between being easier and being easy though. The database will be the engine that drives the project and until the first two objectives are solidly defined, subject to constant tinkering. Knowing WHAT we want the DB is supposed to do will be the hardest part about about writing it.

Completely agreed. But even scribbled out screens and reports make this much easier. -- RfS

I'll put together mock-ups of the first two items and distribute them to stakeholders sometime this week. My mock-ups are NOT to be considered work in progress or attempts to complete the project. In my experience as a coder I've learned that it's a lot easier for a group of people to share a common vision if they're looking at the same thing. Mock-ups are intended to get the conversation started. JTE--192.168.254.89 19:44, 22 Jan 2005 (PST)

Excellent! I'll poke everyone who might use it and get their input. --RfS

Implementation Issues

The first step for this will be to outline all the needed screens and reports for this new module of the database.

Then we look over it all and figure out what tables need to be altered or added to support those screens and reports.

Then we write the SQL that can make that happen.

All of the above should not take too long or be too difficult, but should be well thought out. It all ends up making changes to the underlying data structures.

Finally, we need to write and test the code that talks to those data structures. Some of it is already in place (like the contact information), and some will need to be written from scratch. At this point, it's good to know what's most important, so we can prioritize the parts that need to be done first, adding the other stuff later on.

rfs 18:45, 22 Jan 2005 (PST)