[Koha] Koha 3.0 : item types or CCodes (again - sorry ..)

[Joshua Ferraro]

On Thu, Mar 12, 2009 at 9:35 AM, Owen Leonard <oleonard at myacpl.org> wrote:
>>> 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
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 at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS