Page MenuHomePhabricator

Measure how Phabricator search is used
Closed, DeclinedPublic


It's hard (and unreliable) to evaluate usability issues with the search form without knowing how people actually use it. We should get at least the following data:

  • with what frequency are various types of search used (e.g. quicksearch form, manual search via "advanced" search form, saved search search via "advanced" search form, manual search via Maniphest, saved search via Maniphest, search via click on "view all" in a project
  • with what frequency are these searches useful (user clicks through one of the results)
  • with what frequency is each search field used (has a non-empty/non-default value)

Event Timeline

Tgr created this task.Feb 6 2015, 11:24 PM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a project: Phabricator.
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 6 2015, 11:24 PM
scfc added a subscriber: scfc.Feb 7 2015, 6:19 AM

And all that should be compared to how much bugzilla search was used.
Points 2 and 3 may be difficult to reconstruct from requests logs, though: (2) requires knowledge of sessions; parameters for (3) are sometimes in POST data, IIRC.

Well, the greater problem is that it requires bugzilla hits/searches
to have been logged in the request logs; at this point we're talking
the sampled logs, and I'm not sure if Bugzilla is handled by the
"misc" varnish machines or not. If it is, I don't know if we'll have
data greater than a couple of weeks old.

Aklapper triaged this task as Low priority.Mar 9 2015, 2:38 AM

I'd be also curious about this but I have no idea if anyone plans to commit time...

Tgr added a comment.Mar 9 2015, 9:16 PM

I'd be also curious about this but I have no idea if anyone plans to commit time...

How would someone who does get access to the data?

I imagine we could either use DB queries (in which case we need to to come up with a very reliable filter to make sure they do not contain emails, password hashes etc), or install EventLogging into Phabricator (either on client or server side). Of course, upstream might know of a better way.

Aklapper lowered the priority of this task from Low to Lowest.Feb 9 2016, 9:59 PM

I don't expect anybody to work on this and it's unclear which potential "usability issues" to evaluate.
Order the fields on the query page by how often they are used? The quality of search results? (I don't see how that would be covered.) People who miss certain functionality? (Even less covered by data we'd get.)

To me this feels like an upstream task, and it definitely needs a definition of potential problems.

Proposing to decline this task.

Restricted Application added a subscriber: Luke081515. · View Herald TranscriptFeb 9 2016, 9:59 PM
greg added a subscriber: greg.Feb 9 2016, 10:19 PM

This is definitely an upstream task. I'm pretty sure our already stretched too thin design research/user research team will never put this in their queue; they're busy making wikimedia user sites better :)

I second Andre's suggestion of declining.

Aklapper closed this task as Declined.Feb 13 2016, 12:49 PM
Aklapper claimed this task.