My misuse of the Reason This Information Is Correct box

LegacyUser

Elizabeth Watkins said: Overall, the site gets better all the time. I do confess to misusing this box by adding to it the name of a church where a christening occurred, location where a burial occurred, or other odd bits of information that I don't want to lose (name of a farmstead, where at sea a death occurred, cremation, etc.). Could the box be relabeled Additional Information? Or could a separate Additional Information box be added? This is also the reason I skip many entries when fixing place names; the street or farmstead may be of use to someone, and I don't want to erase it completely just for the computer's sake.

LegacyUser

Jordi Kloosterboer said: Put it in other information. There is actually a field for cremation there where you can put in the description that the ashes were scattered in Logan canyon and then put down the location where cremated.

LegacyUser

Juli said: The main problem with putting information in the reason box is that it's volatile: if someone comes along and removes a comma from the date or something, he will be strongly encouraged by the system to change the reason statement.

As Jordi points out, there is an option specifically for cremation under Other Information. The name of the church and similar specifics of the location can usually be appended to the beginning of the placename field, source references should go in Sources, explanations of one's reasoning (derivation logic) should go in one of the things on the Collaboration tab, and so forth and so on: everything that people put in the reason box has another, better place somewhere.

LegacyUser

terry blair said: If it were me making the entry, I would put as the place of burial Logan Canyon, Cache, Utah. Even better if I could add something like Point Lookout, Logan Canyon, Cache, Utah (if such a place exists in the Canyon). Don't forget to add a date when the ashes were scattered. Then, if the best standard was Cache, Utah, that is what I would use as a standardized location box. (There is no need to have a standardized flag on the place of burial.) In the other, cremation, section I would add the date of cremation and the location of cremation, for example, Jones Funeral Home, 2635 someplace street, Cache, Utah and in the standardized place box I would use Cache, Utah.

LegacyUser

Cherie Gardner Rawlings said: You are not misusing "The reason this information is correct box" The more added here the better FamilySearch is.

LegacyUser

Paul said: I agree. Some users probably never go near the Other Information section - or Collaboration. I particularly like the fact that I can add comments to the Death "Reason This Information Is Correct:" field. Unlike with the other Vitals data, comments can be added here even if no date / place inputs have been made. If I haven't found the death, I add a brief note here concerning the nature of my unfruitful efforts, to date.

I don't believe in necessarily using specific places to add useful information - I'd sooner important details be easy to find, rather than hidden away where an inexperienced user would not dream to look.

LegacyUser

Elizabeth Watkins said: That is my reasoning exactly. The closer to the details of the vital event, the better. Out of sight = out of mind. The biographical sketch is the box most likely to be read, but sometimes not enough details are known to write a true bio. I misuse that box, too, because I try to put enough critical analysis to prevent people from being (re)merged incorrectly or attached to the wrong lineage.

LegacyUser

Chas Howell said: Because it is so convenient to do so, I am often guilty of putting information in the transient Reason field when it more appropriately belongs in a Note field. When I add a source using source linker I can add a Reason statement but no Note field is available at that point.

When I create my own source, Add Source/ Add New Source/ I have the “Reason to Attach Source” field and I have the “Describe the Record (Notes)” field too. Maybe something could be done like that so you could add a Note at the same time you add the Reason?

LegacyUser

Elizabeth Watkins said: Your idea is a good one, I believe. I'm in favor of anything that will accommodate adding more information and yet allow the program to insist on standard usages. Both are important for further research. If the Note fields could be placed where they are more immediately visible, more people would read and use them. If they are hidden away in discrete places, only the more experienced users will think to look for them.

LegacyUser

Adrian Bruce said: "I do confess to misusing this box by adding to it the name of a church where a christening occurred, location where a burial occurred, or other odd bits of information that I don't want to lose (name of a farmstead, where at sea a death occurred, cremation, etc.)."
While I end up putting all sorts of things into that box, I concur with Juli that it's all too easy for the system to persuade someone to splat it with their own text. And in the case that you mention, and I quote, there's no need to misuse the box. Juli also indicated that the name of the church, cemetery, etc, can be stuck on the front of the place-name.

