Create a “list view” for Call Number (Shelf Browse) results lists

Bug #1424690 reported by Don Butterworth
40
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

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

Tags: opac
Revision history for this message
Kathy Lussier (klussier) 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?

Revision history for this message
Don Butterworth (don-butterworth) wrote : Re: [Bug 1424690] Re: Create a “list view” for Call Number (Shelf Browse) results lists

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
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.

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

Revision history for this message
Mike Rylander (mrylander) wrote :
Download full text (5.5 KiB)

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
> >...

Read more...

Revision history for this message
Don Butterworth (don-butterworth) wrote :
Download full text (8.8 KiB)

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 br...

Read more...

Revision history for this message
Dan Scott (denials) wrote :

On Thu, Jul 9, 2015 at 8:32 AM, Don Butterworth <
<email address hidden>> wrote:

> 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 might be a good local customization if your MARC records reliably
contain call number fields, but as Mike warned, in general in Evergreen
we've found that MARC call number fields aren't reliable and changed the
defaults to not include the existing call number index. So I'm pretty sure
we won't be including a MARC call number browse as a general feature.

> 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?
> ;-)
>

Since you're talking about cataloguing and the circulation module, "F5" in
the staff client gets you directly to a "Display item" dialogue box. Scan
the barcode, then you can right click and "Show in Catalogue" to see the
complete bibliographic details. Helpful?

Revision history for this message
Don Butterworth (don-butterworth) wrote :
Download full text (4.3 KiB)

Since you're talking about cataloguing and the circulation module, "F5" in
the staff client gets you directly to a "Display item" dialogue box. Scan
the barcode, then you can right click and "Show in Catalogue" to see the
complete bibliographic details. Helpful?

Let's see ...

Click - F5
Beep - Enter Barcode
R. Click

Scroll/Click
or
Ctr/S

Looks like there is no avoiding 5 click or strokes.

I do plan to change the order in the Number Search Field list so that
Barcode appears first. That will help some.

On Thu, Jul 9, 2015 at 9:49 AM, Dan Scott <email address hidden> wrote:

> On Thu, Jul 9, 2015 at 8:32 AM, Don Butterworth <
> <email address hidden>> wrote:
>
> > 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 might be a good local customization if your MARC records reliably
> contain call number fields, but as Mike warned, in general in Evergreen
> we've found that MARC call number fields aren't reliable and changed the
> defaults to not include the existing call number index. So I'm pretty sure
> we won't be including a MARC call number browse as a general feature.
>
>
> > 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?
> > ;-)
> >
>
> Since you're talking about cataloguing and the circulation module, "F5" in
> the staff client gets you directly to a "Display item" dialogue box. Scan
> the barcode, then you can right click and "Show in Catalogue" to see the
> complete bibliographic details. Helpful?
>
> --
> 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 ...

Read more...

Revision history for this message
Kathy Lussier (klussier) wrote :

I could be missing something, but I count going from 5 clicks/keystrokes and a beep to three clicks/keystrokes and a beep or, if you count the scrolling as a separate action, four clicks/keystrokes and a beep. Another way to cut down on a click in the first workflow is if you set your workstation search preferences to default to the numeric search instead of the advanced search.

But now we are way off topic from the original bug report.

Kathy Lussier (klussier)
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Revision history for this message
Kathy Lussier (klussier) wrote :

After talking to a few folks about this one at the hack-a-way, my plan is to not add an option for this, but for the list view to be used whenever a call number lookup is initiated from an advanced search. The graphical call number browse will continue to be available from the record summary.

My work-in-progress branch is available at http://git.evergreen-ils.org/?p=evergreen/masslnc.git;a=shortlog;h=refs/heads/masslnc/lp1424690-cn-browse-list-view-and-more

I'll move it to the main working repo once I've made some progress on it.

Revision history for this message
Alex Reczkowski (areczkowski) wrote :

First: so excited to see progress on this. Many many thanks.
Second: I'd love to see an entry in the middle that indicates "Your entry would be here", showing how the searchterm fits into the results.
Third: I'd love to see more results than the 9 (though I understand that is the ported limit from the shelf browse.

Kathy Lussier (klussier)
Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Changed in evergreen:
importance: Undecided → Wishlist
status: New → Confirmed
tags: added: opac
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.