<div dir="ltr">Hi Mike,<div><br></div><div>It may take me a while to read and digest your full message, but I just wanted to quickly respond to this comment:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Should we remove options that other EG users want to pursue because<br>the feature happens to make for a good shortcut to a "light-weight org<br>unit" in the simplest case relating to search? </blockquote><div><br></div><div>If I gave the impression that NOBLE was trying to remove a feature, I apologize. I wasn't suggesting any such thing. As I'm sure you remember from our many years working collaboratively on this project, NOBLE has always understood that libraries have different use cases and workflows and have been in favor of supporting multiple options to meet the needs of libraries. In fact, this is why we share our plans ahead of time before contracting with developers. We want to ensure that other use cases are considered and that we aren't forcing libraries into a path that doesn't work for them. </div><div><br></div><div>I hope to get to the rest of your message before the week is done.</div><div><br></div><div>Kathy</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>--</div>Kathy Lussier<div>she/her<br><div>Executive Director</div><div>NOBLE: North of Boston Library Exchange</div><div>Danvers, MA</div><div>978-777-8844 x201</div><div><a href="http://www.noblenet.org" target="_blank">www.noblenet.org</a></div><div><br></div><div><br></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024 at 1:49 PM Mike Rylander <<a href="mailto:mrylander@gmail.com" target="_blank">mrylander@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jan 24, 2024 at 5:08 PM Lussier, Kathy <<a href="mailto:klussier@noblenet.org" target="_blank">klussier@noblenet.org</a>> wrote:<br>
<br>
>> To reiterate the reason we kept the library groups and location groups<br>
>> selector separate from the library (org unit) selector, and also<br>
<br>
[snip]<br>
<br>
><br>
> 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.<br>
><br>
<br>
That's certainly a valid use case!  But it's not the only one, and<br>
really only the very slimmest use case both for the original intent<br>
and of the actual code.<br>
<br>
Should we remove options that other EG users want to pursue because<br>
the feature happens to make for a good shortcut to a "light-weight org<br>
unit" in the simplest case relating to search?  Or, if "light-weight<br>
org unit" is the desired feature, then is that what needs development,<br>
rather than constraining an unrelated feature into that shape?<br>
<br>
> 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.<br>
><br>
<br>
"Shelving location groups are HIERARCHICAL search scopes" may be what<br>
is in their minds, but that doesn't mean it's true.  Location groups<br>
are intentionally non-hierarchical; it is ONLY local configuration and<br>
training decisions saying that they are.  If we end up forcing that to<br>
be true in practice for everyone by limiting their use to be strictly<br>
hierarchical in search, then should we force that in the location<br>
group mapping interface, lest someone add a "foreign" location to a<br>
group?  Of course, when they realize that's what they need to do we'll<br>
be inventing a new "like location groups but you can show them outside<br>
the org tree" concept, and attendant data structures... which was one<br>
of the purposes of location groups all along.  And we can't really do<br>
that today, as it would break the badge-focused location group<br>
filtering.<br>
<br>
At a deep, technical level when searching, org units, location groups,<br>
and library groups are all mutually exclusive.  They are essentially<br>
different search axes, different ways of grouping the full collection<br>
into smaller sets.  Both location groups and library groups are,<br>
additionally, contextually dependent on org units for their context<br>
and selection -- NOT hierarchically, mind you, but through direct<br>
location ownership and group-owner membership for location groups, and<br>
through library group membership and non-hierarchical global group<br>
visibility for library groups.<br>
<br>
As for public vs staff searching, the staff catalog is simply<br>
different from the OPAC.  The ship of perfect parity has sailed, much<br>
to my chagrin in many respects.  However, the natively dynamic nature<br>
of the staff catalog has its benefits!  The UI implementation we've<br>
already developed for location and library groups presents staff with<br>
a laser-focused view of the context-library relevant instances of<br>
those.<br>
<br>
 * First, it always presents them in the appropriate context, where<br>
the location and library groups dropdown /always/ contains the entries<br>
that make sense for the context ("search") library.<br>
 * Second, it naturally extends the existing UI that most EG sites are<br>
already using and are familiar with, by using a well-understood,<br>
common, and accessible UX pattern.<br>
 * Third, it lets us intelligently adjust other, related search<br>
options, such as disabling the shelving location selector when a<br>
location GROUP is selected, and inform the searcher how and why those<br>
related options have been adjusted.<br>
 * And fourth, it does all this without "lying" to the staff member<br>