If you're not sure how to do this, then this is how:


The above is my equivalent to your screen shot - a standardised place-name for the burial, but no exact address, etc. I then insert the church's name / address in front of the place-name. That immediately starts the system resuggesting standard place-names - there is debate over which is the best way to deal with this - I usually click outside all boxes and drop-down lists. That freezes the "decorated" (display) place-name with the extra details that I just added and keeps the standard place-name as it was, in its already standardized form.


Then save it and the result is this:


Note that the pin has gone - this does not matter. The idea is to end up with a "decorated" display-name that adds the church, burial ground, house address, etc, and a separate standardized place-name that is usually a truncated version of the display name.

LegacyUser

Carol Jo Menges said: I do the same thing and have often wished the box was labeled "Additional Information" or something equally inclusive.

LegacyUser

Jeff Wiseman said: If you use that "Reason This Information Is Correct" box for what it seems to imply, you will eventually REGRET it!

That box is not labeled correctly. It should say something like "Reason that you are making this change". This box is volatile. It only applies to the change you are making at that moment. It is NOT saved with the vitals data for that record. It is saved as part of the Change History Log. If the reason for the next change to be made is something like "set date to standard format", it will blow away your 3 page exposé on all the reasons that a particular date and place were chosen from just one of 3 sources with differing contents.

I've tried to get FS to fix this totally misleading page structure for a while. What appears to be very intuitive here is the exact opposite of what is happening in the system.

The only effective way to do this now (which is the same as it was done for years and years all the way back to the paper and pencil days), is to record the "Reason This Information Is Correct" information for a given vital (e.g., a Death) in a note (i.e., a "collaboration note" as FS calls it), and give its title the name of the vital it applies to (e.g., DEATH).

Then when you enter a reason into the box (which SHOULD HAVE BEEN labeled "Reason For Making This CHANGE"), it only needs to reference the note if there is a lot of information in it.

When it is fairly obvious why a change is made (e.g., "date updated based on death certificate"), that is all of the text necessary. But if a larger reasoning with multiple conflicting documents is necessary--NEVER put it in just that field. copy it in from the note if you wish, but don't put it into just that field. As Juli already pointed out, it will normally DISAPPEAR the next time a tweak is made to that data (e.g., someone comes along and changes "St." to "Street").

It really annoys me when people make such a great effort to document things properly and then the system puts it in a place where nobody can easily see or benefit from it.

That field is schizophrenic. FS has taken a shortcut and used the same data block to support two very different functions. This is always a bad choice in software.

P.S., when you use the "Note" approach I mentioned above, your documentation will transport from FSFT to any other system out there as they all support Notes for records used in this way. If you put them into this screwy Reason field, it will not transport to ANY other system out there as the Change History log feature is proprietary to FS. There is no industry standard for it.

LegacyUser

Christina Sachs Wagner said: I'm confused. How is this misusing the reason box?

LegacyUser

Jeff Wiseman said:

The more added here the better FamilySearch is

Respectfully, I really disagree. Most people do not understand how the text in that box actually works due to the totally misleading way it has been implemented. That text belongs to the description of the change that you are making in the data and it is stored with the CHANGE record in the change history log. It does NOT belong the the vital data that you are actually changing.

That box is not implemented so that it functions in the way that you are desiring/expecting it to behave. Loading all kinds of data into that box repeatedly only clogs up the change history logs so that it becomes even MORE difficult to understand. It should really only contain reasons why the CHANGE has been made. If you only added a comma in a location name, that is all the change is concerned with and all that is necessary to document. Then when a person looks at the changed data in the change history log, they get a description of why that specific change was made.

