search

mdittmer / mdn-confluence

2 stars 5 forks source link

Inconsistent results from filters #17

Open jpmedley opened 6 years ago

jpmedley commented 6 years ago

Type the following three items in the search box for the confluence pane.

IDB - results are blank even though confluence contains information about interfaces starting with those letters. Ab then add an o - When just 'Ab' is in the box, results beginning with 'Abort' are visible. As soon as I add the 'o' I only get PaymentRequest#abort

I can enter all of AnaylyzerNode without this strange missing data behavior.

mdittmer commented 6 years ago

This is by design, but I think it's come up as a source of confusion more than once. Perhaps we should revisit the design.

The Design

When any filter restricts a collection to <500 records, all other collections get filtered to: "only show records associated with one of the <500 records in the other collection". This is repeated until the collections converge.

The advantage is that filters in one view pear down the data in other views to "related data". The downside is this: if the the number of records in any collection converges to zero, then all collections will eventually receive a filter saying "only show records associated with null-set"; hence all collections converge to null-set. This happens when, for example, you search for "IDB" in Confluence, and the IndexedDB APIs have no issues.

Alternatives

The most obvious alternatives to me are:

  1. Decouple collections and require the user to to manually filter each one independently, or
  2. Add a heuristic that says "if you've converged to 0, stop broadcasting filters to other views".

I kind of like the second one, but I'm a bit afraid of it. If it's not implemented quite right, the collections could thrash in the following way:

  1. Collection X is constraining collections Y and Z in some way as the convergence runs,
  2. Collection X converges to empty-set and completely drops its constraints on other collections,
  3. Collections Y and Z are now less constrained, but still apply their constraints to X,
  4. The relaxed constraints from Y and Z cause X to re-inflate to some non-empty subset,
  5. This new X sub-set is <500 records, so: goto 1.. Uh oh...

@foolip and @jpmedley WDYT about this issue?

jpmedley commented 6 years ago

If I understand the current design correctly, I should see something for IDB. I know mdn has records for those.

mdittmer commented 6 years ago

I believe the problem is that those MDN records are correct. We have no generated issues for IDB.

We should probably chat synchronously about this. @foolip and I talked about a few ideas, and we seem to be leaning toward a search box that filters APIs (consistently for Confluence and MDN), and possibly a separate search box for issues (to support things like "assignee:me").

foolip commented 6 years ago

Yeah, I did find it surprising also that all views went blank, and I think something that's simpler to explain would be good. The absolute simplest would be a single search box that just filters the Confluence and MDN views to APIs that match a static string.

But then I wonder if one might want to also produce PRs that fix things for just a single browser at a time, in which case filtering by the browsers somehow would also help.

@jpmedley, what's the minimum amount of filtering that you think is needed? Could it go in a single search box, or not?

jpmedley commented 6 years ago

I've been trying to figure out how to convince you guys that it should go to a single box. Even knowing that the current implementation is a boolean intersection, I still have a hard time predicting what I'm going to get.

foolip commented 6 years ago

A single box sounds great if it meets the use cases. WDYT, @mdittmer?

@jpmedley, about the use cases, what kinds of things would you type into and and what would you want to happen? Just filtering by API name in all views, or do you also want to filter by something else, like the browser? And just to cover all grounds, what bad things would happen if there were no search box at all? Just that it's annoying to scroll around, or something less obvious about the work flow being impaired?

mdittmer commented 6 years ago

We could certainly move to a unified search box. @jpmedley what features do you think are most important for the filtering use cases you have in mind? Here's what we currently have:

If we're going to refactor how the search controller works, we should make sure we focus on the most important features for users.

jpmedley commented 6 years ago

The fist two for sure. The last one, not so much.

Joe Medley | Technical Writer, Chrome DevRel | jmedley@google.com | 816-678-7195 If an API's not documented it doesn't exist.

On Fri, Mar 2, 2018 at 6:33 AM Mark Dittmer notifications@github.com wrote:

We could certainly move to a unified search box. @jpmedley https://github.com/jpmedley what features do you think are most important for the filtering use cases you have in mind? Here's what we currently have:

  • Keyword search filters API names + issue descriptions
  • key:value works on properties (e.g., issues: status:open; confluence/MDN: firefox45:false)
  • browser<version (or >, or =, ...) for MDN; this should work on Confluence too, but currently doesn't

If we're going to refactor how the search controller works, we should make sure we focus on the most important features for users.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mdittmer/mdn-confluence/issues/17#issuecomment-369936503, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0vi6MbXQ7rjX4LwRRm94ldfyXscwjZks5taVgwgaJpZM4SYvYA .