Copy Location Search Groups

[Bill Erickson]

From the included release notes:

This feature allows staff to create and name sets of copy locations to use as a search filter in the catalog. OPAC-visible groups will display within the library selector in the template toolkit OPAC. When a user selects a group and performs a search, the set of results will be limited to records that have copies in one of the copy locations within the group. Groups can live at any level of the library hierarchy and may include copy locations from any parent org unit or child org unit.

For advanced users, this change includes a new Query Parser filter called
location_groups().

==

As it stands currently, copy location groups for a given org unit are visible in the TPac org unit selector under the following conditions:
- The org is the current search org unit
- The org is the current physical location org unit
- The org is the logged in patron's home org unit
- The org is a parent or child of any of these.

For example, if you are searching globally, you will see all copy location groups. If you are searching your home library from within your home library, you will see copy location groups for your home library and any parent org units (and any sub-library org units).

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/copy-location-search-groups

[Lebbeous Fogle-Weekley (lebbeous)]

First, I tested this without actually using the conify interfaces, but instead creating groups and mappings directly in the database.

So searching in the TPAC worked great. Shelving loc groups appeared in the ou selector dropdown where I'd expect to see them.

Then I deleted all those groups and mappings and set out to create new ones in the nice looking conify interface. But after clicking "new" in the "Location Groups" column, entering a name in the EditDialog, and clicking save, the interface hangs. The new group object *is* created in the database, but even after reloading the interface I can't seem to do anything with it (nothing within the interface is responding to my clicks). No client side errors in the Javascript console.

Also upon reload, there are no longer any copy locations in the "Copy Locations" column. But aha, as I type I looked for server-side errors, and pcrud complains of missing datatype attributes for the fields on the new objects, so I'll try fixing that for you and see how far I get after that.

Finally, "Visible ✓" vs "Visible X" could be a little unclear in meaning to users. At first I thought I could toggle the ✓ and X glyphs by clicking on them. I'd favor "visible" / "not visible" or "invisible" or something.

[Lebbeous Fogle-Weekley (lebbeous)]

Ignore paragraphs 3-4 out of the 5 in my previous comment. The problem was really with my test environment. The conify interface seems to work fine.

Leaving it up to you, Bill, whether to actually change the Visible ✓ and Visible ✗ thing. I rebased against master, signed-off on HEAD, and pushed the result here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/copy-location-search-groups

[Bill Erickson (berick)]

I was a little unsure about the visible / not visible display as well. Will push patch for "visible" / "not visible" w/ some css

[Bill Erickson (berick)]

Pushed to collab/senator/copy-location-search-groups.
--------

commit 6a682e53597798aa7c5d8b04a7ddedb8193b40a3
Author: Bill Erickson <email address hidden>
Date: Fri Feb 24 15:43:47 2012 -0500

    Copy Location Search Groups : admin UI improvements

    Two improvements to the location group list.

    1. Replace x / checkmark glyphs with clearer Visible / Not Visible
    labels. Thanks for the suggestions, Lebbeous.

    2. Vertically align the edit actions block and the drag grips so the
    actions are always in the same place.

[Bill Erickson (berick)]

I've pushed a patch to fix the copy information "Show" links which no longer worked in the presence of "logc":

This adds a new CGI param "copy_depth" which the record detail page uses
to determine which copies to display in the copy grid and what serials
holdings data to show.

The goal is to separate search depth from copy display depth for 2
main reasons:

1. When present, the search ou is set by the "logc" parameter (org +
copy location group). The "Show" links in the record detail page use
"loc" to determine the copy location org (and subsequently the depth),
which is ignored in the presence of "logc". In other words, we need
a different way to communicate which range of copies to display.

2. Separating copy depth and search depth allows us to display
search location-related summary information while at the same time
displaying a broader set of copy information. For example, searching
BR1, we can see copy summary info for BR1, SYS1, and CONS even when
explicitly viewing copy information for CONS. In other words, viewing a
broader set of copies for a record does not change the search/context
org unit, it only extends the set of copies to display.

[Bill Erickson (berick)]

Pushed an additional feature patch:

Adds a 'top' flag to copy_location_groups which, when enabled, will
cause the location group to sort above the child org units in the org
unit selector in the tpac.

[Dan Scott (denials)]

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.

[Kathy Lussier (klussier)]

