3

I've created this example search field, with toggles on each end (the dots/ellipses) allowing you to toggle between 'starts with' and 'ends with', because I was hoping to stay away from the ideas in this UX.SE question and its answers, for the reasons mentioned in the question, as well as the comments on the answer that suggests auto-complete functionality.

However, besides my example not really being finished yet, I'm far from convinced this is clear/intuitive enough. Surely though, there must be a concise way to make something similar like this work. Do you have any ideas how to improve this search field, to allow for easily toggling between 'starts with', 'ends with', 'contains' and 'equals', without cluttering up the real-estate and without the need for users to use input characters (regular expression-like and/or SQL-like syntax, etc.)?

Here is a very rudimentary mock-up of the envisioned UI: mock-up of UI As you can see it's a very basic UI, much like any other data table/database-style application. The 'search:' row is where the intended fields are supposed to come. There's probably going to be one or two additional columns ('created' and 'modified') as well, which will have date-range search fields.

I've enhanced my example field a little, with some JavaScript, to have the placeholder text give cues about what the toggle combinations mean, but I don't know if that improves matters much.

Here's a second iteration, based on @AndrewMartin's astute remark that there appeared to be a rendering bug, because of the missing side-borders. I have to say, I have the feeling it's slowly going somewhere now, but I'd still much appreciate your feedback/additional input/alternative ideas.

I've created a different concept with a cogwheel that shows the options on hover (which looks good in Firefox, but terrible in other browsers, I just realized), inspired by @Alvaro's suggestions. I'm still curious to hear your feedback and/or alternative ideas.

Improve this question
4
  • In my opinion, the question you link has a clear approach. Select box with "Starts with" "Ends with" and the search field. Why do you want to stay away from these?
    – Alvaro
    Mar 9, 2017 at 13:18
  • @Alvaro Because, as mentioned in that question and in my question, it clutters the UI real-estate. I will have multiple of these fields next to each other, one above each column of a data table. Extra drop-downs will take up way too much space.
    – Decent Dabbler
    Mar 9, 2017 at 13:24
  • 1
    Then maybe the problem is not with the selector but with some other part of the UI - The solution Alvaro proposed is a recognised pattern and easy for the user to understand. The solution you proposed needs to be explained first: My first thought was that you had a bug and the first part of the search box was not rendering correctly. Could you share the rest of your UI to help us understand the reason you can't use a select box? (even a sketch in the built-in mockup tool would do)
    – Roux Martin
    Mar 9, 2017 at 13:34
  • @AndrewMartin I've added a mock-up. Hope this clears things up a bit more.
    – Decent Dabbler
    Mar 9, 2017 at 14:13

2 Answers 2

Reset to default
2

The user needs to take two decisions:

  • Starts with, Ends with or Contains
  • Query to search

The way to approach this could be:

  1. First decision in one element & Second decision in a second element (2 elements)
  2. Both decisions in the same element where you need as many elements as possibilities (3 elements)
  3. Both decisions in the same element (1 element)

If you decide to take approaches 1 or 2, you could try to reduce the design and size of the elements but the more you reduce, and go away from an established UI, the less understandable it will be.

Some solutions for option 1, could be:

  • Select input (Starts with | Ends with) + Search field
  • Toggle buttons (Starts with | Ends with) + Search field
  • Toggle button (Starts with) + Search field + Toggle button (Ends with) This is the one you propose

You could also hide the second element and show it after the first decision is made (for example some kind of auto suggestion appears when the Search field is focused where the user can select between "written text..." "...written text"). Or this other idea:

For option 2, as an example, I meant three Search fields where the placeholder of one says "Starts with", another "Ends with", etc. and focusing one disables the others.

The problem with option 3 is that it will be difficult for the first-time/average user to know before hand he can (should?) make two decisions. This pattern can be seen in the search field in Evernote (search a term + tags) or Google (you can make use of "exact term" or filetype:pdf).

Improve this answer
4
  • Thank you very much for your input. I've incorporated your placeholder idea together with Andrew Martin's critique about the apparent rendering bug. I thinks it's slowly going somewhere now, but I'd love to hear what you think about it.
    – Decent Dabbler
    Mar 9, 2017 at 15:09
  • @DecentDabbler The problem with using the ellipsis is that the meaning is not intuitive, and I'm not sure relying on the placeholder for it helps as much as it should. If you really need to display only one element then I would use two but hide one. Take a look at this JSFiddle.
    – Alvaro
    Mar 9, 2017 at 17:06
  • I agree about the ellipsis' meaning. And even though your jsfiddle example is not exactly what I was aiming at, it has given me an idea: how about a little cogwheel at one end of the field, which pops up the list of choices? I'll make an example later on and put it in my question. Thanks again for your input.
    – Decent Dabbler
    Mar 10, 2017 at 1:55
  • I disagree with the field order. Usually, searching for a few letters somewhere is good enough, so it should be the first field (using implied "contains"). Then you may refine the search with more letters and/or options like "starts with".
    – maaartinus
    Jun 29, 2017 at 12:47
0

Why do you need to create a special input box that is not familiar to users?

Wouldn't it be better if you include operators:

  • contains:
  • startwith:
  • endwith:
  • equals: or "=="

If users want to search a value that includes the string "John", they will type "contains:John".

This way you wouldn't need any special form field which may bring considerable confusion among users. However, there might be security issues with this approach and it should be consulted with a security specialist.

Improve this answer
4
  • Thanks, but my application is not necessarily targeted at a tech-savvy audience. Operators or any other form of syntax is too technical, for my taste. I was hoping we could come up with something that is clean, concise and intuitive, for a non tech-savvy audience.
    – Decent Dabbler
    Mar 9, 2017 at 16:29
  • @DecentDabbler Don't mention it. Is it an application that users interact with every day or they rarely use it?
    – Kristiyan Lukanov
    Mar 9, 2017 at 17:41
  • 1
    They'll probably use it infrequently. @Alvaro has given me an idea though. I think I'll try to make a field with a little cogwheel at one end, which pops up a list of choices. Will add it in my question, when I finished the example. Thanks again.
    – Decent Dabbler
    Mar 10, 2017 at 1:58
  • @DecentDabbler Yep, then Alvaro's example is a good one.
    – Kristiyan Lukanov
    Mar 10, 2017 at 9:53

Your Answer

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

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