Search Bar for List Widget

[GIS_utahDEM]

I know that there is no plug-n-play option for adding a search bar to a list widget (yet), but has anyone found a work around/customization? I have a list of contacts in the dashboard that's long enough that it's not super convenient to scroll through alphabetically. I was thinking something along the lines of category selectors for contacts that start with the letter A, B, C, etc...but I can't figure out a clean way to do that. Any ideas or insight on when this would become an option are appreciated! Thanks in advance. 

[jcarlson]

Using a Category Selector with the filter option enabled works pretty well, as it presents users with a search bar to filter the selectable categories by matching text. It will only search by the field used in the selector, though, so it can be a bit limited.

If there aren't any Dashboard-specific capabilities you need, you might take a look at replicating your dashboard in Experience Builder, where the List widget does include a search tool that can search multiple fields.

[GIS_utahDEM]

Hi Josh,

I was hoping to use dashboard because I like the capabilities with arcade, and setting the visualization based on calcualted factors (I'm highlighting contacts that have not been updated recently), and enabling editing of contacts through an embedded survey123 -- which I don't believe works as well or as easily in experience builder.

Are you aware of a way to configure the category selector so its just a dropdown of all the letters in the alphabet and filters based on whether the contact name (a field in the layer) starts with that layer? The only thing I could think of was a unique selector for each letter which would be really messy. 

[jcarlson]

Ah, those are good reasons to stick with Dashboard, then.

Unfortunately, without calculating a separate field for "first letter of name", you wouldn't be able to even do the unique letter, as category selectors only operate on "equals" and "not equals". I suppose you could use a Data Expression instead of the layer itself, but that seems like a lot of work...

What we really need is a new kind of selector that can utilize "begins with" / "contains" / "ends with".