One more thing: if you get to a task query from a special place vs building the query by hand (e.g. when clicking on View All on a project page), the query form should be hidden by default.

D9224 isn't going to land soon - see the diff for details.

FWIW this problem is functionally quite minute because any / all links within the application should include #R at the end - the anchor to take you to the top of the results. So yes, while the UI element is large, you do actually land right at the results every time from links, etc.

If you have some personal workflow where you scroll down a large list and then need to scroll to the top and find yourself scrolling past the top of the results, I'd suggest simply refreshing the page instead. Provided the result set isn't prohibitively large or the query prohibitively expensive, this may even be faster than scrolling would have been.

I don't think D9224 is addressing what this very task was originally about or am I missing something?

• Just show the "Hide" button even for custom queries (that's a big help UI wise IMO): so you can hide this gigantic form when you're done tweaking it.
• When coming to a pre-built query from another place (e.g. from "View All" in a project page), have the query form hidden by default instead of shown (same as when clicking on a saved query), as it's less likely you'll want to further customize these results. To me the real problem BTW is that the project view does not show all the tasks in place (T5148).

It seems D9224 is doing something else: always hiding the query form after a search. I think the current behavior actually makes sense and is not the biggest friction point in the current UI.

Generally speaking, when developing tools, its really important to understand the problems users are facing rather than implement solutions they specify. For example, users might say they want the color blue, but deeper conversation and question might reveal they have a problem agreeing on what the color should be, blue happens to be the simple majority winner right now, and you're likely going to have to change the color on a per user basis eventually, so that's the right solution to build.

I think the problem might be that you are trying to tell me solutions and not problems? Please do make sure to explain the problem you're facing whenever you can - solution ideas are great too of course - and we'll work on solving the problem as best we can.

Anyhoo, D9224 attempts to solve the problem you stated:

The form to build queries takes so much screen space that it affects the UX when looking at the results:

• it's visually distracting
• you can't rapidly scroll to the top of the page to get to the top of the results but instead have to stop precisely below the form

You suggest the solution of open by default with a close button. D9224 implements closed by default with an open button. This seems better to me given the problem, as well as better given it mirrors the functionality of the pre-built and saved queries. Further, it doesn't suffer from a deficit you point out in your proposed solution - "It's an extra click after the results are displayed, but it's still quite better than the current situation."

In D9224, some discussion happened that stated there was utility to having the form open by default and that the existing workflow is in fact intended. I think it is better in the average case to have things as D9224 as consuming the search results is far more common than tweaking the search and thus the small cost of clicking edit for search result tweakers should be paid. For example, I think its very rare that users coming from the "View All" link on a project tweak that search result as opposed to consume the results. Anyhoo, I'd love to hear thoughts as to how come its better to have it open by default, as I am still pretty convinced its better for most to go closed by default. See D9224 for more thoughts.

Thanks for your detailed feedback! I can only agree with your approach and this is indeed the core problem (observed a number of times at a personal level or during meetings review the workloads through Maniphest tasks):

The form to build queries takes so much screen space that it affects the UX when looking at the results:

• it's visually distracting
• you can't rapidly scroll to the top of the page to get to the top of the results but instead have to stop precisely below the form

I only suggested "open by default with a close button" to minimize disruption to the existing users / workflow.

I think its very rare that users coming from the "View All" link on a project tweak that search result as opposed to consume the results.a

I agree. That's why I would certainly like to see the the query form to be closed by default in such cases as it's just taking a lot of UI space and adding friction to the UI.

Back to your question: in the case of pre-built searches, I would vote to have close by default as it's the most logical and UI efficient. In the case of custom searches like from the global search field in the nav bar, having open by default combined with auto-scrolling of the page to the results is reasonable to me for 2 reasons: 1) it's useful to know what exact search params were used and 2) quite often I end up tweaking the search query.