[OPEN-ILS-GENERAL] Proposal to remove some advanced search options from the catalog
Hardy, Elaine
ehardy at georgialibraries.org
Tue Sep 30 09:50:40 EDT 2014
I agree with removing matches exactly from advanced search. I do see the
value of leaving starts with on advanced search for the reasons Terran
points out -- it can be combined and filtered where browse search cannot.
Moving matches exactly, at least, to expert search would be a would be a
good solution to retaining access to the functionality for a user that
needs it but prefers not to use (or doesn't know) the search syntax,
without creating confusion for the general user.
Elaine
J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service
1800 Century Place, Ste 150
Atlanta, Ga. 30345-4304
404.235-7128
404.235-7201, fax
ehardy at georgialibraries.org
www.georgialibraries.org
www.georgialibraries.org/pines
-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Kathy Lussier
Sent: Monday, September 29, 2014 1:14 PM
To: Evergreen General Discussion List
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