My users find the SearchBuilder Subgroup interface very confusing.

desperado

Here are a series of screen shots and explanations on how my users expect things to work and a suggestion at the bottom for a more intuitive method of creating condition "indentation of depth".

Let's say I am trying to build a query for two columns. What I want is described in sql terms as
where (status = "approved" or status = "submitted") and sfi = 'Yes"

You can't indent your first condition until you add at least one item so you add your first condition.

Notice there is no > yet. So you still can't create the or combination. So your instinct is to add your second condition.
Like this.

So now you know you want to create the "and" condition. So again your instinct is you need to indent the depth of your current "or" but clicking on either > just indents that condition and the other condition is now in the wrong place.

The users instinct is "If I indent the second it should be paired with the one before it.
But that is NOT what happens. This happens instead.

The user is confused at this point on how to fix it. What they have to do is remove the second condition and then re-add it t the first indented condition.

My Suggestion to improve the interface

I think it would be preferable to have the < and > buttons next to the "And" and "Or"

So assuming I had a > button to the Left of the "And" condition seen here.

I could press it and the result would be this.
(NOTE: really both conditions could have "Data" since the > could be present right from the start.
I can not simulate this so I have to make this screen shot with a value in the indented condition.)

I think that would be much more intuitive.

I am interested in what others think especially the developer of SearchBuilder.

sandy

Hi @desperado ,

Creating subgroups is restricted until there are multiple conditions within a group so that the user cannot create endless sub groups. There is no need to create a subgroup unless there is going to be another condition outside of it. I think that adding that ability it only going to allow users to make things more complicated for themselves.

The user is confused at this point on how to fix it. What they have to do is remove the second condition and then re-add it t the first indented condition.

I don't think this is hard for people to work out. You're solution is correct, the best way to use SearchBuilder when implementing complex queries is to create enough conditions for each sub group and then work your way deeper, repeating for each group.

This is the first time anyone has suggested anything along these lines, and given the number of people that are using SearchBuilder I would be reluctant to implement such a change unless there was significant further interest from other members of the community. If enough other people express interest in this then we will consider it further.

The proposed changes would also involve adding more buttons to the UI. This is something we are keen to avoid to keep the UI as simple as possible.

Thanks,
Sandy

desperado

@sandy I understand. I sort of expected this answer, since I realize how difficult it would be to make the switch. I don't think you could actually just switch to my idea, since your existing users might not like the change. You would probably have to make an optional modal for my version which would really complicate the code.

Thanks for considering it anyway. Perhaps if you get other such comments my suggestion will help you do a redesign so it was worth making the request

I personally found the interface confusing but of course I was able to work it out. When I demo'ed it to my users they found it extremely confusing as well so I thought I would bring up the issue and make the suggestion.

colin

That's interesting, as other feedback has been positive, saying the interface is intuitive - this thread is some of the very early feedback for example. We'd be interested in hearing from other users who read this thread what their thoughts are on the usability.

One thing to consider is that this is entirely open-source, so you can modify the code anyway you choose to suit your user base.

Colin

tangerine

Hi Colin.
I don't use the SearchBuilder, mainly because I don't like the UI.
I haven't mentioned it hitherto, as it's not much use just saying "don't like it" without providing any detail explaining what I might prefer. I have too many higher priorities
right now to spend serious time figuring out a new UI.
Just telling you to keep discussion alive.

colin

Hi there. Definitely. This thread, or the other thread I linked to, are good places for people to put their thoughts, and we'd certainly welcome your opinions if you ever have a spare few minutes to list the things you don't like!

Cheers,

Colin

desperado

@tangerine Thanks for your feedback. I am curious, if you have time to look at my suggestion, does it address your concerns with the UI ?

sinfuljosh

I have a site I am working on that they have trouble working through the search builder also and prefer using a set of inputs/selects to filter similar to the classic columns style listed in examples.

I would love to know if there is an option to use the search builders conditions and logic and incorporate it into our own preset filter inputs (mainly for the range and other logic filters that are not just a search)

desperado

@sinfuljosh Thanks for your input. Do you think the design idea I suggested would make it any easier for your users if your approach is also not allowed?

allan

@sinfuljosh Do you mean like this: https://datatables.net/examples/api/multi_filter.html . That isn't really what SearchBuilder is trying to achieve - it is trying to allow a more complex sort of logic - A || (B && C) for example. If simple text input / selects are all you need, then the example I linked to would be a good starting point.

Thanks,
Allan