Standardized Dates and Places

LegacyUser

Wayland said: Date entry and display is not consistent and overly complex. I would propose that when entering a date in various formats (which is good) that before it can be saved, there must be a standard format date and upon saving, it is the standard format date that is saved and consequently it is the saved (standard format) date that is displayed everywhere and the saved(displayed) date that is used in any calculations(110 year rule, 8 year, etc) and searches. I don't see any reason not to displayed the standard format date. If fact, the term standard(ized) date could just be dropped. So the process would be to enter the date (various formats acceptable) sufficient to establish the standard format date and save the standard format date without having to select it.

Right now, we can have a difference between the entered date and the standard date. The entered date is what is displayed everywhere except on the header of the person page and this is the standard date. The standard date is what is used for calculations and searches. If the standard date and entered date straddled, say the 110 year criteria, then it gets really confusing and drives the patron crazy. The screenshots are of such a case.

LegacyUser

Gordon Collett said: How on earth did you ever get the date to display like that? I've never seen that before. That is basically an error in data entry that the program should have caught.

You should post the exact steps of how you got two different dates entered so the programmers can fix that bug.

The purpose of having a displayed data and a standardized date is to allow for both increased information such as including a day of the week (Tuesday, 8 April 1912) or allowing for personal preference in the standard form used such as using ISO format (1912-04-10). (I have run across one person who was adamant that genealogy should only use the ISO format because it is the one universally accepted date standard out there.)

The purpose is not to introduce errors.

LegacyUser

Wayland said: Gordon Thanks for the comments. I got the dates like that just like many users do because they don't understand the selection of standard date etc. And it drives us crazy when it straddles the 110 year or 8 year criteria. I will post the steps later.

Relative to your other comments. We really don't have personal preferences for dates. If someone enters their preference then that is what is used for everybody that uses that record. In other words, when I look at my genealogy, I could have dates in many different formats on the records in my genealogy depending on who entered the date. I would prefer to have all the dates in the same format. That is the purpose of standard formats. And the chosen standard format for Family Search is day month year. I am not suggesting we do this, but the way around personal preferences for display of dates is to allow a personal setting. Like you can do on windows 10 where I have mine set for day month year. But I am in no way suggesting we do that but without that, we really shouldn't allow personal preference because it is for everyone. I like the current standard format but could see changing it. I actually use the ISO format for naming files because it facilitates sorting. However, I don't think we need to the change the standard format

LegacyUser

Adrian Bruce said: I like the idea of being able to "decorate" the standard value and would be loth to lose it, even in the (sensible) cause of greater clarity. (Note that your 1908/1912 example is hugely important!)

