Experience Builder Search Functionality

[marksm_macomb]

I keep struggling with the Experience Builder search widget behaving wonky. I was able to set it up to search my feature layers and zoom to features, but I still don't understand how the text searching actually works. I do not have "exact match" enabled so the search should work as a "contains", correct? Here are some examples of that not working. 

Say I want to search my developments for "The Corners at Cherry Glen" (an existing development).

If I start searching "Corners", my result is in the suggested list as intended:

If I start searching "The", I don't get my intended result returned, or anything beginning with "The":

If I start searching "The Corners" - this is BEFORE I hit enter, nothing comes up:

AFTER I hit enter on "The Corners" even though it brought up no results prior to hitting enter, suddenly it shows up as suggested:

This makes it very confusing for the end user. I'm not sure if this is intended behavior, if it's a bug, or if there's some little setting I'm missing. I do have "Auto select the first result" enabled in the search result settings.

[RachealFarinloye]

The search functionality behaves wonkyy! I think I have come across this before, Did you make sure that your searching fields and display fields match? They both need to match

[marksm_macomb]

Yes, I do have both search and display fields matching.

[TimWestern]

The is an interesting search term.  It gets used so much in english, that it often gets treated as a noise word (ie not descriptive of anything) in other search algorithms.  Could it be search widget is doing that?

I admit though, the fact it found Theater but not The makes me wonder if its looking for The+whatever comes next, and not The as an exact match too.

[marksm_macomb]

This makes sense, because the same behavior happened when I tried searching "at Cherry" - nothing was returned at all likely due to the "at". So there must be certain "filler" words that cause the search to not return anything, which is pretty silly to me.

[ShengdiZhang]

I double-checked with the corresponding teams, and their response was similar to your guess.

When building a full-text index for search suggestions, there are a number of stop words that are not indexed because they are not considered important in a search. Stop words include something like “in”, “the”, etc.

[marksm_macomb]

@ShengdiZhang  Is there any chance that this gets re-looked at by those teams? It seems really un-intuitive for the everyday non-GIS user. Is this something that should be submitted as an idea?

[ShengdiZhang]

They told me that they would consider this case, but I can't guarantee that there will be a firm plan.

[TimWestern]

Thank you for this update.

I would not expect a quick plan for a solution on this one.  The tradition of excluding noise words from searches is one that likely predates the Web.  The reality is that the amount of use for words like the articles: a, an, the, prepositions, etc. are quite large, it is likely those noise words are treated differently specifically to avoid performance issues, and overload of suggestions.  

Imagine if someone has a local search widget tying into the ArcGIS World Coder, and the word the was a possible valid word, you could get many, many hits from places not even in you region, and they in theory could appear due to frequency and usage by more high population centers.  (I'm not speaking here as if I know how it all works behind the scenes).

For this reason, any potential fix naturally would need to weigh the positive improvement vs the potential tradeoffs it could cause.  It may not be an easy thing to get around.   My only thought there, is that words like prepositions and articles often should be grouped with the next word that follows it, without which the article or preposition dangles and lacks real meaning.   


As Laura (MVP) posted earlier on Tuesday, when you have an exact address you'd expect that to be prioritized, but the suggestions are not the actual results, and the UX is such that to many non-native GIS users, this is not clearly obvious.  

In fact I've seen searches where addresses could be, but no actual site with that address exists sometimes appears.  (like E vs W or N vs S street numbers for example).

I've also noticed that the behavior between the search embedded in the map, and a stand alone search widget on a panel somewhere, because of how they are configured behind the scenes may seem to be acting not only different in terms of results, but performance as well.

[Laura]

I found similar behavior. I have users that get irritated typing '10 1st st nw' and it comes up in the middle of the list rather the top. What comes up first and stays at the top is something like '1058 1st st nw'. I don't have exact checked either because you want options but when something 100% matches what you typed you'd think it would show as the first result.