Bringing lassos back: library groups functionality

[Mike Rylander]

Evergreen has, internally, a concept called "lassos" that allows an administrator to define a group of org units to search that has no relation to the hierarchical org tree. For instance, one might create a group of law or science libraries within a university consortium, or group all school libraries together. Unfortunately, it's been ignored during search code and UI changes over the years and has bit-rotted well past the point of even "expert" use directly via advanced search syntax.

Presented at http://yeti.esilibrary.com/dev/public/techspecs/library-groups.pdf are specs to resurrect this feature under the name Library Groups, and to extend its functionality beyond the initial use case of always-visible groups by adding context-awareness.

A branch is currently being prepared to implement these specs, and will follow soon. Of note for possible broader discussion as currently implemented:

  * This functionality requires a conceptual refactoring of the various "location-ish" search filters, such as shelving location groups and search "depth", because it only makes sense to use one of these filters in a given search. Specifically, location groups and library groups are now placed together within a new dropdown adjacent to the library selector, and the depth selector lives in this dropdown as well. The motivation for collecting them in a new dropdown is that these three are secondary or subordinate to the search location -- the org unit tells us what location groups, library groups, and depths are relevant or make sense -- and are mutually exclusive between each other. This dropdown is labeled as "Where" in each place it is displayed, but a different term may suit better.
  * Not implemented, but a straight-forward enhancement might be to use this new dropdown only when there are actually Library Groups to render, and otherwise leave location groups in the org tree dropdown and forget about depth selection altogether. However, that has the major drawback of varying the UI even within a single patron session, based on where in the org tree a search is focused.

Branch forthcoming...

[Mike Rylander (mrylander)]

The promised branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1815815-library_groups

[Jeff Davis (jdavis-sitka)]

I gave this a quick test, and the new dropdown seems confusing to me. I don't think it will be obvious to the user why there are two dropdowns for "scope" (broadly construed) or why certain entries appear in one dropdown rather than the other. In the standard case, where no library groups or location groups are configured, we get a new "Where" dropdown in the searchbar containing a "No Restrictions" entry and one or more entries under Search Scope; I think the average user will not know what this stuff means. The Search Scope options also seem unnecessary when the Location dropdown already lets you adjust search scope in a straightforward way; it's confusing to provide the same option in two different ways.

A few possibilities come to mind:

1. Provide the option for a unified dropdown, similar to the current Location dropdown which combines org units and location groups. I don't know if this is technically possible, but I feel like in many common use cases, the new approach exposes complexity to the user that ought to remain hidden.

2. Make the content of the Where dropdown configurable, e.g. make it possible to exclude Search Scope from the dropdown.

