This is technically straightforward but probably needs some design work. I'd guess it's on the order of 2-4 hours depending how messy application/customfield stuff ends up, although that may happen in a technical block and a separate design block. This can be slipped in if approved.

See that diff for some details, here's what it looks like currently:

This doesn't feel completely solid to us yet so we're going to try it out for a bit and see if there are further adjustments to make. We're interested in feedback on this version of the feature if anyone has a particularly positive or negative experience with it. I'll push it to this install shortly so it's available to play around with.

This task is paused until we have a clearer picture of where we want to take the feature based on feedback, experience, and any further iteration.

On real data, this feels very bloated to me for tasks, at least:

In particular:

• This is probably fairly specific to me, but I'm often using search to find documents (particularly, tasks) that I know to exist, not trying to find new information. So having this extra information doesn't help me find the result I'm after.
• Rendering the remarkup is fairly distracting, visually.
• Essentially none of this data is useful for me (and I don't think it would be useful for this query, at least, with smarter snippeting). I've run like 3 queries at this point so I'm not really sure this generalizes, of course. But the actual result I want here is T5554 to reference a comment I made there, and "mercurial" and "version" appear many times in that task. I also know this task by name, and am searching for specific information I know to exist.

I'm not sure what the best way to move forward is:

• Remove snippeting for tasks -- maybe it's fine for Phriction?
• Try to make the snippeting use text rendering and bold matching terms? This is a lot of work and wouldn't improve results for me in this case, at least.
• Maybe this should be more like a hovercard or preview, instead of snippeting? For example, if we made the result titles pop the result hovercards and expanded them a bit, the snippets would get out of the way for users searching for stuff they know to exist, but be available as a preview / quick look for users searching for content in general.

I'm inclined to maybe pursue the hovercard/preview approach here, since that feels like it might be more promising than text snippeting.

Here's a case where the result feels OK, especially if I'm a new user:

But I feel like that might be even better as a "quick look" when I hovered over the result.

I searched for 'self actions' earlier today and that search would be much harder now.

https://secure.phabricator.com/search/query/2oLe_O1iydvQ/#R

I mocked this out and intended to build it into the redesign for PHUIObjectItemListView, but never got to it. A snippet/summary button like GitHub uses. Could be useful here.

How about we:

• Revert this.
• Put hovercards on results instead.
• Make sure Phriction hovercards have some kind of text snippeting, so that hovering over a link shows you some of the document text.
• See how that feels?

Mostly, that's just easier than building a separate interaction. If it feels mostly positive but not quite there we can customize the hovercard UX for this interface pretty easily (e.g., generate "richer" hovercards here, or show them in a separate column or special way, or activate them on a button instead of the link itself, or whatever).

It seems like a lot of the hovercard information could be useful in assessing which results are relevant.

Basically, pursue something a bit like Google's "result summary box" UI, starting with hovercards, instead of its "content snippet" UI:

pls revert. pls.

D14097 reverts this because it felt really bad in production, and generally not very promising as a direction we could iterate on and make successful.

I'll explore prototyping something hovercardey and see if that feels better, but want to think about this for a bit and possibly collect other open hovercard-related tasks for concurrent resolution (I think we have a handful of them), so I don't plan to pursue this immediately.

Thanks for adding me to this issue! Please don't rely on mouseovers/hovering. I want to be able to just look at the results and see which ones are relevant without having to move my mouse.

Yeah, I think it's very unlikely that we'll require hovering to reveal document hierarchy (or, eventually, parent projects) since two results called "Onboarding" (or, in the future, "Sprint 32") are completely indistinguishable right now. This use case feels much stronger to me as a material usability issue than snippeting.

Phame will probably have this issue in the future too (posts from multiple blogs with similar titles), although it's fairly far behind modern infrastructure (cf T9388). Phragment's file hierarchies (or whatever becomes of that whole area of the codebase) will also have this problem, and commits will sometimes have a slightly weaker version of this problem after T4245. T8667 describes a variant of this problem in Diviner.

Basically, we have a lot of objects where you need to know the position in a hierarchy to make sense of the result, we just dodge this being an issue today in most cases because the problem cases are planned, prototypes, lesser-used, rarely collide in practice, or whatever else. But it's fairly bad for Phriction and will be very bad for Projects soon, and eventually impact a bunch of other applications and object types.

Hi all, glad to see this issue is being looked at. Per my task in T10641, simply having "all documents" search show the same style of content as is seen in Maniphest search would speed up our day to day, as most people on our team use all documents search (unintentionally, as it is the default), even though all they really care about is Maniphest, and so their experience isn't great here (their impression is "Phabricator search isn't good" which I think is related not to functionality but discoverability and smarter default configurations).

My example for this problem was with Maniphest tasks in T10790, where identical task titles is problematic in the search results.

My idea for a solution would be to show the tags on the task, identically to how they are already shown in dashboards and Maniphest queries.

You could also show task text or not, the tags should provide a lot of context already.

That doesn't help wiki objects, but it shows that different objects have different ways to provide meaningful context.

Just bookkeeping; this doesn't have an active external priority driver.

FWIW I partially implemented this in Wikimedia's fork, and I did so in a reusable way. I'd like to eventually upstream it but I'm not sure that my approach is desired upstream. I'll give it another shot though.