We’ve got some excellent advanced search options in Discourse at this point, but the UI for them is… how shall I put this…
… uhhh… bad? Yes, I believe the word I am looking for is “bad”.
Recently, I was pleasantly surprised to discover the advanced search in NodeBB is really quite good! In any full page search result there’s this little expandable “Advanced Search” panel:
I am not proposing any change to the current advanced search options in Discourse at all, merely building UI similar to this around the advanced search options we already have.
My hope is that since this is mostly a UI task, and scoped to the full search results page, it could be taken on by someone in the community. A simple V1 that gets the basics of advanced search UI in, would be perfect. If anyone is interested, we’d be happy to sponsor it.
I’d really like this to include some Slack-like auto-suggestions for the search input field as well. Like when you start typing in: you get a drop-down suggesting “in:likes, in:posted, in:watching” etc.
I don’t disagree, but … that is quite a bit of scope creep given that @username and #category autocomplete should work there as well… I’m also not super convinced that the casual audience is going to be able to use autocomplete for advanced search as effectively as a simple fill-in-the-blanks form, so it’s unclear what audience would really benefit from that big chunk of work.
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.
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.
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…
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.
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.
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
Selecting a Category, puts <Discourse. category:> in the search box (going to fix this tomorrow)
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)
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.
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.
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.
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)?
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).
