The requests I've seen seem like users want this done automatically/by default, not that they want better tools to do it themselves.

It's already pretty easy to do it yourself but I haven't seen anyone say "this is important/useful to me and I already use the tools to do it myself, but I wish those tools were a bit easier to use because <some specific workflow> takes too many steps".

We also already have a "Pin/Star" operation -- "Flag" -- but I think there's very little interest in improving it (e.g., this task doesn't even mention it, T6647, T3692 are sort of "nice to have").

In particular, you can literally already do exactly what this task proposes, in terms of which results are shown:

• Flag the projects or repositories you want, using the existing "Flag" operation.
• Create a custom query in Flags filtered by object type (Project or Repository).

But I haven't seen anyone say "this is what I want and it's really useful to me, but it takes more steps than I'd like". I'd expect to see at least some of this. Obviously, there are cases where we "unlock the value" of a feature by lowering the barrier to entry enough and once we get over some breakpoint something sees way more use, but there seems to be so little traction for this feature today that I suspect this isn't one of those cases.

I think you could implement this today by automatically putting flagged results above normal results.

On a purely personal level, I would never want this behavior. When I search for results matching some query, I don't want to see my "favorites" on top, and if I want my default view to show my "Favorites" I'll just spend like literally less than 30 seconds writing that query:

Or I'll spend maybe 45 seconds in Flags:

We could do a better job with Flags and I think there are a bunch of ways we could improve it to make it more useful, but I'm not sure there's a real problem that this vein of approach is tackling.

Upshot:

• What specific set of problems is this solving for users?
• Why don't the users with these problems already use the existing tools to solve these problems?
• Why is replacing ApplicationSearch a better solution than improving the existing tools (that is: why is this a fundamental problem with Flags/ApplicationSearch, rather than a barrier-to-entry problem with those tools)?

Constructively, some adjacent changes which are maybe worth considering instead:

• Letting administrators define global search queries, like they can define global menu items. So an administrator could make Diffusion's default home page be repositories "X, Y, Z" for all users, instead of "all repositories, ordered by update time". Users would see personal queries, then global queries, then default builtin queries (just like the Home menu).
• Adding a "Display As: Show as List / Show as Cards" option to Diffusion and Projects, or replacing the list with cards entirely.
• Making it easier to edit an existing saved query, so you can update a "Favorites" query more easily. Currently, this step is cumbersome (edit the query, save as, reorder, delete the old one), and could take half as many steps.
• Improving the behavior and integrations of Flags -- but I've held off on this since it will make other application UIs more complex and it's not clear to me that anyone actually wants this feature or would really find it useful.
• Adding additional filtering to try to get this right by default more often, like "repositories I've committed to". I'm not sure if this has a real use case or not, or if there are other filters we could try to define automatically like this one.

Flags is something I definitely thought about, since it's already everywhere. If it integrated with applicationsearch (have a flagged filter automatically everywhere) I think that's reasonably handy and easy to build UI upon.

Maybe also, in general, we could define an "explore by tags" view, that works something like this:

Tags: Phabricator, Third-Party

[+] Tag: Applications (33 repositories)
[+] Tag: Project Management (17 repositories)
[+] Tag: Security (4 repositories)

[</>] rXYZ aaa
[</>] rXYQ bbb
[</>] ...

The top section shows "breadcrumbs" of tags in your current filter, and you can click to remove them.

The middle section shows tags like "folders". The metaphor is that we're sort of simulating a directory structure using tags, and clicking "Security" (to add that tag to your filter) is a little like diving down into the "Security" folder, except that things use tags instead of folders so there isn't a strict "X > Y > Z" crumb pathway. Clicking one of these adds the tag to your query.

The bottom sections shows results matching your query.

The problem this UI would solve is "if you're new, it may not be clear which tags to search for to find what you want, and clicking "Diffusion" can be overwhelming and fruitless". The middle section allows you to browse/explore tags without having to know which tags are in use. The key thing it does is only show you tags which actually find results, so you can read through the options and click to refine your search.

We could do this in every application, although I think Diffusion is the case where it's most likely to be useful.

This has some scale/performance issues (if there are 8392 results, we have to filter them all to get an exact count) but nothing insurmountable.

have a flagged filter automatically everywhere

This is easy to do technically, but my sense is that no one uses Flags so I've been hesitant to clutter up every UI with it since I think it might be a net negative.

Have flags as an automatic search filter then like projects?

I think maybe we're talking about a couple different things? These are both relatively easy:

1. By default, add "[X] Include results I've flagged." or "Flags: [red, blue, yellow]" to every ApplicationSearch control list, alongside existing fields like "Tags", "Spaces", and "Subscribers", if the underlying object implements FlaggableInterface.
2. By default, add "Flagged" to the automatic list of default named filters available in the left menu (like "All, Active, Joined", etc).

If we do (2), we should do (1) first, or Flagged → Edit Query won't be meaningful.

We could do (1) but hide the controls unless they have values, but I worry this would be confusing. We do this in a few cases today, but they're all fairly internal cases where the field value is a list of specific IDs or PHIDs. For example, when you Search Parent Tasks from the "Task Graph" UI, an otherwise hidden "Subtask IDs" field appears, populated with the ID of the task you're searching for. Likewise, Maniphest has a hidden "IDs" field which is used elsewhere.

We could do something like redefine these fields as "Advanced" instead of "Hidden", provide some "Show Advanced Fields" in the UI, and then make "Flags" an "Advanced Field".

But, I worry that both (1) and (2) would be net negatives for the product in any form: I believe almost no users care about this use case and that adding these options would harm users who feel the search UI is too complex. I think we have more users who find the search UI complex than users who want or would use or benefit from better "Flags" integration.

For example, in my recent discussion with @gregprice a major feature he wanted was (paraphrasing) "a big text box that you type an SQL-like query into, like Jira's JQL" instead of the field-based search UI. I don't think this is particularly common -- and my sense is that feedback about this died down a little after we collapsed all the fields using typeahead functions -- but I think there's more of it than feedback in the vein of "I want to pin stuff, but the current tools aren't as easy to use as I'd like them to be". He and some other users left some similar feedback in T10640, although that task is a little tainted. But, before typeahead parameterization, we felt this (excessive complexity / too many fields in the search forms) was an important problem (T6943) and spent a significant amount of effort trying to solve it.

I'm agreeing that (1) is a reasonable starting point.

The flag color system seems like overkill though, I wonder if we can simplify that.

Sorry, I guess I'm being unclear: I don't believe that (1) is a reasonable starting point.

I think (1) adds a field that no one will use to solve a problem no one has and hurts many other users who have a real problem (search UIs being too complex / overwhelming).

Well let me actually re-read everything then.