To figure out all the reasons why a vital was assigned a set of values, you have to go all the way back to the beginning the change history log, and then walk through it completely looking at every change made to that vital. When you combine ALL of that, then you'll have the reason why all the different parts of the the vital have been set to what they are. What a nuisance.

We need a single data point saved in the person record and tagged to the vital where a complete description of the logic applied (given a set of sources) can be centrally stored and maintained with its own appearances of changes made to it showing up in the person record's change history log.

The "Reason This Information Is Correct" box doesn't come anywhere near doing this. All it does is give false hopes to folks using it as to its supposed benefits.

LegacyUser

Jeff Wiseman said:

f the Note fields could be placed where they are more immediately visible, more people would read and use them

There have been several requests here to be able to tag Notes from the Notes list to vitals in EXACTLY the same way that the Sources are tagged to the vitals. This is only one of several ways this could be improved, but it is straight forward.

Also since a single description of sources interpretation may apply to multiple conclusions in the exact same way that a Source may apply to multiple conclusions, The Note tagging would readily be an easily understood mechanism. So you make one note in one place where everyone can find it. The way it is now, you have to repeat the description over and over and over again every time a change is made. And if someone doesn't repeat the description when they make a change, it is lost from the thread.

FS has made several changes to the system that have gradually eroded the true power and usefulness of Notes by scattering their functions across various parts of the site. We even have folks who aren't sure what the Notes should be used for.

The addition of the reason for change box was needed for the change history logs. But it was implemented as though that is the place to put all of your reasoning for the values. This is just another way the FS has been making the Notes more useless.

LegacyUser

Adrian Bruce said: The problem is that there are at least 3 different uses for the box labeled "Reason this information is correct."

1. The literal interpretation is that it's an argument why the date, place, etc are correct. That might be something like mentioning that the place of birth comes from the census while the exact date of birth comes from the 1939 Register (or whatever)

