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

[Ruth Frasur]

+1 as well

On Mon, Sep 29, 2014 at 1:19 PM, Rogan Hamby <rogan.hamby at yclibrary.net>
wrote:

> +1
>
> On Mon, Sep 29, 2014 at 1:13 PM, Kathy Lussier <klussier at masslnc.org>
> wrote:
>
>> 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
>>
>>
>
>
> --
>
> Rogan Hamby, MLS, CCNP, MIA
> Managers Headquarters Library and Reference Services,
> York County Library System
>
> “You can never get a cup of tea large enough or a book long enough to suit
> me.”
> ― C.S. Lewis <http://www.goodreads.com/author/show/1069006.C_S_Lewis>
>



-- 
Ruth Frasur
Director of the Historic(ally Awesome) Hagerstown - Jefferson Township
Library
10 W. College Street in Hagerstown, Indiana (47346)
p (765) 489-5632; f (765) 489-5808

Our Kickin' Website <http://hagerstownlibrary.org>  Our Rockin' Facebook
Page <http://facebook.com/hjtplibrary>  and Stuff I'm Reading
<http://pinterest.com/hjtplibrary/ruth-reads/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140929/048ee06e/attachment-0001.htm>