5

I am building something that allows users to search (for things like words, hashtags, etc) and apply this search to a report that they have built off of twitter posts. So for example, a user that works at Nike may want to search their report that is all about Nike for mentions of the word "Adidas" to see what people think about their competitor. They may also just want to exclude the word "Nike" to get rid of that data and see what else is mentioned.

I am having a few issues here, but he is some things I'd love feedback and help on:

1) How to make it apparent what is being excluded vs included?

-I could make the "buckets" here Included and Excluded and just place all applied filters under each, instead of making the buckets the search type (ie: Author, Hashtag, Text, etc). Or there could be a combination of both? I am not sure which is more important to users at this moment.

2) Does one search make sense? Should I have a search for both include and exclude? or a search for each search type?

3) Does having the is/is not dropdown next to the search box make sense? Should it instead be next to each item?

So many questions! I would love some feedback on what makes sense and what doesn't in general to all of you as I ideate.

Current solution:Current solution Past Ideation: past ideation Thank you!

1
  • This is very interesting! I like the version with the dropdown next to each item, because a selection could be made by accident or i want to change it later for some other reason. "is" and "is not" are binary options, so the idea of having something like a switch came in my mind. This would save one click on each dropdown, but I have no final answer yet.
    – rhauger
    Jul 2, 2018 at 19:53

2 Answers 2

0

1) You could make it more apparent to which category each individual rule corresponds. E.g. coloring them green/red or replacing the IS/IS NOT with the mathematical symbols for equals/equals not or adding plus/minus signs somewhere there. I personally like that they are grouped under their search type buckets. It makes more sense because then you can see what values would be allowed for your Post Text, for example.

2) One search seems fine. I find it a bit weird that the search field starts with "Is not". Usually you specify which search type you want your query to work on (e.g. "Post Text") and then the operator and then the values (e.g. <2134>). I see that you want to include a convenience/efficiency function for the users there, so you guess the search type from the input which is also a nice idea.

3) It depends on the queries the users make. If they are long and complex (which is not the case in your example), it may be nice to give them the option to correct their input without having to type everything again. But then there should also be an option to edit the "values" field. But that also makes the UI more cluttered.

0
0

How to make it apparent what is being excluded vs included?

I assume the grouping by criterion (author, text, URL, etc.) is good. People do not have "positive/negative" groups in their heads; they care about the criterion first.

Does one search make sense?

Again, I think the first solution is good. Adding more search boxes will create more clutter and more load to decode the clutter.

Does having the is/is not dropdown next to the search box make sense?

Here is where I would start to change your proposal.

  • I agree with @Nash that I would have the positive condition ("Is") as default one.
  • I am a little bothered by the "is/is not" terminology. That sounds like I need to type in the complete text to match, whereas I hope that partial matches will also be listed: Searching for "Nik" should also bring up all "Nike" matches. So the condition is actually not "is" or "equal", but rather "contains" or "starts with". That's longer, and I see the point on small displays, but maybe there's a way to convey this meaning better. (For #tags, the condition probably really is "equal", introducing some more distinction... Maybe using "is" on the search control, but the more appropriate longer term on the search condition header is a solution, see next bullet.)
  • The display of the conditions can be simplified by moving the "is" (or "contains") into the header: Use "Post Text contains:" as header, and use "Nike" and "NOT: Underarmour" as entries. Less clutter, quicker readable.
  • Whether it is useful to be able to flip the NOT in an existing condition depends on you use case. What happens when there are no (expected) results? Will your users be content with the empty list, or will they frequently want to flip to the opposite condition to view the matches for the rest of the search conditions? I would probably only keep the "x" to remove the condition, because removing the condition should then bring up the same list as when flipping the NOT on the condition.

One last remark: Are you really sure anyone will remember (and type in) the post ID? That's way too many meaningless digits to be a useful search criterion in my view (except you have a value help, or favorites, or similar mechanism which helps users to enter this number).

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.