Page MenuHomePhabricator

Create "basic" and "advanced" modes in Maniphest Search UI
Closed, WontfixPublic


We need to have a "basic" and an "advanced" break up of our search options for Maniphest. The reasoning is that

  • we should be able to search on as many dimensions as possible
  • we should be able to see all the dimensions at once
  • we should be able to specify all the dimensions at once
  • ...but typically, we need but a small amount of the dimensions
  • ...and we are already at the point we're at least @epriestley isn't using most of the options (see D11306#106065)

So the "basic" mode gets the most often used dimensions and the "advanced" mode gets everything.

This should probably just be two tabs? I think its probably important to re-render the whole form so things can stay nice and logically grouped / otherwise make sure its not hard to see the e.g. entire set of dimensions about projects at once in advanced mode.

Event Timeline

btrahan raised the priority of this task from to Needs Triage.
btrahan updated the task description. (Show Details)
btrahan added projects: Maniphest, Search.
btrahan added subscribers: btrahan, chad, epriestley.

@chad / @epriestley - feel free to say this is an outright bad idea, etc. Otherwise though I want to get moving on it.

@chad - what's your take on this UI wise? I'm not sure if we have something ready to go or not and more generally what would be best here.

I generally disfavor this approach since I think it will lead to even more bikeshedding ("X option is important, please move it to the default list!"), but it's way easier to try than the mess I proposed in D11306#106055.


  • I think this worth trying, but I'm worried it won't be flexible enough to stick as a permanent solution. Specifically, my guess is that any partition we create of "basic" vs "advanced" fields will find lots of disagreement among users, and be something new for them to file feature requests about.
  • This might not even be that easy, since, e.g., if you're viewing a query result which uses any of the "advanced" fields, we should expand them by default (i.e., never hide active filters). So it might require making the search engine significantly more aware of fields as first-class objects anyway. But maybe we could just cheat / hard-code that.

Oh, and to clarify, my crazy-complicated proposal is the same as this, except we would additionally have an "edit" option which let users drag fields from "Basic" to "Advanced" or vice versa, and reorder fields within either view. Hiding fields (dragging them to "advanced") wouldn't remove them completely, it would just put them behind a "click to see all fields" disclosure.

That would resolve "please move X to basic, it's really important!", but it's a lot more work for us, and a more complex UI for users. And it opens up all the concerns in T4103 ("I want this to be a 'basic' field for all users").

I don't have a quick and easy answer for this, except to say this doesn't feel like a long term solution. It could be maybe if it was very very basic (1-2 fields already open, maybe Projects and Text) and everything else is advanced. Basically, if we could get 90% of searches with 2 fields, then maybe, I'm not sure though we have that information.

btrahan triaged this task as High priority.

Is this yoinkable for a Design direction? I can easily bang out a few mocks this week of various ideas. Short-term, I think we're wasting a lot of space. Long term, I want to make sure the experience is simple for new users, and powerful for people who have to sit in it all day.

(also, if you have examples from other sites you feel do this well, feel free to drop inspiration here).

T7251 is a suggestion of a UI I particularly like - the Product Studio (Microsoft's internal bug tracker) / "query builder" interface.

Perhaps simple is some refined elegant thing and "advanced" is this query builder?

Given a bit of thought to this, and a lot of research into competing products. In essence I think T4100 is the correct path, but with a slightly more expanded role - basically go all in.

Basic View: "Requery" based tokenizer/markup/search language. 1 input, search by any dimension, default open on any ApplicationSearch page. This does a few things:

  • Easier to immediately see both the query and result set (space used is minimal).
  • Easier to manipulate result set (is open by default, pro users get right to work).
  • Maintains mantra of optimizing Phabricator for heavy users.

Advanced View: 24+ fields, better organized. By my spreadsheet most fields fall under 1 of 6 categories.

  • Groups common types (Projects, Users, Time, Status, Order) to easier find what you need.
  • Icons! To help guide users quickly.
  • When using advanced form, "pro" form javascripts in the shortcuts for learning above.
chad lowered the priority of this task from High to Normal.May 26 2015, 3:49 AM
chad removed chad as the assignee of this task.May 26 2015, 3:52 AM

To tie in some context:

  • I'm making this problem slightly worse for some applications in connection with T7715/T8441, by adding more fields to many applications (everything automatically picks up "projects", "subscribers", "order", and "spaces" fields now if the app supports them, and not every application previously had them). So, in the short term, these UIs will be slightly more crowded.
  • However, these changes also increase the level of abstraction/indirection on these fields, so we'll face a much lower barrier to building basic/advanced tabs, hide/show/sort preferences, or a "query builder" UI in the future.
  • But none of that is likely to go anywhere before the redesign lands (T8099).

I want to have a query that list all the diff related to me, including author:me, review:me, subscribe:me. Currently the board doesn't support this query. I can only do author:me AND review:me AND subscribe:me.

Let me know if there is a way to create a board with OR query.

You can build a Dashboard Panel and embed multiple queries. There isn't current OR functionality.

epriestley claimed this task.

I think T4100 and design changes elsewhere sharply reduced the need for this, and don't anticipate pursuing it any time soon except perhaps as part of adjacent tasks like T5307 (and maybe T10034 and T4863).

The modern SearchEngine code is abstract enough that we could do a basic/advanced view (or basic/advanced + customization or however much time we wanted to sink into it) fairly easily, but I think every application except Maniphest is in a reasonable state after T4100 and Maniphest is in a tolerable one.