On Thu, May 1, 2014 at 12:48 PM, Boyer, Jason A <[email protected]>wrote:
> I don't have any specific feedback yet, but I'm curious about the > history of this aspect of the client and I've been having lousy luck trying > to find anything about it. > > > > Can anyone point me to any discussion about making the staff client search > interface a modified version of the public opac? I know several other > systems have a slimmed down staff search in their clients and their opac is > completely separate. I'm not suggesting we move that way but it would > certainly solve the problem of keeping angular and dojo from interfering > with each other. Knowing more about the motivations behind it would help me > understand why it's worth keeping them together. > > > Good question... Maybe we need to *cough* rebase or assumptions and requirements on catalog integration. As I recall, the primary impetus for absorbing the catalog into the staff client was that it allows staff to see what patrons see. This makes communication between staff and patrons more efficient, etc. The catalog is a good discovery tool, too, so why not use it? Of course, if you are in a browser, seeing what patrons see is as simple as opening a new browser tab and *voila* there's the catalog. Perhaps such tight integration is no longer necessary. Anyone have any other reasons why tight integration with the catalog and client are necessary? It seems we have a rainbow of options here, from having the staff absorb the catalog (w/ embedded navbar, menus, etc.) to having a few essential integration points, which mostly consist of links directing staff back to the staff UI, to leaving the catalog alone and building inline search and holds placement interfaces. Regardless of which path we take, access to the patron catalog is always a click away. -b -- Bill Erickson | Senior Software Developer | phone: 877-OPEN-ILS (673-6457) | email: [email protected] | web: http://esilibrary.com | Equinox Software, Inc. / The Open Source Experts