about what they are actually asking for in their search, since they<br>
can be expected to understand more about the search process and make<br>
use of more sophisticated features.<br>
<br>
If the label for that dropdown were "Departments and Library Groups",<br>
would that help staff that have been trained that location groups ARE<br>
departments or light-weight org units?  Labels are pretty easy to<br>
adjust now, and the (to date OPAC-focused, but not OPAC-only) local<br>
custom strings feature could be used here to make that configurable<br>
through the staff client without too much effort.<br>
<br>
Please (everyone), at least take a look at the screenshot Andrea<br>
shared, or, even better, install the branch and try it out.  It's<br>
really not a confusing departure from the way things were, and I am<br>
confident it will feel natural and familiar to anyone that's used a<br>
dynamic web app in the last 10 year.<br>
<br>
> 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.<br>
><br>
<br>
Yes, there are, though they may not be on (or paying attention to) this list.<br>
<br>
As for whether they all prefer one specific implementation over<br>
another, I can only speak to what I've been asked to make happen. Some<br>
libraries absolutely do want the non-hierarchical possibilities that<br>
location groups (and library groups) offer, but on more than one<br>
occasion the OPAC's basic-search presentation has made them think it<br>
can't be done.  They have assumed that because the UI doesn't<br>
facilitate a capability today that the capability must not be<br>
possible, otherwise it would already have been added.  The truth is<br>
the opposite, of course -- the simplest UI needed at the time was<br>
built atop a more capable overall feature set.<br>
<br>
In the end, if Nobel decides to implement something that mixes all the<br>
various place-like scoping options into one UI element for staff<br>
catalog search, I cannot stress how strongly I request that you have<br>
it done as a completely new component.  The org selector component<br>
(and related Angular components) is already very complicated, and<br>
frankly pretty brittle.  It's used on scores, if not hundreds, of<br>
screens in Evergreen, but this use case is relevant on only one screen<br>
as far as I can tell: staff catalog search.  I don't think it's fair<br>
or productive for every other interface to carry the additional<br>
maintenance and complexity burden this will likely create.<br>
Additionally, if it's a new, special-purpose component, it will be<br>
much simpler to both argue for, and actually create, a way to choose<br>
between the two presentations in the staff catalog, and allow those<br>
that want the additional flexibility of non-hierarchical location<br>
groups to have it.<br>
<br>
>> Regarding the main "hide certain orgs" concept from the OP, on<br>
>> balance, it definitely feels to me like a job for custom org trees<br>
>> with a new "purpose" (the one existing purpose being: "opac"),<br>
><br>
><br>
> 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.<br>
><br>
<br>
Sorry I wasn't clear.  There is a column on the custom org tree table<br>
literally called "purpose", and I was specifically referring to that.<br>
In the old dojo interface, that's what is shown in the dropdown next<br>
to the "Custom Unit Tree:" label.  Today, the only "purpose" value<br>
allowed is 'opac', but that's one line of SQL away from changing.<br>
<br>
>> Regarding the main "hide certain orgs" concept from the OP, on<br>
>> balance, it definitely feels to me like a job for custom org trees<br>
>> with a new "purpose" (the one existing purpose being: "opac"),<br>
>> especially given the variable shape of the tree mentioned up-thread in<br>
>> some cases.  While there does exist a way to hide "intermediate" org<br>
>> units today, it requires the interaction of multiple configuration<br>
>> points (opac_visible flags, and the "inherit visibility" library<br>
>> setting(s)), which makes it feel flimsy in comparison to an explicitly<br>
>> defined tree.  A single "this is what my staff should see *in this<br>
>> interface*" option seems (1) conceptually simpler, (2) more flexible,<br>
>> and (3) more maintainable.<br>
><br>
><br>
> 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.<br>
><br>
<br>
It is true that if you use a custom org tree then you have to adjust<br>
it when adding a new org, but I find it hard to believe that<br>
separately saying "ok, now show it in the OPAC (and/or staff catalog)<br>
at this position" is a massive, undue burden that is simply a waste of<br>
staff time.  And it would be trivial to add a link from the org unit<br>
admin UI to the custom tree UI, in order to reduce friction.<br>
<br>
Unfortunately, you can't simply uncheck the visibility box on an org<br>
and know for sure that you're done.  Setting aside the server-side<br>
script that you have to run in order to make sure that everyone sees<br>
the change, there are other configuration parameters not on the org<br>
unit interface that are required in order to have descendants show up<br>
(or not, depending on the local desire).<br>
<br>
I try not to deal in absolutes WRT "simpler" or "better" and the like,<br>
but I will go out on a limb here: Custom org trees are /objectively/<br>
conceptually simpler than the base org tree plus all the various<br>
subtle adjustments to it.  The reason is simple: the custom org tree<br>
is concrete.  It is "This is the OPAC search tree, which has this<br>
specific order provided by the admin." vs "This is the org tree, some<br>
of which may be visible in the OPAC for search depending on checkboxes<br>
in one UI and settings in several others, and also local hacks put in<br>
place to hide some orgs based on other criteria.  Oh, and you can't<br>
decide on the order, which is probably sorted by name or short name,<br>
without other local hacks."<br>
<br>
The frequency with which a central admin would need to add an org unit<br>
is so low, and the rest of the configuration is so voluminous, that<br>
surely they must have a checklist of all the /other/ things that may<br>
need to happen when a new org unit is added -- working locations for<br>
users, library settings, receipts and other various templates,<br>
default/pinned workstation settings, notice setup, hold/circ policies,<br>
proximity adjustment, and many, many more -- that having "Add to<br>
custom tree(s) for search" as a checklist item that takes less than a<br>
minute seems reasonable.<br>
<br>
Actually, having typed out that partial list of new-org tasks, I think<br>
some may see it as a significant benefit to have the option of a<br>
custom tree "in front" of the natural tree, because then staff, like<br>
patrons, cannot stumble upon a half-configured org -- or, from the<br>
admin's perspective, central admins don't have to do everything in one<br>
go as quickly as possible (or late at night), and get to control when<br>
staff start having access to the new org for search.<br>
<br>
> Thanks Mike!<br>
<br>
Thank you as well!<br>
<br>
--Mike<br>
<br>
> Kathy<br>
><br>
> --<br>
> Kathy Lussier<br>
> she/her<br>
> Executive Director<br>
> NOBLE: North of Boston Library Exchange<br>
> Danvers, MA<br>
> 978-777-8844 x201<br>
> <a href="http://www.noblenet.org" rel="noreferrer" target="_blank">www.noblenet.org</a><br>
><br>
><br>
><br>
><br>
> On Wed, Jan 24, 2024 at 12:51 PM Mike Rylander via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> As Andrea mentioned, we've been working on functionality adjacent to<br>
>> the main topic of this thread for a bit.  The pullrequest branch is<br>
>> attached to the Library Groups LP bug she pointed to, and you can find<br>
>> it here:<br>
>><br>
>>     <a href="https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups" rel="noreferrer" target="_blank">https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1949109-staff-catalog-lassos-loc_groups</a><br>
>><br>
>> To reiterate the reason we kept the library groups and location groups<br>
>> selector separate from the library (org unit) selector, and also<br>
>> combined them into one UI element: both library and location groups<br>
>> are NOT subordinate to org units, because they can cross hierarchical<br>
>> boundaries, and they are mutually exclusive, because they represent<br>
>> different, competing, non-hierarchical search contexts.  Instead their<br>
>> applicability is /dependent/ on the context ("search", yes, but not<br>
>> only search) org, and essentially /replaces/ it in the search.<br>
>> Especially for large installations with many org units, using either<br>
>> of these grouping mechanisms becomes untenable if we try to shove them<br>
>> all into the same dropdown as the libraries, because they would have<br>
>> to be duplicated in many places and would thereby make the long org<br>
>> list even longer and harder to use.<br>
>><br>
>> Regarding the main "hide certain orgs" concept from the OP, on<br>
>> balance, it definitely feels to me like a job for custom org trees<br>
>> with a new "purpose" (the one existing purpose being: "opac"),<br>
>> especially given the variable shape of the tree mentioned up-thread in<br>
>> some cases.  While there does exist a way to hide "intermediate" org<br>
>> units today, it requires the interaction of multiple configuration<br>
>> points (opac_visible flags, and the "inherit visibility" library<br>
>> setting(s)), which makes it feel flimsy in comparison to an explicitly<br>
>> defined tree.  A single "this is what my staff should see *in this<br>
>> interface*" option seems (1) conceptually simpler, (2) more flexible,<br>
>> and (3) more maintainable.<br>
>><br>
>> If we were/are voting, that'd definitely get my vote.<br>
>><br>
>> Thanks!<br>
>><br>
>> --<br>
>> Mike Rylander<br>
>> Research and Development Manager<br>
>> Equinox Open Library Initiative<br>
>> 1-877-OPEN-ILS (673-6457)<br>
>> work: miker@equinoxOLI.org<br>
>> personal: <a href="mailto:mrylander@gmail.com" target="_blank">mrylander@gmail.com</a><br>
>> <a href="https://equinoxOLI.org" rel="noreferrer" target="_blank">https://equinoxOLI.org</a><br>
>><br>
>> On Tue, Jan 23, 2024 at 12:01 PM Andrea Buntz Neiman via<br>
>> Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> ><br>
>> > Chiming in to note that Equinox recently completed work on these related bugs:<br>
>> ><br>
>> > <a href="https://bugs.launchpad.net/evergreen/+bug/1949109" rel="noreferrer" target="_blank">https://bugs.launchpad.net/evergreen/+bug/1949109</a> - Add Library Groups to Angular Staff Catalog<br>
>> > <a href="https://bugs.launchpad.net/evergreen/+bug/1861701" rel="noreferrer" target="_blank">https://bugs.launchpad.net/evergreen/+bug/1861701</a> - Angular staff catalog copy location group filtering support<br>
>> ><br>
>> > We will be sharing a branch shortly.<br>
>> ><br>
>> > ABN<br>
>> ><br>
>> > On Tue, Jan 23, 2024 at 11:39 AM Tina Ji via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> >><br>
>> >><br>
>> >> On Mon, Jan 22, 2024 at 12:09 PM Lussier, Kathy via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> >> > #2 introduces new behavior that hasn't been used in previous staff<br>
>> >> > catalogs. We could not think of a use case where an org unit<br>
>> >> > should be invisible in the public catalog when performing a<br>
>> >> > search, but should be visible in the staff catalog search. However,<br>
>> >> >  if there is one, let us know so that we can add an option,<br>
>> >> > most likely a global flag.<br>
>> >><br>
>> >><br>
>> >> 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.<br>
>> >><br>
>> >><br>
>> >> ________________________________<br>
>> >> From: Evergreen-general <<a href="mailto:evergreen-general-bounces@list.evergreen-ils.org" target="_blank">evergreen-general-bounces@list.evergreen-ils.org</a>> on behalf of Terran McCanna via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>><br>
>> >> Sent: Tuesday, January 23, 2024 7:13 AM<br>
>> >> To: Evergreen Discussion Group <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>><br>
>> >> Cc: Terran McCanna <<a href="mailto:tmccanna@georgialibraries.org" target="_blank">tmccanna@georgialibraries.org</a>><br>
>> >> Subject: Re: [Evergreen-general] Sharing plans for changing library selector in Angular staff catalog<br>
>> >><br>
>> >> 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?<br>
>> >><br>
>> >> On Mon, Jan 22, 2024 at 5:46 PM Galen Charlton via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> On Mon, Jan 22, 2024 at 12:09 PM Lussier, Kathy via Evergreen-general <<a href="mailto:evergreen-general@list.evergreen-ils.org" target="_blank">evergreen-general@list.evergreen-ils.org</a>> wrote:<br>
>> >> > #2 introduces new behavior that hasn't been used in previous staff<br>
>> >> > catalogs. We could not think of a use case where an org unit<br>
>> >> > should be invisible in the public catalog when performing a<br>
>> >> > search, but should be visible in the staff catalog search. However,<br>
>> >> >  if there is one, let us know so that we can add an option,<br>
>> >> > most likely a global flag.<br>
>> >><br>
>> >> I can think of several:<br>
>> >><br>
>> >> - 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.<br>
>> >> - 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<br>
>> >> - An explicitly hidden or resource collection<br>
>> >><br>
>> >> Does NOBLE have OUs that are completely disused?<br>
>> >><br>
>> >> Regards,<br>
>> >><br>
>> >> Galen<br>
>> >> --<br>
>> >> Galen Charlton<br>
>> >> Implementation and IT Manager<br>
>> >> Equinox Open Library Initiative<br>
>> >> gmc@equinoxOLI.org<br>
>> >> <a href="https://www.equinoxOLI.org" rel="noreferrer" target="_blank">https://www.equinoxOLI.org</a><br>
>> >> phone: 877-OPEN-ILS (673-6457)<br>
>> >> direct: 770-709-5581<br>
>> >> _______________________________________________<br>
>> >> Evergreen-general mailing list<br>
>> >> <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
>> >> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
>> >><br>
>> >> This message originated from outside the M365 organisation. Please be careful with links, and don't trust messages you don't recognise.<br>
>> >> _______________________________________________<br>
>> >> Evergreen-general mailing list<br>
>> >> <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
>> >> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Andrea Buntz Neiman, MLS<br>
>> > Project Manager for Software Development | Product Specialist<br>
>> > Equinox Open Library Initiative<br>
>> > abneiman@equinoxOLI.org<br>
>> > 1-877-OPEN-ILS (673-6457)<br>
>> > Direct: 770-709-5583<br>
>> > <a href="https://www.equinoxOLI.org/" rel="noreferrer" target="_blank">https://www.equinoxOLI.org/</a><br>
>> > _______________________________________________<br>
>> > Evergreen-general mailing list<br>
>> > <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
>> > <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
>> _______________________________________________<br>
>> Evergreen-general mailing list<br>
>> <a href="mailto:Evergreen-general@list.evergreen-ils.org" target="_blank">Evergreen-general@list.evergreen-ils.org</a><br>
>> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
</blockquote></div>