For instance, I have occasionally added "Probably" or even "Unlikely" to the front of a date, where I feel that the previously written (standardised) value can't really be supported by a logical analysis of the scenario but, frankly, I haven't got a better value. (It's arguable that further qualifiers to the standard date formats would be a better way of doing that, of course).

Then there are times when adding some sort of description to the standard date adds something to the "story" - for instance, "Christmas Day 25 December 1066" (William the B****d's coronation after the Norman Invasion) is more memorable than a straight version of the date.

Rather more important is the scenario where the date is given in a precise form of one calendar but cannot be translated into the Western calendar - I struggle to remember this exact scenario but I think it involves calendars that are triggered by the visibility of the Moon / Sun / whatever, from a certain point. We can translate the date accurately into the Western calendar only if we assume that the weather was clear. It might not have been and therefore it makes sense to include the exact date phrase in the "other calendar" as part of the display date while standardising on a Western date prefixed by the standard qualifier "about" or whatever seems best.

LegacyUser

Wayland said: Relative as to how I got the dates of 1908 and 1912 entered it is because a lot of users don't understand selecting a standard date which is kind of unique to family search. We constantly see records where no standard date is selected. And when they tightened the criteria for ordinances, many reserved ordinances fall out because of no select standard date. Any way, here are the steps (using birth dates for this example)
1- enter the birth date of 9 Apr 1912 and select the standard, then save(assume this is done by one user.
2- another user comes along with a correction, edit the date, enter 9 apr 1908 and then click of the reason box to give an explanation and save. Do not select the standard in this step just like many users don't select a standard.

You now have a standard of 9 April 1912 and display date of 9 April 1908

LegacyUser

Gordon Collett said: In one sense we do have a personal preference for the display of dates. For example, the two contributors shown for Test Adams can come to a joint consensus as to whether they want to display dates as April 9, 1912; 9 April 1912; 9 APR 1912 or whatever without worrying about what the other 13.9 million users of Family Search think it should be rather than forcing an artificial standard that tends to change every twenty years.

I was able to replicate what happens with the date entry. I would consider this a programming bug that needs to be addressed while preserving the great utility in the proper situations of allowing more information in the date field than the standardized version has.

Basically, I would suggest doing away with the ability to click anywhere outside the data entry box to set a date without setting a standard. This function was necessary earlier in Family Tree to enter a non-standardized version of a date or place. Then when the data entry was modified it was used to enter a date or place without setting a standard at all. This is still sometimes useful for places, but with dates it seems that one should be required to select either the grey top bar in the drop down menu, one of the other choices on the white background, and to bring back "None of the above" if one absolutely needs to enter a displayed date without setting a standardized version.

LegacyUser

Adrian Bruce said: Oh dear. That's a rather good point.

There has to be some sort of flexibility - you need the ability to have a display date that looks nothing like the standard date to accommodate a non-Western calendar phrase that standardizes to a Western standard. But when it's close like that, you don't want that flexibility! Yes, I'm not at all sure how to suggest that should be programmed!

LegacyUser

Adrian Bruce said: Mmm - I am not sure how that works if I want to have just "Hogswatchnight" in the display date but standardized to the Western calendar in the other date item. It might be made to work but it's a complex set of clicks that you're suggesting, I fear.

LegacyUser

Wayland said: Thanks for the comments Setting aside the proposal to always display the standard date, let me discuss the entry of a date. I have always understood the selection of a standard date but I suspect the majority of users do not from what I see in dealing with patrons every week. But at the same time, I never understood why we required the selection of the standard. So let me give you a couple of scenarios.
1- If I enter a date in the form of 3 Jun 1920 and click enter, then save, I get a displayed date of 3 Jun 1920 and a standard date of 3 June 1920.
2- If I enter a date in the form of 3 Jun 1920 and then click to enter a place or reason then save, I get a display date of 3 Jun 1920 and no standard selected. (I just tried this again and it seems things have changed, I am now getting a display date of 3 Jun 1920 and standard date of 3 June 1920, the same as selecting enter)
3- Then there is the scenario where I got the 9 April 1908 and 9 April 1912

What I suggest is that we enter a date sufficient for the program to determine a standard. At this point, if I select the standard and save I get the standard displayed. If I select enter and then save, I get the display date as entered and the standard as determined by the program. If I click to enter a place or reason, I should get the same thing as when selecting enter. I think this would insure that we always have a standard and regardless of format, the display and standard are the same date. In this case, I don't have to select a standard but if I do, then it is the standard that gets displayed.

Lastly, there is another scenario you can look at. If I enter a date in the format of 19120410 and then select enter and save, I get a display and standard of 10 April 1912. If I enter a date in the format of 1912-04-10 and then select enter and save, I get a display of 1912-04-10 and standard of 10 April 1912. Doesn't seem consistent.

LegacyUser

Gordon Collett said: I'll agree completely that the date entry system is still neither completely intuitive nor straightforwardly explained anywhere. Here I how I have always thought it was suppose to work when adding a date but have not tested out every possible variation of these to make sure it does work the way I though it did.

In the situation where no date is in the record, that is one is adding, not editing a date, after typing in the date, one has five choices:

1) Click in the grey, top line of the drop down menu.
2) Click on one of the white lines in the drop down menu.
3) Click anywhere on the page except the drop down menu.
4) Press tab.
5) Press enter/return.



