I would like to also add a vote in support of this feature request.
Although I have just began using Zotero recently, I am already missing this feature. Some examples of the folders I would set up if the feature was available would include Maintenance (incl. various saved searches of missing metadata), Recent Items (incl today, this week, this month), Type (incl journal article, book, thesis), etc. All of these views would provide a helpful way of navigating the data. However, in the absence of this feature, I find myself making less use of saved searches to avoid the lefthand pane becoming difficult to navigate.
It is unfortunate that this feature has still not been implemented. It is one of my only disappointments with Zotero. I hope organizing saved searches is implemented soon.
It's a lot easier to come up with feature requests than to code them and so there are, in fact, a large number of features that have been planned since the beginning of Zotero or shortly thereafter that haven't been implemented. That's hardly surprising. Comments about things being "not that hard" directed at open source software will invariably get you the response that patches are always welcome.
Is it actually possible to sponsor directly its developement/implementation?
I would also like to see this feature. A great capability would be to drag and drop saved searches into collections and subcollections.
I saw in another thread the option to add a criteria to a saved search to specify a certain collection, but that seems to defeat the purpose of the saved search because (I assume that) I would still have to manually assign each file to the collection.
For now I'm making artificial parent collections by assigning prefixes to my saved searches, e.g., "Author_Brown".
[Side comment feedback -- I'm new to Zotero, and while I like it very much, its use of the word "Creator" instead of "Author" is a bit disorienting. I have to remind myself every time not to look for the author listing but instead creator.]
(it doesn't use Creator instead of Author -- if Zotero is just referring to authors, that's what it says. Creator, on the other hand, includes any person involved, including editor, translator, director, etc. It's actually a limitation of saved searches that you _can't_ search for just authors)
Oohh, that makes more sense, especially for books or other documents where the editor or other person is primarily used instead of the author.
To avoid ambiguity, it would be great if there were a way to search for authors only. It would also be great if the documentation included a list of the different search criteria and clarified what each referred to. (Just now I looked briefly for a clarification of "creator", but I couldn't find it.)
Thanks for accommodating my sub-thread post. It's pretty amazing that all these capabilities exist in a freeware application. Keep up the good work! :)
It would also be great if the documentation included a list of the different search criteria and clarified what each referred to.
You can see the fields that are searched by hovering over the fields in the advanced search drop-down, except for "Creator" because it just searches all creator types.
Thanks, I can see the list of terms themselves but my suggestion was to define what the terms refer to. This would especially be useful for "creator" because at first I had no idea what that meant, and I assumed it was equivalent to "author" because I saw no search (or sort) term for author. (This topic really belongs in a different thread, but thanks for commenting.)
I think you misunderstand -- for all other search terms that refer to more than one field in Zotero, hovering over the term lists the names of all the fields in Zotero it is searching.
The fact that it doesn't do that for Creator I think is too bad and largely for technical reasons, I think.
I also do think we should allow users to search for individual creator roles--the Advanced Search hasn't seen much love in a long time.
Ok, I see it now, thanks for clearing that up. When I hovered over the first few terms in the list, I didn't see anything, but when I got to Numbers and Pages, etc, I see the extended fields.
I agree that the Advanced Search dialog could be improved from a UI point of view. For example, I notice that "Title" has a few different subfields, but "Series Title" is separate. If I want to look for a specific field but I didn't already know that it's grouped under a parent field, I wouldn't know where to look unless I tried taking a guess and started hovering over different terms.
In addition to the pop-up, maybe the parent terms can get an extra dropdown which includes their child search fields, giving the option to search through all of them or individual fields. Plus, it would still be helpful to give a few more details in the documentation under the "Running an Advanced Search" section. For example, hovering over certain terms to identify groups of search fields (or even the fact that some search fields are grouped) is not mentioned here.
Thanks again for the info. I know that a lot can go into stuff like this, so hopefully this feedback is helpful.
I'm not sure what you're suggesting re: Series Title, since that's actually a separate, unrelated field. The fields grouped under things like "Title" (which we call "base-mapped field") are actually the same field, such that you can switch between item types and the contents remain — they just have item type–specific names.
Using submenus for the base-mapped fields isn't a bad idea, though on a technical level it would be fairly tricky to implement. The model for it would be the folder selector at the bottom of the Message Filters window in Thunderbird, where you you can still navigate using the keyboard — typing the beginning of a submenu (e.g., "Pu" for "Publication" in our case) expands the submenu and focuses the top item, which would be the base field itself.
Doing that just for base fields also wouldn't reduce the absurd length of this menu (which is good for keyboard navigation but less so for actually finding things manually), so we might consider other groupings — e.g., adding a "More Fields" submenu like the "More Columns" submenu in our middle pane column picker.
Thanks, Dan. I'm glad that my suggestions spurred some potential new ideas for the program.
Re: Series Title -- This comment came from pure association. I'm a new user, so I didn't know that the base-mapped fields had different names for different item types; I suppose I thought that they were all considered different base-mapped fields. I see now that I misunderstood the purpose behind grouping different terms together; I thought it was based on association, hence my thought to myself, "Why isn't "series title" grouped with all the other "titles"? Thanks for clearing that up. Hopefully my perspective here was useful for you to know the potential thought processes that exist on the user end of the software.
The extra dropdown that I referred to in my suggestion was to be a completely separate list box from the base-mapped fields that appears when a field having different names is selected. Now that I understand that they're actually all the same base-mapped fields, just having different names for different item types, I agree that it makes sense to have the option to specify the item type first and then select the appropriate field. Although this would not reduce the length of the list, it may help the user locate the field of interest more easily.
In either case, I do like the idea of listing only the most common fields and then having a "more fields" submenu for the rest. This would make the common fields easier to find. If not a submenu, a horizontal line would work too, similar to how the File > New Item submenu is arranged.
I still think it would be useful for the (new) user to know how the advanced search dialog works, that some of the search fields have different names for different item types. This could easily be implemented by adding further explanation to the documentation. For example, if I had a bunch of encyclopedia articles and I wanted to search under "Encyclopedia Title", I wouldn't immediately find this in the list, and I may not know that it's grouped under a different name. Just now when I looked for it I finally found it under "Publication". I don't think that kind of trial-and-error guesswork should be necessary. It's not always clear how the listed names of the base-mapped fields were chosen. For example, some people use the word "publication" to refer to an article itself and not the name of the journal or book or encyclopedia, etc. (In scientific circles, "How many publications do you have?" usually means, "How many articles have you published?")
I agree that it makes sense to have the option to specify the item type first and then select the appropriate field
Just to clarify, I wasn't suggesting that. I was saying that you would select the base field first, as you do now, but instead of just a tooltip it would open a submenu with the base-mapped fields, with the base field itself preseleced at the top.
I reallllly really hope that it'll come true someday.
I'm struggling with my master's thesis because I have to imagine a way to bypass the problem of not being able to make a "smart search" within a collection or a subcollection.
Simon: You can certainly create a saved search that searches within a collection. This thread (at least before it got a bit off-topic) is just about being able to move saved searches into collections for organizational purposes.
(But 5.0's new sync system does allow for it to happen at some point. We couldn't make most data schema changes in the previous sync system without cutting off older clients, which we never wanted to do.)
Upgrade Storage
Although I have just began using Zotero recently, I am already missing this feature. Some examples of the folders I would set up if the feature was available would include Maintenance (incl. various saved searches of missing metadata), Recent Items (incl today, this week, this month), Type (incl journal article, book, thesis), etc. All of these views would provide a helpful way of navigating the data. However, in the absence of this feature, I find myself making less use of saved searches to avoid the lefthand pane becoming difficult to navigate.
+1 for this. Surely it can't be that hard.. :/
I saw in another thread the option to add a criteria to a saved search to specify a certain collection, but that seems to defeat the purpose of the saved search because (I assume that) I would still have to manually assign each file to the collection.
For now I'm making artificial parent collections by assigning prefixes to my saved searches, e.g., "Author_Brown".
[Side comment feedback -- I'm new to Zotero, and while I like it very much, its use of the word "Creator" instead of "Author" is a bit disorienting. I have to remind myself every time not to look for the author listing but instead creator.]
To avoid ambiguity, it would be great if there were a way to search for authors only. It would also be great if the documentation included a list of the different search criteria and clarified what each referred to. (Just now I looked briefly for a clarification of "creator", but I couldn't find it.)
Thanks for accommodating my sub-thread post. It's pretty amazing that all these capabilities exist in a freeware application. Keep up the good work! :)
The fact that it doesn't do that for Creator I think is too bad and largely for technical reasons, I think.
I also do think we should allow users to search for individual creator roles--the Advanced Search hasn't seen much love in a long time.
I agree that the Advanced Search dialog could be improved from a UI point of view. For example, I notice that "Title" has a few different subfields, but "Series Title" is separate. If I want to look for a specific field but I didn't already know that it's grouped under a parent field, I wouldn't know where to look unless I tried taking a guess and started hovering over different terms.
In addition to the pop-up, maybe the parent terms can get an extra dropdown which includes their child search fields, giving the option to search through all of them or individual fields. Plus, it would still be helpful to give a few more details in the documentation under the "Running an Advanced Search" section. For example, hovering over certain terms to identify groups of search fields (or even the fact that some search fields are grouped) is not mentioned here.
Thanks again for the info. I know that a lot can go into stuff like this, so hopefully this feedback is helpful.
Using submenus for the base-mapped fields isn't a bad idea, though on a technical level it would be fairly tricky to implement. The model for it would be the folder selector at the bottom of the Message Filters window in Thunderbird, where you you can still navigate using the keyboard — typing the beginning of a submenu (e.g., "Pu" for "Publication" in our case) expands the submenu and focuses the top item, which would be the base field itself.
Doing that just for base fields also wouldn't reduce the absurd length of this menu (which is good for keyboard navigation but less so for actually finding things manually), so we might consider other groupings — e.g., adding a "More Fields" submenu like the "More Columns" submenu in our middle pane column picker.
Re: Series Title -- This comment came from pure association. I'm a new user, so I didn't know that the base-mapped fields had different names for different item types; I suppose I thought that they were all considered different base-mapped fields. I see now that I misunderstood the purpose behind grouping different terms together; I thought it was based on association, hence my thought to myself, "Why isn't "series title" grouped with all the other "titles"? Thanks for clearing that up. Hopefully my perspective here was useful for you to know the potential thought processes that exist on the user end of the software.
The extra dropdown that I referred to in my suggestion was to be a completely separate list box from the base-mapped fields that appears when a field having different names is selected. Now that I understand that they're actually all the same base-mapped fields, just having different names for different item types, I agree that it makes sense to have the option to specify the item type first and then select the appropriate field. Although this would not reduce the length of the list, it may help the user locate the field of interest more easily.
In either case, I do like the idea of listing only the most common fields and then having a "more fields" submenu for the rest. This would make the common fields easier to find. If not a submenu, a horizontal line would work too, similar to how the File > New Item submenu is arranged.
I still think it would be useful for the (new) user to know how the advanced search dialog works, that some of the search fields have different names for different item types. This could easily be implemented by adding further explanation to the documentation. For example, if I had a bunch of encyclopedia articles and I wanted to search under "Encyclopedia Title", I wouldn't immediately find this in the list, and I may not know that it's grouped under a different name. Just now when I looked for it I finally found it under "Publication". I don't think that kind of trial-and-error guesswork should be necessary. It's not always clear how the listed names of the base-mapped fields were chosen. For example, some people use the word "publication" to refer to an article itself and not the name of the journal or book or encyclopedia, etc. (In scientific circles, "How many publications do you have?" usually means, "How many articles have you published?")
Just some thoughts! Thanks for reading.
I'm struggling with my master's thesis because I have to imagine a way to bypass the problem of not being able to make a "smart search" within a collection or a subcollection.