Evergreen

Bug #939570
Comment #7

Comment 7 for bug 939570

Revision history for this message

Dan Scott (denials) wrote on 2012-03-03:

On a basic functional level, I'm very concerned about the usability of an undifferentiated mix of libraries and copy location groups within the same selector widget. Perhaps, at least, split them out via <optgroup>s into "libraries" and "copy location groups", and/or style copy location groups differently, and (in a world with JavaScript) add some form of help (e.g. a question mark that leads to a popup) to describe why the heck the copy location group exists. The current examples on dev198 of "Popular collections", "Super popular collections", etc do a good job of demonstrating that it's going to be hard to communicate what these things are and how they differ from selecting a library.

Also, it looks like "locg"effectively replaces "loc" for the TPAC, given its prominence in the library selector. However, it also looks like "loc" - if set - overrides "locg", and then we also have "physical_loc" to throw into the mix as well. If someone was going to give a presentation on how to control searching in the TPAC, a nice crisp definition of these parameters and their precedence.

Also, to clarify, is it accurate to say that "copy_depth" is only meant to be used on record details, and not in search results? If so, this separates the record details logic further and further away from the in-DB unapi, making it more likely that we'll have to maintain parallel sets of logic for the two main chunks of the TPAC.

I'll admit that I also don't understand the basic use case for copy location groups, as it seems to have sprung up from nowhere. (I know, there's a customer asking for it somewhere, but their use case hasn't been communicated openly, to my knowledge, at least nowhere on the Evergreen mailing lists). Is this for patrons, or primarily for staff? It's all very abstract without the underlying rationale for building this functionality in the first place, and it would really be helpful if an example was included in the release notes. For example, "Enables searching across all of the New Book shelves in a given system" or something like that. I don't think _that's_ a particularly realistic or compelling use case, though, as a patron, and I'm trying to think of some reason I would want to search a collection of specific copy locations rather than just searching the libraries themselves. I could see an argument for "Enables searching only the DVD collections in a set of libraries", but in that case I would want to reply that the perceived need for searching copy locations represents a failure of cataloguing.

Also, to clarify, is it accurate to say that "copy_depth"  is only meant to be used on record details, and not in search results? If so, this separates the record details logic further and further away from the in-DB unapi, making it more likely that we'll have to maintain parallel sets of logic for the two main chunks of the TPAC.

I'll admit that I also don't understand the basic use case for copy location groups, as it seems to have sprung up from nowhere. (I know, there's a customer asking for it somewhere, but their use case hasn't been communicated openly, to my knowledge, at least nowhere on the Evergreen mailing lists). Is this for patrons, or primarily for staff? It's all very abstract without the underlying rationale for building this functionality in the first place, and it would really be helpful if an example was included in the release notes. For example, "Enables searching across all of the New Book shelves in a given system" or something like that.  I don't think _that's_ a particularly realistic or compelling use case, though, as a patron, and I'm trying to think of some reason I would want to search a collection of specific copy locations rather than just searching the libraries themselves. I could see an argument for "Enables searching only the DVD collections in a set of libraries", but in that case I would want to reply that the perceived need for searching copy locations represents a failure of cataloguing.