Add the possibility to filter on more than one crate

[GuillaumeGomez]

Currently, the search can only filter on one crate. Instead, it could be interesting to be able to pick more than one crate (and replace the <select> with a dropdown menu with tickboxes).

What do you think @rust-lang/rustdoc ? (In particular @jsha)

[Manishearth]

ooh that sounds interesting. A good UI definitely sounds tricky though

[GuillaumeGomez]

I had something like that in mind:

Eventually a button "select all" or something. Well, I'd prefer to wait for @jsha's return for this for the UI. :)

[Manishearth]

Yeah I understood that part, I meant that it's tricky to make good

[GuillaumeGomez]

Which is why we need @jsha 😆

[jsha]

I'm still around for a little bit (though trying to limit my computer time). My rough initial feedback would be:

1. We should have a concrete use case. Who are we building this for, and how do we expect them to use it? Presumably not docs.rs or doc.rust-lang.org. Local dev? Self-published crate docs that include all dependencies? What sort of problems are people going to solve with it?
2. What are the range of possible sizes we might have? Are we trying to support a dozen crates in the filter, or hundreds?
3. In general I've been thinking we should move the "Filter crates" menu into the search page itself, so it doesn't take up visual space when you're not searching. This would be a sort of advanced search, or a way to refine a search. The nice thing about that is it gives us a lot more room various types of UI, rather than being limited to something that can fit as a dropdown or popup from the main documentation page.

[Manishearth]

In general I've been thinking we should move the "Filter crates" menu into the search page itself, so it doesn't take up visual space when you're not searching. This would be a sort of advanced search, or a way to refine a search. The nice thing about that is it gives us a lot more room various types of UI, rather than being limited to something that can fit as a dropdown or popup from the main documentation page.

This is a really good idea imo!

[GuillaumeGomez]

1. We should have a concrete use case. Who are we building this for, and how do we expect them to use it? Presumably not docs.rs or doc.rust-lang.org. Local dev? Self-published crate docs that include all dependencies? What sort of problems are people going to solve with it?

I can describe the use case I had in mind (even though I'm not completely convinced about this feature): in gtk3 docs, it happens that I'm looking for a "common" method but I'm only interested in it in either gdk or gtk but can't filter only those two crates at the same time. So as you can see, it's not a huge need on my end, just thought that it might interest people so I proposed it. :)

2. What are the range of possible sizes we might have? Are we trying to support a dozen crates in the filter, or hundreds?

I'd expect more dozen crates rather than hundreds, but I only have my own use case in mind so needs to be investigated further.

3. In general I've been thinking we should move the "Filter crates" menu into the search page itself, so it doesn't take up visual space when you're not searching. This would be a sort of advanced search, or a way to refine a search. The nice thing about that is it gives us a lot more room various types of UI, rather than being limited to something that can fit as a dropdown or popup from the main documentation page.

This is a pretty good idea. Worth a try at least!

[camelid]

Currently, the search can only filter on one crate. Instead, it could be interesting to be able to pick more than one crate (and replace the <select> with a dropdown menu with tickboxes).

There are several times I've wanted a feature like this when searching the rustc API docs, so I'm definitely intrigued!

1. We should have a concrete use case. Who are we building this for, and how do we expect them to use it? Presumably not docs.rs or doc.rust-lang.org. Local dev? Self-published crate docs that include all dependencies? What sort of problems are people going to solve with it?

My use case is doc.rust-lang.org ;)

2. What are the range of possible sizes we might have? Are we trying to support a dozen crates in the filter, or hundreds?

I'd expect more dozen crates rather than hundreds, but I only have my own use case in mind so needs to be investigated further.

For my use case, it would be around 60 crates.

3. In general I've been thinking we should move the "Filter crates" menu into the search page itself, so it doesn't take up visual space when you're not searching. This would be a sort of advanced search, or a way to refine a search. The nice thing about that is it gives us a lot more room various types of UI, rather than being limited to something that can fit as a dropdown or popup from the main documentation page.

I agree that this sounds promising! I imagine it's much more common to either want to search the whole workspace or (in a smaller number of cases) to want really fine-grained filtering.

[jsha]

A couple of interesting examples to possibly draw from:

eBay's search results page lists a bunch of categories with checkboxes. I think the categories are automatically created (and ranked) based on what's in the search results. We could potentially do the same at the module level, not just the crate level. For example, show "there are 10 matches in foo::bar::baz, and 2 in example". I think a lot of flight search websites have a similar UI. It would be neat to check.

Another implementation of this style of multi-select is Bugzilla's advanced search:

https://bugzilla.mozilla.org/query.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&f1=classification&field0-0-0=product&field0-0-1=component&field0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whiteboard&field0-0-5=cf_crash_signature&field1-0-0=product&field1-0-1=component&field1-0-2=alias&field1-0-3=short_desc&field1-0-4=status_whiteboard&field1-0-5=cf_crash_signature&o1=notequals&query_format=advanced&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=substring&type0-0-5=substring&type1-0-0=substring&type1-0-1=substring&type1-0-2=substring&type1-0-3=substring&type1-0-4=substring&type1-0-5=substring&v1=Graveyard&value0-0-0=border&value0-0-1=border&value0-0-2=border&value0-0-3=border&value0-0-4=border&value0-0-5=border&value1-0-0=radius&value1-0-1=radius&value1-0-2=radius&value1-0-3=radius&value1-0-4=radius&value1-0-5=radius

You have to know about Ctrl-Click and Shift-Click to manage the multi-select though. I think this is less preferable.

There are several times I've wanted a feature like this when searching the rustc API docs, so I'm definitely intrigued!
My use case is doc.rust-lang.org ;)

Ah, you mean like https://doc.rust-lang.org/stable/nightly-rustc/?search=hir ? That's very helpful, thanks! Can you give an example of a search you've done where you'd want to filter it with this sort of feature? Also, would you want your selections to persist across page loads? That's what the current crate selection does, but we might want to change it if we add this more complex feature, since it would be easy to get into a surprising state.

[camelid]

There are several times I've wanted a feature like this when searching the rustc API docs, so I'm definitely intrigued!
My use case is doc.rust-lang.org ;)

Ah, you mean like https://doc.rust-lang.org/stable/nightly-rustc/?search=hir ? That's very helpful, thanks! Can you give an example of a search you've done where you'd want to filter it with this sort of feature?

Unfortunately, I can't think of a good example off the top of my head. I'll try to remember if I come across a situation where it would be useful :)

Also, would you want your selections to persist across page loads? That's what the current crate selection does, but we might want to change it if we add this more complex feature, since it would be easy to get into a surprising state.

I actually find it somewhat annoying that the current crate selection persists across different pages, but I don't use it that much because I find it too limited—usually it's just faster to type in the full qualified path. I think I would need to try out the new system before I would know. Maybe once a prototype is built, I could build a version of the compiler docs with it and try using it instead of /nightly/nightly-rustc to see what I think.