Page MenuHomePhabricator

Improving the usability of Maniphest's advanced search
Closed, DuplicatePublic


Maniphest's advanced search seems to follow the structure of a task, but is this a good idea?

The field "Contains Words" (arguably a popular field) must be found down there, between "Order By" and "Task IDs". The whole form is quite dull and uniform, fine for users that use it regularly, but unnecessarily complex for everybody before reaching that point.

Would you be open for a proposal to sort and organize the fields in a different way, so the more popular are easy to spot, and the experience is kind of consistent with the general search (where i.e. "Query" appears on top)? It doesn't need to be a revolutionary change, but I'd rather ask for feasibility before diving deep in a proposal.

This task has been originated at

Event Timeline

qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added a project: Search.
qgil updated the task description. (Show Details)
qgil added a subscriber: tgr.
qgil added a subscriber: qgil.

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?

qgil renamed this task from Improving the usability of of Maniphest's advanced search to Improving the usability of Maniphest's advanced search.Dec 10 2014, 10:59 PM

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?

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 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.

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.