5

I'm working on a user directory widget for a B2B app. The search function is the most important part of the widget. Currently we showing the type-ahead results after 2 characters (So The user types "bo" the displayed results might be Bob Gundersonn and Sarah Flamboe). This is fine, but we're having some disagreement about how to handle near-matches or fuzzy search.

Allowing near matches would help if you typed Steven but meant Stephen. But it might be confusing if they type in Jennifer Barker, who hasn't been added to the system and needs to be created, And they see results like Jian Jan and Jeremy Simon. (which we're currently getting).

If there were no type-ahead functionality, you could just wait for a the user to enter their formal search and say, "There were no matches, did you mean. . . " But it's a little trickier with the type ahead, because as they're typing possible results are being generated, and that list changes dynamically and quickly.

What do you think is the best solution for this behavior?

Improve this question
3
  • Have you taken a look at how other typeahead implementations handle fuzzy results? Would how Google handles this work for you?
    – maxathousand
    Commented Jul 5, 2018 at 20:38
  • Can you set a degree of "fuzzyness", like at least 25% or 30% of characters in common? It seems that the suggestions you're currently getting are too far away from the request to be of any help to the user.
    – celinelenoble
    Commented Jul 6, 2018 at 0:00
  • In my opinion, making sure fuzzy, misspelled and exact searches give relevant results is more a development problem. If it is great implemented, can help a lot the user, if not it will be a bad UX.
    – Madalina Taina
    Commented Oct 28, 2018 at 19:40

1 Answer 1

Reset to default
1

I've worked on lots of search engine solutions and there's a few broad types of search as you describe.

A user will have a particular object in mind; they will use abbreviations for a thing; they may not have a particular thing in mind and want the search engine to provide a variety of possible solutions.

In the last case it's very hard to write look ahead logic so you're really legislating for the first two types of search.

The first is easiest and one you should implement and its a well established pattern. The second you could design on the proviso there a small, finite number of common abbreviations your users employ, otherwise I would advise not to bother.

Summary: look-ahead search results to match same values. Do not legislate for fuzzy searches or abbreviations unless you have evidence its common search behaviour.

But this is only half the story of look-ahead patterns! Much more here about issues such as tagging, keyboard shortcuts, hover behaviour:

https://baymard.com/blog/autocomplete-design

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.