I do want to assign icons to item types which indicate Format ie DVD, Book, and will want those to display on the OPAC search results too,
currently the itemtype icons that display for the search-results are 16x16 silk.
This is a troublesome issue: the icons that display in XSLT search results are connected to the material type of the MARC record. Those icons are not configurable in Koha administration. They don't have any relation to your records' item type. Correct, this is a good solution if you want to obey the MARC format's definitions for what constitutes 'material types', and display icons in your collection using those material types in a way that's somewhat user-friendly (normally, these fixed fields in LDR/008 fields are completely useless for display as they are coded values). This approach assumes you don't want to provide icons for things like location or based on a call number, or something similar ... the XSLT
On Thu, Mar 12, 2009 at 9:35 AM, Owen Leonard <oleonard@myacpl.org> wrote: that ships with Koha by default is meant as an example of what's possible, you can easily enough modify your local XSLT file to point to the icons you want to display, or have icons generated from some other MARC-based characteristic. Since we don't have an XSLT::Template application, the XSLT file can't take advantage of the admin interface or pull values out of the database. (BTW: an XSLT::Template module would be an interesting enhancement (sponsorship?) that would help a lot of other areas in Koha's UI be more flexible).
Joann, you wrote to me that your scheme "hinges on the icon, CCode, Shelved at and Call number fields all being displayed in the OPAC search results, and the CCodes set for Advanced Search options."
Unfortunately neither the icon, CCode, or Shelved at information is displayed in search results. Getting shelf location into search results seems pretty doable, but the new architecture of items in Koha 3 creates a problem for displaying ccode and/or item type information in search results. I don't think you really want item-level information to be displayed at the results page ... unless it's somehow pre-compiled to only display unique icons within a set ... see below.
Now that ccode and itemtype are stored at the item level rather than the biblio (title) level there can be any number of ccodes and itemtypes attached to one bibliographic record. Even if this isn't the case for your library, the very possibility makes it difficult to imagine a system for displaying them accurately in OPAC search results. Would you have to display an icon for every kind of itemtype/ccode which were attached to each record? This is a good explanation of why item-level icons they don't display currently in the results page. Note that with certain sysprefs flipped, any item-level authorized value (including itemtype and ccode) should display on the _detail_ page.
So, for purposes of displaying icons on the results page, do we all agree that a bib-level field would be the best place to pull this info? If so, you can create any authorized value at the bib-level, associate an icon with it, and that icon will display, along with any other bib-level icons, on both results and details pages. For instance, you could create an authorized value for TYPE, associate it with material-type icons, and another for AUDIENCE, and associate it with pictures of audience levels (kids and adults, say), and if they are mapped to bib-level fields, both sets of icons will show up on results and details pages.
Cab Vinton wrote:
The one major problem that I see, that we've bumped against as well, is that Koha currently forces you to choose between Item Types & Collection Codes for searching purposes.
The whole itemtype/ccode issue is really confusing. I'm still learning the ins and outs of it even though I've been working on Koha 3 since the beginning. Here's as much as I know:
collection codes are good for defining, you know, collections. And if you choose you can set those as a search point in the OPAC. But you can't use collection codes to set circulation policy, so I can't set a collection code and then limit my patrons to only checking out 10 of that collection code. And though you can associate an icon with a collection code, the effort is pointless: Koha doesn't display that icon anywhere. Those icons should display on the detail pages (see above).
Item types /can/ be used for defining collections. Like with ccodes, you can choose to use itemtype as a search point in the OPAC. But as Cab points out it's an either/or proposition. Unlike ccode, you can use itemtype to set circulation policy. This makes it useful for defining broad categories of materials which share the same policy.
For instance, we use itemtype to define "AV materials," under which various ccodes fall: Adult videos, juvenile videos, adult DVDs, juvenile DVDs, etc. The AV itemtype allows us to set a circulation policy which says that our patrons can only have 10 AV materials at a time. The broadly-defined itemtype allows us to "collect" multiple categories (ccodes) under one policy.
Unfortunately, displaying an icon in the OPAC for "AV Material" doesn't make much sense when the patron really wants to know whether it's a kids video, a grownup DVD, etc. If it weren't for the circ policy issue (in particular the "Current Checkouts Allowed" aspect of issuing rules), we'd be better served to covert our ccodes to itemtypes and use ccodes as broad category definitions for statistical use only. I think this illustrates why item types (used for circulation rules),
collections (often a callnumber-based categorization of the record), shelving locations (where the item is physically located, e.g., 3rd floor), are item-level pieces of information, and not generally suitable for display on the results page. On the other hand, bib-level information about a record, such as Material Type (Book, Music, etc.), Audience (Kids, YA, Adult, etc.), Content (Bibliography, etc.), Format (DVD, Video Cassette, etc.) lend themselves well to display on the results page and make easy targets for icons. Since Koha lets you specify icons for any bib-level authorized value and all specified bib-level icons will display, it seems to me like a pretty flexible system already.
What steps could be taken to make this work well for everybody?
- Enable display of collection code icons in places where information about individual items is displayed: the holdings table of opac-detail, lists of checkouts, lists of holds on specific copies, lists of waiting holds. This should already be in place for all item-level authorized values.
- Add the ability to define circulation policy based on ccode as well as itemtype? I think that just confuses the issue and you'd have a four-dimension matrix to fill out for circ rules rather than three. If you don't need to distinguish between item types and collection codes, you can just use item types. Also, for those that don't even need to define circ rules at the item level, there is an option to use bib-level itemtypes. When the bib-level itemtypes are linked to an icon, they show up in both results and details pages.
IMO, a library is better off displaying icons for bib-level information rather than attempt to display circ-rule-driven icons, or collection-driven icons, neither of which generally make much sense to users. Hope that helps. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS