Comment 4 for bug 1424690

Thanks Mike for this helpful information.

Because I do a lot of original cataloging, almost exclusively, my use of a
call number search is to determine when a call number has already been
assigned to another title. A browse list result lets me do this at a
glance. It isn't necessary to get to the item specific level and/or the
call number suffix level (v.1, no.1, pt.1). Subfields "a" and "b" of the
MARC call number fields are sufficient.

As a borrower I use call number searching simply to browse my library's
holdings in a specific subject area in the same way I browse the physical
stacks. Again, it wouldn't be necessary to get to the item specific level.

So I'm good with having a call number browse index based on the MARC call
number fields.

It's a little disappointing to find that the barcode number is the only
control number that cannot be included in the general keyword index. Again,
as a cataloger, I use the barcode search a lot, and it takes a lot of
clicks to get there. From the home page:

Click - Advanced Search
Click - Numeric Search
Click - Field drop-down menu
Click - Item barcode
Click - Inside the Identifier box
Beep - light-gun barcode entry

Five clicks and beep instead of one Beep in the general keyword.

There's got to be an easier way. Maybe a function key with a popup window.

So, like, how come the circulation module gets all the good function keys?
;-)

Don

On Wed, Jul 8, 2015 at 4:13 PM, Mike Rylander <email address hidden> wrote:

