Koha 3.0 : item types or CCodes (again - sorry ..)
Hi all, I have loads of incredibly useful feedback about my blog post regarding item types and collection codes, both on my blog and via email .. so glad because it wasn't getting much open discussion on the list for some reason ... So, on further thinking, I wonder if this solution could this be usefully accommodated in Koha 3.x, and made to display nicely in an OPAC search result: 9 'Item types' (based on loan length + rental charge) 13 'CCodes' (collections : a defined area of shelving housing a particular clutch of material eg Adult Fiction) 60 'Shelved at' options (subcollections ie Rental Fiction, Free Fiction) 'Call Number' field used to display dewey number and filing letters. 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, and will set the 'Advanced Search' to display CCodes. Any problems that anyone can see? Cheers Jo.
On 2009/03/12, at 4:44 PM, Joann Ransom wrote:
Hi all,
I have loads of incredibly useful feedback about my blog post regarding item types and collection codes, both on my blog and via email .. so glad because it wasn't getting much open discussion on the list for some reason ...
So, on further thinking, I wonder if this solution could this be usefully accommodated in Koha 3.x, and made to display nicely in an OPAC search result:
9 'Item types' (based on loan length + rental charge) 13 'CCodes' (collections : a defined area of shelving housing a particular clutch of material eg Adult Fiction) 60 'Shelved at' options (subcollections ie Rental Fiction, Free Fiction) 'Call Number' field used to display dewey number and filing letters.
these are pretty straightforward display mods that can be done by editing the .tmpl files, (or using xslt?)
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. you might need to experiment with how your favorite icon-set looks like, when its reduced to 16x16 (as the current silk icon-set is) i suspect it might not look so pretty, IMHO if scaled-down icon-sets generally look OK at 16x16-ish, then its a pretty do-able new feature and syspref, i think or, manually reduce your iconset, then simply swap the default silk set with your new set ;)
and will set the 'Advanced Search' to display CCodes.
a missing, and worthy additional search option (with shelving- location search too)
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. 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. 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? 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. 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. 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. - Add the ability to define circulation policy based on ccode as well as itemtype? I don't know what a broadly-applicable solution to the icons in search results problem is. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
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.
Just as an FYI to go along with Owen's note - there is a document in the manual to help with this part: https://sites.google.com/a/liblime.com/koha-manual/Home/Table-of-Contents/op... --- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard http://liblime.com http://blogs.liblime.com/open-sesame/ On Thu, Mar 12, 2009 at 9:35 AM, Owen Leonard <oleonard@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.
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.
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?
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.
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.
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. - Add the ability to define circulation policy based on ccode as well as itemtype?
I don't know what a broadly-applicable solution to the icons in search results problem is.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
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
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.
I'm assuming that this is only true if you "modify your local XSLT file to point to the icons you want to display?" I think that's an important clarification to make here.
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).
Is this also true only if you modify the XSLT file for the detail page? Because it's not true for the normal view.
- 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.
This isn't the case at all. I can't add a new item-level authorized value and expect it's associated icon to display in the list of waiting holds, or on the list of checkouts on opac-user.pl.
I think that just confuses the issue and you'd have a four-dimension matrix to fill out for circ rules rather than three.
Yeah, I agree that's a messy solution. I did leave one thing out from the wish list: - Enable ccode as a search limiter in the advanced search. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Thu, Mar 12, 2009 at 10:55 AM, Owen Leonard <oleonard@myacpl.org> wrote:
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.
I'm assuming that this is only true if you "modify your local XSLT file to point to the icons you want to display?" I think that's an important clarification to make here. Nope, it should work out of the box with or without XSLT on.
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).
Is this also true only if you modify the XSLT file for the detail page? Because it's not true for the normal view. There may be a few sysprefs to tweak to get them to display, but last time I checked, this was working as well.
Josh
- 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.
This isn't the case at all. I can't add a new item-level authorized value and expect it's associated icon to display in the list of waiting holds, or on the list of checkouts on opac-user.pl.
I think that just confuses the issue and you'd have a four-dimension matrix to fill out for circ rules rather than three.
Yeah, I agree that's a messy solution.
I did leave one thing out from the wish list:
- Enable ccode as a search limiter in the advanced search.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- 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
If so, you can create any authorized value at the bib-level, associate an icon with it, and that icon will display
I'm assuming that this is only true if you "modify your local XSLT file to point to the icons you want to display?"
Nope, it should work out of the box with or without XSLT on.
You'll have to show me how that works.
Those icons should display on the detail pages (see above).
Is this also true only if you modify the XSLT file for the detail page? Because it's not true for the normal view.
There may be a few sysprefs to tweak to get them to display, but last time I checked, this was working as well.
There's not even any markup in the template for displaying icons for ccodes: <td><!-- TMPL_VAR NAME="ccode" --></td>
- 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.
This isn't the case at all. I can't add a new item-level authorized value and expect it's associated icon to display in the list of waiting holds, or on the list of checkouts on opac-user.pl.
I'd be very happy to be wrong about this one as well :) -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
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. Frankly, I don't see the point in having an extra index point if it's not searchable, or if one is effectively a substitute for the other. This seems like a feature that almost all libraries would dearly like to see changed, for precisely the reasons that you've laid out. We certainly would have paid for this upgrade ourselves if we weren't such a small library. Cab Vinton, Director Sanbornton Public Library Sanbornton, NH
participants (6)
-
Cab Vinton -
Joann Ransom -
Joshua Ferraro -
Mason James -
Nicole Engard -
Owen Leonard