2. Usage 2 is "Why I changed this item" - the classic case there is "Standardized place" (This is a Change Log type of use, and you expect change logs to accumulate. This doesn't)

3. Usage 3 is the additional note about the person, such as "She was the 4th generation to be baptized here".

You might think that Usage 1 is the "official" usage - but FS confuses matters still more because when you use Source Linker to create a Vital Event, the system sticks the reason why you have identified this Source with this person into there - a 4th use.

If you carefully craft a usage 1 or usage 3 text, you probably will get annoyed, as Jeff suggests, if someone comes along with a Usage 2 and splats over the top of your text with the single word "Standardized". I fear that I did that in the early days because I automatically assumed that anything I wrote would be appended to what was there, not replace it.

It's never a good idea to work across the intended purpose of a system - and here there are 4 uses so the initial guess is that at least 3 are risky.

Personally I'm not sure any of these count as misuse because the intended use is not clear. But the uses that I mention are certainly at cross purposes and therefore problems may ensue.

LegacyUser

Jeff Wiseman said: #2 *IS* the implemented structure in the database, but it has been implemented in the user interfaces as though it is #1. Because of the internal implementation of #2, you cannot be safe using it as #1 the way it appears to be in the user interface.

BTW change logs do accumulate, but the text description for EACH change's reasons do not. Each change is new. The reason for each new change would be new. Meaning each time you attempt to change something, you would get a new BLANK reason box for that change. That is the PROPER method for tracking change histories for feature #2. But in the schizophrenic Reason box that FS has implemented, they allow text to be carried forward. This gives the illusion that it can be used for #1. I know why they do this. They want the next person to see the reasoning and maybe not change things without thinking. That's GOOD. But that's NOT the way to do it.

LegacyUser

Elizabeth Watkins said: That is why I would prefer a separate Additional Information box that doesn't get wiped clean when someone changes the data in it. Admittedly, it is possible to put additional info far away from the vitals in various places, but that hides it away from people who don't know the system very well--the very people who tend to combine different individuals without careful investigation and tangle up a formerly correct pedigree.
Knowing the farmstead name is vital in discerning one Per Persson from another in Scandinavian research. Knowing the name of the church where a vital event took place in a larger town can accomplish the same in English research. On the other hand are the multiple recordings of the same vital records in different New England towns, where zealous clerks recorded birth dates of all the move-ins with no mention of where they were actually born. Novice researchers need someplace nearby and visible where a prior researcher can spell out such details and avert disaster.

LegacyUser

Jeff Wiseman said: I agree completely.

When you edit a particular vital, the window that opens up has a list of all the sources from that person's source list that contribute to the values of that vital (i.e., they have been "tagged" to that vital). All of the Notes from that person's Notes list that contribute to the values of that vital should be shown there as well!.

This is the type of association of notes with conclusions that has always existed in genealogical documenting over the years. But when FS doesn't make them easily available in appropriate places, people don't figure out on their own that that is where this type of documentation goes.

LegacyUser

Adrian Bruce said: Agreed. There is a minor but unhelpful aspect - the subsidiary information for events is currently, IIRC, hidden behind an "Edit" link. I think that this needs to be renamed as "Edit and More Info"

LegacyUser

Jeff Wiseman said: But you can't change the events on that details page anyway. The details page is really a "Conclusions Summary" page. You typically have to go elsewhere to see the "real" details (e.g., source lists, notes, discussions, and in this case supporting information for vitals). At least it is consistent.

LegacyUser

Kathryn Grant said: Jeff, if I understand you correctly, I respectfully disagree that the text "belongs to the description of the change that you are making." Even though the reason statement (rightly) shows up in the change log, it should still simply be validation for why the information is correct. If the information changes, the reason will probably change as well. But the fact that something changed is secondary to evidence that shows the information is correct.

One screen (the one for editing a source, I think) actually has a field for the reason the info is correct and the reason changes are being made. If FS wants to track both of those things, then both those fields should probably be added to all edit screens on the person page. But if I had to choose one, it would be a reason the info is correct, rather than the reason the user made the change.

And if I misunderstood your comment, just ignore mine

LegacyUser

Jeff Wiseman said: I think that your intuition about which matter is a little "weightier" is really correct, and in fact it does line up with what I'm trying to say. BOTH "Reasons" are important, but for quite different purposes. And munging them together hurts both and confuses everyone.

But the fact that something changed IS SECONDARY to evidence that shows the information is correct.

Exactly (emphasis added :-) Right now the change descriptions are being used to show the evidence of correctness. It is piecemeal, requires a lot redundancy and re-entering of information, and in the end, there is still no guarantee that when someone wants to know why a particular event has a given value, that they will be able to put together all the pieces to do so.

We need a place that is just as visible as the sources are to document how the sources have been interpreted and vital conclusion values arrived at. Some formal genealogical proofs can be 20 to 30 pages or more in length! You can't maintain that in a little 4 line window in the Birth Editing screen that has to be touched and carried forward by everyone that wants to change "Mar" into "March". But with what could be some minor tweaks, we could have something that has the APPEARANCE like the current mechanism, but behaves in a far more structured and logical fashion. There's no reason that the correct solution can't have the same types of appearances and benefits that the current one alludes to have (but doesn't).

So when I said that "the text belongs to the description of the change that you are making", what I was saying wasn't so much that that is the way it should be. What I was saying is that the system is hard-wired to do that at present, whether you like it or not. I'm not saying to ged rid of that text box. I'm saying that if you want the feature of being able to document reasons for why the set of vital conclusions are what they are, the underlying data structures supporting that text box needs to change.

Otherwise, the risk of losing all of you hard work documenting "reasons" will be omnipresent and unavoidable. If folks can live with that, fine. For me, I'll only add information that is useful up until the next change. Anything important will have to go into Notes with the hope that someday they will be considered important again (enough to integrate more fully into the user interface than they are at present anyway).

