|
|
When entering a place in the text field, WeRelate returns a dropdown with matching places. I believe it's sorted by places that have recently been used by the user, then alphabetical (or something simlar). I think that the dropdown should find exact matches first, so, if you start by typing "Texas," the first results should start with "Texas," instead of "Austin, Texas, United States" or whatever the first alphabetical result is.
- I like having recently used places that match the input token(s) first. It is a great time saver because working on a group of related people, most events tend to occur in the same place. Whether or not scoring of matches changes, I believe recently used places should continue to come first.
- Some of the confusion may be that the logic of the drop down list is not obvious. For one thing there is matching of alternate names. For example, "Boston" gives a list that includes Amazonia, Andrew, Missouri, United States. Perhaps it could be displayed as "Amazonia, Andrew, Missouri, United States (aka Boston)" or something similar to let it be known it is an alternate name? Perhaps matching alternate names should be scored lower?
- Perhaps a Help page could be added that would explain the searching and ordering as currently implemented so people are better able to figure out how to get predictable results, as in, is it better to type in "Boston, Mass" or "Boston, Massachusetts" or "Boston, Suffolk" to seed the drop down list (the last one gives the smallest list, the other two are the same). Why "Narragansett" matches Bedford, NH (alt name is "Narragansett Number 5"), and Narragansett Terrace, RI, but "Narragansett," (i.e., with a comma) only matches the second (when it seems it shouldn't match either?) In the example above, "Texas" actually has a place in Mississippi at the top of the list, and Austin wasn't even in the subset of Texas locations that were able to fit in the drop down list (the subset gets truncated first, then sorted?)
- See also, WeRelate:Suggestions/Cemetery pages only on burial location.
- Is this the same logic used to find default places in GEDCOM upload? --Jrich 17:25, 11 November 2012 (EST)
- I should have mentioned that. I agree that having recently used places first (or at least very near the top) is a good choice - it's just the alphabetical list after that which is a problem. -- Jdfoote1 20:56, 11 November 2012 (EST)
- What if we were to sort alternate name-matches after the primary-name matches? So the list would be in three sections: recently-used places, primary-name matches sorted alphabetically, and alternate-name matches sorted alphabetically?--Dallan 13:19, 20 November 2012 (EST)
- Probably won't know how many people like or don't like it until you try it. For example, people that tend to use historical names might not like it since they might be using largely alternate names in their GEDCOM. However, people that rely on the drop down menu should just be typing the beginning of what they want, so perhaps "starting with" is a good criteria for the drop down menu. My point in mentioning alternate names was more that I think including those alternates is confusing to people not familiar with that name, because they don't understand why that entry was brought back in response to their partial name. So, I think part of this is a user education problem. Personally, I can usually find the place I want, and if I can't I do a full-blown search. The other thing to consider is to differentiate the matching algorithm based on city, county, state, country. For example, Texas,,, would favor those names with Texas in the city name, while ,,Texas would match items at the state level. ??? --Jrich 15:37, 20 November 2012 (EST)
- I may be misunderstanding what you are proposing, but that sounds like it's still not solving the main problem that I'm talking about, which is that matches where the query string matches the beginning of the result string should be at the top of the list (e.g., a query of "Texas," should return "Texas, United States" before "Austin, Texas, United States"). -- Jdfoote1 17:24, 20 November 2012 (EST)
- I hope I don't need to return different results based upon comma placement. I'm hoping I can sort results that match on the text before the first comma (matching on the primary name) before results that don't match the text before the first comma (matching on an alternate name). I could then sort each set of results by string length instead of alphabetically. So if you entered "Texas", you would see "Texas, United States" before "Texas, Missouri, United States" (longer string) and also before "Austin, Texas, United States" (text before first comma doesn't match).--Dallan 23:49, 20 November 2012 (EST)
- I think that sounds good. I don't even know if you necessarily need to do the sort by string length, as long as you are matching on text before the comma first - e.g., I don't think it's unexpected or bad for "Texas, Missouri, United States" to be returned first for the query "Texas,", but hopefully "Texas, United States" is first for the query "Texas, Uni". Either way, I think that this definitely solves the (admittedly small) annoyance that I had with this search. -- Jdfoote1 08:57, 21 November 2012 (EST)
This suggestion has been implemented. Dropdown place search now lists:
- higher-level places before lower-level ones
- primary names before alternate names
- places following the located-in path before places following an also-located-in path
- places that link to existing people before places that don't link to anyone
- single-word place names before multi-word place names
In addition, you can now select an alternate name or an also-located-in path and the title-bar-displayname format will be entered into the place
--Dallan 21:19, 4 November 2015 (UTC)
- How does this relate to the posting on WeRelate Talk:Support. In other words, when when I type in Norton, Bristol why does the list show Norton, Bristol, Plymouth Colony? Where is this coming from? There is no place page for it. There never was a town called Norton in Plymouth Colony (it was North Taunton precinct until 1710 when it was made a town called Norton, and Plymouth Colony became Massachusetts Bay Colony in 1691). What rule causes it to sort before Norton, Bristol, Massachusetts, United States even when the latter had been selected on previous edits? Has recently used been removed as a criteria for ordering? --Jrich 21:37, 4 November 2015 (UTC)
- Answered on the support page.--Dallan 22:13, 4 November 2015 (UTC)
|
|
