[OPEN-ILS-GENERAL] Proposal to remove some advanced search options from the catalog

McCanna, Terran tmccanna at georgialibraries.org
Mon Sep 29 14:12:13 EDT 2014


Personally, I wouldn't have a problem with removing the 'Matches Exactly' because of all the issues that have been identified both here and in the bug report. I rarely use that option myself and it's not something that I typically recommend to any other staff or patrons to use either. 

I actually do use the 'Starts With' option for titles on a regular basis (usually in combination with an author name, so it's not quite the same as using Browse). It may be that "contains phrase" in combination with an author name returns a result set that is just as good, but I'd like to do (or see) more comparison testing before forming an opinion.

What if the options were still available in the staff client but hidden from the OPAC? Would that solve the problem with user frustration/confusion?



Terran McCanna 
PINES Program Manager 
Georgia Public Library Service 
1800 Century Place, Suite 150 
Atlanta, GA 30345 
404-235-7138 
tmccanna at georgialibraries.org 

----- Original Message -----
From: "Kathy Lussier" <klussier at masslnc.org>
To: "Evergreen General Discussion List" <open-ils-general at list.georgialibraries.org>
Sent: Monday, September 29, 2014 1:13:59 PM
Subject: [OPEN-ILS-GENERAL] Proposal to remove some advanced search options	from the catalog

Hi all,

I wanted to float an idea to the community. I spent a little time this 
morning looking at a bug submitted earlier this year regarding the 
Matches Exactly search option in the advanced search screen - 
https://bugs.launchpad.net/evergreen/+bug/1267129. After thinking about 
the problem, I came to a conclusion that I've drawn on similar occasions 
when looking at previous problems with exact match searching that has 
since been fixed. Overall, I think this search option along with, to a 
lesser extent, the Starts With search option, is more likely to cause 
frustration for users than to solve any search problems.

I'm curious to know if others have found the same problems in their 
libraries and, if so, if there is any willingness in the community to 
remove those options in the advanced search screen to save frustration 
on the part of users.

My reasons for removing them are below:

1. The intent of this search option is to perform a left- and 
right-anchored search on the search terms. The entered search terms need 
to exactly match the index as it appears in the relevant metabib table. 
If doing a title search, you need to enter the entire title including 
245a and 245b. I believe most users are unlikely to know what the 
subtitle is for a book and a. The re more likely to enter just the words 
that are in 245a.

2. Right now, there is a bug with Matches Exactly. As of now, if you 
enter the following terms in the search box:

the joy of cooking

the system will retrieve anything that begins with "the", ends with 
"cooking" and also contains the words "joy of" in no particular order. I 
just conducted a matches exactly search for the help today and, in 
addition to retrieving "The Help" it also retrieved a record for "The 
Berenstain Bears hurry to help." The fix for this particular issue is 
fairly easy, but the fix also means that the Matches Exactly will become 
even more unforgiving than what I outlined in #1 above. Punctuation will 
matter more. In addition to entering all of the words in the 245a and 
245b, the user will also need to know where to add punctuation. From 
what I can tell, this isn't consistent for all punctuation. In looking 
for the title "The assist : hoops, hope, and the game of their lives" 
the following search works:

"^The assist hoops, hope, and the game of their lives$"

but these searches do not work:

"^The assist : hoops, hope, and the game of their lives$"

"^The assist hoops hope and the game of their lives$"

It looks like the user needs to know that the colon should be removed, 
but the commas should remain.

3. The "Starts With" search is a little more forgiving since a user is 
more likely to know the start of a title rather than the entire string, 
but it still suffers from the problems of a user needing to know what 
punctuation should be entered (or not entered) for the string that they 
type. Since it is a search that uses left-anchoring, it also does not 
ignore non-filing indicators, which is something that users sometimes 
expect it to do. Note: I was the person who added the "Starts With" 
search to Evergreen, mainly as a way to ameliorate the issues we saw 
with the "Matches Exactly" search. Now that Browse search is available 
in the catalog, I don't think this particular search is necessary on the 
advanced search screen anymore.

4. In a standard Evergreen installation where no custom indexes have 
been added, both of these search options will probably fail for a 
keyword search. This happens because, by default, there is one keyword 
index (the blob) where all of the indexed terms for the record are 
stored, and there is no way any user could know all of the terms that 
are stored there and their proper order. If they are entering a title, 
they are more likely to have successful Starts With keyword searches 
because the title seems to be the first thing that starts off the blob, 
but if the user were entering any other terms (author's last name?) for 
a Starts With keywords search, the search will fail.

Rather than present a search option to our users that has a higher 
likelihood of leading to unsuccessful search results than our other 
search options, I would like to see if there is willingness in the 
community to remove these options in the next (March/April) release of 
Evergreen.

Please feel free to share any feedback you have to this idea.

Thank you!
Kathy

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier
#evergreen IRC: kmlussier



More information about the Open-ils-general mailing list