topic Re: Experience Builder Search Functionality in ArcGIS Experience Builder Questions

Experience Builder Search Functionality

marksm_macomb — Tue, 04 Jun 2024 15:57:24 GMT

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.

Re: Experience Builder Search Functionality

RachealFarinloye — Tue, 04 Jun 2024 17:37:53 GMT

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

Re: Experience Builder Search Functionality

TimWestern — Tue, 04 Jun 2024 18:22:16 GMT

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.

Re: Experience Builder Search Functionality

marksm_macomb — Tue, 04 Jun 2024 18:31:47 GMT

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

Re: Experience Builder Search Functionality

marksm_macomb — Tue, 04 Jun 2024 18:34:29 GMT

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.

Re: Experience Builder Search Functionality

Laura — Tue, 04 Jun 2024 20:37:04 GMT

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.

Re: Experience Builder Search Functionality

ShengdiZhang — Fri, 07 Jun 2024 07:45:56 GMT

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.

Re: Experience Builder Search Functionality

marksm_macomb — Fri, 07 Jun 2024 16:04:53 GMT

@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?

Re: Experience Builder Search Functionality

ShengdiZhang — Tue, 11 Jun 2024 02:42:39 GMT

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

Re: Experience Builder Search Functionality

TimWestern — Tue, 11 Jun 2024 11:55:00 GMT

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.

Re: Experience Builder Search Functionality

JenniferEyre — Sat, 15 Jun 2024 10:45:33 GMT

You were able to set up your Experience Builder search function to search your feature layers - can you tell me how you achieved it? I'm struggling with that at the moment.

Re: Experience Builder Search Functionality

Laura — Mon, 17 Jun 2024 13:10:07 GMT

https://doc.arcgis.com/en/experience-builder/11.1/configure-widgets/search-widget.htm

New search source - layer source - select layer & configure

Re: Experience Builder Search Functionality

tasubasu — Mon, 07 Oct 2024 01:57:33 GMT

I have come across a similar issue. It appears the search widget searches well if you copy and paste a whole address, but... if you type in an address it slows right down. In developer tools it looks like it does a new search for each string you enter using "%LIKE%" to look for that text, and it starts a new query for each character you add. So it's not using begins/starts with. So it's slow to load results unless you copy and paste a full string. Can this be improved through configuration? Or is it strictly the Search widget in-built settings?

Re: Experience Builder Search Functionality

ShengdiZhang — Wed, 09 Oct 2024 07:21:45 GMT

Hi @tasubasu ,

Which version of Experience Builder are you using? For ArcGIS Online, using "begin with" to query suggestions was introduced in November 2023. For ArcGIS Enterprise, it's available from version 11.3 onward.

and it starts a new query for each character you add

Currently, it is by design that new requests are sent to query suggestions whenever the search input changes. We're considering modifying this behavior by not sending requests if the user has disabled search suggestions. We'd like to know if this potential change would address your concerns.

Regards,

Shengdi

Re: Experience Builder Search Functionality

tasubasu — Thu, 10 Oct 2024 23:43:24 GMT

Hi Shengdi,
Thanks for your reply. We are using ArcGIS Enterprise 11.1.

Good question, I think the option to disable search suggestions would be useful, but with the introduction of begins with in later versions I think we wouldn't need it ourselves. Thank you.

Re: Experience Builder Search Functionality

TimWestern — Tue, 15 Oct 2024 13:35:39 GMT

I have seen similar slowness in EXB with the Search Widget (not to be confused with the map search, which at times seems to feel like its acting differently)

I recently had one that I reviewed all the fields it was querying, and realized that sometimes the 'auto' search while type may be making the searches take longer, specially if you have layers being queried that are less likely to be normal selections. For me I updated which ones were searched vs what was displayed, and it began to act much much faster. It may depend on how much you are querying though.