Bringing lassos back: library groups functionality

Bug #1815815 reported by Mike Rylander on 2019-02-13
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Wishlist
Unassigned

Bug Description

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) wrote :
Changed in evergreen:
milestone: 3.3-beta1 → 3.next
Jeff Davis (jdavis-sitka) wrote :

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) wrote :

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) wrote :

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) wrote :

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!

Andrea Neiman (aneiman) on 2019-06-19
Changed in evergreen:
milestone: 3.next → 3.4-beta1
tags: added: pullrequest
Jane Sandberg (sandbej) wrote :

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. :-(

Jane Sandberg (sandbej) on 2019-08-21
tags: added: needsreleasenote
Galen Charlton (gmc) on 2019-09-11
Changed in evergreen:
milestone: 3.4-beta1 → 3.next
Mike Rylander (mrylander) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers