Hi koha-devel, circ/circulation and members/moremember are both showing a table of the unreturned issue of a borrower. The two page provides the same information, displayed with only very slight differences. I wonder why the same work is made twice. Should we have this table only on circ/circulation? and a link to circ/circulation on members/moremember? The link could give a summary of current issues (eg: "2 issues with 1 overdue"). Bye -- Pierrick LE GALL INEO media system
circ/circulation and members/moremember are both showing a table of the unreturned issue of a borrower. The two page provides the same information, displayed with only very slight differences.
I wonder why the same work is made twice. Should we have this table only on circ/circulation? and a link to circ/circulation on members/moremember? The link could give a summary of current issues (eg: "2 issues with 1 overdue"). I'm not sure why there are two tables, one for 'current issues' and one for 'previous issues'. I think the same thing could be acomplished by including a 'sort by issue date' feature that would allow a
On Fri, Mar 31, 2006 at 04:02:56PM +0200, Pierrick LE GALL wrote: librarian to see which items had been recently checked out. As far as why both members and circulation contain current issues, we should check with katipo to double-check whethere their clients rely on that for something. Chris? Russ? Cheers, -- Joshua Ferraro VENDOR SERVICES 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
On Fri, 31 Mar 2006 06:09:00 -0800 Joshua Ferraro <jmf@liblime.com> wrote:
On Fri, Mar 31, 2006 at 04:02:56PM +0200, Pierrick LE GALL wrote:
circ/circulation and members/moremember are both showing a table of the unreturned issue of a borrower. The two page provides the same information, displayed with only very slight differences.
I wonder why the same work is made twice. Should we have this table only on circ/circulation? and a link to circ/circulation on members/moremember? The link could give a summary of current issues (eg: "2 issues with 1 overdue").
I'm not sure why there are two tables, one for 'current issues' and one for 'previous issues'. I think the same thing could be acomplished by including a 'sort by issue date' feature that would allow a librarian to see which items had been recently checked out.
The "previous issues" in circ/circulation only means an issue not returned yet but not modified on the current day. AFAIK already returned issues are only displayed in members/readingrec The only difference between the two pages is the "charges" column. -- Pierrick LE GALL INEO media system
On Fri, Mar 31, 2006 at 06:09:00AM -0800, Joshua Ferraro wrote:
On Fri, Mar 31, 2006 at 04:02:56PM +0200, Pierrick LE GALL wrote:
circ/circulation and members/moremember are both showing a table of the unreturned issue of a borrower. The two page provides the same information, displayed with only very slight differences.
I wonder why the same work is made twice. Should we have this table only on circ/circulation? and a link to circ/circulation on members/moremember? The link could give a summary of current issues (eg: "2 issues with 1 overdue"). I'm not sure why there are two tables, one for 'current issues' and one for 'previous issues'.
Because it's important for librarians to be able to easily tell which items they've just checked out as opposed to which were checked out earlier.
As far as why both members and circulation contain current issues, we should check with katipo to double-check whethere their clients rely on that for something. Chris? Russ?
I think we shouldn't worry (particularly in the prog templates) about whether we're displaying /too much/ information. We need to instead be concerned that we're displaying too little. The moremember display is useful for the librarian when they want to see more information about the borrower than is displayed on the circulation screen. The circ screen needs to remain fairly stripped-down and functional because a heavier circ screen will result in slower transaction times (page reload). The moremember screen is for displaying as much information as possible so that the librarian has a single page to go for everything they need to see. -- Owen
On Fri, 31 Mar 2006 09:29:31 -0500 Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
I think we shouldn't worry (particularly in the prog templates) about whether we're displaying /too much/ information. We need to instead be concerned that we're displaying too little.
[...] The moremember screen is for displaying as much information as possible so that the librarian has a single page to go for everything they need to see.
Here follows the reasons why we should avoid having the 95% same informations displayed on different pages: - scalability: the day we'll have a new feature for members, we'll have to duplicate it on as many pages as where they make sense to display? - consistancy: the same form is displayed in 2 places, any normal user will wonder why, what the difference between the two forms. - stability: we have twice more code lines. They are not written the same, they don't even use the same module function to retrieve issues. The day you correct a bug on the first module, the second form will still display the bug. Well, this is dangerous and time consuming for developers. I totally agree that a members/moremember page is useful, but I should be essentially a page linked to others, not a page displaying same informations slightly differently. Cheers, -- Pierrick LE GALL INEO media system
I totally agree that a members/moremember page is useful, but I should be essentially a page linked to others, not a page displaying same informations slightly differently.
I agree in principle. But I also agree wholeheartedly with Owen, I can tell you right now, if we took the issues information off the members page and replaced it with a link. ALL of our clients would say, put that back. They dont want to have to click, one more click is one more click. They want to see the information there. HLT specifically asked to have that information there, so Id really hate for it to go. It should use the same code to generate the information, thats what includes in html::template and subroutines in modules are for. I agree we shouldnt dupcilate code, BUT, I dont agree we cant display the same information in 2 places. Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
participants (4)
-
Chris Cormack -
Joshua Ferraro -
Owen Leonard -
Pierrick LE GALL