Salve! Cataloguing in general has been stewing in my brain for many years, and cataloguing on Koha in particular. I started on a DRA system years back, and I could hear a game show buzzer in my head when I saw the interface. Then I remember colleagues getting all excited to look at Dynix Horizon new cataloguing module. We just kind of looked at one another after the sales guys had gone away. That wasn't it either, but it wasn't game show buzzer bad. III was kind of nice, and as I became a dork and would ask people I didn't know to view their cataloguing systems as the years swam by I came to the conclusion that some were better than others but none were particularly well liked. I've long hated the one that's come bundled with Koha, and I've long though "Oh come on, I know we can do this in a sexy way!" If we put together a module that was better than everyone else's, that would be the proprietary nail in the coffin, and I don't think it's terribly difficult to do since everyone else's bar is so low. I arrived at the inevitable conclusion that this was one of many areas where it was going to be hard or nearly impossible to get fellow Librarians to be very specific in terms of what they would like to use and not just what was in front of them. I feel like it's the aesthetics and interface of things more than anything else. Big warning: I'm not properly a cataloguer, but gosh over the years my cataloguing disguise seems to be getting very good. The time to think about a major overhaul is *now* since the RDA proposal is on the table.
Hopefully starting on a new thread. Just in the last few weeks we've had a couple of clients who would really benefit from an easier way to do their own cataloging.
They don't (Sadly) find their specialist materials being well serviced via the various z39.50 servers etc, often because they are doing cataloging of materials they are producing themselves, or from other government departmens/private publishers essentially.
Yeah. There are an absolute tonne of special Libraries that simply *can't* find records that would match their own since they're drummed up in house or are so rarely held that there aren't records to be found to match. Engineering, transportation, medical, and legal come to my mind, just to name a few. I shudder to think about folks not having someone around that could do original cataloguing, but after a number of years on this project, I know from some of the cataloguing questions that I get that folks can't afford someone or just don't want someone that can do original cataloguing. Many times in this sort of environment, folks want a simple text box for Author, Title, and I think they ought to have subject just to round things off for the big three. I'd argue that a URL needs be in there for electronic organisation of data.
As alluded to we (Katipo) did have an interface to do this in the very early versions of Koha, and I still have essentially the spec for it in the form of a working version, and screen shots/manual type stuff - we called it simple acquisitions, and in the current version of Koha you can see that there is a preference for either simple or normal acquisitions - of which only normal is really there.
I've been toying with the idea of seeing what's involved in essentially adding a simple acquisitions module back in again - but saw that Galen I think is planning something similar sounding as a simple MARC module.
So I'm wondering if the two ideas are close enough to be the same
Find another chump for acquisitions, cause I've not got mah head around that. ;) thing? No, at least not from where I think. Again, I'm not expecting this any time soon, but I'd like to see it as a road map goal, even if it's a couple of releases out. (As in 4 or 5.) I think that we have several different approaches to cataloguing itself, and I think this is the root cause of why all interfaces suck. Something that programmers might want to consider is having permissions tied in to the different approaches, so that an amateur would be able to use the simple module, but not the pro version. I think there ought to be about 4 ways to handle a record in Koha, 2 of them are close enough that they can live under the same roof. We should have what Rachel is asking after. Simple Cataloguing (since it's simple and she's got screenshots of what it used to look like, there's not really much more work in bringing this one back.) then I think we definitely need a new version of Pro Cataloguing I still don't totally like what I see with other products in terms of interface, but both Biblios and current cataloguing aren't it. I've seen people whip up an original MARC record in minutes tops. They want a blank playbox (that's a big old textbox, as for email) that will recognise MARC fields. I think we can go one better than that simple of an approach by making that textbox operate more like Dreamweaver. Why not have those fields change colour, and then have the tooltip display the name of the MARC field in question and perhaps a R for repeatable and a N for non repeatable. I think that would be a neat way of catching the cataloguer before they've had their java, since you'd be able to just hover over a blue 110 and think "Oh! Of course that's not Additional Author! Duh!" So, mostly graphical. Mostly blank. Mostly leave the professional cataloguer the heck alone and let them do their thing. The comment I hear the most on any ILS cataloguing interface is something on the order of "Maybe this is because I'm a little older than you, but I just want my typewriter and card back. It was easier. I'm not opposed to technology, but man, I could just do that in a few minutes." Copy Cataloguing Same approach as above, only a z39.50 button someplace on that same page that would let you very simply import a record by ISBN or Title. Here's the twist. eXtensible Catalog right now has The Thing that I was talking about with authorities. It goes through and finds Evanovich, Janet and Evanovich Janet. and Evanovich, Janet. and possibly even Evanogich, Janit, and asks record by record if they need to be deduplicated. But here's how The Thing would be applied to copy cataloguing. Disagree with me here if I'm getting out on a limb, cataloguers, but in general, when I was copy cataloguing with style, the longer the record I found via z39.50, the better the record was. The exception to this was the odd occasions where someone would apparently have copied and pasted into a record multiple times. We should be able to tell how long that record is before we import it. I don't know whether that's a constraint of z39.50 or no. The system should check internally how many characters are in a given record in the databases we point to and report a little summary back. I'd even love to have ratings creep into this, a la digg, though that may well ruffle some feathers. Is MaineInfoNet good on local stuff, cool, comment and mark em up. Does AccessPenn not do so great a job with children's records, comment and mark em down. A lot of people in rural Libraries end up using Delicious Library. That's the sort of ease to strive for on the first page of copy cataloguing. We could always just have a prompt if someone wanted to edit further after the initial ISBN scan. Guided Cataloguing A long time ago when animals could talk, I had an AIM discussion with Nicole about cataloguing. Why is all of this still a one way street that starts with my brain? Aren't I essentially taking different paths down a big flowchart in my head? When I hold an item in my hand and sit down to catalogue, aren't I going through pretty much the same thought process time in and time out? Yes, it's very complex. Yes, it varies per item. BUT there are questions in common. This is why those veteran cataloguers can whip up a very high quality record in no time flat. They've mental muscle memory for cataloguing. And we have them. >:) Why can't a programme ask the questions that I have in my head in a series and formulate a MARC record from it? Why can't it show me what the verso is in the process? Why aren't we leveraging linking when there's a world wide web? This is the hardest part since no one's tried doing it before that I know of.
Anyways, if anyone has strong views one way or the other let me know. I'm a bit biased against the current MARC interface - we get people being intimidated by it (me included :-) but I'm prepared to work through it.
I think that's from too much text and boxes on the page, plus all of those tabs, like my long winded emails. You're not alone in being intimidated. I wasn't but I know a bunch of people that saw that and said "You're joking! That's a lot of fields!" Cheers, Brooke
Hi all, I am starting to feel really quite positive about acquisitions again! Really love the idea of thinking about a range of cataloguing 'levels', including one for non-marc cataloguers (like me!). I wondered if we could consider FRBR too (or maybe that is what RDA is? - I don't know sorry). We designed Koha 1.0 with BIBLIOS, GROUPS and ITEMS to achieve a similar result to FRBR, in that ITEMS inherit all of the attributes of the GROUP record they are attached to, and GROUPS inherit all the attributes of the BIBLIO they were attached to. This mean reserves could be placed at a BIBLIO level if you didn't care which ITEM you got, or at GROUP level (if you wanted the first ITEm available of a particular edition) or at an ITEM level (when you wanted a specific issue of a periodical or a specific video to send away for cleaning etc). In planning our move to Koha 3.0 I am reconciled to the fact that we have to run a scripty-thing over our database creating new bibios for each group, but our way did make it very easy for patrons to place reserves. Cheers Jo. BWS Johnson wrote:
Salve!
Cataloguing in general has been stewing in my brain for many years, and cataloguing on Koha in particular. I started on a DRA system years back, and I could hear a game show buzzer in my head when I saw the interface. Then I remember colleagues getting all excited to look at Dynix Horizon new cataloguing module. We just kind of looked at one another after the sales guys had gone away. That wasn't it either, but it wasn't game show buzzer bad. III was kind of nice, and as I became a dork and would ask people I didn't know to view their cataloguing systems as the years swam by I came to the conclusion that some were better than others but none were particularly well liked. I've long hated the one that's come bundled with Koha, and I've long though "Oh come on, I know we can do this in a sexy way!" If we put together a module that was better than everyone else's, that would be the proprietary nail in the coffin, and I don't think it's terribly difficult to do since everyone else's bar is so low. I arrived at the inevitable conclusion that this was one of many areas where it was going to be hard or nearly impossible to get fellow Librarians to be very specific in terms of what they would like to use and not just what was in front of them. I feel like it's the aesthetics and interface of things more than anything else. Big warning: I'm not properly a cataloguer, but gosh over the years my cataloguing disguise seems to be getting very good.
The time to think about a major overhaul is *now* since the RDA proposal is on the table.
Hopefully starting on a new thread. Just in the last few weeks we've had a couple of clients who would really benefit from an easier way to do their own cataloging.
They don't (Sadly) find their specialist materials being well serviced via the various z39.50 servers etc, often because they are doing cataloging of materials they are producing themselves, or from other government departmens/private publishers essentially.
Yeah. There are an absolute tonne of special Libraries that simply *can't* find records that would match their own since they're drummed up in house or are so rarely held that there aren't records to be found to match. Engineering, transportation, medical, and legal come to my mind, just to name a few. I shudder to think about folks not having someone around that could do original cataloguing, but after a number of years on this project, I know from some of the cataloguing questions that I get that folks can't afford someone or just don't want someone that can do original cataloguing. Many times in this sort of environment, folks want a simple text box for Author, Title, and I think they ought to have subject just to round things off for the big three. I'd argue that a URL needs be in there for electronic organisation of data.
As alluded to we (Katipo) did have an interface to do this in the very early versions of Koha, and I still have essentially the spec for it in the form of a working version, and screen shots/manual type stuff - we called it simple acquisitions, and in the current version of Koha you can see that there is a preference for either simple or normal acquisitions - of which only normal is really there.
Find another chump for acquisitions, cause I've not got mah head around that. ;)
I've been toying with the idea of seeing what's involved in essentially adding a simple acquisitions module back in again - but saw that Galen I think is planning something similar sounding as a simple MARC module.
So I'm wondering if the two ideas are close enough to be the same thing?
No, at least not from where I think. Again, I'm not expecting this any time soon, but I'd like to see it as a road map goal, even if it's a couple of releases out. (As in 4 or 5.)
I think that we have several different approaches to cataloguing itself, and I think this is the root cause of why all interfaces suck. Something that programmers might want to consider is having permissions tied in to the different approaches, so that an amateur would be able to use the simple module, but not the pro version.
I think there ought to be about 4 ways to handle a record in Koha, 2 of them are close enough that they can live under the same roof. We should have what Rachel is asking after.
Simple Cataloguing (since it's simple and she's got screenshots of what it used to look like, there's not really much more work in bringing this one back.)
then I think we definitely need a new version of
Pro Cataloguing
I still don't totally like what I see with other products in terms of interface, but both Biblios and current cataloguing aren't it. I've seen people whip up an original MARC record in minutes tops. They want a blank playbox (that's a big old textbox, as for email) that will recognise MARC fields. I think we can go one better than that simple of an approach by making that textbox operate more like Dreamweaver. Why not have those fields change colour, and then have the tooltip display the name of the MARC field in question and perhaps a R for repeatable and a N for non repeatable. I think that would be a neat way of catching the cataloguer before they've had their java, since you'd be able to just hover over a blue 110 and think "Oh! Of course that's not Additional Author! Duh!" So, mostly graphical. Mostly blank. Mostly leave the professional cataloguer the heck alone and let them do their thing. The comment I hear the most on any ILS cataloguing interface is something on the order of "Maybe this is because I'm a little older than you, but I just want my typewriter and card back. It was easier. I'm not opposed to technology, but man, I could just do that in a few minutes."
Copy Cataloguing
Same approach as above, only a z39.50 button someplace on that same page that would let you very simply import a record by ISBN or Title. Here's the twist. eXtensible Catalog right now has The Thing that I was talking about with authorities. It goes through and finds Evanovich, Janet and Evanovich Janet. and Evanovich, Janet. and possibly even Evanogich, Janit, and asks record by record if they need to be deduplicated. But here's how The Thing would be applied to copy cataloguing. Disagree with me here if I'm getting out on a limb, cataloguers, but in general, when I was copy cataloguing with style, the longer the record I found via z39.50, the better the record was. The exception to this was the odd occasions where someone would apparently have copied and pasted into a record multiple times. We should be able to tell how long that record is before we import it. I don't know whether that's a constraint of z39.50 or no. The system should check internally how many characters are in a given record in the databases we point to and report a little summary back. I'd even love to have ratings creep into this, a la digg, though that may well ruffle some feathers. Is MaineInfoNet good on local stuff, cool, comment and mark em up. Does AccessPenn not do so great a job with children's records, comment and mark em down. A lot of people in rural Libraries end up using Delicious Library. That's the sort of ease to strive for on the first page of copy cataloguing. We could always just have a prompt if someone wanted to edit further after the initial ISBN scan.
Guided Cataloguing
A long time ago when animals could talk, I had an AIM discussion with Nicole about cataloguing. Why is all of this still a one way street that starts with my brain? Aren't I essentially taking different paths down a big flowchart in my head? When I hold an item in my hand and sit down to catalogue, aren't I going through pretty much the same thought process time in and time out? Yes, it's very complex. Yes, it varies per item. BUT there are questions in common. This is why those veteran cataloguers can whip up a very high quality record in no time flat. They've mental muscle memory for cataloguing. And we have them. >:) Why can't a programme ask the questions that I have in my head in a series and formulate a MARC record from it? Why can't it show me what the verso is in the process? Why aren't we leveraging linking when there's a world wide web? This is the hardest part since no one's tried doing it before that I know of.
Anyways, if anyone has strong views one way or the other let me know. I'm a bit biased against the current MARC interface - we get people being intimidated by it (me included :-) but I'm prepared to work through it.
I think that's from too much text and boxes on the page, plus all of those tabs, like my long winded emails. You're not alone in being intimidated. I wasn't but I know a bunch of people that saw that and said "You're joking! That's a lot of fields!"
Cheers, Brooke ------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Joann, FRBR is already in place in the OPAC. If you enable one of the ISBN services under Enhanced Content in System Preferences and turn on FRBR you're set to go. This added an editions tab to your OPAC showing you all of the same editions of the title. --- 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, Dec 18, 2008 at 3:36 PM, Joann Ransom <jransom@library.org.nz> wrote:
Hi all,
I am starting to feel really quite positive about acquisitions again! Really love the idea of thinking about a range of cataloguing 'levels', including one for non-marc cataloguers (like me!).
I wondered if we could consider FRBR too (or maybe that is what RDA is? - I don't know sorry).
We designed Koha 1.0 with BIBLIOS, GROUPS and ITEMS to achieve a similar result to FRBR, in that ITEMS inherit all of the attributes of the GROUP record they are attached to, and GROUPS inherit all the attributes of the BIBLIO they were attached to. This mean reserves could be placed at a BIBLIO level if you didn't care which ITEM you got, or at GROUP level (if you wanted the first ITEm available of a particular edition) or at an ITEM level (when you wanted a specific issue of a periodical or a specific video to send away for cleaning etc).
In planning our move to Koha 3.0 I am reconciled to the fact that we have to run a scripty-thing over our database creating new bibios for each group, but our way did make it very easy for patrons to place reserves.
Cheers Jo.
BWS Johnson wrote:
Salve!
Cataloguing in general has been stewing in my brain for many years, and cataloguing on Koha in particular. I started on a DRA system years back, and I could hear a game show buzzer in my head when I saw the interface. Then I remember colleagues getting all excited to look at Dynix Horizon new cataloguing module. We just kind of looked at one another after the sales guys had gone away. That wasn't it either, but it wasn't game show buzzer bad. III was kind of nice, and as I became a dork and would ask people I didn't know to view their cataloguing systems as the years swam by I came to the conclusion that some were better than others but none were particularly well liked. I've long hated the one that's come bundled with Koha, and I've long though "Oh come on, I know we can do this in a sexy way!" If we put together a module that was better than everyone else's, that would be the proprietary nail in the coffin, and I don't think it's terribly difficult to do since everyone else's bar is so low. I arrived at the inevitable conclusion that this was one of many areas where it was going to be hard or nearly impossible to get fellow Librarians to be very specific in terms of what they would like to use and not just what was in front of them. I feel like it's the aesthetics and interface of things more than anything else. Big warning: I'm not properly a cataloguer, but gosh over the years my cataloguing disguise seems to be getting very good.
The time to think about a major overhaul is *now* since the RDA proposal is on the table.
Hopefully starting on a new thread. Just in the last few weeks we've had a couple of clients who would really benefit from an easier way to do their own cataloging.
They don't (Sadly) find their specialist materials being well serviced via the various z39.50 servers etc, often because they are doing cataloging of materials they are producing themselves, or from other government departmens/private publishers essentially.
Yeah. There are an absolute tonne of special Libraries that simply *can't* find records that would match their own since they're drummed up in house or are so rarely held that there aren't records to be found to match. Engineering, transportation, medical, and legal come to my mind, just to name a few. I shudder to think about folks not having someone around that could do original cataloguing, but after a number of years on this project, I know from some of the cataloguing questions that I get that folks can't afford someone or just don't want someone that can do original cataloguing. Many times in this sort of environment, folks want a simple text box for Author, Title, and I think they ought to have subject just to round things off for the big three. I'd argue that a URL needs be in there for electronic organisation of data.
As alluded to we (Katipo) did have an interface to do this in the very early versions of Koha, and I still have essentially the spec for it in the form of a working version, and screen shots/manual type stuff - we called it simple acquisitions, and in the current version of Koha you can see that there is a preference for either simple or normal acquisitions - of which only normal is really there.
Find another chump for acquisitions, cause I've not got mah head around that. ;)
I've been toying with the idea of seeing what's involved in essentially adding a simple acquisitions module back in again - but saw that Galen I think is planning something similar sounding as a simple MARC module.
So I'm wondering if the two ideas are close enough to be the same thing?
No, at least not from where I think. Again, I'm not expecting this any time soon, but I'd like to see it as a road map goal, even if it's a couple of releases out. (As in 4 or 5.)
I think that we have several different approaches to cataloguing itself, and I think this is the root cause of why all interfaces suck. Something that programmers might want to consider is having permissions tied in to the different approaches, so that an amateur would be able to use the simple module, but not the pro version.
I think there ought to be about 4 ways to handle a record in Koha, 2 of them are close enough that they can live under the same roof. We should have what Rachel is asking after.
Simple Cataloguing (since it's simple and she's got screenshots of what it used to look like, there's not really much more work in bringing this one back.)
then I think we definitely need a new version of
Pro Cataloguing
I still don't totally like what I see with other products in terms of interface, but both Biblios and current cataloguing aren't it. I've seen people whip up an original MARC record in minutes tops. They want a blank playbox (that's a big old textbox, as for email) that will recognise MARC fields. I think we can go one better than that simple of an approach by making that textbox operate more like Dreamweaver. Why not have those fields change colour, and then have the tooltip display the name of the MARC field in question and perhaps a R for repeatable and a N for non repeatable. I think that would be a neat way of catching the cataloguer before they've had their java, since you'd be able to just hover over a blue 110 and think "Oh! Of course that's not Additional Author! Duh!" So, mostly graphical. Mostly blank. Mostly leave the professional cataloguer the heck alone and let them do their thing. The comment I hear the most on any ILS cataloguing interface is something on the order of "Maybe this is because I'm a little older than you, but I just want my typewriter and card back. It was easier. I'm not opposed to technology, but man, I could just do that in a few minutes."
Copy Cataloguing
Same approach as above, only a z39.50 button someplace on that same page that would let you very simply import a record by ISBN or Title. Here's the twist. eXtensible Catalog right now has The Thing that I was talking about with authorities. It goes through and finds Evanovich, Janet and Evanovich Janet. and Evanovich, Janet. and possibly even Evanogich, Janit, and asks record by record if they need to be deduplicated. But here's how The Thing would be applied to copy cataloguing. Disagree with me here if I'm getting out on a limb, cataloguers, but in general, when I was copy cataloguing with style, the longer the record I found via z39.50, the better the record was. The exception to this was the odd occasions where someone would apparently have copied and pasted into a record multiple times. We should be able to tell how long that record is before we import it. I don't know whether that's a constraint of z39.50 or no. The system should check internally how many characters are in a given record in the databases we point to and report a little summary back. I'd even love to have ratings creep into this, a la digg, though that may well ruffle some feathers. Is MaineInfoNet good on local stuff, cool, comment and mark em up. Does AccessPenn not do so great a job with children's records, comment and mark em down. A lot of people in rural Libraries end up using Delicious Library. That's the sort of ease to strive for on the first page of copy cataloguing. We could always just have a prompt if someone wanted to edit further after the initial ISBN scan.
Guided Cataloguing
A long time ago when animals could talk, I had an AIM discussion with Nicole about cataloguing. Why is all of this still a one way street that starts with my brain? Aren't I essentially taking different paths down a big flowchart in my head? When I hold an item in my hand and sit down to catalogue, aren't I going through pretty much the same thought process time in and time out? Yes, it's very complex. Yes, it varies per item. BUT there are questions in common. This is why those veteran cataloguers can whip up a very high quality record in no time flat. They've mental muscle memory for cataloguing. And we have them. >:) Why can't a programme ask the questions that I have in my head in a series and formulate a MARC record from it? Why can't it show me what the verso is in the process? Why aren't we leveraging linking when there's a world wide web? This is the hardest part since no one's tried doing it before that I know of.
Anyways, if anyone has strong views one way or the other let me know. I'm a bit biased against the current MARC interface - we get people being intimidated by it (me included :-) but I'm prepared to work through it.
I think that's from too much text and boxes on the page, plus all of those tabs, like my long winded emails. You're not alone in being intimidated. I wasn't but I know a bunch of people that saw that and said "You're joking! That's a lot of fields!"
Cheers, Brooke ------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
FRBR is already in place in the OPAC.
I don't know what the official definition of FRBR is, but what Nicole is describing doesn't come close to satisfying the expectations that a Koha 1.0 user would have switching to Koha 3.0. Koha 1.0 not only displayed different material types under one title heading, but allowed the patron to place a hold on one or any of those items. Can anyone supply a screenshot of that functionality? I'm not pointing this out to criticize the current version--I'm as much to blame as anyone, speaking as someone from the library that sponsored MARC compliance in Koha (the nail in the coffin of that 1.0 feature). I point this out because I think this is an important discussion, and a bit of Koha history that we shouldn't forget. I this case we need to know history so we *can* repeat it. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Sat, Dec 20, 2008 at 2:30 AM, Owen Leonard <oleonard@myacpl.org> wrote:
FRBR is already in place in the OPAC.
I don't know what the official definition of FRBR is, but what Nicole is describing doesn't come close to satisfying the expectations that a Koha 1.0 user would have switching to Koha 3.0. Koha 1.0 not only displayed different material types under one title heading, but allowed the patron to place a hold on one or any of those items.
Can anyone supply a screenshot of that functionality?
Sure can http://photos.bigballofwax.co.nz/gallery2/main.php?g2_itemId=5920 It was also grouped on the search results page, (not just when you get to the detail). I dont have a screenshot of that handy, but Ill get one and post it. Chris
http://photos.bigballofwax.co.nz/gallery2/main.php?g2_itemId=5920
Thanks Chris, I'm curious now how the user knows details about the various formats. Were there detailed descriptions of the different versions on the detail page that the user clicked the 'place reserve' button from? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Sat, Dec 20, 2008 at 8:53 AM, Owen Leonard <oleonard@myacpl.org> wrote:
http://photos.bigballofwax.co.nz/gallery2/main.php?g2_itemId=5920
Thanks Chris,
I'm curious now how the user knows details about the various formats. Were there detailed descriptions of the different versions on the detail page that the user clicked the 'place reserve' button from?
Yep, that's pretty much it. Search results page just had the title, then the number of items linked to the title. The detail page had them broken down by group (versions, formats, biblioitems ... whatever you want to call them :)) In the librarian interface it had more detail, including options to shift things from group to group, eg, you might have 3 items as bestseller, and you could choose to shift 2 of them over to fiction. Or from pay dvd to free dvd Chris
participants (5)
-
BWS Johnson -
Chris Cormack -
Joann Ransom -
Nicole Engard -
Owen Leonard