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

[J. Sara Paulk]

 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 <mailto: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 <tel:%28508%29%20343-0128>
>         klussier at masslnc.org <mailto: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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140929/72c403ec/attachment.htm>