4153: FAM facts displayed on HUSB & WIFE
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
#1049 4153: FAM facts displayed on HUSB & WIFE
Persons wanting events on an INDI's personal facts page should put them in the INDI record.
I put a CENS subrecord in a FAM, containing all the info, plus NOTEs for the entire family.
I then intended to put one on each family member, containing only the part that pertained to that individual. I found, though, that ALL the info was repeated here as if I had pasted the exact same lines into the INDI record. A waste of screen space, pushing more important things below the fold.
I don't think this should be--users and admins should have the freedom to decide what information goes where.
The convenience for _some_ people to not repeat _some_ things is not worth making _every_ one have _every_ thing automatically repeated.
I make a usual practice of adding census records to the family. I very much LIKE the feature that shows the census record on the husb and wife's pages. It isn't actually duplicated in the gedcom, only displayed. Personally I think census records are very important when available. Much of the time it gives us our only available glimpse into the lives of these people. I wouldn't care if there was a toggle to show or not show but I think it would be a shame to remove this.
Also this isn't a bug. Should probably be in feature requests or open discussion.
Regards,
Stew
Wes - surely the answer is in your first statement "Persons wanting events on an INDI's personal facts page should put them in the INDI record."
ANY event you put in the FAM page is going to get repeated on the INDI page for the husband and wife, so its easier to enter CENS data just in the INDI record.
This also makes sense because it is SO common that people in the household are not always direct members of that FAM record; or that members of the household are NOT at home for the census (inlcuding sometines either the husband or wife themselves). IMHO its just too messy to use the FAM record for CENS.
Of course, you could enter the data in the FAM record, then on every INDI page EXCEPT the husband and wife :-)
In my view users and admin DO have the freedom to decide what goes where - they just need a little understanding of the consequences.
I'm moving this to the RFE tracker, as it is currently working as designed.
If you want to customise your own installation, go to function add_family_facts() in file includes/class_person.php, and add CENS to this line:
if (($fact!="SOUR") && ($fact!="NOTE") && ($fact!="CHAN") && ($fact!="_UID") && ($fact!="RIN"))
I can understand where you're coming from, but it seems to me the FAM record, as far as GEDCOM allows, is the best place to put something that applies to the _entire_ family. The INDI record IMHO should be primarily concerned with that individual. In the case of CENS, that means to me, only the data from one line of the census.
If I were to accept the rationale for repeating the CENS data on both the HUSB and WIFE, I would have to apply the same reason to repeat it on each of the children.
Wes, one problem with that approach is that it is very common for the census NOT to be for the _entire_ family. It's often for just a part of the family, or the family (all or part) plus other people.
2 - if you only enter a single person's information on their INDI page, then you are losing valuable information when viewing a persons history of events. Yes, you can see they were in such a place at the time of the census - but who were they living with at the time, and what other valuable details were recorded. I find it invaluable to have the entire census record (including where I can an image of the original page) on each person's INDI page.
I actually find the whole 'family page' a bit confusing - putting aside the issue of the FAM record itself. The page actually displays an extended family(children, parents, grandparents), and is only accessible from a single couple's 'family' link. For this reason I tend to avoid using it for anything other than marriage details.
Sure, duplicating the whole census record on each INDI page takes up storage (DB and GEDCOM file), especially for a family of (say) 15 children - but its negligible, and far outweighed by the added information provided.
However, Brian Holland is currently working on a new census data entry module that (I hope) will store the information in a shared note structure - a feature that PGV currently lacks (it will display shared notes, but has no GUI to add, edit or manage them) which will solve even that minor issue.
On a slightly side issue - if you use the RA module, and add census info through that (i don't - far too buggy), then it automatically adds all the census data to each INDI, adds nothing to the FAM record; and if you let it generate an OCCU tag for any of the individuals it adds all the same data again there as well!
I still feel that it is valuable to put the entire record with a FAM an selected parts of it with each INDI. Not to save DB or GEDCOM space, but to save screen space. With the current implementation, I'd rather not use CENS records and instead refer to the cenus as source for dates and places on other tags.
Aside: yes, I tried the RA once. When I saw what it did, I edited the GEDCOM back to something I consiered reasonable and never tried that again. (In fact, I reported that behavior back then as a bug.)
I agree the the family.php is a bit confusing. I created a variant of it that looks more like a traditional Family Group Sheet, but subsequent upgrades to other files have broken it, and I haven't fixed it.
Wes
FAM record facts/events appear on the HUSB and WIFE records only, not on the CHIL records. You can attach an ASSO record to a CENS/MARR/etc FAM event/fact and that will move some of the information to that ASSO, but not exactly a good thing.
Brian, Kiwi, Greg and I are working on a new Shared Notes feature, primarily for CENS, but there may eventually be other uses, which will go a long way to tying this data (CENS, at this time) to ASSO-type INDI's, all those listed in that Shared Note census.
Stephen
Wes,
As Nigel says, I am currently working on a GUI for entering Census Info into a shared note.
Only in the beginning stages at the moment, as I am having problems with IE and certain Javascript Items.
It is Javascript based so should be fairly quick with the data entry.
I attach a screenshot of what I am up to.
If you are interested, get back to me offline.
Brian
Screenshot of Census Assistant Module
The problem is that census data is for the "household" at that instance in time. Not only could a single entry pertain to individuals fro multiple families (such as the parents of one of the spouses living there), but may not include every individual from the primary family (adult children may be away at school). Your best options are either to duplicate data for each individual *OR* to add ASSO tags to each event
Also of consideration, many of us have polygamists in our trees; which of a man's families should contain the single census event?
"best options are either to duplicate data for each individual"
No, MY best option is to put on each INDI only that part of the data that is pertinent to that INDI, instead of having the software put in ALL of it for me.
I don't have any polygamists; if I did, I'd put the data (or part of it) on as many families as I saw fit, and I _still_ wouldn't want the software to decide that what's pertinent to one wife is EXACTLY (no more and no less) what's pertinent to the whole family.
Of course, it's not my decision, an the viewpoints of others are worthwhile in determining what feature is best for most. It does seem to be going in a direction that requires me to take Greg's patching suggestion.
Wes,
I have been thinking about your wish to save screen space.
If a CENS event was to just hold the citation details (place, page address etc) and a link was made to a popup window of the total detailed textual info on the census return, would this do?
Brian
Brian, I personally don't see the need for a complication like this. At present text attached to CENS entries (just like long NOTE text, and text attached to SOUR) are normally hidden from view anyway, with just the one line citation showing. I then click the '+' sign to display all. Even an image attached, if at the correct level, will be hidden at the same time. All that's required is to set "automatically expand sources" (and Notes) to 'No".
Nigel,
I agree in principle, but I was just trying to answer Wes's objection ...
>> A waste of screen space, pushing more important things below the fold.
The fold I presume is the unfolding of the "plus" icon" when clicked.
There is a secondary reason behind my enquiry.
If I can open a linked pop up window, then I can specify a separate standard "HTML/PHP page
which could format the data into a table (Which shared notes does not do as is now) and have the possibility of adding a Notes section, etc etc.
When you click on a thumbnail (without lightbox ... (but this is not a problem)) that is within a CENS event, then you get a pop-up for this ... so why not a special html page for a "Census Form ... or any other type of form for that matter"
Hey, I like an easy life in developing, it's hard enough as it is with the problems of JavaScript and the different browsers (particularly IE)
Just wanted to get to the nub of Wes's objections.
Having said all that I am always happy to go with the flow <grin>
Brian
Brian
Actually thats a very good point. I'd forgotten about the formatting issue. I too would much prefer to seee a neat formatted table for census notes. Ideally I would prefer it to be possible without having to have another pop-up, but I acknowledge thats probably not feasable (without being a security hole) - so yes, I would support the extra 'form window'.
Thanks Nigel,
I probably will want Greg's, sanction on this "output" idea (security reasons) before pursuing it as an idea for output.
In the meantime I am still struggling with the "input" JavaScript for now, so this "output" stuff is still a ways down the road .. It's slow work, but I will get there with a demo in the end)
I had a very long think about the presentation of "stuff" on any page, and have to agree with Wes that things are getting a little busy on pages now (as I know you know too). That was the only reason for reflecting a little.
We will see ... Hope Greg catches this
Brian
<<Hope Greg catches this>>
I was trying to keep out of this one ;-)
I think that storing html markup in the gedcom is asking for trouble. A couple of options that spring to mind are
1) detect lines of text containing tab characters and reformat as an html table; I could probably do this in two calls to preg_replace(). If challenged, I could probably do it in one, but it might not be very readable ;-)
2) some "simplified" markup, similar to that used by wikipedia.
Greg,
The idea was not to store html in the Gedcom, but essentially to have a php page extract the shared note (which will probably be in the format like a cv text file separated with commas), and then format that using the code in the php file ... would this be OK?
This is still a long way off as I said ;-)
Brian
Ooops,
I think I meant a csv text file with commas.
Brian
Starting to get different ideas in different directions.
1. "The fold" is a newspaper term redefined for the web.
In a newspaper, you want the most important stuff
"above the fold" on the front page, so people see it
and buy the paper. On the web, you want it on the
first screen, so they see it without scrolling down.
It doesn't matter how good your content, if it's
"below the fold" many people will never see it.
That's one of the reasons for drop down menus in
spite of their disadvantages--they make room for more
real content on the first screen.
2. It is good that the CENS record is collapsed; that helps.
And the popup is an excellent idea as well.
But I still want to put the entire thing in the FAM record
and decide for myself what parts of it go in each INDI.
3. For a popup, I would suggest comma-separated column heads
in the style of a FORM tag, followed by the corresponding
comma-separated row values. Then the research assistant
could know ALL the heads for the particular census, but
if someone wanted to do it by hand, they could leave out
the columns that are empty.