When doing an initial search, I'd recommend we stay with the current set up (more results is better, as they can be narrowed with the filters), but if you're clicking the subject tracing on a specific record (or on one of the filters), yes, I think it should be forced to completeness. You want precisely _that thing_. You're seeking, rather than searching.

We could also apply this to names and series entries in a similar fashion. We have made a development for Nimes public library that is related to

Le 24/02/2011 13:21, Ian Walls a écrit : this too. You can see the result here : http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=84738 click on an author or a subject. A popup is spawn, letting the user specify better how he want to jump. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

[Subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 12:53, Nicole Engard wrote:

On Thu, Feb 24, 2011 at 7:39 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:

...

We have made a development for Nimes public library that is related to this too.

You can see the result here : http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=84738 click on an author or a subject. A popup is spawn, letting the user specify better how he want to jump.

1. COMPLEXITY AND SOPHISTICATION.

While that is cool, I'd argue that it's too complicated for your average library user.

More contextual clues to usage such as more explicit but still very brief description at the top of the pop-up window might be helpful. The feature is no more complicated than similar navigational aids used by many online retailers who would not be using such features if they retarded sales. An important difference is that online retailers using a similar feature provide all users with multiple means to access different navigational functionality. Such retailers have a form in one part of the user interface and mere links in another part. The BibLibre contextual subject selection feature is more than cool for my preferences. Yet, the feature is much less complicated/sophisticated than a semi-functional mock up which I had posted in the Koha wiki five years ago. I had to remove my semi-functional mock-up from the wiki because it relied on embedding too much HTML and CSS content into the wiki page to fight the fact that wikis are not designed to show general purpose HTML. I like the fact that BibLibre have implemented a feature which Koha should have had years ago. Koha would have had many such features years ago if Joshua Ferraro had not continually claimed that such features were too complicated for the average library user. What Joshua had really been expressing to me is what others have said about various proposals for adding some sophisticated features to Koha: that they did not think that such features could be successfully marketed to their customers nor help find additional customers. I am pleased that people at libraries such as Nîmes are helping to correct some false presumptions by not being silent about meeting all their user's needs and even sponsoring such good features for everyone.

If we went that way it should be a system preference so that it's not the only way to do a subject search.

2. USER CHOICE. I agree that the contextual subject selection feature is not the only way to do a subject search. Yet, using a system preference to provide only one of multiple alternatives to all users would have the effect of providing the ultimate users only one way to do something. Only the people at the library administering the system preference would then have a choice. Either/or choices controlling software behaviour should be avoided to the extent that they can be. Choices controlling software behaviour should also be as widely distributed as possible. Every library has a diverse set of users irrespective of whether people running the library recognise that diversity. As a characteristic of that diversity, some people's preferences may never be revealed to the librarians. Some people may never communicate to librarians about how well or poorly the software serves their preferences. Some people will never participate in surveys. Usage logs provide no information about features which have not been implemented or have never been developed. Libraries should be able to serve all of their users equally but not by forcing the same preferences on everyone. The most sophisticated and least sophisticated users may all be readily able to use the simplest features. Yet, we do not have to provide only one option to all users. Furthermore, forcing the least degree of sophistication on everyone impairs not only people who are readily prepared to use some sophisticated feature but also retards people who are currently unprepared by preventing the unprepared from having the opportunity to learn. 2.1. IMPLEMENTING USER CHOICE. Users should have a means to specify their own preferences at query time and as a user preference default overriding any default set as a system preference. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

[Subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 13:45, Linda Culberson wrote:

I like this development by BibLibre very much. We have a variety of patrons. Some are very serious researchers who know exactly what they want and don't appreciate the vagueness of the fuzzy-type searches. On the other hand, we have some people who are new to researching, aren't quite sure what they want, and they do want (or think they want) *everything* we have on "civil rights" or "Vicksburg" even if such a search gives a mind-numbing number of results. I think the "drill down" filters would be very helpful.

I applaud the recognition which Linda Culberson gives to the diversity of library users. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

[This time correctly changed subject changed for different context.] Reply inline: Original Subject: Re: [Koha-devel] Subject tracings On Thu, February 24, 2011 13:45, Linda Culberson wrote:

I like this development by BibLibre very much. We have a variety of patrons. Some are very serious researchers who know exactly what they want and don't appreciate the vagueness of the fuzzy-type searches. On the other hand, we have some people who are new to researching, aren't quite sure what they want, and they do want (or think they want) *everything* we have on "civil rights" or "Vicksburg" even if such a search gives a mind-numbing number of results. I think the "drill down" filters would be very helpful.

Again, I applaud the recognition which Linda Culberson gives to the diversity of library users. Any one user also has a diversity of intentions and preferences which may very from time to time and query to query. 1. USER SPECIFICATION OF QUERY BEHAVIOUR. Users have intentions and expectations for queries and navigation links. Users may have a reasonable if often false expectation that a result set should correspond to the their information finding intention for the query or navigation link from which a result set is returned. When software aids users to efficiently fulfil their intentions, then software behaviour and users' expectations happily correspond. Those developing the software have to be thinking about how to help the user express his intentions efficiently. The software should provide features which help each individual user at any particular time express the degree of precision which the user is seeking. The software must provide some default but the users should be able to choose.

On 2/24/2011 6:39 AM, Paul Poulain wrote:

...

Le 24/02/2011 13:21, Ian Walls a écrit :

...

When doing an initial search, I'd recommend we stay with the current set up (more results is better, as they can be narrowed with the filters),

The size of the result set should be appropriate for fulfilling users' intentions and should not be any larger or smaller. The software should provide the means for users to knowingly choose an imprecise query when they prefer a large result set. The software should also provide users the means to knowingly choose a precise query when they prefer a small result set. What is better is what is better for the particular user's intentions at a particular time. Few results are not better for users who intend imprecision to obtain an expansive result set. Many irrelevant results are not better for users who intend precision. The software should provide users the opportunity to have precise queries at every point in the user interface including the initial query form. If most users of a particular library would reasonably be expected to run in fear from the novelty of a sophisticated user interface which guides users to control the precision of their queries, then there is no need to force such an interface upon users by default. The software should never force users to waste their time examining a large result set with poor relevance. Users should be able to use searches of the tracings and references in authority records to build queries containing appropriately normalised headings. [I recognise that the thread was started for the case in which authority records are not being used.] Librarians and software developers should take the task of helping to inform users about various means of increasing the precision of their queries seriously. Librarians and software developers should not surrender to the fact that users have been trained by full text web indexing services, such as Google, to be satisfied with whatever is returned from haphazard general queries against an extraordinarily large index. 2. DISPLAY REPRESENTATION AND USER EXPECTATION.

...

...

but if you're clicking the subject tracing on a specific record (or on one of the filters), yes, I think it should be forced to completeness. You want precisely _that thing_. You're seeking, rather than searching.

Users always want what they are seeking unless they fail to appreciate their own intentions. Often, what a user is seeking may be different from what the system specifies from a query formed by current hard coded functionality. When users see some particular metadata element representation, such as a subject heading in a bibliographic record; users may reasonably have an expectation that navigational links which follow from that metadata element representation will have the same structure. If some metadata elements are designated as a subject headings, then features relating to the subject headings should be expected to function in a manner consistent with the structure of subject headings. If some metadata elements are designated, as keywords from subject headings, then features relating to keywords from subject headings should be expected to function in a manner consistent with the structure of keywords. The form of metadata element designation might vary in different parts of the interface but textual labels and structural representation should be unambiguous when present. The structure of keywords can be shown by presenting them in a list form with a separator between each key word. Whatever functionality is actually implemented should be designated appropriately allowing users to recognise it correctly. 2.1. IMPROPER DIFFERENCE. The legacy Koha behaviour which Jared Camins-Esakov identified at the start the original thread is over a distinction which should not have the consequences which it has currently in Koha. When authority records are in use currently, software behaviour is often close to user expectation of behaviour. In the absence of authority records currently, navigation links from more precisely structured metadata elements have mere rough fielded keyword behaviour. Using the example of subject headings, they are treated as mere collections of keywords matching any subject field. Such behaviour is unlikely to correspond to users' expectations. The behaviour produces differences from users' expectations in various cases, such as when very different subject headings use the same words. Consequently, links to additional records for some metadata elements should specify the structure to match the elements appropriately. 2.2. USER CONTROLLED CHANGES. Any user should have the option of changing the behaviour to something more useful for the user at a particular time. If a user wants to transform subject headings into keywords, then there should be an option to support such a transformation but the metadata representation should be labelled appropriately with an appropriate structural representation in list form and not subject heading form. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783