Suggestions for Improved Efficiency in Data Entry?
As a frequent contributor to this site, I have some some recurring frustrations. Recent system changes have seemingly made making suggestions almost impossible. Accordingly, I am posting these suggestions in the hope that SOMEONE with the power to effect changes will be made aware.
Marital Status from Census and/ orother Records
Currently,the user is encouraged to post a martial status of “single” evenf or minors. The resultant post is not associated with a date, so itis quite ambiguous and often misleading when viewed on the person page. An edit should be installed to prevent this from happening. Fore xample, If marital status date < death date and there exists a marriage record, do not show for comparison.
1935 Residence from 1940 Census
Currently, the system invites the user to plug “Same Place” for 1935, but thenp roceeds to highlight an error message (Non-standardizedPlace) in red when the user pulls it in along with the 1940 location. This doesn't make sense.Either the system should not offer the option of reporting “Same House.” or else plug appropriate location data from 1940 and/or appropriate language to reflect that the person did not move between1935 and 1940.
Burial Date
I know of no reliable source for an exact burial date. I used to make something up, or just enter the month and year following death. Most users seem to just input the year. I just leave the field blank these days, but most users seem to fell like they are expected to enter something. Isee no value in this, and suggest that the date field for burials be eliminated.
Cemetery Name and Location
The cemetery GPSstandard location from find-a-grave.com is already available in Family Search, yet it is not carried over during the linking process.This usually results in recording of ONLY the city, state, etc. To identify the cemetery location, someone has to manually look it up and copy-and-paste, usually AFTER the fact, because the average user does not know to look it up and plug it.
Answers
-
@AdrianClift These are all good points. I can't give you good answers on some, but I will see if I can get the information to the correct people to look at them.
First, where to make suggestions. This is the place. You have found us!
Marital Status. Yes it is frustrating to have pieces of information that do not have dates attached. Currently, FamilySearch is expecting family members to choose which pieces of information to keep and which to not as well as which to make edits to. Although, it does make sense for the date of the record to be attached to any piece of information, same as for residence.
1935 Residence. Pretty much same as above. It seems like there should be a way for the computer to do the work of putting an actual place in, rather than 'Same Place' or 'Same house'.
Burial Date. On this one, I can tell you for sure that it will never go away. Modern records are more difficult to find burial dates, but in older times (before civil registration was created by Napoleon in 1799) there were only church records and churches kept records of burial dates, they did not necessarily track the date of death. I know my Norwegian ancestors only have burial dates. Many of my English ancestors and my Chilean ancestors also only give burial dates, not death dates. In many places, when there is not a death date, FamilySearch calculates from the burial date. (This is also the case for Christening/Baptismal records.)
The FindaGrave index was created from FindaGrave in 2018 and has not been updated since. At that time FindaGrave held very few GPS coordinates in the database. The information page says
"Additional records and/or images may be added to this collection in the future."
2 -
Martial status. You assume that all users are totally conversant with what they are presented with. What is the value of "single" reported for a minor, unless there is a date associated with the status? Most folks get married, after all. Folks are currently encouraged to repot "single" for minors. This will only create clean-up work for subsequent researchers when the person is later married and/ or divorced.
Burial date. If what you say is true, then an option to enter a burial date should be presented for "modern" records, say after 1799.
The cemetery name (and GPS coordinates) is ALREADY currently available within the Family Search database. New entries do not offer the option to include the cemetery name. As a result, people are not including the cemetery name, which only creates unnecessary work for subsequent researchers.0 -
I have raised part of your concerns previously at the New Source Linker Feedback group. I am particularly concerned that events are carried across to the Details page of the individual without any connection to the date of the source. I would not have thought it impossible, for example, to carry items like Occupation and Marital Status across with the date of the census in question - rather than for only (the main) Residence field to have the date attached via the source linker. As you say, it is rather meaningless having conclusions like "Single", "Married" "Widowed", or "Labourer", "Miner" on the page without there being any indication of when the marital status changed or when the person followed particular occupation.
It is all very well for others to say we can add dates to these Other Information items when we return to the Details page after adding, say, a census source. But the problem lies in adding dates to all those "Events" that have been added over the years by other users. It's bad enough having to spend so much time correcting errors, but filling in omissions is a bit too much!
3 -
The index from Findagrave.com is updated regularly according to the Collection List:
Collection TitleResults (1)
Column headers with buttons are sortable. 245,716,234
26 July 2024
-1 -
Modern burial dates can often be found in obituaries (typically as day of week).
Burial dates and locations are also common fields in death certificates. Unfortunately, that part of the record is never, ever indexed - so we have to record-dive for the data.
0 -
Why is FS (also Ancestry) so resistant to having the cemetery name be part of the attachable data? I have interrupted my work flow 10s x 1000s of times go and retrieve the cemetery name and make it part of the record.
I remember a version of the Android app that bravely fielded cemetery names. Unfortunately, it was also that brutal version that followed the Fully Awesome 3.1.7. Such a distressing app, yet it was the one place where cemetery names were deemed worthy of attachment!
So anyway. We've been a really good community. Can we have cemetery names be included in the data-to-be-attached now? In the webui, I mean.
1 -
Thanks for the support! Sometimes one feels a little lonely when trying to help by suggesting improvements.
1 -
When searching for records of married women, neither their spouse nor their married surname is added to the default search terms.
New researchers find this non-intuitive and reasonably so. It can take them time to puzzle why the expected records aren't there.
0 -
I think FamilySearch is doing it Exactly Right when it doesn't automatically assume that people swapped families just because they got married. If a person lived in a community that followed that practice, then the user can put in the appropriate search terms.
This is one of the things that frustrates me every time I try to use one of the other genealogy sites. I search for X Y, and it serves me up a long list that says X Y, but when I look at the actual records, they're for people named X A and X B and so on. It's not until I look at their spouses that I see any sign of Y. This is Wrong, and I have never been able to figure out a way to tell those sites to Stop Doing It Wrong.
7 -
"When searching for records of married women, neither their spouse nor their married surname is added to the default search terms.
"New researchers find this non-intuitive and reasonably so. It can take them time to puzzle why the expected records aren't there."
I would agree with @Julia Szent-Györgyi that if you are working in a culture where name swap doesn't occur, then adding the name of the husband can be at the very least unhelpful. I don't have to go far to find a continuing use of maiden names after marriage - Scotland, for instance, did so for many years.
If the user wants to search on both maiden and married name, then, the profile should have an Alternate Name added (labelled in the drop-down list as "Married Name"). Then, when the user hits the Search Records / FamilySearch link, the resulting search uses both names.
Having said that, there are two big "howevers" about that paragraph.
In the first place, how are users supposed to know to enter the Married Name as an Alternate Name? After all, in many programs outside FamilySearch, we are explicitly told not to enter married names - because they can be derived from the husband's name. (A staggeringly parochial view!)
Secondly, searching with both Married and Maiden Names is not a panacea. I have my gran's profile set up with an Alternate Name of her Married Name. If I hit the Search Records / FamilySearch link and look for her death records, I see what I know is her correct Death Registration under her married name, but I also see a Death Registration apparently under her exact Maiden Name. It's the same county, but this woman was born 2y after gran and died 2y after her. So - it's not her, it's just a close match.
Ideally, if I'm searching for anything before her marriage, I want to use her maiden name only. For anything after her marriage, I maybe want to use her married name only (depends on the collection, I suspect).
If this sounds complicated - that's because it is.
It goes back to "how are users supposed to know to …?". If we want to help users find their data, we have to be better at teaching people how to find stuff themselves and not expect them to rely on single button presses, because, with the best will in the world, there will always be exceptions to every single naming rule.
5 -
@Julia Szent-Györgyi @Adrian Bruce1 Most of my work is in post-1850, N.American records and this may skew my perspective, which is this:
I work well with Ancestry's method of appending every husband and father surname to the default search request. Just the spouses names might be ideal but I do like the current method because
1) I find it much, much easier to delete names from one field than retrieve names from multiple locations and add them to the search parameters. Doubly so when I switch between all the name combos, when trying to unearth especially shy records.
2) Having all those names appear in the surname field helps me keep this person's timeline fixed in my head, while I adjust the other search parameters.
That said: If there could only ever be one default search, I think that what the majority wants is best.
But if users could tweak their default search terms, we'd all be happy(er)(ish).
0 -
@Adrian Bruce1 I'd bet there are a ~dozen factoids that would substantially ease new user grief.
0 -
@AdrianClift "Same House" for 1935, but then highlights an error message
I find "Same House" helpful and agree it should be the text and the standardized place for 1940 should be the data.
If would be sweet if that combo was entered automatically but I'd be willing to enter it manually. At least on some profiles.
To enter that combo however, I'd have to fight with PlaceNameAutocomplete - and PNA can be testosterone-overdose assertive about what text to display.
In this particular battle, I believe PNA would beat me every time.
0 -
The thing with the 1935 "Same House" problem is that Source Linker doesn't have a separate module or algorithm specifically for the U.S. 1940 census, or for any other indexed collection. It's the same programming that has to be able to deal with all indexes in all languages. This means that fields labeled "residence" get their contents transferred into residence events, regardless of the specifics of said contents. (I can't really argue with the people who set up the indexing project such that the 1935 field got indexed with a non-placename: it wasn't the indexers' job to make that level of interpretation. I do question the field's inclusion in the index, though, since it's not information that's likely to make a record any easier to find, in most cases.)
For the "search" tool on profiles and the question of whether it autofills the spouse (and parents) or not, I concede that it's easier to delete a search term than to fill one in, but unless you're searching for people in the U.S., automatic inclusion is likely to result in mostly-unsuccessful searches. FS's search algorithms really do work on a "less is more" principle (no matter how rude the "no results" message is that says so). Also, being forced to fill in the family members on a search helps keep the names straight in my head, at least for the moment — which is exactly what I need for evaluating the results.
I have a vague theory for another reason the search tool doesn't fill in the family members: it's not usually necessary, because the records that match on relationships are the hinting system's forte. It can find misindexings that fall below the inclusion threshold on "manual" searches, and has usually already offered up all of the records that a "fully-autofilled" search would find.
2 -
'Source Linker doesn't have a separate module or algorithm specifically for the U.S. 1940 census, or for any other indexed collection' - this is a really key point. There is so much that is collection specific and that could if properly interpreted as rules/algorithms within the Source Linker, at indexing project time, and no doubt elsewhere, make the relevant processes clearer and more accurate, save loads of time, and improve data quality. FS presumably understands each collection's habits and structure in detail, why not make proper use of this information? I just do not understand how FS sets its development priorities (AI is great but is it /really/ more important than making it easy to use the collections, or improving data quality?)
0 -
@MandyShaw1 said
"… FS presumably understands each collection's habits and structure in detail, why not make proper use of this information? …"
Permit me to raise a quizzical eyebrow, a la Mr Spock.
Don't take that as a cynical comment, though. There are a number of occasions when with something as "regular" as UK Parish Records, I've had to take a step back in astonishment. I remember in the Cheshire PRs, in the index to one register I found some very odd burials - every name was on the pattern of "Mrs Smith", "Mrs Jones", etc. Eventually I worked out that these were not Burials but Churchings (roughly speaking - blessings for mothers recently delivered of their child).
Clearly these had not been anticipated by FS, which is fair enough as I didn't anticipate them either. I've never seen any since.
My worry would be that starting to make tweaks to logic when unanticipated stuff such as Churchings lie beneath the metaphorical water could result in worse problems. Compare this to background auto-standardisation…
5 -
The churching liturgy is still in the Book of Common Prayer to this day, I think ... so why /wouldn't/ FS have allowed for churching as one of the services that might be recorded?
I do take your point, though, but I don't see this as about automation, I see it as about putting the data in context, customisation of data capture, an aid not a straitjacket. Yes it would require monitoring and tweaking to handle anomalies, on top of a deep level of understanding of the data and of where/when it came from, but that's business as usual (and, indeed, the interesting bit) if you're looking after information of this level of volume and complexity, surely? And the originators of the data should be able to provide a lot of this information, it's their archivists' job to know this stuff.
0
