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

[Tim Spindler]

I could see continue exposing it  in "Expert Search/MARC Tag search" where
it is expected.  Maybe it already is doing it? I haven't tested it.

On Mon, Sep 29, 2014 at 1:38 PM, J. Sara Paulk <jspaulk at houpl.org> wrote:

>
> From a non-programmer, but one who catalogs  -  could the Matches Exactly
> be available for advanced or expert searching?  Sometimes, you really DO
> need to search in the most narrow way possible.
>
>
>> 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 <%28508%29%20343-0128>
>>> klussier at masslnc.org
>>> Twitter: http://www.twitter.com/kmlussier
>>> #evergreen IRC: kmlussier
>>>
>>>
>>
>>
> --
> J. Sara Paulk, Director
> Houston County Public Library System(478) 987-3050  x 26
> Fax (478) 987-1862
> **Temp location for renovation***
> 1530 Sunshine Ave., Perry, GA  31069
> jspaulk at houpl.org     http://houpl.org/
>
>


-- 
Tim Spindler
tjspindler at gmail.com

*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140929/94267441/attachment.htm>