Unfortunately, no, none of that is available in Zotero. Though I don't think anyone would object if this was implemented.

Isn't it strange that we have all sorts of people working on something like visual mapping of data, but none on something so simple and powerful as this? I think even just a counter of how many times a term appears in a document would add so much and be reasonably easy to code.

This may not be too difficult to add, but it's not exactly clear where this data is supposed to be displayed (not so much the hit counts, but the hit context). I think displaying keywords and surrounding text would go well with the "preview" pane proposed here. Adding a dynamic column that appears and disappears for different views (i.e. browsing vs searching) may be less trivial given how Zotero functions currently (though I haven't looked too carefully). Also, what about hits within metadata? Does that get highlighted as well (not sure how we would implement that one)?

In any case, to approach this, you would probably want to get familiar with javascript, XUL, and SQL first, which is a good amount of reading.

I am not sure if these functions are useful for a search in the bibliographic metadata. The entries in Zotero represents normally literature which I already know or have found somewhere and want to cite in the end. Thus, if I remember an author's name or some words in the title, the normal search is fine to find the corresponding entry in Zotero.

The use case I can see is a search in attachements (notes, html, pdf text). I think this was also the starting point for the discussion here (documents =? attachements):

When I conduct a search (say 'India') across all my documents,

I guess one could really do a lot on the fulltext of all attachements (proximity search, term frequency within a document, snippets in search results, data mining and natural language processing methods...). Such tools can be very handy, but maybe not all of them are in the main focus here.

I doubt that we need a ranking algorithm for the search in bibliographic metadata of our own collected literature. I should - up to some point - know what is inside my collection, and not need a "I am feeling lucky"-search.

A ranking algorithm that weighted, say, a title highly, followed by creators, followed by number of occurrences, etc., seems more useful, but obviously more difficult to implement.

Yes and you would also to quantify your preferences (e.g. title factor 10, creator factor 8, etc.). In this way you would prefer literature about Shakespeare (having "Shakespeare" in the title) over literature from Shakespeare. Is this what an user would expect? Moreover, multiple hits have to be added somehow and in a search with various terms we have to add these together somehow (and maybe boosting some fields in the end...).

I am using discovery services (e.g. Primo) quite a lot and they have a relevance ranking based on the bibliographic metadata. The ranking is sometimes good and sometimes bad. A major fallback IMO is that it is always a blackbox, i.e., you cannot explain a human why the ranking is exactly how it is. The lack of transparency together with sometimes bad ranked results, will give a bad user experience. Moreover, these discovery services are designed for millions of entries, and I doubt that we have that many in a Zotero collection.

In terms of display space, Mendeley does it by putting two/three lines underneath each item (I'm trying to get my friend to send me a screenshot). It seems pretty elegant.

That's pretty limited though. You could only show a single hit. What if there are 10 hits within a document?

I think showing every hit (or so) is massive overkill.

I would disagree. I think showing context for the first hit would be almost as useless as not showing any context at all. Odds of the first hit being what I'm looking for are not that high, so it would be just as good as telling me that the paper has a hit.

The difference for Google, though, is that if you enter multiple keywords it will try to show you the context where those keywords are close together. If that's the case for Zotero searches as well, then maybe showing single hit is ok.

You could only show a single hit. What if there are 10 hits within a document?

I'd say you could just show multiple snippets, with ellipses in between, but unfortunately I don't think can do auto-flow between multiple lines (e.g., and just have as many matches as will fit in one or two lines). The alternative would be to just have multiple lines with one snippet per line, with some maximum number of lines.

But again, I don't think we can highlight/bold individual words within the lines, which may rule out using the tree at all.

What about showing the hits in the information panel?

This would avoid the above issues, but it of course would mean that you'd have to individually go through each match to see the results, which sort of seems to negate most advantages of having these snippets in the first place.

Oh, I was thinking a separate window as in Thunderbird, but the middle pane might be less awkward. (Part of the reason I never use the TB search is that it takes you completely out of the context you're in.) I'm not sure how you'd switch between browse/filter mode and search results mode — in TB it's a completely separate search box, which is really clumsy.

Here's a screenshot of Mendeley's implementation for people who haven't seen it - http://i.imgur.com/JlSQhxD.jpg Mendeley highlights hits in key metadata and text. (only displaying non title metadata if there's a hit).

In response to aurimas, there are essentially 2 goals: (a) on a quick glance to determine which attachments are important and (b) to understand more fully what any particular attachment contains. I think goal (a) should have priority, given that it's relatively easy with other existing programs to do (b) once you have located an important file, whereas (a) is not, and would make sense with zotero's role as an information manager.

Turning the middle pane into a separate search results page with rich text formatting would probably be the best solution as a user.

Failing that, multiple lines with one snippet per line is still definitely a good idea, even WITHOUT highlighting/bold. Could probably capitalise search terms as a workaround...

Also agreed that right hand side panel (i'm assuming this is what you're calling the information panel?) would be good to display all/more hit results once you click on the item if that's desirable and not too resource intensive/development time intensive. I'm essentially keen for fastest useful implementation =P

Could probably capitalise search terms as a workaround...

Ugh. That's a good idea, but I think it's just too gross.

Semi-returned from easter holidays and adding to this again.

In my imagination the search results page would just replace the middle pane and be activated when a search occured. You'd 'get out' of it by clicking an x in the search bar.

Clicking a tag would be a filter on the search results (I imagine that would require a recreation of the search results page unless it was created with an ability to selectively display items based on tags)

I reckon you could probably have a 'sort by' drop down somewhere, possibly as a context menu (right click) or on the top. Otherwise, people would complain about the loss of functionality.

I'm curious to understand, Dan, what do you imagine is going to be jarring?

I totally want this too!

For what it's worth, I really like Thunderbird's search function (the ability to refine the results, and the fact that it opens each new search in a new tab). It would be great to see something similar in Zotero.

I'd also like this feature! My friend who uses Mendeley told me about it. -- And I think it's a much nicer (and quicker) way to search literature in a fast way. Zotero's search always seems a bit klunky if you just want to do a quick search.

In the intermin, my solution is to just install Mendeley, have it 'watch' my Zotero's PDF folder, and do this kind of quick search in Mendeley. For all other things than 'quick search', Zotero still is better though.

Mendeley's zotero integration functionality (or import) sucks BTW. Sub-folders are not taken into account when you use zotero integration, and with all import functionalities, the PDF's are not imported (or wrongly referenced). So don't bother trying those and just use 'watch folder' - it will save you some time.

Adding to ashwinthomas' suggestions. I'd love to see a feature of being able to display more fields in advanced search results (eg. year and item type), and be able to sort by them.