| Time |
S |
Nick |
Message |
| 17:44 |
|
thd |
kados: are you there? Did I miss the announcement? |
| 20:20 |
|
kados |
thd: no ... haven't done it yet because I'm waiting to hear from someone |
| 20:20 |
|
kados |
thd: it'll all become clear soon enough ;-) |
| 09:07 |
|
paul |
hello world |
| 09:07 |
|
kados |
hi paul |
| 09:07 |
|
paul |
hi joshua |
| 09:08 |
|
kados |
have you seen bug 997? |
| 09:09 |
|
kados |
and 998? |
| 09:11 |
|
paul |
yes. |
| 09:11 |
|
paul |
997 is already partially fixed on my desktop. |
| 09:11 |
|
paul |
998 is strange. |
| 09:12 |
|
paul |
but i have an idea |
| 09:12 |
|
kados |
paul: cool ... thanks |
| 10:00 |
|
thd |
paul: How did you partially solve 997? |
| 10:01 |
|
paul |
hi thd. |
| 10:01 |
|
thd |
paul: hello |
| 10:01 |
|
paul |
for instance it's not completly done. but here is what i did : |
| 10:02 |
|
paul |
- fix a bug in Biblio.pm (a sql was ordered on subfieldcode and not subfieldorder) |
| 10:02 |
|
paul |
- add the possibility to modify the subfieldcode. |
| 10:02 |
|
paul |
so, we can store : |
| 10:02 |
|
paul |
700$x$x$y$a |
| 10:02 |
|
paul |
as expected. |
| 10:03 |
|
paul |
what is still to be done : |
| 10:03 |
|
paul |
- adding a button to "up" or "down" a subfield. |
| 10:04 |
|
paul |
(are you the bugreporter ?) |
| 10:04 |
|
thd |
paul: what about a selection list for the value of the field? |
| 10:04 |
|
paul |
(as me) |
| 10:04 |
|
paul |
would make a too big html page. |
| 10:04 |
|
paul |
some of my libraries already have a 75kB page. |
| 10:04 |
|
thd |
thd: yes, blame the messenger :) |
| 10:04 |
|
paul |
we reach the limits of HTML here.. |
| 10:05 |
|
paul |
(you're the bug reporter ?) |
| 10:05 |
|
thd |
thd: yes I am the bug reporter for both 997 and 998, you can blame the messenger now :) |
| 10:06 |
|
paul |
tu es francais ? |
| 10:06 |
|
thd |
paul: no |
| 10:06 |
|
paul |
(i ask because alinto is a french company, funded by a french of mine) |
| 10:07 |
|
thd |
paul: alinto has the best freemail service for my uses right now, I like it very much. |
| 10:07 |
|
paul |
(funded by a friend of mine) |
| 10:08 |
|
paul |
(not french of mine :-( ) |
| 10:08 |
|
thd |
paul: few freemail services have POP support anymore |
| 10:09 |
|
paul |
right. that's why I have my own, koha-fr.org ;-) |
| 10:09 |
|
thd |
paul: I use alinto for anonymity |
| 10:10 |
|
paul |
I don't need anonymity, I need to be well known in the library world ;-) |
| 10:10 |
|
paul |
(to get customers) |
| 10:12 |
|
thd |
paul: Unserstood, in some contexts I avoid people from other contexts knowing what I am doing where the other context may hold something against me until I think it is safe. |
| 10:13 |
|
paul |
of course I understand ! |
| 10:16 |
|
thd |
paul: if a subfield entry line presented a list of possible subfields adjacent to the entry line in a drop down selection box for that field only why would that be too much HTML? |
| 10:16 |
|
paul |
because on a page with 40 subfields, that would mean 40 select lists. |
| 10:16 |
|
paul |
(or there's something i didn't understood) |
| 10:17 |
|
thd |
paul: how often do you have 40 subfields? |
| 10:18 |
|
paul |
that's usual when creating a biblio |
| 10:18 |
|
paul |
(with repeated authors, subject, that means around 15 fields, with 1-5 subfields in each) |
| 10:19 |
|
thd |
paul: I guess I was thinking about the problem one field at a time |
| 10:19 |
|
paul |
but we can't afford the price of a html request for each field/subfield isn't it ? |
| 10:22 |
|
thd |
paul: even still with the fields you have commonly on one page, do you actually have 40 or too many in the 10 paged view? |
| 10:22 |
|
paul |
??? |
| 10:22 |
|
paul |
(not clear) |
| 10:23 |
|
thd |
thd: you don't have all the fields in one page just five or so and then you fo to the next five |
| 10:23 |
|
paul |
you mean in the page with the 10 tabs ? |
| 10:24 |
|
thd |
paul: yes the whole record is not there on one page |
| 10:25 |
|
paul |
i think the user don't want to have to wait between pages. The actual page loads the 10 tabs in 1 HTML page |
| 10:25 |
|
paul |
I think that in the future, the best would be to have something not in pure html. |
| 10:25 |
|
paul |
something like XUL |
| 10:26 |
|
thd |
paul: I did not realise, I have not been thorough in my examination of koha yet. |
| 10:26 |
|
thd |
paul: wouldn't 10 separte pages be better? |
| 10:27 |
|
paul |
http protocol is too slow for this I think. |
| 10:29 |
|
thd |
paul: how much slower is it to fetch 1/10th of the information 10 times as opposed to 10 times the information once? |
| 10:30 |
|
thd |
paul: all 10 pages are not usually even used are they? |
| 10:31 |
|
paul |
it's not a question of measurable speed, but user feeling. waiting for 2 seconds before beginning is better than waiting 4 times 0,4 seconds. |
| 10:31 |
|
paul |
(+ there is html rendering time) |
| 10:32 |
|
thd |
paul: everyone should be using elinks :) |
| 10:34 |
|
thd |
paul: Is there a way to simplify the design so that any page renders faster on any browser? |
| 10:35 |
|
paul |
maybe a little, but only a little I think. |
| 10:35 |
|
paul |
in the future, I think the best solution would be to let the user having the MARC editor he want. |
| 10:36 |
|
paul |
the "koha internal" or "XXX", or "YYY" |
| 10:36 |
|
thd |
paul: I like the editor in Koha, most are free form subfield entry which allows mistakes to be made more easily. |
| 10:37 |
|
paul |
right, that was my 1st goal : having something that does not require a professionnal MARC cataloguer. |
| 10:37 |
|
thd |
paul: you did an excellent job with that |
| 10:38 |
|
thd |
paul: even professional cataloguers make mistakes, just look at any large data set, especially OCLC. |
| 10:39 |
|
paul |
(already enough to see with...) |
| 10:41 |
|
thd |
paul: it would seem that having the whole record in html at one time is a great burden if full cataloguing on all fields is enabled. |
| 10:42 |
|
paul |
right. But that's rarely needed. So you can define frameworks to limit the number of fields you need (1 for serials, 1 for monography...) |
| 10:43 |
|
thd |
paul: I had envisioned a model where the cataloguer could press a link or button to activate less commonly needed fields for the type of item being catalogued. |
| 10:44 |
|
thd |
paul: I had imagined the tabs worked in a similar way to fetch susequent pages in the record |
| 10:48 |
|
thd |
paul: If the model does not require the whole record on one page, then very complete cataloguing can be supported where all relevent fields for the item type are a click or two away. |
| 10:53 |
|
thd |
paul: under the current model, if you have too many fields enabled for the occasion that they might be needed then the MARC editor loads more slowly than it would need to for most records of the item type that would not need the obscure fields. |
| 10:59 |
|
thd |
paul: am I being unclear, apart from my spelling errors? |
| 10:59 |
|
paul |
no, you're clear. |
| 11:00 |
|
paul |
& i agree with you on a theoric point of view. but for instance, the MARC editor has some weaknesses that makes them correct but not powerful. |
| 11:00 |
|
paul |
s/them/it/ |
| 11:02 |
|
thd |
paul: I think you could change the model a 'little' and have something to support common MARC cataloguing and complete deluxue cataloguing in the same model. |
| 11:03 |
|
paul |
explain how to do it... |
| 11:03 |
|
thd |
paul: It would be a tool to die for :] |
| 11:04 |
|
thd |
paul: specoify the item type first as you already do. |
| 11:06 |
|
thd |
paul: then each page for an appropriate minimal standard is loaded separtely as I had thought the tabs did. |
| 11:07 |
|
thd |
paul: at any page or point in the record a link or button fetches a more complete set of subpages for all the marc fields appropriate to the record at that point when needed. |
| 11:08 |
|
thd |
paul: you still have separte pages when you expand the level of cataloguing detail so the page loading burden for each individual page is low. |
| 11:10 |
|
thd |
paul: if you only need full marc in one section you can go back to the standard view in another section |
| 11:11 |
|
thd |
paul: koha needs 'killer' tools to say that it not only does x but it does x better than any other program |
| 11:12 |
|
thd |
paul: I will help for whatever I can to make it work, obviously I have a big gap in knowing just how koha does some things already |
| 11:14 |
|
thd |
paul: the selection lists for the subfields would be less of a burden under that design |
| 11:14 |
|
paul |
right. Your suggestions are good. |
| 11:16 |
|
thd |
paul: if the user changed the order form a good default then the page might have to be reloaded to support the value lists or authorities thesaurus in the correct adjacent location. |
| 11:18 |
|
thd |
paul: Of course it would help if there was a group institutions to support the work for a cataloguing tool that worked as well for the non-M |
| 11:19 |
|
thd |
ARC expert as for cataloguers who know every field backwards. |
| 11:20 |
|
thd |
paul: I think your basic user friendly forms design is better for everyone, even if expert cataloguers are faster with free form subfield entry into a text box. |
| 11:21 |
|
thd |
paul: what you loose on speed for the experts you gain on a degree of automatic validation for everyone |
| 11:24 |
|
thd |
paul: do you know of commercial tools that use your guided forms approach to subfield entry? My experience seeing commercial cataloguing tools is a little to old and incomplete. |
| 11:25 |
|
paul |
no thd. i'm not a cataloguer, i'm a developper. So i only have a minor knowledge of commercial ILS. |
| 11:26 |
|
thd |
paul: the koha project needs a closer liason with the most expert users. |
| 11:28 |
|
paul |
right. When I was Release Manager (2.0 and 2.2), I spoke a lot with "my" libraries, but they are mostly "small" libraries. very happy with actual MARC editor. |
| 11:28 |
|
paul |
joshua/kados, has views/ideas/will for larger libraries. |
| 11:29 |
|
paul |
where my code is a little bit under-featured. |
| 11:29 |
|
paul |
i'm happy with joshua goals & objectives. He will make Koha a great product (& i'll help him where possible) |
| 11:30 |
|
thd |
paul: Almost every developer sees programming solutions in terms of how to most efficiently solve problems rather than tackling the difficulties head on for what the users imagine they should when they are dreaming clearly about an ideal world. |
| 11:32 |
|
thd |
paul: Programming becomes harder when you tackle the greatest difficulties head on but even the frustarations are more fun and the result is more rewarding. |
| 11:36 |
|
thd |
paul: As for commercial ILS, it is good to know what the competition is doing so you can take the best ideas for your own and have a superior product. |
| 11:38 |
|
thd |
paul: Of course, I do not believe in software idea patents. You have to be careful about British Telecom claiming HTML even in Europe soon I fear. |
| 11:40 |
|
thd |
paul: BT is over that foolishness over HTML but there will always be someone in the US at least causing trouble with patents. So a modest amount of care is warranted in the current IP world. |
| 11:43 |
|
thd |
kados: are you back from lunch? |
| 11:44 |
|
kados |
thd: yep ;-) |
| 11:44 |
|
kados |
thd: just finished reading your discussion |
| 11:46 |
|
thd |
kados: even though my programming experience is less deep than it should be I have generally employed it toward difficult problems and been pleased with how quickly they can sometimes fall once you consider them seriously. |
| 11:48 |
|
thd |
kados: my lack of deep programming knowledge is often the greatest burden in knowing how to do some simple things the common way. |
| 11:48 |
|
thd |
:) |
| 11:49 |
|
kados |
:-) |
| 11:50 |
|
kados |
I think the best approach to pattents is to simply ignore them |
| 11:50 |
|
thd |
kados: Do you know of commercial tools that use Paul's guided forms approach to subfield entry? My experience seeing commercial cataloguing tools is a little to old and incomplete. |
| 11:50 |
|
paul |
joshua/kados : i've a ta_MY translation files (.po) in my mailbox |
| 11:50 |
|
kados |
the best cataloging tool I've seen is ITS.MARC from TLC |
| 11:51 |
|
kados |
paul: nice! |
| 11:51 |
|
thd |
kados: Ignore patents and remain ignorant about them. Knowlegde entails triple damages in the US. |
| 11:51 |
|
kados |
:-) |
| 11:51 |
|
kados |
well the best way to prove you had an idea is to code it |
| 11:54 |
|
thd |
kados: I had not realised the tabs were not separate pages there is more work there than I had first supposed. |
| 11:54 |
|
kados |
not sure why that means there is more work |
| 11:55 |
|
kados |
what's wrong with having everything on one page? |
| 11:56 |
|
kados |
I think we may need to employ some javascript on the cataloging tool to provide the ability to generate a new subfield for repeatable fields |
| 11:56 |
|
thd |
kados: I thought the MARC record had separate pages already for cataloguing. |
| 11:56 |
|
kados |
and also to handle some hotkeys for authorized value and for common tasks |
| 11:56 |
|
kados |
macros, etc. |
| 11:56 |
|
kados |
why does it need seperate pages? |
| 11:57 |
|
kados |
separate even ;-) |
| 11:58 |
|
kados |
paul: in the record you showed me earlier wherever there are little icons (magnifying glass) means there is an authorized value that you can search? |
| 11:58 |
|
thd |
kados: Read the discussion with Paul about separate pages again. One record is a burden for supporting full MARC cataloguing for all the obscure fields when needed by a particular cataloguer. |
| 11:59 |
|
paul |
kados : no. it's a way to search for a field value to "jump" from biblio to biblio |
| 11:59 |
|
thd |
kados: , for an appropriate item that deserves full cataloguing. |
| 11:59 |
|
paul |
i spoke of this with owen last friday |
| 11:59 |
|
kados |
paul: I'll read the logs |
| 11:59 |
|
paul |
ok, thx |
