Expandable advanced search UI panel

[cpradio]

First, a few notes:

• Disregard the values in the drop downs, they are fake
• Assume that the fields related to tags, groups, categories, posted by will help you choose the type of object that belongs there

Okay, so I’m finally able to get this started, would love feedback on the wording in all of the locations you see above.

So with all that said, here is what each of those areas are related to, in the current “Search Help” detailing verbiage in screenshot to verbiage in help modal.

• Posted By (@username and user:foo)
• In Category (#category-slug and category:foo)
• In Group (group:foo)
• With Badge (badge:foo)
• With Tags (tags:one,two)
• Additional Filters (in:likes, in:posted, in:watching, in:tracking, in:private, in:bookmarks, in:first, in:pinned, in:unpinned, and in:wiki)
  • I have been unable to get multiple in:... commands to work together, hence why they are shown as one drop down (I do still need to look at the code to verify it is coded to only accept one)
• With Post Count (posts_count:num)
• Post time (before:days or date and after:days or date; first drop down determining before or after)

Not in the screenshot:

• order:views, order:latest, order:likes, because this already exists on the Full Page Search, no need to duplicate this or move it (IMHO).

So with all that said, please help me figure out the best “default” wording to use for these and if there are any significant changes that should occur in the layout itself.

[codinghorror]

Looks great! I like the word “any” versus “uncategorized” for defaults on fields where it is appropriate. Alternately leaving a field blank could mean “anything” or “unspecified” and does not need to be translated, either…

[cpradio]

Yeah, that category drop down is going to be a challenge, as it is defaulting to uncategorized, much like it does for Admins today (and I’m logged in as an admin in that screenshot). Not sure how difficult it may be to fix that, the other ones showing “uncategorized”, will be custom made most likely as to my knowledge there aren’t any areas that have drop downs listing groups or badges in existence today, so I can reasonably handle those when I make them.

As for the other drop downs with (default) in them, I haven’t a clue how that value got in there since none of this is linked up, and is just existing components sitting in the UI for now.

My next steps are to start to bind the drop downs so they actually work with the data they are to be holding.

[codinghorror]

It might be easier to just make them open input fields (not drop-downs), so the user just has to type stuff in.

The autocomplete can be worked in later, we need it for the regular search field anyhow, e.g. when you start typing @cpr or #bu it should autocomplete like it does in the editor.

[cpradio]

Okay. I can do that.

[erlend_sh]

With Post Count (posts_count:num)

I think this should be “Minimum Post Count”

[cpradio]

Okay, initial PR submitted

FEATURE: Advanced Search UI

There are some issues I need to fix, but I wanted to get feedback with what I have done.

Issues that I already know about

1. Selecting a Category, puts <Discourse. category:> in the search box (going to fix this tomorrow)
2. Selecting a Badge might be putting the wrong thing in the search term? (name is indeed correct, which brings a challenge for badges with spaces)
3. Typing user:admin or @admin in the search box doesn’t update the Advanced Search UI (same with Category, Group and Badge) – I have no idea why this is though the autocomplete plugin/component was never built to receive updates, now it can.

Everything seems to be in working order. I did have to make improvements to autocomplete, group-selector, and category-selector (and the badge_controller).

Love to get some feedback on some efficiences I could utilize and anything else you might see.

[cpradio]

I have fixed the selecting a Category (but I want to revisit it and try an alternate solution) (I have now implemented a better way of detecting the multiple category filters).
I have also improved the ability for the Badge and Group inputs to receive updates. Category and User are a bit of a larger challenge.

I’ve updated the prior post to reflect these changes.

Edited:
Updated to reflect I’ve improved the category filtering detection.

[Tom_Newsom]

Can we see what it looks like without installing a custom branch?

[cpradio]

When I get a chance to do a video of it, I will.

[cpradio]

Here you go @Tom_Newsom

Username

Category

Group

Badge

Tags

"In" Filters

Status Filters

Post Time

Post Count

All the Things!

As you can see, the username is the only field that doesn’t update right now if you type into the search bar. Username is now updated live too.

[meglio]

While this, may we also make prefixes translatable?

So, in English it will accept category:abc
In Russian, it will accept раздел:abc AND the English version as well.

any should be translatable as well.

People who know zero English struggle to use advanced search with prefixes

[cpradio]

Unfortunately, that is still well outside the scope and would require both server side and client side translations. Plus with the advanced UI, they could just fill out the appropriate field and it will put the prefix in for them… so it sort of removes the need for them to know the prefix (or at least that is the idea).

But if the Discourse Team wants it to go that direction, I can investigate it.

[Overgrow]

Thanks for great improvement, non-existent search UI is one thing non-tech people on our site were criticizing…

Just small idea: Is there any chance to do Category input the way that user can select from drop down to add categories (without having to write initial letter from category title)?

[cpradio]

Just small idea: Is there any chance to do Category input the way that user can select from drop down to add categories (without having to write initial letter from category title)?

I think that is a good idea. Consider it done.

[cpradio]

Okay, I’m officially done refactoring the component on this. I’ve just cleaned up the REGEX work in it to make it less complex and less finicky around unicode (based on my research – it seems using a-zA-Z ranges are not necessary unicode safe… so I found a way to not need them*)

At this point, I plan to make no further changes to this PR. I went ahead and squashed my commits to clean it up.

All videos/enhancements suggested thus far remain as is. The refactoring simply cleaned up the code, didn’t alter any of the UI or the enhancement to use the category-chooser (dropdown).

* for the most part

[Mittineague]

it seems using a-zA-Z ranges are not necessary unicode safe

AFAIK that would be OK for typical “English” letters.

I don’t know for certain if POSIX regex considers \w the same as PHP PCRE - i.e. “word” characters are based on locale - but I believe it does and I think that would be safer if you’re using a character class

[sam]

This is now merged in and available for testing on meta!

Big thank you to @cpradio!!!

[jomaxro]

Feature suggestion: this (amazing, by the way) new UI is not accessible from search until you enter full-screen search. That means if I am sitting here in this topic and click search, I don’t see the UI. If I click options, I get the old text based popup.

Could the “options” button redirect you the full-screen search, or add a button that does that? At the moment I have to actually type something and click enter to reach full-screen search (or right search and open in new tab). Not intuitive or accessible.

[cpradio]

I think the next step is to build auto-complete ability into the existing search so it can help populate the advanced search features. Whether that helps with intituitiveness, I’m not sure, but I believe that is the next up-coming step.

Granted, changing “options” to “advanced” and linking it to the full page search, may be something worthwhile now, since the UI now exists.