I can answer the questions regarding use case. Our primary use of copy location search groups will be to search for materials in children's and YA locations. I included this use case in MassLNC's original project description - http://masslnc.cwmars.org/node/2392 - which I believe was shared with the list in August, but was probably buried among other project ideas (I still haven't found a good way of sharing a large group of development ideas with the community.)

To expand upon this use case, although there currently is an advanced search limiter for audience, the MARC record isn't a true reflection of the audience. One MARC record for Harry Potter will be used by libraries that have shelved it in children's and YA collections. We would want this to show up in results for both audiences. Another MARC record for Hitchhiker's Guide to the Galaxy may include copies shelved in Adult Fiction at BR1 while shelved in YA Fiction at BR2. We would want this to show up for the appropriate audience at each location.

Of course, there are other use cases where the MARC record doesn't provide a good means for characterizing materials, but its copy location may be a little more informative. Another example off the top of my head might be consortium-wide scope for historical collections.

[Dan Scott (denials)]

Thanks, Kathy. The link to the project description is quite helpful! We should probably get in the habit, as developers, of pointing to public specifications in our bugs when we start working on something.

It looks to me like the code that has been developed in the attached branches matches what has been requested in the specification, but as software developers we need to question the specification in an attempt to provide the best solution to the underlying use case - particularly for code that is targeted for Evergreen in general that would introduce additional complexity at the code & UI level.

I find it interesting that the problem that you're trying to solve is related to records having copies that might exist in multiple locations, and the desire to find those records in all of those locations. In all of those use cases, it seems that the attribute we want to search on should be attached to the record, not to the copy or the copy's location; the location is just an accidental property at a given point in time. (If a copy gets moved to a different location, does it stop being "Children's Material"? Methinks not, unless copies mature over time - heh.)

From the Hitchhiker's Guide example, I don't see how it would actually help a patron to bind together the YA shelf at one library with the Adult shelf at another library. If someone searches for "Hitchhiker" in that theoretical copy location group, they could still get adult fiction about murderous hitchhikers from one library mixed in with results for zany speculative fiction at another library. If the libraries have conflicting shelving policies, it sounds like they'll have conflicting cataloguing policies, and that the "copy location group" is an attempt to impose one standard last-ditch unification policy on the unruly libraries.

I think that there is a solution to this, in MARC, using mostly existing Evergreen functionality. You could define a custom index (call it "subject|audience") on a local field (say, 695) in config.metabib_field and use the 695 field to hold values that would map to the example "copy location groups" in the specification. For example:

695 $a Children's Materials
695 $a Young Adult Materials
695 $a Historical Collection
695 $a Local Authors

(You could go further, if this is a matter of cataloguing / shelving disagreements, and include a subfield identifying which library added a given classification so that the search could include a particular library's point of view - my local author isn't your local author!).

The MARC records could be fairly easily populated with this additional field through an automated means (e.g. if you wanted to retrofit the MARC records with these fields based on copy locations, you could identify which records currently have copies in those copy locations and augment them accordingly).

