Type-based searches à la search.cpan.org

[joelbernstein]

s.c.o allows querying by "type" (module, distribution, author) which restricts results to only come from the specified type of resource.
I find this a very useful feature and have a number of browser quicksearches which rely on it.
I can't figure out how to achieve the same thing using metacpan.

Examples:

1. search for distributions matching DBIx::Class, without listing modules therein
2. search for modules matching DBIx::Class, ignoring which dist they are in
3. search for ACME as an author, ignoring any Acme:: modules
4. search for Acme modules, ignoring an author whose name contains 'acme'

[ranguard]

No action has happened - Closing as part of the great issue cull of Dec 2013

[ranguard]

Moving to wishlist: https://github.com/CPAN-API/cpan-api/wiki/Wishlist

[neilb]

Was about to submit an issue on this topic, then found this ticket via the wishlist. I often wish that MetaCPAN had the ability to constrain searches to distributions. It's the main case where I "go back" to using search.cpan.org

I think a drop-down menu is too "expensive": too much additional cognitive load for something I suspect many users wouldn't use.

Search operators (c.f. google's site:) would be handy, but might cause confusion due to the who colon thing:

dist: constant

[rwstauner]

I thought we had this (author: and distribution: operators)

[neilb]

I read your response: "yay!", quick, let's go and try it. I'll be embarrassed if it's there. Oh why didn't I know about this. Must read the doc. Is there doc?

oh, it doesn't work. Phew. And disappointed.

you're just playing with me, aren't you?

[rwstauner]

I know there is code to that effect in the Search controller, but if it
doesn't work as you expect I'll have to look at it later.

[oalders]

https://metacpan.org/search?q=author%3ANEILB
https://metacpan.org/search?q=author%3AOALDERS+HTML
https://metacpan.org/search?q=distribution%3AMoose+MOP

As I understand it, some Lucene syntax is exposed via ElasticSearch and that's what you are taking advantage of with the single colon. It's entirely undocumented, but something that we could reference via a small "advanced" link under the search box or something like that.

[neilb]

Nice tag-teaming for the double embarrassment there. Bastards.

I swear I was typing that last night and getting blank results. You sure you haven't just enabled that? ;-)

Nice though. I can type version:0.01 to find first releases of modules, and will have to think about other uses.

I'll have a go at writing an advanced help page, if you like?

[monken]

See http://lucene.apache.org/core/4_1_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html for the syntax and here is the mapping of the available fields for search: http://api.metacpan.org/v0/file/_mapping

Thanks for your help!

[omega]

Just a small input. We have that really "wasted" sidebar on the search results page, so perhaps addings links for "distrubution", "module", "author" facets or what you want to call them could be worth it as well?

[oiami]

How about something like we have other types of result in separate tabs e.g. distributions, modules and authors ? It will look like

I mixed all of your suggestions on this, any comment ?

[neilb]

@oiami: I like the idea! You could put the number of hits with each as well. Ie

All     |     Distributions (4)     |    Modules (16)    |    Authors (2)    |

It would be nice to compact the space taken up before you get to the actual search results. I don't have any immediate suggestion, but will have a think about that.

Also, I wonder could you drop the "All" tab, and only show the different types, picking "the most appropriate one" to display first?

[oiami]

As my experience, displaying result number in each tab is expensive, since sometime we have to send multi-query to get to total number of each type without displaying it.

I agree with the the space with since it's just mock up and it need more decoration :D

I'm not sure if it's good idea the drop 'All' tab, I think it's it can be the best choice for people who like something 'All in One', since it display many types of search results. Let listen what others say.

[rwstauner]

That's a very interesting idea (and a nice mock-up).
I'd like to gather more feedback before we go ahead with this.

I definitely agree with keeping the "All" results as the default. We have a few other issues out there where guessing has gotten us into trouble.

@oiami I appreciate your caution about getting the counts. I agree with you and don't want to add new queries just for that. However, in this case we may already be doing those queries and it might just be a matter of adding up the totals for the the collapsed distribution (the default) search. If that info is already available we can definitely use it. If not the counts can wait.

I'd also like to better define what each of those searches (tabs) would be in order to make sure it's useful. My first thought was that we already have all the results and these would basically be display filters. Then I realized that the distribution: search operator is only for exact matches (the default field is not_analyzed), so it might be nice to give people a clickable link rather than expecting them to know that they have to type in distribution.analyzed: to get that to work. Then again, if PAUSE moves to requiring a dist name to match a module name (which is the overwhelming majority now anyway) there may not be much use in a distribution name search.

The modules search (tab) would be essentially the same as "all" minus the authors, though I suppose it could display the "expanded" style (instead of the collapsed by distribution style).

The authors tab would just show all authors (whereas the ones on top of the "all" tab might be clipped)?

I'm not sure about some of those things yet, so like I said, let's gather some more feedback and give this some more thought. It could be a great addition.

[pau4o]

I like @omega proposal for using "wasted" sidebar.

It would be great if sidebar can be used to filter search results based on "distribution", "module", "author", etc.

Placing tabs on top of search results use to much vertical space (it's quite important in world where wide screen laptops are majority), and will be hard to add new tabs.
If tabs are in sidebar, than adding new tabs will be easy in future.

[ghost]

On a phone where there is not much to width of a screen, using a vertical side bar would be worse than having the filter bar at the top.

[rwstauner]

On a phone the sidebar slides in and out by pressing the menu button.

[oiami]

I tried to make the horizontal tabs

We used to have left menu like this before, in my opinion I think this way will make user think they can go to another page instead of another type of result. Similar to our existing left navigation menu on about page.

@pau4o , @Parv and all, what do you think ?

[pau4o]

@oiami I like what you have done, but may be some titles in sidebar will help users to distinguish menu from filtering search results.
For example see marked elements in partial screenshot from newegg.com search results page

I know that goals on e-shop site is different from these on metacpan, but e-shop sites try to help users to find goods that they search quickly and easily. So there is a lot to learn from them.

[ghost]

oiami, I agree with you that the images in your last reply do not seem to have enough differentiation.

rwstauner, there does not seem to be much in the sidebar when I opened metacpan.org site 2-3 weeks ago on the phone. If the result refinement options would appear in there & presented as such clearly, that would be fine by me.

[neilb]

I'm curious, what percentage of MetaCPAN usage is on a mobile?

[ranguard]

About 5% - that's in the last 30 days

[neilb]

thanks @ranguard!

Surprised it's as high as 5% — I was expecting under 1%.

I wonder if they're all using larger screen mobiles, like the Samsung Galaxy Note? (not asking you to check, just pondering).

[ranguard]

I know you didn't ask...

Screen sizes:

Devices:

[ranguard]

No action - closing... again... still on wishlist