[Koha-devel] Subject headings - intentions and display

[Thomas Dukleth]

[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