... and then invoke that not from the search location, but (here's the only bit of additional code that would be required): from an additional search selector such as an "Audience" drop-down menu or the like, that would then include 'subject|audience:"Children's Materials"' in the search string (or 'subject|audience:"Children's Materials" Andy Bra...

[Tim Spindler (tspindler-cwmars)]

Dan,

One of the reasons for us using shelf location is that some libraries
define childrens' material different than others and may not want to follow
what is specified in the MARC tags. Kathy might have better examples than
me but I know that some libraries with the "Hunger Games" may classify it
as young adult and others as adult. (I don't remember what the audience is
indicated in the MARC record). There other areas where it may be more
arbitrary. A library may have a to locations for their reference location
"Reference" and "Indexes" and want to have a search scope for both of those.

Tim

On Mon, Mar 5, 2012 at 1:15 AM, Dan Scott <email address hidden> wrote:

> Thanks, Kathy. The link to the project description is quite helpful! We
> should probably get in the habit, as developers, of pointing to public
> specifications in our bugs when we start working on something.
>
> It looks to me like the code that has been developed in the attached
> branches matches what has been requested in the specification, but as
> software developers we need to question the specification in an attempt
> to provide the best solution to the underlying use case - particularly
> for code that is targeted for Evergreen in general that would introduce
> additional complexity at the code & UI level.
>
> I find it interesting that the problem that you're trying to solve is
> related to records having copies that might exist in multiple locations,
> and the desire to find those records in all of those locations. In all
> of those use cases, it seems that the attribute we want to search on
> should be attached to the record, not to the copy or the copy's
> location; the location is just an accidental property at a given point
> in time. (If a copy gets moved to a different location, does it stop
> being "Children's Material"? Methinks not, unless copies mature over
> time - heh.)
>
> >From the Hitchhiker's Guide example, I don't see how it would actually
> help a patron to bind together the YA shelf at one library with the
> Adult shelf at another library. If someone searches for "Hitchhiker" in
> that theoretical copy location group, they could still get adult fiction
> about murderous hitchhikers from one library mixed in with results for
> zany speculative fiction at another library. If the libraries have
> conflicting shelving policies, it sounds like they'll have conflicting
> cataloguing policies, and that the "copy location group" is an attempt
> to impose one standard last-ditch unification policy on the unruly
> libraries.
>
> I think that there is a solution to this, in MARC, using mostly existing
> Evergreen functionality. You could define a custom index (call it
> "subject|audience") on a local field (say, 695) in config.metabib_field
> and use the 695 field to hold values that would map to the example "copy
> location groups" in the specification. For example:
>
> 695 $a Children's Materials
> 695 $a Young Adult Materials
> 695 $a Historical Collection
> 695 $a Local Authors
>
> (You could go further, if this is a matter of cataloguing / shelving
> disagreements, and include a subfield identifying which library added a
> given classification so that t...

[Thomas Berezansky (tsbere)]

I am not going to claim to know everything about what this development aims to accomplish, but I see multiple potential issues with the MARC Record approach compared to the approach Dan brought up. Anyone who does know more can chime in and tell me I am wrong.

One of those is loss of data if someone isn't doing a good job editing the MARC Record, via merging, overlaying, or manual editing. Perhaps even intentional edits along the lines of "No WAY this is supposed to be in that category!" regardless of whether or not there is a "who put this here" subfield.

A second is transitory locations that people may want to search, like "Display" locations, or perhaps "New" or "Popular" locations. Editing the MARC every time you move something in or out of these locations would be annoying at best, and wouldn't happen at worst. Add to that the detail that the staff moving things in and out of these locations may not be catalogers, and thus may not have enough knowledge or permissions to edit the MARC itself. Furthermore, if two libraries put something on Display at the same time, one may wipe out the Display tag when the other is still using it, causing the MARC to no longer reflect reality in one of the libraries at that point.

A third is that I suspect this is partially intended to replace the missing Copy Location limiter from JSPac, which ignored MARC designations and showed you what is in that specific location. That limiter was built based on scoping rules that don't work in TPac, and thus doesn't currently exist in TPac. I don't see MARC information as being a suitable substitute for that functionality, personally.

[Tim Spindler (tspindler-cwmars)]

Tom,

I know the transitory locations like Display is important to some of our
libraries and you make a very good point. There essentially is a lot of
information stored in shelf locations that I would not want to carry over
into a MARC record for the sake of creating a search index.

Tim

On Mon, Mar 5, 2012 at 7:02 AM, Thomas Berezansky <<email address hidden>
> wrote:

> I am not going to claim to know everything about what this development
> aims to accomplish, but I see multiple potential issues with the MARC
> Record approach compared to the approach Dan brought up. Anyone who does
> know more can chime in and tell me I am wrong.
>
> One of those is loss of data if someone isn't doing a good job editing
> the MARC Record, via merging, overlaying, or manual editing. Perhaps
> even intentional edits along the lines of "No WAY this is supposed to be
> in that category!" regardless of whether or not there is a "who put this
> here" subfield.
>
> A second is transitory locations that people may want to search, like
> "Display" locations, or perhaps "New" or "Popular" locations. Editing
> the MARC every time you move something in or out of these locations
> would be annoying at best, and wouldn't happen at worst. Add to that the
> detail that the staff moving things in and out of these locations may
> not be catalogers, and thus may not have enough knowledge or permissions
> to edit the MARC itself. Furthermore, if two libraries put something on
> Display at the same time, one may wipe out the Display tag when the
> other is still using it, causing the MARC to no longer reflect reality
> in one of the libraries at that point.
>
> A third is that I suspect this is partially intended to replace the
> missing Copy Location limiter from JSPac, which ignored MARC
> designations and showed you what is in that specific location. That
> limiter was built based on scoping rules that don't work in TPac, and
> thus doesn't currently exist in TPac. I don't see MARC information as
> being a suitable substitute for that functionality, personally.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> https://bugs.launchpad.net/bugs/939570
>
> Title:
> Copy Location Search Groups
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> From the included release notes:
>
> This feature allows staff to create and name sets of copy locations to
> use as a search filter in the catalog. OPAC-visible groups will
> display within the library selector in the template toolkit OPAC.
> When a user selects a group and performs a search, the set of results
> will be limited to records that have copies in one of the copy
> locations within the group. Groups can live at any level of the
> library hierarchy and may include copy locations from any parent org
> unit or child org unit.
>
> For advanced users, this change includes a new Query Parser filter called
> location_groups().
>
> ==
>
> As it stands currently, copy location groups for a given org unit are
> visible in the TPac org unit selector under the following conditions:
> - The org is the current search org unit
> - The org is the current physical l...

[Thomas Berezansky (tsbere)]

I apparently need to not write these responses from home before coming into the office. Stupid me paying attention to more than just the moderation queues before the 8 am "email me about any I haven't dealt with".

"but I see multiple potential issues with the MARC Record approach compared to the approach Dan brought up" should probably have been "but I see multiple potential issues with the MARC Record approach compared to the implemented approach" or similar. <_<

[Kathy Lussier (klussier)]

Although audience was the example I used in my use case, I would like to add that we generally see these as location searches, and that location happens to be a subset of the larger location that is the library branch. If the Hitchhiker's Guide to the Galaxy is moved from the adult collection to the YA collection as part of the Summer Reading program, then we no longer would want to see that title appear in the search results for the adult collection. As Tom mentioned, with centralized cataloging used in our consortia, we do have cataloging staff at many libraries who do not have permission to edit the MARC record since their role is to do copy cataloging. Making those changes at the MARC record level would be complicated.

Overall, I see this as one piece of a larger goal to give libraries more flexibility in how they scope their collections. At a minimum, we need to be able to scope to the branches and to the entire consortium, and we are already doing this by relying on the hierarchy. Many systems are probably happy with these built-in scopes and may just want to continue with this approach, but others may find it to be too rigid. Allowing a system to group together several copy locations is one way to provide more flexibility. Allowing systems to more easily hide redundant org unit levels is another way to provide more flexibility, and ESI is currently working on a project to do so (the specs are available at http://www.esilibrary.com/esi/docs/?p=841 - Greater flexibility in library selector display.) I could see incorporating org unit lassos as another piece to giving consortia greater control over their scopes (not something we're working on, but I can see the benefit of such a project).

I agree that usability could be an issue if you went crazy with copy location groups, but I think each system should be able to decide which scopes work best for them.

As a side note, I also wanted to mention that I personally do not see this as a replacement for the copy location limiters that were available in jspac. When we first issued the RFP for this project, tpac was still in its infancy, and I didn't realize that the copy locations would be removed (actually, I think it's left as a "to do" item in the code.) I still see a use for those more granular limiters (e.g. I'm looking for a book on the solar system for my 3 year old and want to make sure I'm only searching the Picture Book location), but it is probably something more likely to be utilized by a power searcher and therefore belongs on the advanced search page.

[George Duimovich (george-duimovich)]

I also see this as a way of grouping "virtual collections" as a result of library mergers, consortia formation, etc.

In our setting, we've merged libraries and would find it useful to group certain copy locations into some kind of named collection facet that spans across several physical library branches. So if three of our branches have various copy locations for "Archives / Rare Books", then being able to limit search to all the copy locations for that collection grouping (across multiple physical locations) would be desirable feature.

[George Duimovich (george-duimovich)]

Additional use case scenario:

Our Org Unit locations are roughly in line with subject area specializations, so when we first launched, the OU groupings in our library selector were labeled in a way that essentially acted as broad subject collection filters (in lieu of the more common geographical, administrative, or consortial type of group labels used elsewhere).

So our situation was born out of the scenario where for the most part, our branch locations were fairly subject specific focused, and the Org Unit group limiter could be used for predictably narrowing down your search to, say "Earth Sciences" libraries/collections at group or branch level versus "Forestry" collections at group or branch level.

But given impending (likely) cuts to locations and/or collections in the upcoming federal budget, we will likely see one or more collections consolidated in the coming months/ years. In fact, this has already happened with one of our Ottawa collections -- we have a couple of "clean" groupings in our OU library browser (catalogue.nrcan.gc.ca) but then have this mashup labeled "Energy, Minerals, and Management" (as a result of previous merger of collections). That latter grouping obviously not as useful as the more defined groupings of "Earth Sciences" or "Forestry" for the purpose we originally intended.

So going forward our use of OU groupings by subject will likely become too awkward in the event that, say, one of our Earth Science branch locations is closed and its collections (copies) moved to a nearby Foresty network branch library (or vice versa etc.).

Haven't seen TPAC yet, but seems that the functionality being discussed here would help us maintain some kind of facet/filter or limiter at these defined groupings based upon copy locations (and in the future, with more dev investment, possibly use other 'hooks' to identify arbitrary collection groupings, both physical or digital, deemed useful for our patrons).

[Dan Scott (denials)]

Okay, clearly a number of sites want copy location group functionality; I suspect more for staff purposes than for the public, but so be it.

Given that, I still think the interface design is a problem. If we're going to have copy location groups that are owned by particular libraries, I would much rather see a linked widget that shows the copy location groups that are available for the currently chosen library. So, if you change the selection for the drop-down widget from "Example System 1" to "Example System 2", a separate "Collection" widget would change to show all of the collections available at that scope. The ideal implementation might mean more JavaScript, but I think that decoupling the copy location groups from the search library picker would be much more usable and in keeping with the current "Search [format] for [search term] [index] at [library] in [collection]" model of the search bar (with the default being "All collections", naturally).

[Dan Scott (denials)]

George: One place you can see the current implementation in action is at http://dev198.esilibrary.com/eg/opac/home (at least currently) thanks to Equinox & Bill Erickson :)

[Bill Erickson (berick)]

Dan, the design was based on not requiring JS for the functionality. I agree it could be smoother. I see a couple of options:

1. Apply CSS to better differentiate org units and copy-loc-groups, simulate nested optgroups, etc.

2. Implement a version of the linked selector Dan suggests that fails gracefully without JS, though I imagine it would require loading all copy-loc-groups and hiding the non-visible ones when JS is present. One problem with that approach is that in the non-JS world, the secondary selector would have to render all of the libs as well, in order for the user to know where each collection lives. In addition to being a duplicate of org tree, this creates a scenario where the user could select an org unit and a copy-loc-group for a different org unit. Hmm, yeah, I don't think this is really an option, but I'll leave it here for reference.

3. Alternatively, we could only show the copy-loc-groups relevant to the current context org units and in a non-JS situation, you would have to search at another org unit before its copy-loc-groups appeared in the linked selector. This would avoid the "show the entire org tree again" problem from #2.

4. Render the 1-selector-to-rule-them-all for non-JS and render the linked selector when JS is present. This would require we keep the "locg" parameter instead of creating a separate parameter for copy-loc-group.

5. Allow certain types of tpac features to require JS and, I suppose, hide them when no JS is present. In this case, I would still prefer to fetch all of the copy-loc-groups and show/hide as necessary to avoid requiring XHR to update the list.

---

"locg" replaces and extends "loc". "loc" is still supported and used when "locg" is not present, though I imagine its use may effectively be phased out with this feature.

---

copy_depth was meant only for record details page, though it could conceivably be used elsewhere. The goal is to decouple search depth from copy/holdings display depth. I don't see why it wouldn't work with unapi. It's really just "depth" as the OPAC currently understands it, minus its affect on bib search range. We could alternatively create a "search_depth" parameter for controlling search depth and leave "depth" as the copy/holdings/etc depth.

[Mike Rylander (mrylander)]

Maybe I'm missing something huge, but since your average library patron probably just sees that dropdown as "groups of books that I can constrain my search to", isn't it the least confusing to simply toss them all in a single nested dropdown as they are now?

To put that another way ... what I mean is, wouldn't making a building and a shelving location / collection look different be more confusing to someone that doesn't necessarily know that either are "things", in the way that a librarian knows that?

[Dan Scott (denials)]

Mike, I work with library patrons on a daily basis; that's the experience I'm basing my concerns on.

Mixing libraries and collections of shelving locations into the same undifferentiated picker, without providing any sort of guidance as to what a given selection contains beyond the name of the thing, seems like the huge thing that you may be missing.

On the other hand, it might be a good way to boost reference stats. The following sort of scenario seems utterly plausible, based on experiences that I've had with patrons confused by even the existing search library / search scope UI we have in the JSPAC:

'I'm looking for "Hitchhiker's Guide to the Galaxy" but can't find a copy."

"What were you searching?"

"I tried searching by title, and I changed the search library from 'Our Local System' to 'Sci-fi Collections' because it's an SF title."

"Oh, well you chose the collection that (the Consortium | the System | another Library) created, but we don't have a dedicated Sci-fi section and they must not have included our YA Fiction shelf. Let's search Library A instead. Ah, there you go, it's actually over on the "Monthly Display" shelf, I guess it's British Humour month."

I think the primary problem with copy location groups and the current UI is that the nature of these copy location groups is utterly opaque to the user; we provide them with no affordances - other than the name - to know that 1) what they're searching is a subset of the entire collection of a given library or set of libraries 2) what scope the collection cuts across - it could include libraries from the entire State when they're interested in only the library they're standing in 3) what shelving locations are actually in the collection group 4) what the purpose of the collection group is.

By comparison, the search scope of a library is explicit: it is everything in a library.

As I noted in a previous comment, this feature seems much more suited for library staff performing specific searches who will have a better idea of what these collection groups mean, rather than towards regular patrons who will be guessing blindly (and increasing the likelihood of preventing themselves from finding a copy of the item they're looking for).

[Jason Etheridge (phasefx)]

Some personal opinion and rambling here... Evergreen has always been about not overloading concepts, not conflating things that should be orthogonal. Yet people tend to do it anyway (how many folks use circ modifiers for both statistics and circ rules, because that's what they're used to with legacy item types?) I think it's for convenience that they do this. What's more important in this case? Being strict in separating concerns, or letting folks do what they want? Is this a foot gun? Does it negatively impact the code base? If someone wanted to represent call numbers as org units, do we stop them? Maybe. It's well understood what org units are for, and what call numbers are for. But how well defined are shelving locations (aka copy locations)? Many folks migrate legacy "collection codes" as shelving locations, and what connotations might _those_ have? Some legacy systems have collection groups that contain multiple collection codes. What do we do for folks who are coming to Evergreen with that sort of data?

[Bill Erickson (berick)]

On Tue, Mar 06, 2012 at 10:01:24PM -0000, Dan Scott wrote:
[...]
> I think the primary problem with copy location groups and the current UI
> is that the nature of these copy location groups is utterly opaque to
> the user; we provide them with no affordances - other than the name - to
> know that 1) what they're searching is a subset of the entire collection
> of a given library or set of libraries 2) what scope the collection cuts
> across - it could include libraries from the entire State when they're
> interested in only the library they're standing in 3) what shelving
> locations are actually in the collection group 4) what the purpose of
> the collection group is.

