[Koha-devel] (koha 3.0) OPAC search results list

[Thomas Dukleth]

I agree with M J Ray as I usually do, especially about user interface
issues.  I have also identified the following additional difficulties.


1.  MATCHED TERM HIGHLIGHTING.

When the matched term highlighting is coextensive with the field/subfield
represented, the matched term highlighting scheme obscures hyperlinks. 
This occurs in cases such as matching all the words in a title.

Under the example matched term highlighting schemes, the background is
yellow and the foreground is orange.  That colour scheme breaks with the
blue foreground colour scheme for link text.

My experiments with matched term highlighting colour schemes have found
that a light orange background colour may work better than light yellow. 
Using a consistent link text colour whether highlighted or not preserves
the information about the hyperlink function even if the matched term is
coextensive with the hyperlink.  Web standard dark blue link text which I
prefer for high contrast readability appears to be black against a light
yellow background colour and breaks with the hyperlink colour scheme. 
Against a light orange background colour the web standard dark blue link
text appears dark blue consistent with the link text colour scheme.


2.  FOCUS COLOUR.

An attribute for focus colour seems to be absent from both example
schemes.  I have found that light yellow tends to work well as a focus
colour.

The IPT result set provides mouse hover highlighting but nothing to
support users who know how to use a keyboard and regard pointing devices
as a mere hindrance to full productivity in most well designed user
interfaces.


2.1.1.  DISABILITY ACCESS.

Keyboard support is an important disability access issue as well. 
Disability access is a matter of law in the US.  Unfortunately, too many
US libraries seem to ignore the requirements of the Americans with
Disabilities Act except for wheelchair access at entrances.

It would be nice if Koha could claim to support best practises for
disability access.


3.  MISSING MATCHED TERMS.

The brief result set list should show contextual highlighting of matches
from wherever they occurred in fields against which the index was
searched.  Many term matches are not shown because the brief result set
list only shows a standard set of field information.

The reason I first switched from AltaVista to Google even though AltaVista
had a search syntax which is still superior to the syntax Google supports
is that Google showed contextual matches for search results.  That feature
alone more than made up for the extra time I have to spend searching with
an inferior syntax.  I am often able to eliminate the irrelevant matches
to my query by glancing at the contextual match text in the result set
without needing to take the time to look at the full page content of those
matches.


4.  MISSING RECORD ELEMENTS.

Some records in the example result set do not have a main author entry,
therefore, there is no author entry link for those records in the brief
result set list.  The brief records should include links to added entry
authors in addition to main entry authors.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
212-674-3783


On Wed, July 4, 2007 1:05 am, MJ Ray wrote:
> Paul POULAIN <paul.poulain at free.fr> wrote: [...]
>> Here are 2 proposals :
>> http://catalog.ccfls.org/search?idx=&q=chaos
>> http://catalogue.iptheologie.fr/cgi-bin/koha/opac-search.pl?q=chaos
>> I show ccfls look to ipt librarian, and she is happy with this. so I
>> think we could move head to this look. [...]
>
> Yes, I think ccfls is slightly ahead.  Both suffer from the a:hover
> and result highlight colours being too similar.  The three-tick icon
> is a bit confusing - I think the IPT-style titlebar-checkbox is
> becoming pretty common (but both do nothing without Javascript).
>
> ccfls could maybe be improved further by careful styling of the - YYYY
> - PUBL ; PLACE - EXTENT block, and by limiting the image width (or by
> using <div>s instead of <td>s to block-divide the image and text).
>

...