The behavior where the form is still shown is intentional -- I'll do something like this fairly often:

• Run an search
• Look at the results
• I quickly see it's not quite what I want
• Go tweak the search
• Repeat

Showing the form -- especially in applications other than Maniphest, where it isn't 35 pages tall -- makes this process a lot easier. It also makes reviewing the query (again, particularly when not in Maniphest) easier, since you can't tell from the label text (i.e., "Custom Query" isn't helpful, while other labels like "All Tasks") are.

I'm not a huge fan of putting tons of explanatory text in the UI -- one thing I think we should do is reload the page after you reorder the list. It's confusing when you change the order, but the left side doesn't reflect that.

Offhand, I haven't seen users having trouble with saving queries. Have you? Did you find this tricky? Are you just worried that this makes it harder to figure out (I do sort of agree on this point)?

Well, in Maniphest at least, your workflow is probably faster with this change. (As in, I posit you are probably messing with search parameters near the top of the huge form, so clicking "edit" to be right at the top of the form versus scrolling up from the results to the top of the form... its a race I think.) I think its generally pretty standard to collapse "Advanced Search" UI on the search result page in web apps - probably because its more common to happily consume results than tweak the search further - but since we have the anchor to the results its not so bad.

re: usage of saved queries - I feel pretty blind to be honest about how well the feature is being adopted. I personally don't think its that discoverable though. I also think this revision makes it strictly less discoverable as the "Save" button was the first thing you'd see if you scrolled up before this change. Additionally, I don't think its clear you can drag and drop things to a new user in our various drag and drop UI. I also dislike explanatory text but felt like it was worth it in this case.

Making the page refresh on drag and drop can be done; seems like a cluster on mobile though.

I dig the intent overall, but think we need a more comprehensive 'rooster' system or other NUX for explaining some of these things - such that they are closable or in dialogs for re-use later?

(This silliness is my fault, I'll get a fix out.)

For Roosters, I hypothetically like this workflow:

• Create New Rooster
• Choose Audience: members of X, users over Y age, etc
• We do all the logic and publish direct rows right then (or in a daemon or whatever)
• On reads, we only check direct rows.

This is slightly less flexible, but doesn't have all the scaling problems (almost the entire cost is born on the write). It's also a lot easier for us, since we don't have to have anything fan out and iterate over user databases.

(I think the big issue at Facebook was that it would pull all the roosters, then run all the logic for them, and a lot of that had other checks.)

So if you published a rooster for "Guatemalan graduates of El High Schoolo who have been on the site for at least 15 days", every user would have to do that check, and would need to pull education history and account history or whatever in order to do it.