Ah, I see what part of the problem is here. Dan, when you were looking
at my dev198 server, I only had "global" copy location groups
configured. When a branch configures their own groups, they show up as
children of the branch in the org selector. In other words, if a patron
is only interested in the branch he/she is standing in, he should choose
one of the groups that are a child of the branch instead of the
global (or system, etc) groups.

As a general rule, I'd suggest that global groups should be used
carefully and only when they pull copies from most or all of the org
units they encompass to prevent the kind of confusion you're talking
about.

-b

--
Bill Erickson
| Senior Software Developer
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 877-OPEN-ILS (673-6457)
| email: <email address hidden>
| web: http://esilibrary.com

[Mike Rylander (mrylander)]

Just a note about the seeming lack of tech-spec publishing ... the were, actually, at http://www.esilibrary.com/esi/docs/?p=841 .

I had assumed, obviously quite incorrectly, that the ESI documentation blog had been added to the planet. So, if someone that provides care and feeding for http://planet.evergreen-ils.org/ would add that, it would be really great. That's where we post docs and tech specs for funded projects, and I think everyone would benefit from early access to that.

[Mike Rylander (mrylander)]

> Mixing libraries and collections of shelving locations
> into the same undifferentiated picker, without
> providing any sort of guidance as to what a given
> selection contains beyond the name of the thing,
> seems like the huge thing that you may be missing.