LegacyUser

Adrian Bruce said: "editing a source" - and that's probably yet another aspect, yet another reason, needing yet another item.

As Jeff indicates, I believe, you're both right - all these things are important but the lack of clarity leaves text at risk from someone who comes along with a different, equally valid idea of what should go in a particular box.

To be clear, the reduction to separate reason boxes is not easy. It requires some hard analysis of what happens. And then it requires a really clear User Interface. Right now, I think that FS have just stuck a text box in a few places to cover multiple purposes. It's an approach that works for a desktop program because only I use it and instinctively I work in the same way (for a while!) so won't sabotage myself. But when different people have different understandings...

LegacyUser

Kathryn Grant said: And then there's the problem with the Source Linker. It asks why you're attaching the source, and a typical answer will be something like, "Provides evidence of birth date and location." But if the source is tagged to the birth (which often happens automatically), the reason for attaching the source is transferred to the Reason this Information Is Correct box for the birth, where it is nonsensical.

If it's important to capture why a change is made, in addition to why the information is correct, then two fields are needed. But I suspect FamilySearch won't implement that, simply because it will be too overwhelming for most users, who struggle with putting a good explanation in even one box. I can appreciate that.

Thanks both for your insights!

LegacyUser

Adrian Bruce said: And just to show that we all interpret things differently (as if we hadn't realized!) my interpretation of "why you're attaching..." is to record why I think that the person in the source (index) matches the person in the profile!

LegacyUser

Paul said: I don't know how I have not noticed previously that comments added during the source linking process overwrite any existing text. (As discussed above and, I assume, due to tagging.)

This behaviour seems inconsistent with instances where data cannot be carried across in the process if there is an existing entry - although I will have to experiment with this, as I believe I have had the option to carry (say) birth detail across when I have already entered something in the vitals field.

Obviously, the former entry (reason statement) can still be found in the change log, but I realise I will need to take care in future regarding this issue.

Even though it is no longer relevant, I was surprised to find the reason statement I'd inputted earlier had been replaced during the source attachment process:



The original reason statement has been replaced by the one written during the source linking process:

LegacyUser

Adrian Bruce said: I don't think that the text added in Source Linker overwrites anything that's there already. Rather, if it creates a Vital, then the text appears against that Vital - but there was nothing there before.

LegacyUser

Paul said: Perhaps this is a more unusual example. Apart from the default "Deceased" there was no date I'd previously inputted. However, unlike with the other vitals fields, I discovered some time ago that the "Deceased" entry in the date of death field allows one to add comments against the "Death".

I have been taking advantage of this provision, as on this occasion, where I added the note shown in the change log. As soon as the date (1979) was carried across by the source linker (replacing) "Deceased" I found the reason statement, written during with the process, came across too, replacing the one I had not deleted. In itself, that action was not important, as I had discovered my conjecture about a 1957 death had been incorrect. However, it was this behaviour that had surprised me (until I reread some of the comments above).

Incidentally, when I replace reason statements in general, I prefer to delete the whole field (date, place and comments). I then add a reason statement for deleting everything, before adding the (newly found) accurate data (with new reason statement). The alternative is to just delete / replace the TEXT, which creates a confusing picture when the change log is viewed.

As an example, click on Edit Birth - there you have a choice of deleting the whole lot (using "Delete", bottom right) or just overtyping the specific details you wish to replace.

I'm sure I'm not teaching experienced users anything here, but I seem to be discovering alternative ways of working within Family Tree all the time!

LegacyUser

Paul said: So, in brief, Adrian, there WAS something there before, viz.
"Possibly died 8 Sep 1957 Edmonton, Alberta, but no birth year shown at https://provincialarchives.alberta.ca..."

LegacyUser

Adrian Bruce said: Well, I've never seen that - I've never seen my Source Linker reasons replace anything. I wonder if the Default Deceased is handled differently?? Interesting!