I'm not sure of the best way to store people without families.
I'm inclined to create a family with a single individual as a member for consistancy of reporting and queries.
For example the "family member count" query does not list individuals (with no family) at all (although obviously it is doing exactly what it says - but I hope you see my point).
I'm concerned that having two ways of storing people (in and out of a family) may cause confusion.
Does anybody else have any thoughts or experience?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was wondering the same thing... what is the purpose of being able to enter individuals if they aren't assigned a family... I understand being able to assign individuals to groups but I think that it is confusing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I talked this in another software package. Right now the only solution is to have families composed of single individuals.
What if we added a mod that would "auto-create" families for any family-unassigned individuals?
Usually the family title is used as a mailing label and individuals are used for email contacts and group enrollment. I do not see an easy clean separation of the two. And many times churches count membership by families.
Thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2005-02-03
Autocreating families for unassigned individuals would work for me (or just give an option to do that).
But to get everything working as I would expect there would need to be some associated work to tidy things up in the query/reporting area...
For example, families are always listed as "The <surname> Family" which is not really appropriate for a single person/widow.
Some intelligence in the "mode of address" for families in queries/reports would be good.
So for a multi-member family (at least one adult and child) it would be "The Smith Family", for a couple with no children it would be "Mr & Mrs Smith" and for a single person it would be "Mr Smith".
Of course it would also need to take care of families where husband/wife have different surnames (e.g. "The Smith/Jones family" or "Mr Smith & Mrs Jones").
I guess families need a surname (in database terms) - currently I'm planning to use "Smith" or "Smith/Jones" but that doesn't take care of single people or couples with no children. The auto generated "The <surname> Family" in reports is a little inflexible in my view.
But maybe the alternatives are too complex to code.
Barry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the auto-create mod would work... as far as I can tell there's no real reason to enter under the individual mode as it exists now... you can just as easily create a family with only one member
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm new to osc and I'm thinking about using it at my church. It seems to me that trying to associate families by address may be a challenge. What if the user could be free to type in either "Residence" or "Family" for the appellation?
This would handle single or married people. If Ronald Reagan lives alone his newsletter goes to the <The Reagan Residence>. If Richard Nixon has a large family it would be addressed as <The Nixon Family>.
By allowing the user to type whatever they like for the appellation it solves the complex task of having to code different appellations. Let the user handle the complex task of deciding an appropriate appellation.
This would also handle unrelated people living in the same household. For example Gerald Ford is renting a room from John F. Kennedy but they are not related. Not an unusual situation in college towns where several unrelated people may live at one residence and call themselves roommates. The user should get to decide if they are all grouped and given a creative appellation to receive a single mailing. Or perhaps they all need different mailings because they likely all file taxes seperately so they would each want to be handled as unique pledge units while at the same time sharing a single newsletter.
Don't make the code try to figure out what to do in these situations. Give the user the chance to implement their creative solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure of the best way to store people without families.
I'm inclined to create a family with a single individual as a member for consistancy of reporting and queries.
For example the "family member count" query does not list individuals (with no family) at all (although obviously it is doing exactly what it says - but I hope you see my point).
I'm concerned that having two ways of storing people (in and out of a family) may cause confusion.
Does anybody else have any thoughts or experience?
Thanks.
I was wondering the same thing... what is the purpose of being able to enter individuals if they aren't assigned a family... I understand being able to assign individuals to groups but I think that it is confusing.
Hmmm,
I talked this in another software package. Right now the only solution is to have families composed of single individuals.
What if we added a mod that would "auto-create" families for any family-unassigned individuals?
Usually the family title is used as a mailing label and individuals are used for email contacts and group enrollment. I do not see an easy clean separation of the two. And many times churches count membership by families.
Thoughts?
Autocreating families for unassigned individuals would work for me (or just give an option to do that).
But to get everything working as I would expect there would need to be some associated work to tidy things up in the query/reporting area...
For example, families are always listed as "The <surname> Family" which is not really appropriate for a single person/widow.
Some intelligence in the "mode of address" for families in queries/reports would be good.
So for a multi-member family (at least one adult and child) it would be "The Smith Family", for a couple with no children it would be "Mr & Mrs Smith" and for a single person it would be "Mr Smith".
Of course it would also need to take care of families where husband/wife have different surnames (e.g. "The Smith/Jones family" or "Mr Smith & Mrs Jones").
I guess families need a surname (in database terms) - currently I'm planning to use "Smith" or "Smith/Jones" but that doesn't take care of single people or couples with no children. The auto generated "The <surname> Family" in reports is a little inflexible in my view.
But maybe the alternatives are too complex to code.
Barry.
the auto-create mod would work... as far as I can tell there's no real reason to enter under the individual mode as it exists now... you can just as easily create a family with only one member
I'm new to osc and I'm thinking about using it at my church. It seems to me that trying to associate families by address may be a challenge. What if the user could be free to type in either "Residence" or "Family" for the appellation?
This would handle single or married people. If Ronald Reagan lives alone his newsletter goes to the <The Reagan Residence>. If Richard Nixon has a large family it would be addressed as <The Nixon Family>.
By allowing the user to type whatever they like for the appellation it solves the complex task of having to code different appellations. Let the user handle the complex task of deciding an appropriate appellation.
This would also handle unrelated people living in the same household. For example Gerald Ford is renting a room from John F. Kennedy but they are not related. Not an unusual situation in college towns where several unrelated people may live at one residence and call themselves roommates. The user should get to decide if they are all grouped and given a creative appellation to receive a single mailing. Or perhaps they all need different mailings because they likely all file taxes seperately so they would each want to be handled as unique pledge units while at the same time sharing a single newsletter.
Don't make the code try to figure out what to do in these situations. Give the user the chance to implement their creative solution.