Page MenuHomePhabricator

Provide more context for search results, particularly wiki documents
Open, WishlistPublic

Assigned To
Authored By
Jun 23 2015, 3:17 AM
Referenced Files
F788606: plan.png
Sep 11 2015, 3:33 AM
F788596: pasted_file
Sep 11 2015, 3:27 AM
F788584: Screen Shot 2015-09-10 at 8.12.58 PM.png
Sep 11 2015, 3:13 AM
F788574: Screen Shot 2015-09-10 at 8.03.26 PM.png
Sep 11 2015, 3:12 AM
F788036: Screen Shot 2015-09-10 at 11.36.11 AM.png
Sep 10 2015, 6:45 PM
"Like" token, awarded by ofbeaton.


Search results, particularly wiki documents in Phriction, often do not provide enough context to be distinguishable. In particular:

  • There's no way to quickly preview body content, especially for wiki documents.
  • There's no way to quickly distinguish between multiple documents with the same title in different sections of the wiki, like EngineeringOnboarding vs OperationsOnboarding. Both show up as "Onboarding". Projects will also have this issue after T3670 (lots of identical hits for "Milestone" or "Sprint").

Related Objects

Event Timeline

angie renamed this task from improving the snippeting of their search results to improving the snippeting of search results.
angie raised the priority of this task from to Needs Triage.
angie updated the task description. (Show Details)
angie added a project: Restricted Project.
angie added subscribers: jhurwitz, angie, alexallain.
chad renamed this task from improving the snippeting of search results to Improving the snippeting of search results.Jun 28 2015, 8:45 PM

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.

angie moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Sep 10 2015, 5:10 PM
epriestley triaged this task as Normal priority.
epriestley added projects: Prioritized, Design.
epriestley added a subscriber: chad.

D14095 is a rough pass at this. I'm summarizing (showing the first ~paragraph of content) rather than showing contextual content around body search results. This is easier and maybe-better, given that our search results are more highly structured than webpages? I'm not sure if this holds up in practice.

The technical implementation feels a little flimsy.

I don't hate this but don't particularly love it either.

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

Screen Shot 2015-09-10 at 11.36.11 AM.png (1×1 px, 206 KB)

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:

Screen Shot 2015-09-10 at 8.03.26 PM.png (1×1 px, 324 KB)

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:

Screen Shot 2015-09-10 at 8.12.58 PM.png (566×1 px, 104 KB)

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.

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.

pasted_file (42×349 px, 10 KB)

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:

plan.png (525×1 px, 203 KB)

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.

chad lowered the priority of this task from Normal to Wishlist.Sep 17 2015, 8:47 PM
chad moved this task from Backlog to 2015 Redesign on the Design board.
epriestley renamed this task from Improving the snippeting of search results to Provide more context for search results, particularly wiki documents.Sep 18 2015, 11:23 PM
epriestley updated the task description. (Show Details)

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.