Expandable advanced search UI panel


(Mittineague) #23

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 Saffron) #24

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

Big thank you to @cpradio!!!

(Joshua Rosenfeld) #25

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) #26

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.

(Jeff Atwood) #27

Yes, I agree – clicking “options” should trigger full page search with the Advanced panel pre-expanded. I’ve removed all the old search help copy entirely to expedite this.

Advanced Search UI
(cpradio) #28

I’m going to throw this on my plate for this week in my spare time (hoping I get to it tonight)

(Jeff Atwood) #29

One minor tweak. When filling in the user and populating the search field, don’t use


but instead


(Sam Saffron) #30

That old search help copy was a nightmare to localize and maintain, it will be really nice to get rid of it all.

(Jeff Atwood) #31

Yes this is a case study in “better UI” replacing “bad help pages”.

(cpradio) #32

K, will work that in tonight too. :slight_smile:

(cpradio) #33

This is done. I also updated the qunit tests so they stopped failing due to the removed markup from


(cpradio) #34

PR Submitted

(cpradio) #35

Seems the removal of the old search help broke the build by making eslint unhappy. I’ve fixed it (just waiting on build to run to verify it is fixed).

(Jose C Gomez) #36

Any chance this could also give an option for number of results returned? Still getting killed by MAX 50 results issue #WishFullThinking

(Penar Musaraj) #37

Cool, this looks good. Two questions:

  • should the label be “advanced search” now, instead of “options”?
  • I liked the Google search form in the previous help message, it would be nice to keep it as a link at the bottom of the advanced search screen, any intereset in keeping it?

(Alan Tan) #38

Some :bug:s/UX issues

  1. The default for “In Category” is “uncategorized” but it doesn’t actually search for “uncategorized” categories but all categories.

  2. “Posted” before/after should use a date picker and we can expand that to support “in between” searches.

  3. ‘With Tags’ input field is much longer than other input fields.

(cpradio) #39

That is intentional (hence why it is on its own line), as it can support multiple entries.

You will lose the ability to search for before X days or after X days if you use a date-picker. Since the feature supports both, I elected to leave it a text field.

Yeah, the category-chooser defaults to that… :frowning: Has for ages, there are multiple topics about it here on Meta because it impacts Admins when Uncategorized is disabled. (but it seems setting it to Null, solved this?)

(cpradio) #40

It isn’t. So the uncategorized also only applies to instances that permit uncategorized topics. It seems to be due to the fact Uncategorized is treated in a special manner, which is the same reason you can’t default a New Topic off of Latest to “Select a Category”, that option doesn’t exist when Uncategorized is present. :frowning:

(Alan Tan) #41

tag-chooser has a variable height so we don’t really need it to be that long :slight_smile:

I’ve actually never known about the before: and after: advanced search terms until today and it wasn’t easy for me to determine how to use it from the search UI. The format of the date required is a mystery as well. I think we should just drop support for before:5 in the search UI and just use a date picker since selecting 7 days ago in a date picker isn’t difficult.

(cpradio) #42

That’s fair. I’ll switch it to use type=“date” here shortly. That should get it operational.

So should I add a width of 70%? I really don’t want to end up with a squashed tag selector on mobile.

Also, I just pushed a change to fix removing the filters via the search-term text field.