The results of each choice are:

1) The typed text is preserved and the second line of the drop down menu is entered as the standardized value.



2) The entry clicked on from the white selections in the drop down menu is entered as both the displayed text and the standardized value.



3) The typed text is preserved and "No Standard is Selected" is entered for the standardized value.



However, if one saves this entry and reopens it, one sees that the second line of the drop down menu has been added as the standardized value. This effectively makes this action behave just like (1).



This is a rather recent change in the behavior of the editing box.

4 and 5) These act exactly like (1).

The purpose of 1, 3, 4, and 5 is to allow additional calendar information to be added to the displayed text for the purpose of increased accuracy, clarity, and interest while still linking the displayed date to the correct standard date.

The purpose of 2 is to allow shortcuts in typing for those who desire to use such and prefer to type as little as possible then scroll:



So it does appear that entering new dates works just like I think it should, at least for having only entered dates in English along with the occasional named Sunday and Feast Day. I have no idea what treats the FamilySearch software engineers have here for other calendar systems or other helps that have been built in.

Wayland has uncovered one little, shall we call it, Easter Egg… [truncated]

LegacyUser

Gordon Collett said: I forgot one set of actions that is available for use by touch typists and others who do not like to take their hands off the keyboard to use a mouse or touch pad.

Type in enough of the date that the computer can recognize what standardized value you are aiming for and open the drop down menu:



Press the downward arrow key until the desired date is highlighted:



Press Enter or Tab to select that standardized value:



This is the same behavior as (2) above. Enter leaves the cursor in the date box. Tab advances the cursor to the place box.

LegacyUser

Gordon Collett said: When editing dates, there are two situations:

1) The displayed is identical to the standardized value.
2) The displayed date is different that the standardized value.

I'll cover the first one here:



After making the edit, depending on the amount of editing, one has four or five choices:

1) Click in the grey, top line of the drop down menu.
2) Click on one of the white lines in the drop down menu. (Depending on the amount of editing, this may not be an option.)
3) Click anywhere on the page except the drop down menu.
4) Press tab.
5) Press enter/return.

For edits that leave a date looking just like its standardized version, one will see this:

Case 1


For edits that bring in more information than the standardized version, one will see this:

Case 2


Here are the results for Case 1 using options 1 through 5:

1 and 2) Click top line of drop down or line of choice:



3) Click anywhere outside of data field



4) Press Tab



5) Press Enter



Doing the same for Case 2 gives these results:

1) Click top line of drop down menu:



2) Click one of the white lines in drop down menu:



3) Click anywhere outside of the data entry box:

LegacyUser

Wayland said: Gordon, thanks so much for all your effort on this. Let me comment first on your scenarios of entering a date when there is no date. First of all, my big concern is eliminating any scenario where either there is no standard saved and a situation where the displayed date (in whatever format) is different than the saved standard date. It seems recent changes have maybe eliminated ever getting a date save without a standard. Until recently it was possible to do this but I haven't been able to replicate that. I have already given one scenario where the displayed date and standard can be different. That should never happen.

Relative to your scenarios for entering a date when no date has been entered. I agree with your scenarios. On #3 where you click other parts of the page and get the no standard selected. When saved, there is a standard saved. I would suggest that in scenario #3, you display the standard that is going to be saved. It is confusing to save something different that what is displayed. This would make scenarios 1,3,4,5 exactly the same. On all scenarios after doing one of the actions and before saving, there is a drop down list available on the standard date. Selecting that provides a list of possible standard dates and a selection for none of the above. If you select none of the above you get a display like in your scenario #3 where is says no standard selected. When saving though, there is a standard save. So just eliminate the possibility of selecting none of the above on the standard date drop down. Again it is confusing to select and display something and then save something different. In your case of entering a date in the format of 4/10/40, it also confusing after doing one of the actions and just before saving to look at the drop down list on standard date, you get a list of the possible dates which you can select one of. The result seems really confusing after saving.