I ... guess? ... Snark aside, I think we'll just have to agree to disagree that on this one.

I didn't write the code (so, no personal investment), and I was originally opposed the the idea of mixing shelving location groups into the "search within" dropdown for exactly the overloading concerns that Jason raised. Then, when I saw it in action, it immediately struck me -- as a user, not as someone with a fundamental understanding of the underlying data structures and the differences among things being mashed together on the screen -- as a really efficient and elegant UI. I understood, because of the hierarchical indentation, that I was looking at subsets, or "circles within circles", and, at least for me it was obvious, it seemed like a way for the library to guide me toward things they felt should be highlighted.

Bill pointed out a problem with the test data that existed on his particular instance when you looked, but that was a case of "bad example, not bad feature" IMHO.

Anyway, as I said, I have no personal investment beyond my positive reaction to the UI, so having offered my opinion I shall step down from the soap box.

[Dan Scott (denials)]

A bug report is a bit of an odd place to request an addition to the
planet, but I guess there's no other way to raise that request. Oh
wait, on the right-hand side of the planet there's "To add your blog
to the Planet Evergreen blog aggregator, send an email to
<email address hidden>" - always has been!

Anyway, I'll go ahead and add that...

[Dan Scott (denials)]

The description of this functionality says: "Groups can live at any level of the library hierarchy and may include copy locations from any parent org unit or child org unit."

