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@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).
...