So in all scenarios just prior to saving, I should have a displayed date and a standard date and this is what is saved.

Because it used to be possible to enter a date without a standard saved, there are an untold number of records in the system with no standard date. I think I am right in saying in this case, things like record search(record hints), possible duplicate searches do not find those records without a standard date. That being the case, would it be possible for the programmers to do a mass cleanup by inserting a standard date based on the displayed date. This would aid in the clean up of the records. Perhaps the same could be done in the case of a different standard and displayed date. Just a thought but it would be a great help.

Gordon, you come at this with full knowledge of how the system works. I think I also have a pretty knowledge of how it works but without the inside information you have. I tend to come at this with how the system is used by our patrons. Certainly new patron and probably most of the others just enter a date, click on enter and save. I can't tell how hard it is to explain to many patrons the concept of standard date. So I just want to make sure we accommodate how the system is used by many of the patrons. Thanks again. I will post make comments on editing later.

LegacyUser

Gordon Collett said: Wayland, I don't have any inside information at all or any kind of full knowledge. All I think I understand is from staring at this screen, playing around, and noticing how things work.

It doesn't hurt that I bought a book on FORTRAN when I was 12 and taught myself a little, learned BASIC and fiddled on a university mainframe who would sell computer time on teletype machines or punch cards to anyone in the community when I was 14, and had a lot of fun using Applesoft BASIC to program my mother's Apple II when I was 16.

Now the bad news. I woke up the morning and realized the Option 3 above when editing dates is not a bug. It is a high powered featured that can be dangerous in the wrong hands but is a valuable replacement feature for one that disappeared a couple of major updates ago.

The date field used to be much better at accepting words and special characters while still proving correct standardized values. It isn't anymore and I've been missing that feature.

For example, in the oldest Norwegian parish registers, there are many entries that have no date, just the named Sunday or Feast Day, for example, Dominica 4 post Epiphan 1735. I really prefer to enter the date as it is written in the records because that is the real date. I then include, in editorial brackets [ ] my conversion of the date from a website that calculates these like this:

Dominica 4 post Epiphan [30 January] 1735

This used to provide on the drop down menu the choice to standardize as 4 January 1735 or 30 January 1735. It no longer does. Now all is get is a bunch of weird stuff:





It works a little better if I use parenthesis.



But parenthesis have a different meaning than brackets.

However, if I enter just the converted date and standardize:



Then go back and enter the information it needs and click outside the data entry box, I preserve the correct standard:



When understood and used properly, this is an important feature.

LegacyUser

Adrian Bruce said: Interestingly, your last method is the one that I tend to use whenever I'm "decorating" a standard date or place. I don't have your instinctive knowledge of what works in one go, so I usually create the standard value (date or place) first, save it (belt and braces), then decorate the display value and finally click outside the box before saving again.

That, of course, is not obvious....

LegacyUser

Gordon Collett said: Regarding explaining this whole concept of display and standardized dates and places, I realize that this is a difficult concept for many who are new to Family Tree because as far as I am aware, it is unique to Family Tree. But is is a very important and valuable feature.

A couple of years ago I put together a presentation on this, just for fun, which I have updated once since the most recent major update here. I don't think I included what we are discussing here so I should probably update it again.

If you think this would be valuable for people to view when you are trying to explain this to new user of Family Tree, feel free to share this:
https://docs.google.com/presentation/...

LegacyUser

Gordon Collett said: Hope I haven't caused too much confusion. i was focusing so much on the problems Wayland was seeing from the misunderstanding and misuse of this feature that I completely forgot that in certain situations this important feature is the only way to accomplish some tasks.

LegacyUser

