[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