3. Provide an option in config.tt2 to suppress the Where dropdown entirely in the main searchbar. (It can already be suppressed on advanced search, where you're more likely to want to expose it.)

I hope this doesn't sound too negative! I think library groups are a great feature. I'll try to make time for more testing, since my consortium has relatively intricate scoping requirements.

[Andrea Neiman (aneiman)]

Hi Jeff-- thanks for the feedback! This development was sponsored by PaILS, and they will be testing it over the next few weeks as well. We have not pullrequested this yet since a final branch will be posted after partner testing is complete & I hope you can take a look at that branch, too, when it's ready.

[Mike Rylander (mrylander)]

I've force-pushed an update to the branch to address a display issue with location groups in the new UI component, and with a label in the IDL. Same coords.

[Mike Rylander (mrylander)]

I've rebased and pushed an updated version of the above branch. I haven't addressed Jeff's concerns, but I think we can do some of that. I think we can definitely provide ways to suppress the new dropdown, either entirely or just in certain cases (such as when there are no library groups to choose from given the context). And a way to suppress the depth selector seems reasonable, but I disagree that the equivalent functionality exists today.

The problem with providing just one dropdown and folding library groups into it, as I see it, is that we need a context org unit in order to identify context-based groups. IOW, they're dependent objects. One option I considered but discarded was embedding groups either under or directly above all the org units that are relevant. The most obvious problem with that is all the duplication it would create.

With that in mind, the fact that location groups are also dependent objects of org units (though, in general, in the other direction with regard to scope restriction) it seems useful to put them in the secondary dropdown as well.

Does anyone have more thoughts on how to come to a good UX compromise?

Thanks!

[Jane Sandberg (sandbergja)]

A few thoughts:

* This is cool!
* The new Angular Server Admin page will need links to the Library Group and Library Group Map admin pages.
* This feature will need release notes.
* From my perspective at a small consortium (6 libraries), two dropdowns definitely seems like more dropdowns than we could ever use. But having one lasso for public libraries and one for academic libraries could be really helpful on our advanced search screen. Would you consider making the "where" dropdown on the front page opt-in?
* I'm not sure what the difference between these two items in the "Where" menu are: No Restrictions, Scopes > Everywhere
* Having two dropdowns makes it more likely for patrons to choose mutually exclusive options (for example, they could choose BR1 and a Library Group that doesn't include BR1. Ditto for Shelving location groups). This feels like it could lead to some disappointing search results. :-(

[Mike Rylander (mrylander)]

I've force-pushed a master-rebased version of the above-linked branch. I'll be looking at how we might fold some of the ideas from Jeff and Jane into this work soon, and I'll update here when that happens.

[Mike Rylander (mrylander)]

I'm grabbing this back as I'll be offering a 1-dropdown version of the UI components soon. This will roll back the depth-scoping capabilities of the branch that exists now, which is disappointing to me personally, but hopefully we can get Library Groups in to 3.6!

[Mike Rylander (mrylander)]

Hi folks,

I've pushed a new rebased branch to https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1815815-library_groups-simplified_basic-rebased that folds Library Groups into the main Library dropdown on the search bar (basic search). The advanced search does still use the 2-dropdown UI, but the value from either interface (to the degree it can be) is transferred to the other.

Thoughts on this change?

Thanks in advance!

[Ruth Frasur Davis (redavis)]

Well, this is a fun feature.

I have tested this code and consent to signing off on it with my name, rfrasur and my email address, <email address hidden>.

[Mike Rylander (mrylander)]

Hi all,

I've pushed a master-rebased branch with Ruth's signoffs to

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1815815-library_groups-simplified_basic-rebased-again-signedoff

Thanks!

[Mike Rylander (mrylander)]

And I've now added an extra commit to add library group support to the BooPAC.

[Andrea Neiman (aneiman)]

Docs here to facilitate testing:

https://docs.google.com/document/d/1-v1tUgzwMVsToI3APLLCr3XcEE-7tF8u7rcy-johYgA/edit?usp=sharing

[Mike Rylander (mrylander)]

I've added a commit to this branch to facilitate testing by creating two Concerto-stock library groups:
 * A global library group containing "Non-branches", the test bookmobile and sub-library
 * A non-global library group containing the even numbered Concerto branches, Example Branch 2 and Example Branch 4

[Terran McCanna (tmccanna)]

Testing on the festivus test server during feedback fest:

I really like having the Library Groups integrated into the same dropdown as the libraries.

However, when choosing one of the pre-set Concerto filters, I'm not getting the expected results in the copy tables as compared to filtering by a normal location. For example, if I filter by Example System 2, I only see the holdings appear for
Branch 3, Branch 4, and Bookmobile 1. If I filter by Non-branches, I expect to only see the holdings for Example Bookmobile 1 and Example Sublibrary 1, but I actually see all the holdings for whatever previous search filter I used.

1. Search "piano" by BR1 and either show more details or open record details. (BR1 holdings are displayed.)
2. Change search filter to Non-branches and repeat. (BR1 holdings are still displayed.)

When I try to search for anything with the "Test Library Group" filter, I get no results.

This behavior is the same for both the tpac and the bootstrap opac.

(also note that the test server isn't allowing me to log in to the staff client at all right now, so unable to test the config side)

[Mike Rylander (mrylander)]

Hi Terran,

Thanks for testing!

For the Non-branches and Even Libraries "piano" example, you are seeing results included because of located URIs. There is (for our purposes here) an unfortunately large number of those in concerto.

For the Test Library Group, that one only contains the CONS org unit, so wouldn't get any results /except/ for located URIs that point at the top of the org tree, and there are some, but they wouldn't match "piano".

I recommend trying a search for "penderecki" at Example Branch 2. There are no copies there, so you'll get no hits, but if you then use one of the library groups, you'll get results. That record has both copies (in SYS2) and a located URI at BR3 (the parent of Bookmobile 1, which is in the Non-libraries group).

[Terran McCanna (tmccanna)]

Thanks, Mike. That does make sense to me for the actual search results. To test that, I deleted the holdings for BR2 and BR4 from one of the records, then tested to be sure that limiting the search results to Even Branches didn't bring in that record - that part works great.

However, that doesn't explain the mismatch with in the copy tables. To replicate the problem:

1. Do a basic search for ready player one / title / all books / Even Branches / Example Consortium.

2. You get 3 titles, and the copy tables on each record show all of the copies for all of the branches, so far so good.

3. Change the search to limit to BR3. You get the same 3 search results, and the copy tables on each result will only show the copies that belong to BR3. That's good, too.

4. Change the search to limit to Even Branches. You get the correct 2 title results (because I removed the BR2 and BR4 holdings from the third title). However, the copy tables that display for each of those 2 titles still show the copies that belong to BR3. It should show the copies that belong to BR2 and BR4.

(Screenshot attached.)

[Terran McCanna (tmccanna)]

Oops, step 1 above shouldn't say Even Branches, just Example Consortium

[Mike Rylander (mrylander)]

Thanks, Terran.

There's some complication here, because all other search types deal with a strict branch of the org tree, and the display code (separate from search) assumes that's always the case. Library Groups, of course, do something different, and while we can definitely restrict the copy table on the record detail page to just the list of copies, we cannot provide the same "ranked" ordering that the tree-ish variants do.

The summary count lines (and hold counts) are based on the search context location, BR3 in your example, and those only work with a single org unit at all, currently.

I should, very soon, have the copy table working as close to how you expect as the current non-search display code allows. The summary rows (and "show more details" table on the result page) need some definition wrapped around them, however.

[Mike Rylander (mrylander)]

Hi Terran,

I've pushed a commit to do that, and updated the festivus test server. A link showing this change per your example:

https://festivus-tpac.evergreencatalog.com/eg/opac/record/247?locg=6%3Alasso%281000001%29&query=title%3Aready%20player%20one

Thanks again for testing.

[Terran McCanna (tmccanna)]

I tried applying this today on current master and I'm getting conflicts. (Apologies for my lack of rebasing skills.)

[Mike Rylander (mrylander)]

Hi Terran,

A newly rebased branch is available at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1815815-library_groups-simplified_basic-rebased-again-2x-signedoff

[Terran McCanna (tmccanna)]

Thanks, Mike (and Chris on my end!)

I was able to get the latest branch installed and tested on BooPAC (as well as on TPAC on Festivus). It's working to limit the holdings some of the time, but it looks like it's only working if the search was limited to another org unit first. (Same behavior on both TPAC and BooPAC.) To illustrate the problem:

1. Go to the OPAC home page and search for blueberry at the CONS level.
2. Open up the record and view holdings and it shows holdings for all locations.
3. Limit the search to Even Branches. Open the record and view holdings and it still shows the holdings for all locations.
4. Limit the search to BR1. Open the record and view holdings and it limits the holdings to BR1.
5. Limit the search to Even Branches again. Open the record and view holdings, and *this time* it limits the holdings to BR2 & BR4.

[Mike Rylander (mrylander)]

Hi Terran,

I figured out the issue -- the depth of the context org was being forced on the copy table filter. I've told it how to ignore that for lassos, and applied the change to festivus.

The commit is at the top of the same branch.

Thanks!

[Terran McCanna (tmccanna)]

That did the trick! I tested on both TPAC on festivus and on BooPAC on my test server with current master and it worked great. My sign off is at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1815815-library-groups-signedoff

[Galen Charlton (gmc)]

Pushed to master for inclusion in 3.7. Thanks, Mike, Ruth, and Terran!