Falsche Entfernung (Wrong distance)
Comments
-
When I said that is "the way that FS actually works right now" I was simply addressing the point that FS already separates the user input from the standardized value in two separate fields. That specific point is unquestionably true. I apologize if I was unclear on that point or implied that I was trying to address more of the many points made in this thread. That was not my intention.
I made no attempt to defend the way the standardized field is shown or the confusing message on the merge message that started this discussion. On those points, I fully agree with you that there are definitely improvements that can be made. I'll address those in my next comment that I promised to post.
0 -
The way that FS standardizes dates and places may not be perfect, but it currently is used for several billion dates and places in the Family Tree database and other associated databases. A large amount of code for handling the current standardization scheme has been written on the backend, on the web frontend, on mobile apps, and partner apps that interface with Family Tree. Changing the way this data is stored would be a monumental effort. That doesn't mean that it is impossible to change, but with such a significant cost, I think it's helpful to consider what could be done within the current system.
- Improve the data in the Places database.
- This is an ongoing effort. The Standards and Authorities Team at FamilySearch is constantly improving the database, and that team also welcomes user input in the Places webpage to suggest new places or corrections to existing places.
- Because of limited resources, I think it's safe to say that the Places database will never include every place that some people will hope for. There are just too many places in the world, many of which have been part of several jurisdictions over the centuries. But it will constantly improve over time.
- Improve the way that standards are entered.
- Right now, as users enter a place, they are allowed to select any standardized place, with little guidance as to which is the best choice. If I am entering a place associated with a birth in Aachen in 1960, then I really shouldn't be allowed to choose the standard in the Holy Roman Empire, or the one in Prussia, or the one that is labeled "2009-present". None of those are appropriate, but they all can currently be selected. That makes it too easy to select the wrong option.
- There may well be other improvements that could be made to encourage the most accurate selection of standards.
- Improve the display of dates and places to make the standardized field less hidden.
- As we have seen with the Merge situation that started this thread, the standardized value is hidden in many places. And yet the standardized value is the one used for many features. This makes it far too easy to have confusing results, where users reasonably assume that the displayed value is the one being used.
- Displaying both the display value and the standard value presents its own challenges. There are many pages where there are a lot of dates and places, so it could take a lot more space. I'm not a designer, but I think that with care, this could be improved.
- Teach users how to responsibly use the dual-entry system.
- Primarily, this should be done through the user interface at the time of data entry.
- Help articles could be written to better explain the standardization process; one of the them could be linked to from the data entry fields using an Info button or Learn More link.
- It's amazing how many users, even fairly experienced users, are unaware of how the standardization system works. Improving awareness could reduce errors.
- We all can improve our use of the current system
- In the collaborative Family Tree, we can find ways to improve the standardization of particular dates and places. If we note that an imprecise or incorrect standard (or even no standard) was selected, we can do our part to choose an accurate standard.
- We can propose updates and additions to the Places database. Since there are millions of places in the world, making specific suggestions, along with documentation for the reasons, is very helpful to the Standards Team.
Finally, I would commend you for the thought you've put into your proposal for a completely different system to provide "a dynamic calculation of the administrative hierarchy at any arbitrary point in time specified by the user." If you'd like that to be considered by the appropriate engineering team(s), I'd recommend that you use the Suggest an Idea page here on FamilySearch Community. Although support staff will see items posted in threads such as this one, suggestions made via Suggest an Idea will be routed to the engineers for consideration.
1 - Improve the data in the Places database.
-
Grüß Gott, @Alan E. Brown part 2
I'll answer your question in the context of dates. Although standardizing and translating dates can be quite complex, especially when we deal with the transition from Julian to Gregorian calendars in different parts of the world, dates are still simpler than places.
Which is more important: the data enterer or the visitor?
Without an explanation, the visitor cannot possibly divine the enterer's train of thought. Nor can they necessarily distinguish between a Julian and a Gregorian date simply by looking at the date itself.
I have pointed out on several occasions that dates are location-dependent. Gordon has just noted that the Gregorian calendar—established in 1582—was not officially adopted in Norway until March 1, 1700.
Consequently, there is a virtually infinite number of calendars in the world—quite apart from the fact that, alongside solar calendars, there exist various bounded lunisolar and unbounded lunar calendars.
Let us now combine my proposal for a "Standardized Location" with this realization and create a complex object in which—among other things—the applicable calendar is stored. If there is absolutely no other way to handle it, then an explanation for a date (e.g., a Persian date) can be placed in the supplementary line (see Gordon's example).
Now, the day of the week—for instance—can be calculated at any time using a well-known algorithm developed by Gauß. Thus, for a German visitor, I would present the date accompanied by the corresponding day of the week. For an American visitor, I would reorder the date accordingly, ensuring correct capitalization and comma usage. By now, surely every Windows programming language is "localizable"—that is, capable of detecting the user's linguistic environment and adjusting the date format accordingly. Indeed, even the alphabet used for display can be switched.
However, FS already handles this particular issue quite satisfactorily via its "MouseOver" display feature.
Nevertheless, given that I repeatedly encounter requests to display the localized date, it should surely be no problem to simply reverse the logic: all visitors who wish to know "what the data enterer was thinking" would then see the original date when hovering their mouse over the entry.
Herzliche Grüße vom Hans-Jürgen Scheibl
0 -
We appreciate your willingness to share your thoughts; however, it is important to clearly understand and follow Community guidelines.
Ideas posted in the Community are not forwarded to engineering. They are only visible to other users and moderators and cannot be progressed from here. If you want your ideas to be reviewed and considered, you must use the Suggest an Idea or Feedback option. This is the only channel that ensures your input reaches the appropriate teams.
Community responses will continue to direct you to these tools, and posts that do not follow this process are subject to removal after 48 hours.
These guidelines are in place to ensure feedback is directed to the correct teams and that the Community remains a respectful, productive environment for everyone.
0
