A component being worked on YAY!! Field updates in source attachments... plus...
LegacyUser
✭✭✭✭
Justin Masters said: As I discussed some ideas about improvements with a FS developer, he mentioned a WONDERFUL improvement that will be forthcoming and bears sharing..
I had mentioned the need for granular field updates and pointed to partially (broadly) entered data in a birth from a census, but needing to be updated with a subsequently found birth or findagrave record entry. The current source attachment doesn't allow for ANY updates if there's ANY info in the entire vital record field associated with that event (date, place). It currently requires a manual effort outside of the attachment process. I tend to do it BEFORE I attach, with info from the preview button on a record hint - which causes some other undesirable events that he was very appreciative that I pointed out.
(Okay, so I work backwards from most... and it just has to be confusing people who look at the change logs when they see my updates before the record attachments - it's to get around this problem of field updates during source attachments. Yes, I know you can see it AFTER the source attachment in the vital record update part of a person's page (but surprisingly can't copy/paste from it) hmmm... I'll report that as a UI improvement idea.. but perhaps it will be negated by what's coming below)
He mentioned that granular updates will be forthcoming, ALONG with the same kind of info seen now as if you were to go into a vital record update function, where OTHER info relevant to that field is found (for instance, findagrave birthdates, birth years from other censuses, etc) for consideration before updating/altering that data in the current field.
YAY!!
From this functionality, I'm wondering if my problem mentioned at the end of my paragraph before the one above will still be there, or if the "most correct/desired" info will be SELECTABLE, rather than just viewable for comparisons during a source attachment. That would affect the "purity" of data from THAT source, when you select info from a different source to put in as an update for data.
In other words, Adding a census birth year, subsequently adding a more granular birth month/year (1900 census for instance), but seeing that there was a birth date from a birth record available for comparison, but not a valid data entry possibility for a census record.
But I've often added granular info during a census-based person-create/update operation when I'm staring at more granular info on my other screen, and I figure I'd just enter it while I'm there in that operation. (I'm glad that kind of record attachment restriction doesn't exist.) Sometimes it's just easier to let FS "create" the family structure via a census than for me to have to type in essentially the same info manually.
I had mentioned the need for granular field updates and pointed to partially (broadly) entered data in a birth from a census, but needing to be updated with a subsequently found birth or findagrave record entry. The current source attachment doesn't allow for ANY updates if there's ANY info in the entire vital record field associated with that event (date, place). It currently requires a manual effort outside of the attachment process. I tend to do it BEFORE I attach, with info from the preview button on a record hint - which causes some other undesirable events that he was very appreciative that I pointed out.
(Okay, so I work backwards from most... and it just has to be confusing people who look at the change logs when they see my updates before the record attachments - it's to get around this problem of field updates during source attachments. Yes, I know you can see it AFTER the source attachment in the vital record update part of a person's page (but surprisingly can't copy/paste from it) hmmm... I'll report that as a UI improvement idea.. but perhaps it will be negated by what's coming below)
He mentioned that granular updates will be forthcoming, ALONG with the same kind of info seen now as if you were to go into a vital record update function, where OTHER info relevant to that field is found (for instance, findagrave birthdates, birth years from other censuses, etc) for consideration before updating/altering that data in the current field.
YAY!!
From this functionality, I'm wondering if my problem mentioned at the end of my paragraph before the one above will still be there, or if the "most correct/desired" info will be SELECTABLE, rather than just viewable for comparisons during a source attachment. That would affect the "purity" of data from THAT source, when you select info from a different source to put in as an update for data.
In other words, Adding a census birth year, subsequently adding a more granular birth month/year (1900 census for instance), but seeing that there was a birth date from a birth record available for comparison, but not a valid data entry possibility for a census record.
But I've often added granular info during a census-based person-create/update operation when I'm staring at more granular info on my other screen, and I figure I'd just enter it while I'm there in that operation. (I'm glad that kind of record attachment restriction doesn't exist.) Sometimes it's just easier to let FS "create" the family structure via a census than for me to have to type in essentially the same info manually.
Tagged:
0
This discussion has been closed.