[Evergreen-general] Sharing plans for changing library selector in Angular staff catalog

[Mike Rylander]

On Wed, Jan 24, 2024 at 5:08 PM Lussier, Kathy <klussier at noblenet.org> wrote:

>> To reiterate the reason we kept the library groups and location groups
>> selector separate from the library (org unit) selector, and also

[snip]

>
> I can delve into our reasons for displaying the groups in the selector. Most of our copy location groups are really departemental level groups (children's, teen, adults), similar to the department levels that were suggested at one time as possible child org units to branches. However, we didn't want all of the other things that come with creating a new org unit: a new pickup location, a message to send items into transit when items are checked in at the branch, etc. We just wanted the department level for the purposes of searching.
>

That's certainly a valid use case!  But it's not the only one, and
really only the very slimmest use case both for the original intent
and of the actual code.

Should we remove options that other EG users want to pursue because
the feature happens to make for a good shortcut to a "light-weight org
unit" in the simplest case relating to search?  Or, if "light-weight
org unit" is the desired feature, then is that what needs development,
rather than constraining an unrelated feature into that shape?

> In the minds of our libraries and patrons, these shelving location groups are "search scopes" in the same way that a branch or a system is a search scope. On the public side, most patrons will not bother to go to the advanced search page to see what's there, but they will easily see there is a way to search the children's collection from the main search page. I get what you're saying about large installations with many org units, but I also know that CW MARS, which is far larger than us, is also interested in seeing these restored to the library selector.
>

"Shelving location groups are HIERARCHICAL search scopes" may be what
is in their minds, but that doesn't mean it's true.  Location groups
are intentionally non-hierarchical; it is ONLY local configuration and
training decisions saying that they are.  If we end up forcing that to
be true in practice for everyone by limiting their use to be strictly
hierarchical in search, then should we force that in the location
group mapping interface, lest someone add a "foreign" location to a
group?  Of course, when they realize that's what they need to do we'll
be inventing a new "like location groups but you can show them outside
the org tree" concept, and attendant data structures... which was one
of the purposes of location groups all along.  And we can't really do
that today, as it would break the badge-focused location group
filtering.

At a deep, technical level when searching, org units, location groups,
and library groups are all mutually exclusive.  They are essentially
different search axes, different ways of grouping the full collection
into smaller sets.  Both location groups and library groups are,
additionally, contextually dependent on org units for their context
and selection -- NOT hierarchically, mind you, but through direct
location ownership and group-owner membership for location groups, and
through library group membership and non-hierarchical global group
visibility for library groups.

As for public vs staff searching, the staff catalog is simply
different from the OPAC.  The ship of perfect parity has sailed, much
to my chagrin in many respects.  However, the natively dynamic nature
of the staff catalog has its benefits!  The UI implementation we've
already developed for location and library groups presents staff with
a laser-focused view of the context-library relevant instances of
those.

 * First, it always presents them in the appropriate context, where
the location and library groups dropdown /always/ contains the entries
that make sense for the context ("search") library.
 * Second, it naturally extends the existing UI that most EG sites are
already using and are familiar with, by using a well-understood,
common, and accessible UX pattern.
 * Third, it lets us intelligently adjust other, related search
options, such as disabling the shelving location selector when a
location GROUP is selected, and inform the searcher how and why those
related options have been adjusted.
 * And fourth, it does all this without "lying" to the staff member
about what they are actually asking for in their search, since they
can be expected to understand more about the search process and make
use of more sophisticated features.

If the label for that dropdown were "Departments and Library Groups",
would that help staff that have been trained that location groups ARE
departments or light-weight org units?  Labels are pretty easy to
adjust now, and the (to date OPAC-focused, but not OPAC-only) local
custom strings feature could be used here to make that configurable
through the staff client without too much effort.

Please (everyone), at least take a look at the screenshot Andrea
shared, or, even better, install the branch and try it out.  It's
really not a confusing departure from the way things were, and I am
confident it will feel natural and familiar to anyone that's used a
dynamic web app in the last 10 year.

> Out of curiosity, are there other libraries / consortia out there who are using shelving location groups? If you are using them and do not want to see them in the library search selector, it would be good to know. I guess we shouldn't assume that restoring the traditional method is the approach everyone wants to take.
>

Yes, there are, though they may not be on (or paying attention to) this list.

As for whether they all prefer one specific implementation over
another, I can only speak to what I've been asked to make happen. Some
libraries absolutely do want the non-hierarchical possibilities that
location groups (and library groups) offer, but on more than one
occasion the OPAC's basic-search presentation has made them think it
can't be done.  They have assumed that because the UI doesn't
facilitate a capability today that the capability must not be
possible, otherwise it would already have been added.  The truth is
the opposite, of course -- the simplest UI needed at the time was
built atop a more capable overall feature set.

In the end, if Nobel decides to implement something that mixes all the
various place-like scoping options into one UI element for staff
catalog search, I cannot stress how strongly I request that you have
it done as a completely new component.  The org selector component
(and related Angular components) is already very complicated, and
frankly pretty brittle.  It's used on scores, if not hundreds, of
screens in Evergreen, but this use case is relevant on only one screen
as far as I can tell: staff catalog search.  I don't think it's fair
or productive for every other interface to carry the additional
maintenance and complexity burden this will likely create.
Additionally, if it's a new, special-purpose component, it will be
much simpler to both argue for, and actually create, a way to choose
between the two presentations in the staff catalog, and allow those
that want the additional flexibility of non-hierarchical location
groups to have it.

>> Regarding the main "hide certain orgs" concept from the OP, on
>> balance, it definitely feels to me like a job for custom org trees
>> with a new "purpose" (the one existing purpose being: "opac"),
>
>
> To be clear, this isn't really a "new" purpose. The custom org trees always worked in the tpac staff catalog.  For this year, NOBLE is prioritizing development for features we previously funded, either individually or as part of a larger development cooperative, that were inadvertently missed as interfaces were replaced. Getting the library search selector in the Angular catalog looking like the one we used in the tpac staff catalog is something our libraries have told us is necessary before they're willing to move to the Angular Catalog.
>

Sorry I wasn't clear.  There is a column on the custom org tree table
literally called "purpose", and I was specifically referring to that.
In the old dojo interface, that's what is shown in the dropdown next
to the "Custom Unit Tree:" label.  Today, the only "purpose" value
allowed is 'opac', but that's one line of SQL away from changing.

>> Regarding the main "hide certain orgs" concept from the OP, on
>> balance, it definitely feels to me like a job for custom org trees
>> with a new "purpose" (the one existing purpose being: "opac"),
>> especially given the variable shape of the tree mentioned up-thread in
>> some cases.  While there does exist a way to hide "intermediate" org
>> units today, it requires the interaction of multiple configuration
>> points (opac_visible flags, and the "inherit visibility" library
>> setting(s)), which makes it feel flimsy in comparison to an explicitly
>> defined tree.  A single "this is what my staff should see *in this
>> interface*" option seems (1) conceptually simpler, (2) more flexible,
>> and (3) more maintainable.
>
>
> I agree that the custom org tree is much more flexible, but we really don't need that flexibility. I'm not sure that I agree that it is conceptually simpler or more maintainable.  Although the Angular custom org tree admin interface is a huge improvement over the old dojo one, I find it's much simpler to just uncheck a visibility box when setting up or editing an org unit. The org tree admin is another place you have to remember to go after setting up the org unit to make sure it displays correctly in the catalog. But as I said to Galen, we'll reconsider it.
>

It is true that if you use a custom org tree then you have to adjust
it when adding a new org, but I find it hard to believe that
separately saying "ok, now show it in the OPAC (and/or staff catalog)
at this position" is a massive, undue burden that is simply a waste of
staff time.  And it would be trivial to add a link from the org unit
admin UI to the custom tree UI, in order to reduce friction.

Unfortunately, you can't simply uncheck the visibility box on an org
and know for sure that you're done.  Setting aside the server-side
script that you have to run in order to make sure that everyone sees
the change, there are other configuration parameters not on the org
unit interface that are required in order to have descendants show up
(or not, depending on the local desire).

I try not to deal in absolutes WRT "simpler" or "better" and the like,
but I will go out on a limb here: Custom org trees are /objectively/
conceptually simpler than the base org tree plus all the various
subtle adjustments to it.  The reason is simple: the custom org tree
is concrete.  It is "This is the OPAC search tree, which has this
specific order provided by the admin." vs "This is the org tree, some
of which may be visible in the OPAC for search depending on checkboxes
in one UI and settings in several others, and also local hacks put in
place to hide some orgs based on other criteria.  Oh, and you can't
decide on the order, which is probably sorted by name or short name,
without other local hacks."

The frequency with which a central admin would need to add an org unit
is so low, and the rest of the configuration is so voluminous, that
surely they must have a checklist of all the /other/ things that may
need to happen when a new org unit is added -- working locations for
users, library settings, receipts and other various templates,
default/pinned workstation settings, notice setup, hold/circ policies,
proximity adjustment, and many, many more -- that having "Add to
custom tree(s) for search" as a checklist item that takes less than a
minute seems reasonable.

Actually, having typed out that partial list of new-org tasks, I think
some may see it as a significant benefit to have the option of a
custom tree "in front" of the natural tree, because then staff, like
patrons, cannot stumble upon a half-configured org -- or, from the
admin's perspective, central admins don't have to do everything in one
go as quickly as possible (or late at night), and get to control when
staff start having access to the new org for search.

> Thanks Mike!

Thank you as well!

--Mike

> Kathy
>
> --
> Kathy Lussier
> she/her
> Executive Director
> NOBLE: North of Boston Library Exchange
> Danvers, MA
> 978-777-8844 x201
> www.noblenet.org
>
>
>
>
> On Wed, Jan 24, 2024 at 12:51 PM Mike Rylander via Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>>
>> Hi all,
>>
>> As Andrea mentioned, we've been working on functionality adjacent to
>> the main topic of this thread for a bit.  The pullrequest branch is
>> attached to the Library Groups LP bug she pointed to, and you can find
>> it here:
>>
>>     https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups
>>
>> To reiterate the reason we kept the library groups and location groups
>> selector separate from the library (org unit) selector, and also
>> combined them into one UI element: both library and location groups
>> are NOT subordinate to org units, because they can cross hierarchical
>> boundaries, and they are mutually exclusive, because they represent
>> different, competing, non-hierarchical search contexts.  Instead their
>> applicability is /dependent/ on the context ("search", yes, but not
>> only search) org, and essentially /replaces/ it in the search.
>> Especially for large installations with many org units, using either
>> of these grouping mechanisms becomes untenable if we try to shove them
>> all into the same dropdown as the libraries, because they would have
>> to be duplicated in many places and would thereby make the long org
>> list even longer and harder to use.
>>
>> Regarding the main "hide certain orgs" concept from the OP, on
>> balance, it definitely feels to me like a job for custom org trees
>> with a new "purpose" (the one existing purpose being: "opac"),
>> especially given the variable shape of the tree mentioned up-thread in
>> some cases.  While there does exist a way to hide "intermediate" org
>> units today, it requires the interaction of multiple configuration
>> points (opac_visible flags, and the "inherit visibility" library
>> setting(s)), which makes it feel flimsy in comparison to an explicitly
>> defined tree.  A single "this is what my staff should see *in this
>> interface*" option seems (1) conceptually simpler, (2) more flexible,
>> and (3) more maintainable.
>>
>> If we were/are voting, that'd definitely get my vote.
>>
>> Thanks!
>>
>> --
>> Mike Rylander
>> Research and Development Manager
>> Equinox Open Library Initiative
>> 1-877-OPEN-ILS (673-6457)
>> work: miker at equinoxOLI.org
>> personal: mrylander at gmail.com
>> https://equinoxOLI.org
>>
>> On Tue, Jan 23, 2024 at 12:01 PM Andrea Buntz Neiman via
>> Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>> >
>> > Chiming in to note that Equinox recently completed work on these related bugs:
>> >
>> > https://bugs.launchpad.net/evergreen/+bug/1949109 - Add Library Groups to Angular Staff Catalog
>> > https://bugs.launchpad.net/evergreen/+bug/1861701 - Angular staff catalog copy location group filtering support
>> >
>> > We will be sharing a branch shortly.
>> >
>> > ABN
>> >
>> > On Tue, Jan 23, 2024 at 11:39 AM Tina Ji via Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>> >>
>> >>
>> >> On Mon, Jan 22, 2024 at 12:09 PM Lussier, Kathy via Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>> >> > #2 introduces new behavior that hasn't been used in previous staff
>> >> > catalogs. We could not think of a use case where an org unit
>> >> > should be invisible in the public catalog when performing a
>> >> > search, but should be visible in the staff catalog search. However,
>> >> >  if there is one, let us know so that we can add an option,
>> >> > most likely a global flag.
>> >>
>> >>
>> >> One of our library system does central cataloguing at its headquarter, which is not open to the public. It's OPAC invisible, but needed on the staff catalogue.
>> >>
>> >>
>> >> ________________________________
>> >> From: Evergreen-general <evergreen-general-bounces at list.evergreen-ils.org> on behalf of Terran McCanna via Evergreen-general <evergreen-general at list.evergreen-ils.org>
>> >> Sent: Tuesday, January 23, 2024 7:13 AM
>> >> To: Evergreen Discussion Group <evergreen-general at list.evergreen-ils.org>
>> >> Cc: Terran McCanna <tmccanna at georgialibraries.org>
>> >> Subject: Re: [Evergreen-general] Sharing plans for changing library selector in Angular staff catalog
>> >>
>> >> About disused Org Units - even after a branch closes completely and all of the active materials and patrons have been moved off of it so we don't want it to appear in most dropdown lists, we sometimes still need to run reports on it. It would be nice to have the option in the reporter to include non-staff-visible branches. Maybe that is as simple as adding a new report source in the fieldmapper that can be used instead of the normal Org Unit source when desired?
>> >>
>> >> On Mon, Jan 22, 2024 at 5:46 PM Galen Charlton via Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Mon, Jan 22, 2024 at 12:09 PM Lussier, Kathy via Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>> >> > #2 introduces new behavior that hasn't been used in previous staff
>> >> > catalogs. We could not think of a use case where an org unit
>> >> > should be invisible in the public catalog when performing a
>> >> > search, but should be visible in the staff catalog search. However,
>> >> >  if there is one, let us know so that we can add an option,
>> >> > most likely a global flag.
>> >>
>> >> I can think of several:
>> >>
>> >> - Library joining a consortium. Most any migration workflow I can imagine will result in a period of at least a few days, and sometimes longer, where an OU exists and has holdings attached to it but shouldn't be visible in the OPAC, but where staff nonetheless need to be able to do staff-side searches limited to that OU.
>> >> - Library opening a new branch with an opening day collection. This could lead to an even longer period where the OU exists but is not yet ready to be visible to patrons
>> >> - An explicitly hidden or resource collection
>> >>
>> >> Does NOBLE have OUs that are completely disused?
>> >>
>> >> Regards,
>> >>
>> >> Galen
>> >> --
>> >> Galen Charlton
>> >> Implementation and IT Manager
>> >> Equinox Open Library Initiative
>> >> gmc at equinoxOLI.org
>> >> https://www.equinoxOLI.org
>> >> phone: 877-OPEN-ILS (673-6457)
>> >> direct: 770-709-5581
>> >> _______________________________________________
>> >> Evergreen-general mailing list
>> >> Evergreen-general at list.evergreen-ils.org
>> >> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>> >>
>> >> This message originated from outside the M365 organisation. Please be careful with links, and don't trust messages you don't recognise.
>> >> _______________________________________________
>> >> Evergreen-general mailing list
>> >> Evergreen-general at list.evergreen-ils.org
>> >> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>> >
>> >
>> >
>> > --
>> > Andrea Buntz Neiman, MLS
>> > Project Manager for Software Development | Product Specialist
>> > Equinox Open Library Initiative
>> > abneiman at equinoxOLI.org
>> > 1-877-OPEN-ILS (673-6457)
>> > Direct: 770-709-5583
>> > https://www.equinoxOLI.org/
>> > _______________________________________________
>> > Evergreen-general mailing list
>> > Evergreen-general at list.evergreen-ils.org
>> > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>> _______________________________________________
>> Evergreen-general mailing list
>> Evergreen-general at list.evergreen-ils.org
>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general