> On Wed, Jul 8, 2015 at 1:46 PM, Don Butterworth <
> <email address hidden>> wrote:
>
> > Hi Kathy,
> >
> > First, I am ecstatic to hear that this recommendation is being addressed.
> > Wonderful!
> >
> > In answer to your question, my opinion ... the new call number index
> should
> > become *the* default call number index and be a line item in the Browse
> > drop-down menu, not in the Numeric Search drop-down. Even though it is
> >
>
> If you want the Browse UI to expose holdings-specific call numbers -- the
> ones you manage through holdings maintenance -- as opposed to the "bib call
> number" in, say, 099 or 092, that's not possible without significant
> development. The Browse interface is a specific set of technology based on
> bibliographic (and, to a degree, authority) information, which (in
> Evergreen) those call numbers are not. One could, through configuration,
> add a "bib call number" browse index, though. Note that the "bib call
> number" numeric search was recently removed from the "numeric search" UI.
>
>
> > called a call "number" it is not really a control number. It is an A to Z
> > index.
> >
> > The current index I would leave optional, as is now the case.
> >
> > In my own Evergreen installation, I am on a crusade (a tiny crusade) to
> > eliminate the Numeric Search tab altogether. It makes no sense to me why
> > some of the control numbers are included in the General Keyword index but
> > not all of them (e.g. barcode and TCN/OCLC) unless, of course, there is
> > some technical systemic reason that I haven't heard about.
> >
> >
> Bibliographic Search / Browse (of all types) is limited to bibliographic
> data. You could certainly add search and browse indexing support for TCN
> or OCLC number, which are embedded in the bib record. There are
> instructions on adding new index definitions in the documentation. But,
> item barcodes are not bibliographic data (in Evergreen) and so cannot be
> included in bibliographic search. That's the purpose of the "numeric
> search" tab -- to provide a unified interface for various bib and non-bib
> known-identifier look-ups.
>
> Hope that helps!
>
> --Mike
>
>
> > Many thanks!
> >
> > Don
> >
> >
> > On Wed, Jul 8, 2015 at 10:54 AM, Kathy Lussier <
> <email address hidden>
> > >
> > wrote:
> >
> > > We have somebody who has been working on a customization for a call
> > > number browse list view. When it's done, I'll look at what needs to be
> > > done to get it into master.
> > >
> > > I have one question. Should it be a config.tt2 option where an
> Evergreen
> > > site can choose to display either the list view or the current shelf
> > > browse? Or should it be listed as a separate search option in the
> > > numeric search?
> > >
> > > --
> > > You received this bug notification because you are subscribed to the
> bug
> > > report.
> > > https://bugs.launchpad.net/bugs/1424690
> > >
> > > Title:
> > > Create a “list view” for Call Number (Shelf Browse) results lists
> > >
> > > Status in Evergreen - Open ILS:
> > > New
> > >
> > > Bug description:
> > > The issue:
> > > When a Call Number (Shelf Browse) transaction is performed, the
> current
> > > results list grid display, is difficult for some to interpret.
> > >
> > > Recommendation:
> > > Create a list display results screen, which is similar in appearance
> to
> > > other Evergreen search results screens, for the Call Number (Shelf
> > Browse)
> > > search. Each title retrieved should display at least the following data
> > > elements. Call Number, Title, Author, and Publication Date.
> > >
> > > Particulars:
> > > Mike Rylander indicates that this feature probably would not be that
> > > hard to implement “since it’s been done before in the old SlimPAC and
> the
> > > underlying code we need already exists”
> > >
> >
> http://webby.evergreencatalog.com/opac/extras/browse/html/call_number/-/FIC
> > >
> > > There appears to be a strong consensus that a list display is
> > > preferable to the current results screen.
> > >
> > >
> >
> http://georgialibraries.markmail.org/thread/tmwudvof53r6fjfj#query:+page:1+mid:hrl6hw2xbkkyha35+state:results
> > >
> > > To manage notifications about this bug go to:
> > > https://bugs.launchpad.net/evergreen/+bug/1424690/+subscriptions
> > >
> >
> >
> > --
> > Don Butterworth
> > Faculty Associate / Librarian III
> > B.L. Fisher Library
> > Asbury Theological Seminary
> > <email address hidden>
> > (859) 858-2227
> >
> > --
> > You received this bug notification because you are a member of Evergreen
> > Bug Wranglers, which is subscribed to Evergreen.
> > https://bugs.launchpad.net/bugs/1424690
> >
> > Title:
> > Create a “list view” for Call Number (Shelf Browse) results lists
> >
> > Status in Evergreen - Open ILS:
> > New
> >
> > Bug description:
> > The issue:
> > When a Call Number (Shelf Browse) transaction is performed, the current
> > results list grid display, is difficult for some to interpret.
> >
> > Recommendation:
> > Create a list display results screen, which is similar in appearance to
> > other Evergreen search results screens, for the Call Number (Shelf
> Browse)
> > search. Each title retrieved should display at least the following data
> > elements. Call Number, Title, Author, and Publication Date.
> >
> > Particulars:
> > Mike Rylander indicates that this feature probably would not be that
> > hard to implement “since it’s been done before in the old SlimPAC and the
> > underlying code we need already exists”
> >
> http://webby.evergreencatalog.com/opac/extras/browse/html/call_number/-/FIC
> >
> > There appears to be a strong consensus that a list display is
> > preferable to the current results screen.
> >
> >
> http://georgialibraries.markmail.org/thread/tmwudvof53r6fjfj#query:+page:1+mid:hrl6hw2xbkkyha35+state:results
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/evergreen/+bug/1424690/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1424690
>
> Title:
> Create a “list view” for Call Number (Shelf Browse) results lists
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> The issue:
> When a Call Number (Shelf Browse) transaction is performed, the current
> results list grid display, is difficult for some to interpret.
>
> Recommendation:
> Create a list display results screen, which is similar in appearance to
> other Evergreen search results screens, for the Call Number (Shelf Browse)
> search. Each title retrieved should display at least the following data
> elements. Call Number, Title, Author, and Publication Date.
>
> Particulars:
> Mike Rylander indicates that this feature probably would not be that
> hard to implement “since it’s been done before in the old SlimPAC and the
> underlying code we need already exists”
> http://webby.evergreencatalog.com/opac/extras/browse/html/call_number/-/FIC
>
> There appears to be a strong consensus that a list display is
> preferable to the current results screen.
>
> http://georgialibraries.markmail.org/thread/tmwudvof53r6fjfj#query:+page:1+mid:hrl6hw2xbkkyha35+state:results
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1424690/+subscriptions
>

--
Don Butterworth
Faculty Associate / Librarian III
B.L. Fisher Library
Asbury Theological Seminary
<email address hidden>
(859) 858-2227