@RMurray2, your complaint about the removal of the map pin perfectly illustrates why it needed to go away: nobody understood what it was supposed to mean.
The absence of a map pin on the old page did NOT indicate that the place wasn't "recognized". All that its presence indicated was that the display text happened to match the database location's label exactly, in the chosen interface language. Such matching is not necessarily undesirable, but it should never be a goal, given that a simple change of interface language is enough to remove it.
I am very happy to see the end of that dratted map pin.
Oh wait you are planning on getting rid of the old person page? That will be a total disaster for expert users. The new one is bloated, less readable, and ineffiecient to work on the tree. I don't understand this decision all. It is not possible to make an all in one UI for PC and mobile users. This is why mobile devices have apps.
If you want to make the right improvements, please leave the old UI as an option for expert users to get work real done.
The map pin represented data location standardization as it was a great step in making the data on a person's page easily searchable. Removing it will lead to gibberish being entered in the location data fields and create unsearchable content.
None of this is an improvement.
Is the goal of FS to get an accurate genealogy of people or to allow anyone to easily make edits to the tree?
I don't know what to say, after seeing incremental improvements over the last 10 years, all of that is now going in reverse in the last 2.
99% of the time I use my Samsung Android A12 phone. I'm rarely on a computer. I am updating people and attaching multiple records daily. The current person page is very user friendly to a mobile device and not much different when on a computer. Your new person page should be geared toward the same outcome, not the opposite.
You state to "make the page less busy" you chose to remove a tiny location symbol. Instead you've made it very busy with your giant colored banner and pencil symbols instead of clear and consice information.
I agree with CESchultz.
I know it may not seem like much to you, but making the process take longer, even just adding a few clicks and having to scroll more to see a record takes time. That time adds up over every edit or source attached.
Your new person page makes many of us absolutely dread its implementation.
Things not working on mobile phone anymore.
Unfinished Attachments: Even though the setting is turned on nothing shows up until put into desktop mode. Then the formatting causes the page to be unreadable with zoom all the way out and micro font.
When previewing a similar record from the sources page, the feedback button is in front of the X to close that pop-up. Dragging the bar to make that pop-up move is much slower responding.
Available hints are hidden. You have to open up the side panel, choose Research Help, click on the hint and then it opens up a small pop up. I don't need help with the research, I want to see the available hints. Research Help makes it sound like you are contacting someone for help. It's not a great title. It's misleading. When you click on a hint right now in the old person page it opens fully in the screen on a pop-up. Minimal scrolling is needed.
I am also noticing a definite lag in my device from all the new coding and the sheer amount of added coding. It's cumbersome and a real drag on the experience.
The formatting also does not allow the page to fit a mobile screen. The main header specifically. The personally profile, messages icon, notifications bell and more is off to the right of the screen and I'm already zoomed out as far as it will allow.
The pencil icons for editing instead of just the word edit. If we have to keep this, at least move the pencil away from the side of the screen and back in place where the edit button was in the first place. The Feed button is also very close to these.
The colored banner. It would be great if this was a personal option instead. Allow them to see it individually on their own screens rather than changing a person page. Like a theme or background that a user can change for themselves but to anyone else the banner isn't there.
I'll add more as I come across them. Trying to be helpful as you asked.
@CESchultz, like @RMurray2, you misunderstand the meaning of the map pin. Yes, if it's present, that means there is a standard selected, but its absence does NOT mean the opposite. In fact, its absence doesn't mean anything at all, really.
If I have the interface set to English, then "Bana, Komárom, Magyarország" doesn't have a pin, even though it's a standardized location, because in the chosen interface language, that location's label is "Bana, Komárom, Hungary".
Not having the map pin will not result in gibberish being accepted: as now, if the place isn't standardized, it's marked as such in red.
@Julia Szent-Györgyi the location should be standardized per language and for English the standardized English form should be used. Standards improve search results in databases and improve the accuracy of finding people and sources on this platform.
The lack of a pin DOES mean something, it means the location entered is not a valid location that is searchable in the Family Search database and thus certain hints will NOT be generated and people will not be able to locate that person or their records searching for a non-standard location or the person using that non-standard location.
You just said nobody knows what the map pin represents but FS has had campaigns here to standardized locations so I do not believe that is true at all. What happens more often is a standardized location is missing and instead of getting that corrected people start "edit warring".
Location standards need to be implemented for data accuracy and the lack of a location standardization labelled correctly as a data error which it is.
Location corrections can be submitted to the Familysearch Places Group; https://community.familysearch.org/en/group/68-familysearch-places
The new persons page obscures locaton data errors that are not standardized and instead will allow the proliferation of gibberish places that are harder to correct because the pin is hidden and the warnings not visible. Your example is a language issue which is more minor than what I am referring to or that I have frequently seen. The new person page is HORRIBLY innefficient to work on a person in the tree and the old interface needs to be retained for expert users as an option they can turn on. Expert users want the simplified interface and I am begging the engineers to keep this as an option.
On every single person I have worked on which is tens of thousands, standardizing locations generates new record hints and many times duplicate people who exist in the tree that need to be merged.
I understand what you are saying about the Hungarian standard of a place name not being recognized as an English standard.
The problem is that Hints are populated after changing a place name from the foreign language equivalent to the English standard. It happens almost every time I change a foreign language standard to the English standard that new hints will pop up that were not there before.
I wish that it could be formatted or coded to recognize both and deliver hints for both standardized place names. I can't imagine how much coding that would take.
When I do change a place name in the future I will copy the foreign language equivalent in the note.
Hopefully this will be something they actually work on.
An actual improvement to FS would be in the future adding the native language location below the standardized English language equivalent. This would obviously take quite a bit of work to add in all those locations but it could be done on a country by country basis. In the mean time for proper functionality of this platform only the English language equivalent should be used.
I really wish more emphasis was placed on standardizing locations here since it improves record hint generation and finding duplicate people, as well as making the data fields cleaner and more organized.
"it means the location entered is not a valid location that is searchable in the Family Search database"
No, that is NOT WHAT IT MEANS.
As I said, the place can be perfectly standardized and fully valid and searchable and yet lack the map pin. THIS IS NOT A PROBLEM. If there's no red text or icon, then the place is standardized, and absolutely nothing needs to be done, and in fact, most of the time, absolutely nothing should be done.
You folks are demonstrating in full glory exactly why I think removing the map pin from the new person page was one of the best decisions FS has ever made.
Technically it is possible for it to be correct without the map pin but 99% of the time this is NOT the case and the map pin ENSURES it is fully searchable. It is also not true that the lack of red error flag or an icon means it is fully valid and searchable. Family Search's error checking algorithm only flags for eggregious location errors with serious formatting issues where the algorithm is unable to determine acceptable GUESSES. This means that without the pin the location entered matches SOMETHING or more often MULTIPLE locations in the FS database but not necessarily the correct location.
Example: "Ind" can match both India and Indiana in the FS location database. This can generate useless record hints.
I see this all the time when working on records and no location flags were thrown for a person's profile but once the locations were properly standardized (map pin present), ACCURATE record hints were immediately generated.
Go to any location without the pin, edit it and press the space bar, if it suggests more than one location then it is NOT properly standardized. Standardizing all locations so the map pin shows up with ENSURE the location is properly formatted and fully searchable in the FS database. This can and almost always will generate new and CORRECT record hints and duplicate people in the FS database.
If the map pin is not there, the location needs to be PROPERLY standardized to the English language equivalent of the location and if the correct standardized location is not an option, the FS places community needs to be notified so they can correct it.
Sorry, Gordon, you're right: we've gone off on a topic that's only peripherally related. One last rejoinder and then I'll consider just starting a new discussion about map pins.
CESchultz wrote: "Go to any location without the pin, edit it and press the space bar, if it suggests more than one location then it is NOT properly standardized."
This is false. There are many, many places in the database that will always have multiple choices in the drop-down. For example, places where the language of administration has changed will correctly have at least two choices in the drop-down (although with the state of the database, those choices may be a nonsensical mix of jurisdictions and languages).
The database is also full of larger jurisdictions named after smaller jurisdictions that result in multiple choices even if the place is fully standardized (and has a map pin). This means that the above assertion is false from both ends.
Yes, occasionally the map pin can catch "India" versus "Indiana", but most of the time, the pin is missing simply because I'm using a different language than the person who standardized it, or because it's an older entry that predates someone over at the Places department dealing with Slovakia deciding to add the word "county" to counties, or because what's in the database is messed up and we're still waiting for a response to the submitted correction. Or I could be using the display-versus-standard feature on FamilySearch to its full potential, and adding the name of the outlying farm where someone was born, while standardizing it to the place that the farm belonged to administratively. Again, this is a feature, not a flaw!
@Julia Szent-Györgyi in each of you examples those are different locations.
The first one is a MUNICIPALITY that existed until 1918 and the other a POPULATED PLACE that existed after 1960.
One is a DISTRICT the other a TOWN.
I ask again: