Problems with search configuration

We have some serious issues with the search.

The success of any directory is based on the search function. If the search function is too brittle, then the directory dies.

In the eDirectory search function we have two boxes:

# 1 - What you are searching for

# 2 - Where you are searching

The sort is configured so that if you select a Category from the dropdown for Box # 1, you have to select from the dropdown in Box # 2, otherwise you get bad results.

For example:

I want to search for Lawyers in Chaguanas in the Caribfind.tel directory.

If I select "Lawyers and Attorneys" from the dropdown in the first box, and I just type in "Chaguanas" (not dropdown) in the second box, I get bad results. I get lawyers from all countries and all towns.

If I type in 'lawyers' in the first box (not dropdown), then I type in 'chaguanas' (not dropdown) in the second box I get good results.

If I select "Lawyers and Attorneys" from the dropdown in the first box, and I select "Chaguanas" from the dropdown in the second box, I get good results.

_______________________________________________________

I think that the search in configured badly. The dropdown should be just a help, a suggestion, but it should not determine how the search is carried out.

From a technical perspective, the search input should be processed based on the final text value present in the field at submission-regardless of how it got there. This is standard practice in search query parsing.

If the dropdown contains predefined territories, the search backend can still:

· match typed text to the closest known territory (normalization),

· perform partial or fuzzy matching,

· or fall back to broad search logic (e.g., "contains 'Chaguanas'").

This ensures the search engine remains flexible and resilient, rather than brittle.

By enforcing selection from the dropdown, the current implementation:

· eliminates fuzzy or "contains" matching,

· blocks valid searches,

· and allows only strict exact-match values-which is unnecessarily rigid.

A well-designed search system separates UI suggestions from backend logic. The backend should accept whatever the user entered and interpret it as the intended search term.

In short: technically, the search should treat typed text the same as selected text because both produce a valid search term. The backend should not rely on selection events but on the submitted input value.

Please address this issue as soon as possible.

I received this response from Douglas in support. He suggested that I post it on ‘Ideas’.

Thank you very much for taking the time to share such a detailed explanation about the search behavior. We truly appreciate the clarity of your feedback and your focus on improving the user experience — especially since search performance is indeed a critical component of a successful directory.

Regarding your observation:

The current search behavior — where dropdown-based selections for categories and locations are required to ensure accurate filtering — is part of the platform’s default implementation. At this time, the system interprets typed values differently from predefined taxonomy selections, which is why you are seeing differing results depending on how the terms are entered.

That said, your suggestion about treating both inputs equally and enabling a more flexible search interpretation is excellent. Enhancements like fuzzy matching, normalization, and better handling of typed location queries could certainly improve the overall experience for your users.