Can you provide an example here? The application level search is primarily intended to build search queries that get saved for later re-use. For searching in general, I'd expect the regular advanced search to be used.

Specifically, I'd expected most normal 'find text' queries to originate in the search box in the header. Are people building and saving a large number of custom Maniphest queries that this is an issue?

Regular search doesn't provide good enough results / ranking. Maniphests' neither, but at least you can define more accurate parameters to restrict the amount of results. This is why users really needing to find a specific task end up using Maniphest's advanced search pretty quickly.

Is T4475 the correct fix then? I do agree these forms are awful, which is why I'd prefer people not end up there.

The downstream task makes this claim:

I'm pretty sure 99% of the time someone uses the advanced search form, they need the Contains Words field

The empirical figure on this install is about 32% (1360 of 4177 unique queries in Maniphest). There are also about 16x more global fulltext queries than Maniphest fulltext queries. At least on this install, it seems like this field is not overwhelmingly popular and using global search for fulltext queries is significantly more popular.

In general, I'd strongly prefer to improve search based on specific problems with finding information, rather than, e.g., intuition about which fields are probably popular. In particular, our desired solution is for global search to be an effective way to find information in most cases where surgical parameters are not known ahead of time. If it's failing at that, we'd prefer to address that over rearranging fields on a sub-interface. An example might be like:

I was looking for T123 foobar. I searched for "a" in global search, then for "b", then I went to Maniphest and searched for "c", and then I finally found it with "d".

This allows us to examine whether "a", "b" and "c" were reasonable queries (did we do the wrong thing, or was it implausible for us to return relevant results?), why we didn't get it right if it's our fault, and improve either the UX or the search engine.

That number sound high to me, at least higher than I'd expect for something being under the page fold. It seems reasonable to move it up at least, maybe above status?

Sure, send me a diff?

In T6717#87036, @epriestley wrote:

In general, I'd strongly prefer to improve search based on specific problems with finding information, rather than, e.g., intuition about which fields are probably popular.

I strongly agree with this. Google still gets away with a single textfield most of the times, right? :) Fixing Phabricator's search is a top priority for Wikimedia. See https://phabricator.wikimedia.org/T75854 for details. If the general search works well, most of our unhappy users will indeed don't bother about Maniphest's advanced search for their regular searches.

It looks like this task could be merged with T6943: Create "basic" and "advanced" modes in Maniphest Search UI?

At least as a user, I would partition "Contains Words" into the "Advanced" mode, which would make this task worse.

I think T6943 is the short term fix, and not every person will be happy with it.

Unhappy folks can wait for some unfiled task that lets you configure basic vs advanced and is the bulk of D11306#106055.