6

Wanted to get your input on different methods for implementing these sort of operators for search fields.

I've seen it done mostly by adding an extra dropdown option before each field with these options (Apple uses this method a lot)

mockup

download bmml source – Wireframes created with Balsamiq Mockups

However this takes up a lot of real-estate on the UI.

I would like to keep it within a single input field and maybe introduce filtering from how the string is entered:

  • Contains (default): John
  • Begins with: Jo*
  • Equals: "John"

This would be a training issue initially, but once you learn it much quicker, and minimal UI impact on current design.

1
  • I think "Beings with" overlaps with the functionality of "Contains" so it's more or less an overkill for a name search. I'm not sure what the context is for you but generally users know the name of the person they're looking and "Beings with" is an advanced search setting which can probably be hidden within the "advanced search" link. Again, it'll help with more context on how the search is used.
    – Poyi
    Commented Sep 26, 2013 at 21:08

3 Answers 3

8

Something that requires zero learning efforts, less cognitive and memory loaded and provides more rich logical relations is:
enter image description here
So the proposition is to display search results in ordered way including occurrences from first name to last name. The relations will not be built in mind but recognized and picked from the search result. Recognition over recall!

Advantages are:

  • No learning required – just type a fragment.
  • Less cognitive and memory loaded: human is great in recognition operations. He looks at result, recognizes and recalls a person being searched. In contrast to:

    1. Constructing in mind relations of name fragments (start with, contains, etc.),
    2. Mapping the relations in mind to interface controls.
  • More logical relations: beyond Start with, Contains and Equals there are more relations. So for not to develop own search language, just sort the results in proper way.
  • More error proof as relation could be built wrongly in mind (fragment is not in first name, as someone thought, but in last name).
3
  • 1
    It may be easier, but it is also less exact because of the "more logical relations". So it largely depends on the context in which the search/filtering will be used. For example searching for products in a product database and the intent of the filter is not to locate a single item but to specify a set of items that you want to operate on. Here you don't want the extra "logical relations" as that could include items that are completely unrelated to what you are looking for. Commented Sep 27, 2013 at 12:23
  • @MarjanVenema, I totally agree with you, it depends on context. So I think in the context of user names it has sense. For example, "Second name begins with", "Souns like", and other relations do improve searching, but they are not presented in question. Maybe you can end up with strong search language for user names. I proposed other option. Commented Sep 27, 2013 at 12:34
  • Oh yes, for names I'd prefer not having to specify any specifiers (starts with etc) as well. Commented Sep 27, 2013 at 17:47
2

Here is a nice article by Smashing magazine on building effective search forms: http://uxdesign.smashingmagazine.com/2009/12/08/principles-of-effective-e-commerce-search/

I think what you did looks very similar to this http://www.myfonts.com/search/ (mentioned in above article) and it seems to be working fine for these guys. The difference is: their search form can be customized, as they allow the user to remove unwanted filters (to save on screen space).

0

Here is an option for a way to combine the input fields. There can be alternate options for this as I don't think the icons are intuitive enough.enter image description here

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.