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

[Benjamin Kalish]

I'm not a fan of the badge idea, but I like the idea of the explanatory box
that pops up when when an experimental feature is selected and the a
special beta page for such features, whether linked or unlinked, could be
useful. (It might actually be more useful linked, especially if there was
also a link to a way of reporting bugs on that page.)

Benjamin Kalish
Forbes Library / 413-587-1012 / bkalish at forbeslibrary.org

Currently reading:* 2001: A Space Odyssey by Arthur C. Clarke* and *1Q84 *by
Haruki Murakami
Just Finished: *The Ghost of the Mary Celeste* by Valerie Martin

On Mon, Sep 29, 2014 at 6:12 PM, Lazar, Alexey Vladimirovich <
alexey.lazar at mnsu.edu> wrote:

> Hello.
>
> A feature that is unavailable is more user-friendly than a broken feature
> that is available. A broken feature is a broken promise to the user.
> Without a feature being available there is no promise to the user and a
> nonexistent promise cannot be broken, so to speak.
>
> Of course, frequently it is impossible to thoroughly test a feature during
> development and production use is needed as the next testing phase. In this
> case, production users really become beta-testers which is totally fine, as
> long as they know that and expectations are adjusted accordingly.
>
> A while back I worked on a project called Class Schedule Builder (
> www.mnsu.edu/schedule). Our team knew that in addition to potential
> issues with front-end code and browser support we had some instability with
> the back-end data source, which could become unavailable any time for
> reasons outside of our control. So, we needed to make the schedule builder
> available, but also to set user expectations appropriately. I suggested
> using a beta-badge, which was popularized at that time by various Google's
> beta-websites. After some initial laughs the team agreed and we went live
> with it. (Unfortunately, that beta-badge is still there, but that’s a
> different story.)
>
> I am not suggesting necessarily that the Matches Exactly search option
> should get a beta-badge, but something like that is certainly a way to
> adjust user expectations accordingly. (Could be added straight to the
> Evergreen logo, to cover for ALL the bugs, right? ;)
>
> A bit off-topic maybe, but here is an example of a search that allows
> wildcards and also has a highly-usable set of instructions:
> http://onelook.com/. Perhaps the Matches Exactly search option on select
> could pop-out a little how-to table on the side that would list some of the
> possible search examples, and also maybe a couple of examples of what is
> currently known not to work. In theory, this would allow users to continue
> using the parts of the feature that do work, while setting expectations
> accordingly about what’s currently broken.
>
> Otherwise, it would be better to remove the option altogether, perhaps
> moving the interface to an unlinked (but documented) location, like
> http://ecrl.mnpals.net/eg/opac/advanced?pane=beta, or something like that.
>
> Aleksey
>
>
> On 2014-09-29, at 12:13 , 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
> >
>
> Aleksey Lazar
> IS Developer and Integrator - PALS
> http://www.mnpals.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140929/eabb415a/attachment-0001.htm>