in my school life to build a parent volunteer database. The need there
was to have something simple and web based where volunteers could fill
in their own info (contact data, skills, etc.), but to make that data
easily accessible to volunteer coordinators. I'm not sure if the Zoho
Creator app survived long after I handed it off to the main volunteer
coordinator, but she seemed to get the hang of it easily enough.
FileMaker would have been inappropriate there, because the webform and
distributed access were more important than rich structure
(ultimately, it was a cloud-based spreadsheet with related forms, not
unlike a google doc).
For the FM route, I'd maybe recommend starting with one of the many
templates provided in the application (like Event Management, or even
just Contact Management). Whatever you do, keep it SIMPLE. while you
and I can see all the benefits of a robust relational DB (connecting
volunteers to events, storing multiple email addresses, running
elaborate reports, etc.), your Parent coordinator is coming from a
different place (a word document). Just being able to put things in a
structured place and perform searches is already a revolution in
functionality. If you have FM server, I'd recommend leveraging that
asset and hosting the solution for them, so that you (or they) can
make tweaks as you go, and so that the data can be easily shared and
backed up. Probably most of what you need to offer can be provided by
FM instant web publishing, or through FileMaker GO on an iOS device,
so you probably don't even need to supply full FM licenses to the
parent users.
Per Lavina's point, I'd say little databases (I sometimes call them
"disposable databases") like this should be allowed to grow
unfettered. There is a space between excel and Oracle where humans
need to organize data and can't wait for the perfect web 2.0 offering
to fit the bill for them. If a database becomes unmanageable, it's a
sign that a piece of organizational workflow has grown to the point
where it needs thoughtful consideration and possibly resources. If you
get to the point where you need to scrap a small database and start
fresh in something larger, you're no worse off than you would be if
you were scrapping a disjointed collection of excel spreadsheets and
word docs. The key is managing expectations. Ideally, you should have
someone (an outside consultant, group or in-house developer) ride
herd on these things as they grow and advise you on how and when to
expand them or kill them, but if you don't, then IT just needs to be
very hands-off. Show them the product, give them some pointers, point
them to some learning resources, and step away, or better yet, route
them to an office assistant who knows enough FM to be dangerous and
let them go to town on it.
My (somewhat biased) $.02
Peter Vinogradov
On Sep 8, 2010, at 9:18 AM, Richter, Lavina A. wrote:
> I would be wary of database development by someone who may neither
> document nor stick around to support its use. What about a simple
> Excel
> file/Word merge process? Is that what you're already using? If you
> do
> go the database route, I'd choose a mainstream one --FilemakerPro or
> Access, for example -- and insist upon documentation (what data is in
> what table, what each field name really means, etc.). We placed a
> moratorium on database development a couple of years ago because it
> got
> so out of hand around here. IT kept "inheriting" databases that were
> orphaned and it took a lot of time analyzing and supporting them.
> That
> having been said, you can do more with a relational database than you
> can a spreadsheet. Have you asked your volunteer what functionality
> is
> missing in the current setup? Perhaps that will get at the root need
> that spawned the request in the first place.
>
> My two cents, Vi
>
> -----Original Message-----
> From: A forum for independent school educators
> [mailto:ISED-L@LISTSERV.SYR.EDU] On Behalf Of Dave Baker
> Sent: Friday, September 03, 2010 4:52 PM
> To: ISED-L@LISTSERV.SYR.EDU
> Subject: Filemaker solution for tracking and managing parent
> volunteers
>
> Hello,
>
> I was recently contacted by a parent who would like to track our
> parent
> volunteers in a database, instead of the word-processed method used in
> the
> past. I'm am comfortable developing in FMP, but don't have the time
> to
> take on this task; however, I could adapt an existing solution if
> anyone
> had one to share. Direct replies will be summarized and posted back
> to
> the list.
>
> Thanks,
> Dave
>
> David Baker
> Associate Head
> Dean of Technology
> Mount Tamalpais School
> http://www.mttam.org/
> dbaker@mttam.org
>
> [ For info on ISED-L see
> https://www.gds.org/podium/default.aspx?t=128874 ]
> Submissions to ISED-L are released under a creative commons,
> attribution, non-commercial, share-alike license.
> RSS Feed, http://listserv.syr.edu/scripts/wa.exe?RSS&L=ISED-L
>
> [ For info on ISED-L see https://www.gds.org/podium/default.aspx?t=128874
> ]
> Submissions to ISED-L are released under a creative commons,
> attribution, non-commercial, share-alike license.
> RSS Feed, http://listserv.syr.edu/scripts/wa.exe?RSS&L=ISED-L
[ For info on ISED-L see https://www.gds.org/podium/default.aspx?t=128874 ]
Submissions to ISED-L are released under a creative commons, attribution, non-commercial, share-alike license.
RSS Feed, http://listserv.syr.edu/scripts/wa.exe?RSS&L=ISED-L
