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

Wed Jan 24 17:08:21 EST 2024

Hi Mike!

OP here, aka kmlussier. Thanks for adding your thoughts! My comments are
below.

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.

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.

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.

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.

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.

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.

Thanks 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20240124/30d737e2/attachment-0001.htm>