Numeric Search should be possible from results page

Bug #1869890 reported by Benjamin Kalish
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

Currently, if you navigate to Numeric Search and perform such a search, you must navigate back to Numeric Search to do further searches of the same type.

It would be much better if the search box on the results page were populated in such a way so that it could be edited to modify the search. This would require to changes:

1. The search box should be populated with a human readable version of the search, e.g. isbn:0545010225 or call_num:PS301 or barcode:A001122334455

2. The search grammar must be updated to recognize searches entered as in #1.

This also would have the advantage of allowing more proficient users to perform their numeric searches from any screen, without having to navigate to the numeric search page in the first place.

Revision history for this message
Elizabeth Thomsen (et-8) wrote :

In the Angularized staff catalog (also known as the "Experimental" Staff Catalog), if you do a Numeric search you can initiate a new numeric search of the same type from the search box at the top of the search results screen. This will be the default staff catalog in Release 3.6.

Revision history for this message
Elizabeth Thomsen (et-8) wrote :

No improvement on this (yet) in the Bootstap (refreshed) version of the catalog -- the search type shows as Keyword with the search terms showing as identifier|isbn:0141002514 (for example.)

tags: added: search
Revision history for this message
Benjamin Kalish (bkalish) wrote :

It seems like we've achieved #1 (The search box should be populated with a human readable version of the search, e.g. isbn:0545010225 or call_num:PS301 or barcode:A001122334455) but not #2 (The search grammar must be updated to recognize searches entered as in #1.).

Revision history for this message
Mike Rylander (mrylander) wrote :

As it happens, you can configure search to do exactly that! There's not a staff client interface to add or remove them, but Evergreen has the ability to map aliases to classes and fields. There are many predefined ones, like "kw" for keyword, and "eg.isbn" for identifier|isbn. They live in the table config.metabib_search_alias. These are used for CQL index aliases to support SRU (and Z39.50) searching.

For call number search, the bib call number that's indexed by default is the local call number in 099, and it has a stock alias of "eg.callnumber", so you could search for

  eg.callnumber:PS301

if that value lives in your 099. Of course, you can add or change aliases (in the database) if you have direct access to that table, and you can add new search fields and give them new aliases as well, though you'll need to do a targeted reingest for any new search field definitions you add.

The stock aliases are:

         alias | field_class | name
------------------------+-------------+-------------
 au | author |
 bib.edition | keyword |
 bib.genre | keyword |
 bib.name | author |
 bib.nameconference | author | conference
 bib.namecorporate | author | corporate
 bib.namepersonal | author | personal
 bib.namepersonalfamily | author | personal
 bib.namepersonalgiven | author | personal
 bib.subjectname | subject | name
 bib.subjectoccupation | subject | complete
 bib.subjectplace | subject | geographic
 bib.subjecttitle | keyword |
 bib.title | title | abbreviated
 bib.titleabbreviated | title | abbreviated
 bib.titlealternative | title | alternative
 bib.titleseries | series | seriestitle
 bib.titletranslated | title | translated
 bib.titleuniform | title | uniform
 creator | author |
 dc.contributor | author |
 dc.creator | author |
 dc.identifier | identifier |
 dc.publisher | keyword |
 dc.subject | subject |
 dc.title | title |
 eg.author | author |
 eg.bibid | identifier | bibid
 eg.callnumber | identifier | bibcn
 eg.isbn | identifier | isbn
 eg.issn | identifier | issn
 eg.keyword | keyword |
 eg.name | author |
 eg.series | series |
 eg.subject | subject |
 eg.tcn | identifier | tcn
 eg.title | title |
 eg.upc | identifier | upc
 id | identifier |
 kw | keyword |
 name | author |
 se | series |
 srw.serverchoice | keyword |
 su | subject |
 ti | title |

and if the "name" column is empty then it's a class-wide search rather than field-specific.

HTH!

Revision history for this message
Benjamin Kalish (bkalish) wrote :

Thanks, Mike, that's very good news. I'd still, however, consider it a bug if this doesn't work out of the box for any of the stock options available in numeric search. I haven't checked the source, but based on the docs I would expect that to be ISBN, ISSN, Bib Call Number, Call Number (Shelf Browse), LCCN, TCN, and Item Barcode.

Revision history for this message
Mike Rylander (mrylander) wrote :

For non-bib data, the numeric "search" is doing something entirely separate from searching and not using the actual Evergreen search logic. It's not "searching" but retrieving, or in the case of values in asset.call_number, finding a "pivot" for browsing.

The numeric search UI could certainly be reworked to make use of features added since it was first written (for the bib data, anyway), but that's not about whether the search logic /can/ do it.

I do understand that for end users that may be a distinction without a difference, but from a development and technology perspective it's actually fairly nuanced and complicated, so we'll probably want to identify specific technical goal. For instance, "provide a mechanism for dynamically defining numeric search UI options, and make sure that bib-related data uses true search functionality". From there we could move on to "provide a query parser mechanism that can "search" for bibs by item barcode", and then flip that over to work like ISBN etc do from the first step before.

Thanks for the input and discussion!

Revision history for this message
Benjamin Kalish (bkalish) wrote :

Yes, you are exactly right when you say that for end users it is a distinction without a difference.

If we want to make end users know that it is different we should ensure that the search box is not populated at all–there is an unspoken contract with the user that if a search tool populates the search box then you should be able to search on that text and get valid results!

The best user experience would be that we both populate the search box for numeric searches *and* Evergreen can process that as a new search–I would very much like to see that! But until that is possible it might actually be best to ensure that the search box is empty after a numeric search.

tags: added: usability
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.