This is what strikes me as wrong: taking a purely hierarchical model of org units, where parents contain children, and breaking that universally understood UI feature with a group that can "include copy locations from any parent org unit".

So, Mike, your own expectation and misunderstanding confirms my opinion that the current design of the UI is deficient. If the copy location groups in the hierarchical picker can break the hierarchy by including locations from parent orgs, it is misleading.

[Bill Erickson (berick)]

I disagree, Dan. A copy location from a parent does not mean "copies owned above me", it just means a location that is configured at a higher level that any branch can use for its own purposes. The location is still referfing to copies owned by the branch.

[Mike Rylander (mrylander)]

Arg ... you misunderstand me, which is surely my fault for not explaining well enough what I meant.

I don't care, as a user, how strict the visible hierarchy actually is. I care that my home library has put together a collection of shelving locations that highlight something I care about -- and I'm perfectly OK with that collection including things from other physical buildings!

Anyway, I'm probably just making things less clear. Feel free to toss that in whatever evidence pile you like. I know what the feature can do, and how it can be used, and what uses people already have planned for it, and yet, as a user, it still satisfies me and I would be happy to be a patron-user of it.

[Bill Erickson (berick)]

For reference, a more practical example might help:

Consortium
 - System
  -- Branch1
   --- BR1 Bookmobile
   --- [ Popular Collections ]
   --- [ Young Adult Fiction ]
  -- Branch 2
   --- [ Historical Collections ]
   --- [ Local Authors ]

