After many years of suffering with partial solutions for contact management, I developed a two-file solution exclusively for Libertarians. Since then I realized a twenty-nine-file solution would be more flexible and comprehensive. Candidates may need as many as twenty-six of those files. If different telephone carriers are not used to minimize calling costs, then two files are not necessary. If networked, the National and State organizations each only needs one file.
LOCATEM is intended to be a comprehensive solution that leaves no one complaining that they wished there was another telephone field, or a date and time stamp button, or a way to sort members or registered Libertarians by street number or carrier route to facilitate petition drives or sign distribution. It may seem overwhelming to the uninitiated, adequate to the experienced, or minimal to those with scares fresh from the political information management battle.
After running for office five times (Assembly twice, Representative twice, City Council once) and auditing the Libertarian Party of California database system, I arrived at the need for LOCATEM. It can be readily extended to handle additional requirements that I did not foresee, or that may subsequently arise. For example a Libertarian Party 'Yellow Pages' directory of libertarian businesses.
Libertarian candidates and activity organizers as well as Region, State and National Party organizations need strong database tools if we are to be sufficiently organized to become the largest Party. They all have special needs and often can't wait for data to be extracted from a centralized database. Each only needs to maintain data about resources in their area.
Centralized data is risky. Data distributed redundantly mitigates loss. Candidates are invariably unhappy with the response of Regions, Regions with State organizations and States with National. National doesn't trust State organizations to accurately maintain data. State organizations are afraid marginal Regions my cease to exist or otherwise lose data. If the data is redundantly maintained at all levels, everyone is happy. If all levels utilize copies of the same system (less the databases they don't need), they can more readily import new and moved member data accurately using matching field names.
A web-based system is proposed because practically everyone knows how to use a Web browser. While the National, State and the larger Regions may want to collocate servers at Internet Access Provider facilities for improved responsiveness, anyone with a cable or DSL modem and a permanent IP Address can support a Web server.
The portal hierarchy of databases can be maintained across the Internet, so National can see information in State databases, which can in turn see data in Regional databases. Portal values can be displayed in popup selection lists. If that is considered a security or privacy risk, then the data must be periodically exported, compressed, encrypted, FTPed or Emailed, decrypted, decompressed and imported. This process can be automated with scripts, but that poses a maintenance burden as IP Address and file locations change.
The automated calling function and formatted printing/FAXing features cannot be used via the Web, so the databases may be provided as runtime solutions for both PC and Mac users so they will not have to buy the database program. They only need a modem to utilize the call button. Similarly, the Region, State and National sets can be provided to those organizations for local use.
LOCATEM consists of a maximum of twenty-nine related databases. References to "buttons" are graphics or text that can be associated with the execution of a script either as Web form buttons or local database window buttons.
|
# |
Database |
Fields |
Relations |
Reason for DB |
Scripts |
|---|---|---|---|---|---|
|
0 |
|
Person ID to Person.fp4 |
Restrict access to any database to Members only and indicate who changed what where. |
||
|
1 |
|
Each state organization needs to know about its Regions. National will have officers, candidates, activities and access constraints unique to it, |
|||
|
2 |
|
|
Each state organization needs to know about its region organizations. State organizations will have officers, candidates, activities and access constraints unique to them. |
||
|
3 |
|
|
People move among Regions and Regions are redefined. Only the IDs need be changed to establish the appropriate with a prospect, registrant, member, volunteer, contributor... Regions need to know about their members. Region organizations will have officers, candidates, activities and access constraints unique to them. |
||
|
4 |
|
|
Although there is normally a one to one relationship to Regions, it may be one to many or many to one. |
||
|
5 |
|
|
By relating various voting districts to precincts, the voters in each district can be determined. Districts may be allocated to Regions. |
||
|
6 |
|
|
By relating various voting districts to precincts, the voters in each district can be determined. |
||
|
7 |
|
|
All political and appointed offices available in jurisdiction. |
||
|
8 |
|
|
ZIP Codes are a useful way to find and allocate resources. |
||
|
9 |
|
|
Important for bulk mail and signature gathering purposes. |
||
|
10 |
|
|
Automate the use of different carriers to reduce calling costs by mapping area codes and prefixes to carriers. |
||
|
11 |
|
|
Telephone area codes and prefixes can be a useful way to find and allocate resources. |
||
|
12 |
|
|
Contact descriptive information useful for searching and resource allocation. Candidates, petition drivers and those conducting other activities will have access constraints unique to their purpose. Members can maintain their own contact information, relieving Regions of the burden. To avoid problems, each entry must be for one individual, e.g. no Mr. and Mrs. Related individuals in families using Relate.fp4. Mailing option will concatinate names at the same mailing address to minimize mailing costs. Dates are split to facilitate notifications, e.g. renewal and statistics, e.g. member age. |
Find all records with Renewal Date < value and > value. |
|
|
13 |
|
|
Persons can play many roles |
||
|
14 |
|
|
Need to sort on Street Number or Carrier Route to optimize signature gathering. Many people may share the same street address, which is important to optimize signature gathering. |
||
|
15 |
|
|
Many people may share the same postal address, which is important save money on mailings. |
Make mail address same as street address Find all Persons of Type at the same address. |
|
|
16 |
|
|
Many people have many telephone numbers and may share the same telephone number(s). |
New button creates new Phone.fp4 record. Delete button deletes current Phone.fp4 record. Dial script button dials number using carrier number if present and area code if different from Local Area Code. Date and Time Stamp script button updates Date Stamp and Time Stamp fields. |
|
|
17 |
|
|
One Person, Region, State or National may have more than one email address or multiple Persons may share an email address. |
New button creates new EmailAddress.fp4 record with Person, Region, State or National ID. Delete button deletes current EmailAddress.fp4 record. Send button creates email message with Message field in body. |
|
|
18 |
|
|
One Person, Region, State or National may have more than one URL or multiple Persons may share a URL. |
New button creates new Phone.fp4 record with Person, Region, State or National ID. Delete button deletes current Phone.fp4 record. Connect button opens URL in browser window. |
|
|
19 |
|
|
People are related to each other in complex and unpredictable ways. |
New button creates new Relation.fp4 record. Delete button deletes current Relation.fp4 record. |
|
|
20 |
|
|
Each person may donate in many ways. |
New button creates new Donation.fp4 record with Person ID. Delete button deletes current Donation.fp4 record. |
|
|
21 |
|
|
Each person may volunteer in many ways. |
New button creates new Volunteer.fp4 record with Person ID. Delete button deletes current Volunteer.fp4 record. |
|
|
22 |
|
|
Different accounts may be used for different activities. This financial data base can remain closed until needed for a billing activity (pledges, sales). |
Notify Person of account debit via email. |
|
|
23 |
|
|
Sort to determine which promotional or recruiting activity has the highest ROI, or which ad in which publication in which media has the highest ROI. Spend 80% on that and experiment with the remaining 20% of your budget. |
||
|
24 |
|
|
What activities have been conducted and what was their value? |
New button creates new Activity.fp4 record with Comparison ID. Delete button deletes current Activity.fp4 record. |
|
|
25 |
|
|
What was the cost of an activity? |
New button creates new Item.fp4 record with Activity ID. Delete button deletes current Item.fp4 record. |
|
|
26 |
|
|
Activities must be planned, coordinated and executed.
Only the Schedule records pertinent to an Activity will appear in the Schedule portal of that Activity. |
||
|
27 |
|
|
The task hierarchy can be extended with additional databases (SubTask.fp4, SubSubTask.fp4) as necessary. |
New button creates new Task.fp4 record with Activity ID. Delete button deletes current Task.fp4 record. |
|
|
28 |
|
|
Some tasks are dependent on the completion of other tasks. |
New button creates new TaskRelation.fp4 record with From Task ID. Delete button deletes current TaskRelation.fp4 record. |
I have just begun this list for those who may be unable from their experience to infer the benefits from the database descriptions.
FileMaker Pro 4.0v3 is proposed as the engine, because FileMaker Pro is relational, scriptable, easy to use and modify, runs on Macs as well as PCs, and has its own Web server (WebCompanion) that, unlike later versions, which limit access to 10 concurrent users, allows unlimited TCP/IP access without the extra cost of the Unlimited or Server ($999) versions. I can generate FileMaker 4.0 runtime copies of the system. FileMaker will dial telephone numbers, email and connect to URLs. Its performance degrades after 600,000 records, but that limit will be exceeded if the hierarchy of databases is maintained. Servers can perform well with fifty database files concurrently open. Should the State organizations wish to redundantly maintain all of the Region member data or should National wish to maintain all of the State member data, then at some time in the future FileMaker 4.0 may prove to be inadequate and the system will have to be migrated to a later version of FileMaker or to another relational data management system, like Oracle,
LOCATEM must be treated as a commercial product with formal releases and distribution of those releases to all current "owners" to keep the data synchronized. Replacement database files will require exporting from the old, importing into the new and adding data for new fields. New database files will require adding relationships to some of the existing files. These are not difficult tasks, but they need to be documented and promptly done.
Consequently, the distributed system must be viewed as having a configuration the evolves over time. Information about who has what version of what file and who has implemented the latest version must be maintained. Not shown above is a database version field for all database files to facilitate problem isolation.
Multiple information layouts can be provided for various printing and FAXing purposes, like envelopes, labels, membership application forms, Petition in Lieu of Filling Fee forms, etc. Each would be populated with the data in the found set. The layout formats peculiar to the Party can be standard. The layouts peculiar for a jurisdiction will likely have to be modified to comply with jurisdiction specifications, e.g. different Counties may have different Petition in Lieu of Filing Fee form formats. If the information is served, then those making modifications must be careful to preserve the database peculiar code (CGI, specifically CDML). To facilitate that, I can provide a copy of HomePage at no cost other than CD copying, because the product is no longer sold.
More to come.
While I am unemployed, I am willing to develop this system, and leverage the Form/Survey (activity sign-up, decision-making), Forums/ListServer (discussion groups - needs overhaul and additional file), Letters and Quotes (letter- and article-writing support) systems I have already developed (only need to enter Person ID to relate to Person.fp3 data), but it will be a full-time job (six months). Documenting it so anyone can maintain it is a full-time job (two months). Distributing and maintaining it throughout the various Libertarian organizations will also be a full-time job (indefinite).
Of course the system can be implemented in chunks according to priority, but that will introduce additional maintenance burdens, because during the development of subsequent databases the need for a field, relationship or script in a database file that has already been distributed may be discovered. This can be avoided if the entire system is developed, tested and released as a whole.
My monthly nut is $5,000. Does the Libertarian Party want to crack it for the duration?
Should I be employed full-time by a commercial enterprise, then this will be a part-time effort and take at least four times longer to develop, document and deliver in calendar time. In this case I would charge half of my normal rate of $80/hour, and customer support will be limited to evenings.
Some functionality that requires control of the computer or application programs thereon may only be available on Macs using AppleScript. As far as I know, there is no equivalent to AppleScript on IBM clones (MS Windows computers).
Home based servers can be existing personal computers. To avoid viruses and hacking, and have in integral "UPS," I recommend a used $500 iMac running System 91 or 9.2. For Regions without computer expertise, I would acquire iMacs and install them at the homes of officers or their designates. With Timbuktu installed, I can maintain them remotely. I would also provide a CD for disk maintenance purposes.