Expandable advanced search UI panel

Feature
43

PR for Tag and Post Time
https://github.com/discourse/discourse/pull/4496

2 Likes
44

So I just took my first detailed look at the new UI, and have a question/concern. How can you select multiple Only return topics/posts that... options? It seems that clicking on another option replaces the current option in search, as opposed to appending it.

For a specific case to test, I wanted to search for this:
in:wiki in:watching in:likes

45

Right now, you canā€™t. You can add additional ones to the search input field at the top and it will retain it, but the UI doesnā€™t add them.

46

I believe some of the more high value options in that drop down should be standalone checkboxes.

47

Which ones in particular? I can try tackling that later tonight. :slight_smile:

Granted, select2 supports Multiple (which is used for the dropdown), so it might be simple to convert it to a multiple container. I can play with either approach.

48

Donā€™t do multiple select that is a usability nightmare. Use your judgment as to which ones are high value, likely to be useful and thus used reasonably often, and make those checkboxes.

49

Sorry, when I say multiple select, Iā€™m talking similar UI as Tags, but it is a finite list and will then show as boxes like the tags selector does to for easy removal.

Example located at
https://select2.github.io/examples.html#multiple

1 Like
50

I donā€™t think that UI metaphor fits well here.

51

Okay, fair enough, checkboxes will be my main focus then as I donā€™t have a strong opinion on the matter and both are likely the same amount of work.

52

What doesnā€™t fit? I agree that we donā€™t need the boldface headers, but the multiple selectability fits perfectly.

53

I didnā€™t get to the multiple in: scenario last night, like I had hoped. I had to do a refactor and improve how it finds matches before I could sustain this feature. I completed the refactor and it should get merged sometime today (now that Iā€™ve squashed the commits)

https://github.com/discourse/discourse/pull/4495

The biggest hurdle that I had to get around was the ability to know ALL of the matching blocks at the time that I update the UI and the search-term field. Otherwise, it would have been extremely difficult to know which match I was supposed to update/remove.

Iā€™m hopeful I will find time to work on this request today. :slight_smile:

3 Likes
54

Okay, here is a mockup of it using checkboxes (it is actually functional too, but I want to play with it a bit before commiting it ā€“ plus I need to update the acceptance tests still)

Pasted image860Ɨ428 8.55 KB

Mobile Layout, which needed a lot of love

Pasted image390Ɨ617 23.6 KB

6 Likes
55

Now that I can see it live here on meta I think that UI is major improvement! I very appreciate it and my members will too!

Just a question, ā€œIn Categoryā€ allows only single category? I donā€™t know how difficult would be to allow selecting more categoriesā€¦ Is it easily doable?

1 Like
56

I donā€™t think that request makes sense, as right now, it would mean nothing gets returned. As it is filtering the results by the first category and then it would filter them again by the second. And topics canā€™t exist in two categories (which is how the existing search works ā€“ keep in mind, I didnā€™t do any improvements to existing search, I simply built a UI to handle the advanced search parameters).

7 Likes
57

Ok, no problemā€¦ I was not aware of that conjunction ā€¦

58

Hmm right now ā€œanyā€ can be selected in the combobox while the checkboxes are still checked. I find that having two different ways of selecting options under a single label is confusing.

Perhaps we can just make all the options check-boxes but dynamically disabling options so that we can protect users from checking options that donā€™t go well together. Examples:

  • ā€œin:privateā€ and ā€œin:wikiā€ will always not return any results since you canā€™t wiki a private message.
  • Disable ā€œin:pinnedā€ when in:unpinned is checked and vice versa
59

I defer to @codinghorror. I really do not have a strong opinion on the matter, it was suggested that 3 be choosen to be checkboxes to permit the multiple in: possibilities, not all of them. The ones left in the drop down can still be used so this gives 4 quick possibilities to choose.

Although Iā€™m not against adding precautions to prevent people from mixing conflicting possibilities, Iā€™m not sure it is worth the added effort to code and maintain it when the worst that can happen is zero search results. The user will alter their query when that happens automatically, they donā€™t need to be told to do it. /shrug

3 Likes
60

I think the way it is now is fine. If someone wants to make the case that option X is also common enough to be elevated to discrete checkbox that is fine.

1 Like
61

The checkboxes were merged in today.

There was a lot of refactoring done to help lessen the complexity of the code and a few more acceptance tests were added to cover some edge cases uncovered.

4 Likes
62

Iā€™m trying the new advanced search and if I try to search without login it is impossible choose a category (but I can choose a @user). Is it normal?

If you use the category box and you have a category + sub-category (not short but not too long) the sub-category goes in a new line. Is it possible make the container a bit longer? Take a look on the category box for new topic.

4 Likes