(koha 3.0) OPAC search results list
Hello world (and mainly kados) yesterday, kados & me spoke of the look the result list could/should have for Koha 3.0 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. The tabular view is interesting, but need more space on screen (the item location column is mostly empty) On ccfls templates, there are some tweakings to do anyway : - copies available at : BRANCHNAME (number) would be copies available at : BRANCHNAME LOCATION (number) - the 2nd line, with the itemcallnumber (658 Peters in the 3rd result) is fine, except when there is more than one item : go to page 2, the 5th result (If you give a moose a muffin) : the callnumbers are repeated with a |. worst, go http://catalog.ccfls.org/search?q=potter&offset=20 : the biblionumber 50994 entry (has 2 differents callnumbers [ FIC YA Rowling | JUV PB (SERIES) ], and the link reaches a zebra error) cheers -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
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). Hope that helps, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
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).
...
While the section
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.
gets my 100% agreement, I can't say the same for everything else. Specifically,
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.
is subject to strenuous debate and I, for one, would argue against this approach. I think the difference between main entry author and added entry author, for those who catalog using rules that include this concept, is very important. Where there's no main author entry, I think the display of the result set should reflect that fact. Spencer -- Spencer M. Anspach, Library Systems Analyst/Programmer Library Information Technology, Indiana University Library E456 phone: (812) 856-5318 Bloomington, IN 47405 fax: (812) 856-4979 sanspach@indiana.edu pager: (812) 335-7403
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.
is subject to strenuous debate and I, for one, would argue against this approach. I think the difference between main entry author and added entry author, for those who catalog using rules that include this concept, is very important. Where there's no main author entry, I think the display of the result set should reflect that fact. Spencer, I'm curious if you're coming at this from a cataloger's
----- "Spencer Anspach" <sanspach@gmail.com> wrote: perspective, or from a user's. One thing I've often noticed, is that the average user often would view a corporate name (like 'Time Life Books') as a series, not an author, and I've been asked by some users to put Corporate Name entries (110$a) down in series listings ... I've not seen many cases of Meeting Name entries (field 111 in MARC) so don't have much of an intuition on those. As far as main vs. added entries, I think again, that's all in who the audience is. I've had plenty of users express confusion over the difference. What I have noticed, is that professionally trained catalogers view the bibliographic universe in vastly, and often incompatible ways, from the average library user. While the distinctions that catalogers make are essential for accurately recording materials, they aren't always the best as a resource for finding what the user wants. So I guess the questions is, how can we build a search tool that satisfies both worldviews :-) Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Spencer, I'm curious if you're coming at this from a cataloger's perspective, or from a user's.
Neither, and I think that's important, so I'm glad you asked. :) As a cataloger, I don't believe in the concept of main entry. It had its uses in the card catalog days, but we are way beyond that and in this "keyword" world, the idea of one author being named in a 100 field and another in a 700 field merely because one name appeared before another on an item (or an earlier edition of an item) is patently ridiculous. As is the limit to three named authors (LC's rule for decades) and many, many other outmoded rules/guidelines/practices. Cataloging needn't be the conservative practice it is today (in the "status quo" meaning of the word conservative, not the political meaning) when so many of our systems allow for global changes and other maintenance tasks that were impossible in earlier generations. As a user, the concept of main entry/added entry is foreign and inexact and therefore useless. That's why the label for the 700 field is so variable and vague across library systems--in some cases it is an additional (and co-equal) author, in other cases it is a secondary participant (e.g. editor, translator), etc. In my earlier post I was speaking as someone who has tried (usually with little success) to explain the treatment of this data in some OPAC to some other hapless user. The inconsistency of 700 treatment is especially bizarre in non-book formats. Take a look at the output of the search http://www.worldcat.org/search?q=au%3Aausten&fq=+dt%3Avis+%3E&qt=advanced and imagine a catalog where the first name following the "by" is in a separate column so that it stands out. How is a user supposed to make heads or tails of a list that runs Joe Wright Ang Lee Colin Firth Jane Austen etc. As a sympathetic user who might have the ear of a cataloger, I can only ask: Who *are* these people and what have you done to my catalog?!
What I have noticed, is that professionally trained catalogers view the bibliographic universe in vastly, and often incompatible ways, from the average library user. While the distinctions that catalogers make are essential for accurately recording materials, they aren't always the best as a resource for finding what the user wants.
Absolutely!
So I guess the questions is, how can we build a search tool that satisfies both worldviews :-)
I think this is next to impossible with current cataloging practices/standards. The only thing you can do is to try not to confuse the user too badly with the data available. In my experience, catalogers rarely look at the public view of things if given a choice, so let them merrily carry on, because they probably won't ever change. As for me, when given the freedom, I catalog using many, many of the options available in current standards (much use of the subfield e in author fields, mandatory use of the first indicator in the 650/653 fields to differentiate primary from secondary subject terms, etc.). I hope that whatever system I'm working in can make adequate use of the intellectual effort I put into cataloging, but I'm generally satisfied as long as the system doesn't mangle things too badly. Spencer -- Spencer M. Anspach, Library Systems Analyst/Programmer Library Information Technology, Indiana University Library E456 phone: (812) 856-5318 Bloomington, IN 47405 fax: (812) 856-4979 sanspach@indiana.edu pager: (812) 335-7403
On 7/3/07, 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
Just in case any of the developers are interested, I forwarded these two links to my local library which is working on switching to Koha later this summer. While the staff liked both designs, they preferred the French site to the English one. The consensus was that although they like the Amazon cover images, they thought the design on the French site would be easier for users to understand. For me, regarding the English example, the fact that the check boxes are not in a definite column on the left side (as they are in other interfaces I use with a similar concept, such as web mail) is confusing. And, I agree that the display of call numbers doesn't work very well in that design either. Sincerley, Bradley Peters.
On 7/3/07, 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
Just in case any of the developers are interested, I forwarded these two links to my local library which is working on switching to Koha later this summer. While the staff liked both designs, they preferred the French site to the English one. The consensus was that although they like the Amazon cover images, they thought the design on the French site would be easier for users to understand. For me, regarding the English example, the fact that the check boxes are not in a definite column on the left side (as they are in other interfaces I use with a similar concept, such as web mail) is confusing. And, I agree that the display of call numbers doesn't work very well in that design either. Sincerley, Bradley Peters.
At 11:24 AM +0200 7/3/07, Paul POULAIN wrote:
yesterday, kados & me spoke of the look the result list could/should have for Koha 3.0 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 haven't been following this list closely, but happened upon this discussion and decided to look at the examples. My perspective is that of a cataloger (traditionalist), so my thoughts might be skewed by that. I apologize if the nature of my comments stray from what is expected. I viewed the pages using iCab 2.9.9 (on MacOS 9.2.2) with JavaScript turned off (and minimal CSS support). As a result of that, I believe the page layouts were a bit off--on CCFLS, the sidebar for refining the search appears at the bottom of the page, after all results. On IPT, the sidebar appears at the top followed by the refinement terms, then the results--requiring quite a bit of scrolling to get to the results. In both cases, I believe my browser is making it more difficult to determine which checkbox goes with which record, particularly in the CCFLS display. When in the middle of the results set, mostly for items with no cover image, the call number line appears close to the next title, and it isn't immediately clear whether the call number belongs with the title above or the title below. The IPT display is better in having the table format, but with the links for author and title, the records become mixed, as well--for example between "Un chant dans le chaos" and "Temps, mémoires, chaos." On IPT: 1. While searching, I came upon #36489, Lettres a Madame Caroline Commanville. Under the 200, type de document, it has "HASH(0x906aa80)." 2. From the initial link, I clicked on "Charbonneau (2)" and then Topics->"Developpement econ... (2). This results in a message "Aucun resultat ne correspond a votre recherche 'chaos and au:Charbonneau and su-to:Developpement economique' dans le catalogue de Bibliotheque - Institut Protestant de Theologie (Paris)." Why does the link have (2) if clicking on it brings up no results? 3. I find it difficult to determine what the title link is vs. the link belonging to the statement of responsibility/author, mainly due to the lack of ISBD punctuation or anything else in the initial results list to clearly indicate whether the link is for the title or the author. On CCFLS: 1. A recent thread of discussion on AUTOCAT dealt with the importance of displaying the transcribed statement of responsibility (245$c) vs. substituting "by"+ inverted form of name. An example of where meaning is lost is with record # mpl19219724 (ISBN 0765194902), Beautiful stories from Shakespeare for children / retold by E.Nesbit ; beautifully illustrated with color plates and fine pen drawings by Max Bihn ; edited and arranged by E.T. Roe. Without going to the MARC record view, how are the users to know the roles E. Nesbit and E.T. Roe played in working on this book? 2. Going along with CCFLS#1, I don't understand why ISBD-based display is now outdated and no longer valid in online catalogs. On record # bl2005009213 (ISBN 0764131427), William Shakespeare's A midsummer night's dream, why is "2002 - Barron's Educational Series, ; Hauppauge, N.Y. : - vi, 58 p. : : Originally published: London : Hodder and Stoughton, 2002. ; 26 cm." more understanable than Hauppauge, N.Y. : Barron's Educational Series, 2002. -- vi, 58 p. ; 26 cm. -- (Picture this! Shakespeare) -- Originally published: London : Hodder and Stoughton, 2002.? 3. On the Details (single-record default display?) page, it would be helpful if the 521 generated some label before listing the data. For example, in the record cited in CCFLS#2, "7-9" appears in the Description section. What does this mean? The MARC display doesn't help much, as the indicators seem to be missing. Even if the indicators are blank, a label like "Audience:" would be more informative than simply giving what appear to be random numbers. 4. On the MARC View page, clicking the ISBD button results in a page "Fill with appropriate value..." 5. After following the MARC View link, the text of the button for going to the default record display varies between "Normal View" and "Simple View" (on ISBD page). 6. On the MARC View: a. As mentioned in CCFLS#3, the indicators appear to be missing. If this display is intended primarily for librarians, why not show the whole MARC record? b. Why are there hyphens in the ISBN in the MARC display but not in the Normal display? Preferable would be to leave them out. I'm not sure how Koha searches, but in most systems, the hyphens have to be removed in order to be searched. c. Having descriptions of what each field and subfield means might be helpful to some users, but for someone more familiar with the MARC record, a more useful display (at least for me) would be to have all subfields in a single row (or set of rows, if wrapping is necessary). On the other hand, since this display is for the public interface, I guess having the description of each subfield would be better for the general public users who might venture into the MARC display. Thank you for your assistance, Bryan Baldus Cataloger Quality Books Inc. bryan.baldus@quality-books.com eijabb@cpan.org http://home.inwave.com/eija
participants (8)
-
Bradley Duane Peters -
Bradley Peters -
Bryan Baldus -
Joshua M. Ferraro -
MJ Ray -
Paul POULAIN -
Spencer Anspach -
Thomas Dukleth