As a patron, I would think the intent for each of these is pretty clear. "I'm searching a collection of items at a branch". If you search "Popular Collections", you will only get hits that have copies at Branch 1 (within the configured set of copy locations).

[Bill Erickson (berick)]

Similarly, if you wanted to include items from all branches in a system...

Consortium
 - System
  -- Branch 1
  -- Branch 2
  -- [Local History]

[Dan Scott (denials)]

The original description was: "When a user selects a group and performs a search, the set of results will be limited to records that have copies in one of the copy locations within the group. Groups can live at any level of the library hierarchy and may include copy locations from any parent org unit or child org unit."

If it had said something about continuing to limit results to copies owned by org units within the chosen search scope, that probably would have avoided 20 comments or so. All this time, I thought the intention of the feature was to extend the search scope to include arbitrary locations across the org unit hierarchy.

[Kathy Lussier (klussier)]

Bill described it pretty well, but I thought it might be helpful to provide a screenshot of how it looks on the test system where we have configured some copy location groups. The ones at the bottom are the consortium-wide groups (which can also be sorted at the top of the list), and the others are branch-level groups.

FWIW - we aren't wedded to this display for the copy location groups. There are some advantages for including them in the library selector, but we can also see some merit to Dan's suggestion to decouple them from selector and wouldn't object if this were done to gain wider community acceptance for the project.

[Bill Erickson (berick)]

I'd like to propose that we keep the existing design primarily because it's the best implementation for non-JS clients. In fact, I think it's the only one that does not allow for paradoxes (search branch A, search collection at branch B). I'd be happy to add some CSS to differentiate between orgs and collections, perhaps as a follow-up LP ticket, if desired. Naturally, if this turns out to be very confusing to users, we'll need to readdress the design. My hunch is it won't, though.

[Bill Erickson (berick)]

Repaired a merge conflict and pushed a rebased branch to

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/copy-location-search-groups

[Dan Scott (denials)]

Picked, tested, and pushed to master (with one additional tiny commit to add classes to the OPTION elements). Looks good - thanks for bearing with my lack of understanding earlier.