Wayland said: Gordon and Adrian Maybe I am missing the point, but I think a much simpler way to enter what you want is to enter the display date you want and then do actions 1, 3, 4, 5. Then select the drop down by the standard date, This allows you to select the standard date you want without changing the displayed date and then save. Isn't that what you want.

LegacyUser

Wayland said: Under my scenario above, the actions 1, 3, 4, 5 can all be exactly the same. No need for an exemption such as #3 today.

LegacyUser

Wayland said: This same thing works on places also which really helps when entering a cemetery that is not part of a standard. Just enter the place as you want, do action 1,3, 4, 5 and select the drop down by standard place if you need to change the standard place without changing the displayed place.

LegacyUser

Gordon Collett said: Option #3 is a last resort when none of the others allows you to enter what the displayed data needs to be and link that to the correct standard. It allows you to set the standard first, then put in whatever the displayed data needs to be.

All other options require you to set the display first and then choose from a limited set of probable standardized values.

LegacyUser

Adrian Bruce said: So far as I can read (and I'm just being pedantic to be clear) - you suggest entering the display first, then the standard.

Whereas I tend to do it the other way round.

I suspect that in many, many cases, it doesn't matter which way round you do it. However, I ended up setting standard first for two reasons (if I recall correctly):
- My analytical mind regards the standard as more important (since it drives hinting and searching of Historical Records from FSFT) - therefore I prioritise that;
- Depending on how big the difference is between desired display and desired standard, if the display is set first, the desired standard may not appear in the drop down list. I imagine that this non-appearance is much more likely to happen with place-names than dates but once I found that, and deduced that it was easier to set standard first, then I just automatically use the same process for both dates and places.

LegacyUser

Jeff Wiseman said: Gordon,

I have also observed this unexpected behavior on occasion but haven't dealt with it. It is a sequence of editing/entry of the dual value date entries that produces an absurd end result.

I have not dug into the details provided here, but the thing that concerns me is this: Since the Dual value date entries and the Dual value place entries are basically built on the same premise/algorithms, does this same error being described in this topic ALSO manifest itself during the entry/editing of place names as well?

If so, it might need its own topic added.

LegacyUser

Gordon Collett said: Jeff, yes, place names work the same. There also it would come under the category of being used in a last ditch effort to establish a correct standard for a place that is not yet in the Places database and there is not a standard that is even close when the correct display name is entered.

This is a powerful tool.

Which means it can cause trouble if people are not paying attention.

Used wrongly it can lead to this:



Correctly used, it will let you do this:



There is no other way to get this correctly entered this way.

LegacyUser

Jeff Wiseman said: So does the Standard event date formate include a "None of the above"?

I suspect that it should, but just as in the places editing, their seems to be a misbehavior between entering a new value and editing an old one.

LegacyUser

Adrian Bruce said: I have to say that I'm not remotely clear what "None of the above" is supposed to mean or do. Is it transient, referring to just that transaction, or permanent, setting a value of .... Not sure what value!

LegacyUser

Adrian Bruce said: My concern is that we must not get so tied up with the North Pole / Antarctica nonsense, that we lose sight of the hugely important ability to enter names like Danmark-Norge. Given that the Standard Places team declines to enter place names that were only very short term (25y or less names are ignored I think) - and for purely practical reasons I can't blame them! - We need that ability to enter display names that are quite separate from the standard.

In the end, I think that we have to put the responsibility on the inputter to actually read the resultant names and dates.

LegacyUser

Jeff Wiseman said: Let's say that you have 2 or three very clear sources that showed a birth in "Springfield, Ohio" in the late 1800s. Let's also say that there are no counties in Ohio named Springfield. So you know that the "Springfield, Ohio" is a town or township, village, etc. in the state. But it turns out that there are 3 cities named Springfield, each in a different county (this may not really be true, but I'm just using this as an example)

So you enter into the record the known birth location as "Springfield, Ohio". But now the system wants you to pick WHICH Springfield in Ohio that you want in order to standardize the location that you've entered. But you don't know which Springfield it is yet. So in order to get past this problem, you select the Standard Event Place value of "None of the Above" (it's at the bottom of the standard event places list). This way you can INTENTIONALLY enter a non-standardized name of "Springfield, Ohio" and you can then go on with your research and hopefully resolve the "which county" issue later on.

Yes, it will be marked as a data error WHICH IT IS, but that is great! You now have a flag on that vital until the county issue can be completely resolved. In the meantime, the appropriate conclusion of "Springfield, Ohio" fills that field until more information is found.

If you didn't have that option, you couldn't even put in what little data that you KNEW was correct based on the sources currently available to you. And you wouldn't have the advantage of having those values for searchs and hints. You would have to always add them manually.

LegacyUser

Adrian Bruce said: Seems sensible, Jeff.

I suspect that in the case that you quote, I'd standardise "Ohio, United States" first, then alter the display to "Springfield, , Ohio, United States", using click-outside-the box to terminate processing (not "None of the Above" because - if it's there - that appears to empty the standard). Of course, that then doesn't induce an error....

Note the extra comma that I insert to show an unknown element - but that's not necessarily understood by all.

LegacyUser

Gordon Collett said: Jeff, I like your use of setting a red icon on purpose to indicate more research is needed so that you can find it again easily.

There is a bit of a risk, however, that someone else will stumble across it, pick one of those three counties in Ohio that has a Springfield, and "fix" it for you. This would have a pretty good change of making both the displayed text and the standardized value wrong.

There is also a possibility that the new volunteer effort to fix standards and get rid of as many red icons as possible would find your entry and someone would pick the first standard he sees for the place. This would not change the displayed place name but would have a high chance of putting the wrong standard on it while removing your marker.

The third issue is that by setting the Place as "None of the Above," you deprive yourself any hints for the item because the hinting routine is based on the standard.

Making use of what I'm calling here Option 3 as Adrian describes above and avoiding the double comma that only long term genealogists may understand at this point, you could even standardize the place as "Ohio, United States" then go back and reenter the place name as "Springfield, (Which of three possible counties is correct still needs to be determined), Ohio, United States"



At this point I think we can pretty well agree that the program works very well as designed and there are clear situations that demonstrate why it is designed the way it is.

Therefore, Adrian, I'll stop with the hyperbolic nonsense examples provided for emphasis of the risks that not understanding date and place name entry could lead to and take us back full circle to Wayland's original concern which is based on the fact that many both new and long term users of Family Tree really don't understand the program and that, unfortunately, too many users of the program just don't pay attention to what they are doing.

Let me rephrase Wayland's original example:

1) A gentleman in Family Tree shows a birth date of 1912 which is correctly standardized to 1912.

2) A user of Family Tree has found that his birth date was actually 1908.

3) That user opens the birth info editing box and types 1908 into the date. A drop down menu opens that only contains 1908. Thinking this is strange and useless, he sees no reason to click on what he just typed because what he typed looks just fine.

4) Being a diligent researcher, he now clicks directly into the Reason Statement box unintentionally triggering Option 3 and types in his reason statement.

5) Without ever glancing up to see that the standardized value still says 1912, he saves.

6) Now he is completely befuddled because the program still acts as if the gentleman is 108 rather than the 112 his birth year clearly shows him to be. Stupid program.

Now, this degree of inattention is nowhere on the same magnitude of users who merge two people born 100 years apart and living 1000 miles apart, but is there any way Family Tree can be programmed to block the unintentional use of Option 3? Something that would only be triggered by the mouse click outside the data entry box? Something like what I posted elsewhere?



Other ideas?

LegacyUser

Adrian Bruce said: I can't think of a better idea at the moment. I'd been thinking about the possibility of warning validation between the 1908 and 1912 items but that only works in that obvious case. If the Display date is in a text based calendar, it's not going to be possible to interpret that for validation.

Just don't make it an immovable modal box that covers up the 2 items in question!