From: Andrew N. <as...@gm...> - 2009-06-24 20:24:25
|
Phil - my answers are below: On Wed, Jun 24, 2009 at 4:11 PM, Philip Shafer <sh...@ro...> wrote: > Andrew, > > I just tried posting a message to the vufind-general list and both times I > was bounce back. > > Here are my questions: > > We have been waiting for the next release candidate (or official 1.0 > release) for quite some time. Now I’m wondering if there is a version that > fixes some of the functions that weren’t quite functional as of RC1. > > Here are the functions I am looking to use come this fall: > > 1.) PHP Session based user logins, we have disabled the user logins > currently because they were storing username and password in a plain text > cookie > This has been rewritten to use sessions and secure password management by Chris Delis at CARLI. > > 2.) As of RC1 the save to book bag and the tagging features we not quite > working properly, I’m hoping that by now they are fixed in some version. > What was not working? We have tweaked this quite a bit since then. The favorites mechanism now has lists so people can organize into lists. This is not yet in SVN but coming soon. > > 3.) There have been issues with the Voyager driver, especially with course > reserves, multiple holdings hopefully these have been resolved. > A major issue that was causing the holdings display to fail has been solved. The course reserves search has not been changed as it has not been a major concern in the community - so it got a lower priority. > 4.) Book covers don’t work all the time, I know there was a patch for this, > so I’m hoping a newer version from the SVN could resolve this. > Im not aware of this problem - but if it is documented in JIRA - than thats all that needs to happen. If it is not in JIRA - please make sure it is well documented there. > > 5.) ‘Next’ and ‘Previous’ record links on the record view page. > > I mainly ask because I don’t want to get into a loop of editing core files > and losing those changes upon an update to the next version. I would prefer > to use this as much out of box as possible and leave any/all changes to > happen in the theme. > There has not been any development with this yet. If you want to work on this - that would be great. The hard part with this is to make it tab/mulitple window safe. Andrew |
From: Anoop A. <ano...@mn...> - 2009-06-25 13:25:40
|
Well it probably would break RSS feeds for searches too. As for POSTing Al Rykhus who works with me and has a lot more experience with Vufind (and all things library) has actually moved away from POST to GET in our implementation since POST has search string length limitations so that would be a problem here also (I think). Al had some thoughts on implementing this feature but has had other priorities on his plate lately. We all agree there is no simple solution but if we want this feature we need to just decide on one method and implement it OR if it's possible we should extend Vufind to do modules/extensions. Where adding a prev/next extension would make that feature available whatever method that particular extension dev decides to use. This would help conserve software bloat in the core and allow independent users to add on to Vufind much more easily without forking away on individual installations as new needs arise. Cheers -- - - - - - - - - - - - - - - - - - - - - - - - - - Anoop Atre IS Developer & Integrator, MnPALS PH: 507.389.5060 OF: 3022 Memorial Library (Office-ML 3022) -- "Mit der Dummheit kämpfen Götter selbst vergebens" ~ Johann Christoph Friedrich von Schiller Till Kinstler wrote: > Andrew Nagy schrieb: > >> The way I envision this happening is by caching the search results and >> assigning a record view page the search cache id and referencing the >> next and previous IDs. Difficult to do without making the URLs reallly >> ugly .... but maybe something like this: >> >> vufind.myuniversity,edu/Search/1/Record/12345/ > > But doesn't that break persistent links, bookmarks etc.? Because the URL > above is only valid in a specific session or search context (of course > that's the context you need for next/prev...). I feel that's no good > idea (inter alia because it breaks the concept of "linked data", and > because of some less dogmatic reasons (eg. around usability) as well). > > Of course, you need to keep state/context data somewhere to do > next/prev. If kept in the user's session data on server side, it breaks > tabs/multiple windows... > If kept in the client, it should be transfered back to the server > without breaking the nice stateles/session independent and persistent > URLs we currently have. NLA puts the whole search into the next/prev > links. I don't like that, because it breaks the concept "one persistent > URL for each record". > > Is POSTing the state data a solution? Maybe like this: > > <form method="POST" action="/Record/12344"> > <input type="hidden" name="Search" value="1"/> > <input type="hidden" name="Record" value="12345"/> <!-- (needed?) --> > <button type="submit">back</button> <!-- or whatever to submit() the > form --> > </form> > > <form method="POST" action="/Record/12346"> > <input type="hidden" name="Search" value="1"/> > <input type="hidden" name="Record" value="12345"/> > <button type="submit">next</button> > </form> > > But we need to know the IDs of the next and previous record in the > result set when generating these forms, then. > > So maybe use a redirection: > POST session data (or search string, because prev/next depends on > search, not on user session) to /Record/12345 that looks up the next (or > previous) record (eg. 12346) and redirects to /Record/12346? But then, > /Record/12346 doesn't know, which session/search it belongs to, grr. So > a redirect plus POST (like Shibboleth uses them)? Ugly... > > No simple solution, I guess... |
From: Alan R. <ala...@mn...> - 2009-06-25 14:36:49
|
Hello, Just so this is correct, we implemented the POST way to get away from the limits of GET calls. The work was done by someone else(forgot name) and submitted to the project. al ps. Anoop has had his coffee now On Thu, 2009-06-25 at 08:25 -0500, Anoop Atre wrote: > Well it probably would break RSS feeds for searches too. As for POSTing > Al Rykhus who works with me and has a lot more experience with Vufind > (and all things library) has actually moved away from POST to GET in our > implementation since POST has search string length limitations so that > would be a problem here also (I think). Al had some thoughts on > implementing this feature but has had other priorities on his plate lately. > > We all agree there is no simple solution but if we want this feature we > need to just decide on one method and implement it OR if it's possible > we should extend Vufind to do modules/extensions. Where adding a > prev/next extension would make that feature available whatever method > that particular extension dev decides to use. This would help conserve > software bloat in the core and allow independent users to add on to > Vufind much more easily without forking away on individual installations > as new needs arise. > > Cheers > -- Alan Rykhus PALS, A Program of the Minnesota State Colleges and Universities (507)389-1975 ala...@mn... |
From: Chris B. <chr...@vi...> - 2009-06-24 21:01:27
Attachments:
vufindLists3.jpg
|
Hi Phil, U. Michigan did next/previous links. Maybe we could get those in the core? (In my opinion I think this is confusing and I've only seen this feature in library catalogs.) I am hoping that development will be picking up soon. We have hired another developer at Villanova that will be starting in a couple of weeks. His primary assignment will be VuFind development. Hopefully, he will be able to pick up things quickly and take some stress off of Andrew. Best, Chris P.S. - Attached is a mockup of how the new "lists" feature might look in a future release. Andrew Nagy wrote: > Phil - my answers are below: > > On Wed, Jun 24, 2009 at 4:11 PM, Philip Shafer <sh...@ro... > <mailto:sh...@ro...>> wrote: > > Andrew, > > I just tried posting a message to the vufind-general list and both > times I was bounce back. > > Here are my questions: > > We have been waiting for the next release candidate (or official > 1.0 release) for quite some time. Now I’m wondering if there is a > version that fixes some of the functions that weren’t quite > functional as of RC1. > > Here are the functions I am looking to use come this fall: > > 1.) PHP Session based user logins, we have disabled the user > logins currently because they were storing username and password > in a plain text cookie > > > This has been rewritten to use sessions and secure password management > by Chris Delis at CARLI. > > > > 2.) As of RC1 the save to book bag and the tagging features we not > quite working properly, I’m hoping that by now they are fixed in > some version. > > > What was not working? We have tweaked this quite a bit since then. > The favorites mechanism now has lists so people can organize into > lists. This is not yet in SVN but coming soon. > > > > 3.) There have been issues with the Voyager driver, especially > with course reserves, multiple holdings hopefully these have been > resolved. > > > A major issue that was causing the holdings display to fail has been > solved. The course reserves search has not been changed as it has not > been a major concern in the community - so it got a lower priority. > > > 4.) Book covers don’t work all the time, I know there was a patch > for this, so I’m hoping a newer version from the SVN could resolve > this. > > > Im not aware of this problem - but if it is documented in JIRA - than > thats all that needs to happen. If it is not in JIRA - please make > sure it is well documented there. > > > > 5.) ‘Next’ and ‘Previous’ record links on the record view page. > > I mainly ask because I don’t want to get into a loop of editing > core files and losing those changes upon an update to the next > version. I would prefer to use this as much out of box as > possible and leave any/all changes to happen in the theme. > > > There has not been any development with this yet. If you want to work > on this - that would be great. The hard part with this is to make it > tab/mulitple window safe. > > Andrew > |
From: Anoop A. <ano...@mn...> - 2009-06-24 21:41:03
|
Chris, It's great to hear you're hiring another dev! A note to the prev-next record feature talk - it has been implemented by UMich AND Nat Lib of Australia (links below) in different ways. The problem with the UMich method is as Andrew mentioned - making the feature tab/multiple window safe. See thread > http://www.nabble.com/Next-record-to20228911.html > http://mirlyn2-beta.lib.umich.edu/ > http://catalogue.nla.gov.au/ ~ Chris Barr wrote: > Hi Phil, > > U. Michigan did next/previous links. Maybe we could get those in the > core? (In my opinion I think this is confusing and I've only seen this > feature in library catalogs.) > > I am hoping that development will be picking up soon. We have hired > another developer at Villanova that will be starting in a couple of > weeks. His primary assignment will be VuFind development. Hopefully, he > will be able to pick up things quickly and take some stress off of Andrew. > > Best, > Chris > > P.S. - Attached is a mockup of how the new "lists" feature might look in > a future release. > > > > Andrew Nagy wrote: >> Phil - my answers are below: >> >> On Wed, Jun 24, 2009 at 4:11 PM, Philip Shafer <sh...@ro... >> <mailto:sh...@ro...>> wrote: >> >> Andrew, >> >> I just tried posting a message to the vufind-general list and both >> times I was bounce back. >> >> Here are my questions: >> >> We have been waiting for the next release candidate (or official >> 1.0 release) for quite some time. Now I’m wondering if there is a >> version that fixes some of the functions that weren’t quite >> functional as of RC1. >> >> Here are the functions I am looking to use come this fall: >> >> 1.) PHP Session based user logins, we have disabled the user >> logins currently because they were storing username and password >> in a plain text cookie >> >> >> This has been rewritten to use sessions and secure password management >> by Chris Delis at CARLI. >> >> >> >> 2.) As of RC1 the save to book bag and the tagging features we not >> quite working properly, I’m hoping that by now they are fixed in >> some version. >> >> >> What was not working? We have tweaked this quite a bit since then. >> The favorites mechanism now has lists so people can organize into >> lists. This is not yet in SVN but coming soon. >> >> >> >> 3.) There have been issues with the Voyager driver, especially >> with course reserves, multiple holdings hopefully these have been >> resolved. >> >> >> A major issue that was causing the holdings display to fail has been >> solved. The course reserves search has not been changed as it has not >> been a major concern in the community - so it got a lower priority. >> >> >> 4.) Book covers don’t work all the time, I know there was a patch >> for this, so I’m hoping a newer version from the SVN could resolve >> this. >> >> >> Im not aware of this problem - but if it is documented in JIRA - than >> thats all that needs to happen. If it is not in JIRA - please make >> sure it is well documented there. >> >> >> >> 5.) ‘Next’ and ‘Previous’ record links on the record view page. >> >> I mainly ask because I don’t want to get into a loop of editing >> core files and losing those changes upon an update to the next >> version. I would prefer to use this as much out of box as >> possible and leave any/all changes to happen in the theme. >> >> >> There has not been any development with this yet. If you want to work >> on this - that would be great. The hard part with this is to make it >> tab/mulitple window safe. >> >> Andrew >> > > > ------------------------------------------------------------------------ > -- - - - - - - - - - - - - - - - - - - - - - - - - - Anoop Atre IS Developer & Integrator, MnPALS PH: 507.389.5060 OF: 3022 Memorial Library (Office-ML 3022) -- "Mit der Dummheit kämpfen Götter selbst vergebens" ~ Johann Christoph Friedrich von Schiller |
From: Andrew N. <as...@gm...> - 2009-06-25 01:02:24
|
On Wed, Jun 24, 2009 at 5:40 PM, Anoop Atre <ano...@mn...> wrote: > A note to the prev-next record feature talk - it has been implemented by > UMich AND Nat Lib of Australia (links below) in different ways. The > problem with the UMich method is as Andrew mentioned - making the > feature tab/multiple window safe. > > See thread > http://www.nabble.com/Next-record-to20228911.html > The way I envision this happening is by caching the search results and assigning a record view page the search cache id and referencing the next and previous IDs. Difficult to do without making the URLs reallly ugly .... but maybe something like this: vufind.myuniversity,edu/Search/1/Record/12345/ Andrew |
From: Till K. <kin...@gb...> - 2009-06-25 10:33:20
|
Andrew Nagy schrieb: > The way I envision this happening is by caching the search results and > assigning a record view page the search cache id and referencing the > next and previous IDs. Difficult to do without making the URLs reallly > ugly .... but maybe something like this: > > vufind.myuniversity,edu/Search/1/Record/12345/ But doesn't that break persistent links, bookmarks etc.? Because the URL above is only valid in a specific session or search context (of course that's the context you need for next/prev...). I feel that's no good idea (inter alia because it breaks the concept of "linked data", and because of some less dogmatic reasons (eg. around usability) as well). Of course, you need to keep state/context data somewhere to do next/prev. If kept in the user's session data on server side, it breaks tabs/multiple windows... If kept in the client, it should be transfered back to the server without breaking the nice stateles/session independent and persistent URLs we currently have. NLA puts the whole search into the next/prev links. I don't like that, because it breaks the concept "one persistent URL for each record". Is POSTing the state data a solution? Maybe like this: <form method="POST" action="/Record/12344"> <input type="hidden" name="Search" value="1"/> <input type="hidden" name="Record" value="12345"/> <!-- (needed?) --> <button type="submit">back</button> <!-- or whatever to submit() the form --> </form> <form method="POST" action="/Record/12346"> <input type="hidden" name="Search" value="1"/> <input type="hidden" name="Record" value="12345"/> <button type="submit">next</button> </form> But we need to know the IDs of the next and previous record in the result set when generating these forms, then. So maybe use a redirection: POST session data (or search string, because prev/next depends on search, not on user session) to /Record/12345 that looks up the next (or previous) record (eg. 12346) and redirects to /Record/12346? But then, /Record/12346 doesn't know, which session/search it belongs to, grr. So a redirect plus POST (like Shibboleth uses them)? Ugly... No simple solution, I guess... Regards, Till -- Till Kinstler Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG) Platz der Göttinger Sieben 1, D 37073 Göttingen kin...@gb..., +49 (0) 551 39-13431, http://www.gbv.de |
From: Philip S. <sh...@ro...> - 2009-06-25 13:11:19
|
Thanks for the input Chris. The design looks good, and I look forward to any updated releases in the near future. As far as next/previous links are concerned I don't believe they are very confusing at all. As a matter of fact they are in most commercial catalogs which I have seen, and I believe they provide a great function, especially for a product that calls is self a discovery tool. Is there any target date to have the next Release Candidate or 1.0 available. The community has been waiting far too long for an updated release. With that said, I know Andrew was asking about some of my concerns. So I'll outline them here: Tagging: Multi-word tags were not being processed properly when I had them enabled in our dev environment: For example, Bill Clinton, president, Monica Lewinsky would to be processed properly. I forget what the actual syntax should be, but I know it wasn't working and I abandoned working on a solution since I knew we couldn't use it until the cookie issue was resolved. Also, I should point out that the application needs to be able to handle when an item is deleted or no longer in the index after an update. Is this something that has been addressed? Bookcovers: I think the following will can explain the issue, it was a simple fix, however there should be a better way to this. HTTP/1.1 200 OK Date: Tue, 10 Mar 2009 16:07:23 GMT Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.8g DAV/2 PHP/5.2.6 mod_fastcgi/2.4.6 X-Powered-By: PHP/5.2.6 Content-Length: 2385 Connection: close Content-Type: image/gif <br /> <b>Warning</b>: file_get_contents(images/covers/syndetics_1x1.gif) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: No such file or directory in <b>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/bookcover.php</b> on line <b>93</b><br /> JFIFC [Binary gobbley gook omitted] It¹s getting the image fine, it¹s just failing to load some other placeholder before hand while it¹s downloading the cached image. That¹s why you¹re seeing it try to deliver an ³image/gif² that it can¹t read (syndetics_1x1.gif) and then following that up with binary JPEG data (the JFIF header on the binary data would be the indicator there) and the content length indicates that the server has the whole image as well (2385 in this case). Course Reserves: The course reserves will die out when the query has no results. Also as far as voyager is concerned the reserves should only list current or active reserves (Faculty with current or active reserves, Courses with current or active reserves, etc). An error has occurred Unable to process query Solr Returned: [576] /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/PEAR.php [726] /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/sys/Solr.php [712] /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/sys/Solr.php [491] /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/sys/Solr.php [68] /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/services/Search/Reserves.php [102] /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/index.php ------------------------------ Philip Shafer Library System Services Rowan University Library 201 Mullica Hill Rd Glassboro, NJ 08028 856-256-4418 856-256-4924 Fax |
From: Till K. <kin...@gb...> - 2009-06-25 14:21:28
|
Philip Shafer schrieb: > Thanks for the input Chris. The design looks good, and I look forward to > any updated releases in the near future. As far as next/previous links are > concerned I don't believe they are very confusing at all. As a matter of > fact they are in most commercial catalogs which I have seen, and I believe > they provide a great function, OK, sorry, now it becomes fundamental: Those (commercial catalogs) are not the reference, are they? Navigation tools (like next/prev) may improve browsing experience and discovery, sure: Discovery is essentially based on navigation. But thinking about it: This next/prev is a very limited (to one dimension: up and down a list sorted by one more or less useful parameter) tool for navigating records. There are many others, like facets, sort parameters, even the search box. And I am not sure if current catalog interfaces provide easy access to their full potential. I am not so much a user interface guy, but somehow this whole "search box" -> "(one dimensional) short title list" -> "details/full title view" concept sucks (just my own impression as user, neither tested, nor based on deeper research into it): eg. when you dive into the detailed data view you usually lose context and tools (eg. facets) you had with the short list (though the breadcrumbs in the new "default" interface in VuFind may help)... Someone else feeling that way? Are there some user interface gurus around? Ideas? Regards, Till -- Till Kinstler Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG) Platz der Göttinger Sieben 1, D 37073 Göttingen kin...@gb..., +49 (0) 551 39-13431, http://www.gbv.de |
From: Chris D. <ce...@ui...> - 2009-06-25 15:00:29
|
I'm no interface guru but when I use these types of catalogs myself during discovery, instead of drilling down into the detailed records and navigating via Prev/Next links (which to me also seems very one-dimensional and feels like I have blinders on), I would instead make heavy use of the list views; and when I find potentially relevant records I would "control-click" (or on a mac, "command-click") each one so as to bring them up into their own tabs for later perusal; this is all done very rapidly and efficiently. The only reason I would ever make use of Prev/Next links would be to view a list of records I had already known to be relevent, e.g., a "my list" of known "good" records I had already created myself. But perhaps I'm not a typical user. On 6/25/09 9:21 AM, "Till Kinstler" <kin...@gb...> wrote: > Philip Shafer schrieb: > >> Thanks for the input Chris. The design looks good, and I look forward to >> any updated releases in the near future. As far as next/previous links are >> concerned I don't believe they are very confusing at all. As a matter of >> fact they are in most commercial catalogs which I have seen, and I believe >> they provide a great function, > > OK, sorry, now it becomes fundamental: > Those (commercial catalogs) are not the reference, are they? > Navigation tools (like next/prev) may improve browsing experience and > discovery, sure: Discovery is essentially based on navigation. > But thinking about it: This next/prev is a very limited (to one > dimension: up and down a list sorted by one more or less useful > parameter) tool for navigating records. There are many others, like > facets, sort parameters, even the search box. And I am not sure if > current catalog interfaces provide easy access to their full potential. > I am not so much a user interface guy, but somehow this whole "search > box" -> "(one dimensional) short title list" -> "details/full title > view" concept sucks (just my own impression as user, neither tested, nor > based on deeper research into it): eg. when you dive into the detailed > data view you usually lose context and tools (eg. facets) you had with > the short list (though the breadcrumbs in the new "default" interface in > VuFind may help)... > Someone else feeling that way? Are there some user interface gurus > around? Ideas? > > Regards, > Till |
From: Sandford, M. <SAN...@wp...> - 2009-06-25 15:30:05
|
Chris, I'd do exactly the same thing (though I prefer clicking the mouse wheel rather than control or command). And I get very frustrated when dealing with sites that break when you have a second tab or window open (classweb, for instance). Given a choice between "ugly" URLs and the ability to effectively navigate and use multiple tabs/windows, I vote for ugly URLs. It doesn't seem to hurt online retailers. Mark -----Original Message----- From: Chris Delis [mailto:ce...@ui...] Sent: Thursday, June 25, 2009 11:00 AM To: vuf...@li... Subject: Re: [VuFind-General] Navigating records (was: Re: VUFindInformation) I'm no interface guru but when I use these types of catalogs myself during discovery, instead of drilling down into the detailed records and navigating via Prev/Next links (which to me also seems very one-dimensional and feels like I have blinders on), I would instead make heavy use of the list views; and when I find potentially relevant records I would "control-click" (or on a mac, "command-click") each one so as to bring them up into their own tabs for later perusal; this is all done very rapidly and efficiently. The only reason I would ever make use of Prev/Next links would be to view a list of records I had already known to be relevent, e.g., a "my list" of known "good" records I had already created myself. But perhaps I'm not a typical user. On 6/25/09 9:21 AM, "Till Kinstler" <kin...@gb...> wrote: > Philip Shafer schrieb: > >> Thanks for the input Chris. The design looks good, and I look forward to >> any updated releases in the near future. As far as next/previous links are >> concerned I don't believe they are very confusing at all. As a matter of >> fact they are in most commercial catalogs which I have seen, and I believe >> they provide a great function, > > OK, sorry, now it becomes fundamental: > Those (commercial catalogs) are not the reference, are they? > Navigation tools (like next/prev) may improve browsing experience and > discovery, sure: Discovery is essentially based on navigation. > But thinking about it: This next/prev is a very limited (to one > dimension: up and down a list sorted by one more or less useful > parameter) tool for navigating records. There are many others, like > facets, sort parameters, even the search box. And I am not sure if > current catalog interfaces provide easy access to their full potential. > I am not so much a user interface guy, but somehow this whole "search > box" -> "(one dimensional) short title list" -> "details/full title > view" concept sucks (just my own impression as user, neither tested, nor > based on deeper research into it): eg. when you dive into the detailed > data view you usually lose context and tools (eg. facets) you had with > the short list (though the breadcrumbs in the new "default" interface in > VuFind may help)... > Someone else feeling that way? Are there some user interface gurus > around? Ideas? > > Regards, > Till ------------------------------------------------------------------------ ------ _______________________________________________ VuFind-General mailing list VuF...@li... https://lists.sourceforge.net/lists/listinfo/vufind-general |
From: Till K. <kin...@gb...> - 2009-06-25 16:09:35
|
Sandford, Mark schrieb: > I'd do exactly the same thing (though I prefer clicking the mouse wheel > rather than control or command). And I get very frustrated when dealing > with sites that break when you have a second tab or window open > (classweb, for instance). Given a choice between "ugly" URLs and the > ability to effectively navigate and use multiple tabs/windows, I vote > for ugly URLs. It doesn't seem to hurt online retailers. Reasons against "ugly URLs" are less a question of "style" than one of interoperability: - no/limited bookmarking (depends on how ugly they are) - no interoperability with social bookmarking tools - no/limited persistent URLs you may pass on (eg. in emails, depends again on grade of ugliness) - no (easy) "linked data" - ... We were trying hard to implement persistent URLs in our legacy OPACs (they address records by result set and hit number) to open them for various use cases (a really simple but common one: library users send emails with remarks or questions on a catalog item and reference that item by the url they copy and paste from the browser, you never gonna find out, what they a are talking about, because the URL is not persistent). We tried adding kind of "permanent link to this record" on record displays. Unsurprisingly no one uses them... So, please, at least "session independent URLs" (ok, the ones NLA uses are, if I remember correctly). Till -- Till Kinstler Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG) Platz der Göttinger Sieben 1, D 37073 Göttingen kin...@gb..., +49 (0) 551 39-13431, http://www.gbv.de |
From: Chris B. <chr...@vi...> - 2009-06-25 15:39:24
|
I agree with Till. The next/previous breaks down and loses its context once you have other ways to browse the catalog than just straight searching. With the old catalogs you did a search and clicked through results. With VuFind there are several ways to get to a record. What happens if I do a search and then click on a related item? Do I still get the prev/next? This breaks on the Michigan site: 1. Search for "Sausage Dogs" 2. Choose "The Finer Points of Sausage Dogs" 3. Choose a similar item 4. Prev/Next still acts as though I am on the first result, which I am not. I am on a fiction book, that while related to the the first result in that search, would never show up under a search for sausage dogs. The point is, that when you browse, those links lose context. The user is left to think, "Next what?" --chris Till Kinstler wrote: > Philip Shafer schrieb: > > >> Thanks for the input Chris. The design looks good, and I look forward to >> any updated releases in the near future. As far as next/previous links are >> concerned I don't believe they are very confusing at all. As a matter of >> fact they are in most commercial catalogs which I have seen, and I believe >> they provide a great function, >> > > OK, sorry, now it becomes fundamental: > Those (commercial catalogs) are not the reference, are they? > Navigation tools (like next/prev) may improve browsing experience and > discovery, sure: Discovery is essentially based on navigation. > But thinking about it: This next/prev is a very limited (to one > dimension: up and down a list sorted by one more or less useful > parameter) tool for navigating records. There are many others, like > facets, sort parameters, even the search box. And I am not sure if > current catalog interfaces provide easy access to their full potential. > I am not so much a user interface guy, but somehow this whole "search > box" -> "(one dimensional) short title list" -> "details/full title > view" concept sucks (just my own impression as user, neither tested, nor > based on deeper research into it): eg. when you dive into the detailed > data view you usually lose context and tools (eg. facets) you had with > the short list (though the breadcrumbs in the new "default" interface in > VuFind may help)... > Someone else feeling that way? Are there some user interface gurus > around? Ideas? > > Regards, > Till > > |
From: Ya'aqov Z. <zi...@ro...> - 2009-06-25 15:52:24
|
Till and Chris, Thanks for once again pointing out how VUFind construes multi-faceted tools for discovery, rather than emulate one-faceted ILS tools, Ya¹aqov On 6/25/09 11:38 AM, "Chris Barr" <chr...@vi...> wrote: > I agree with Till. The next/previous breaks down and loses its context > once you have other ways to browse the catalog than just straight > searching. With the old catalogs you did a search and clicked through > results. With VuFind there are several ways to get to a record. What > happens if I do a search and then click on a related item? Do I still > get the prev/next? > > This breaks on the Michigan site: > > 1. Search for "Sausage Dogs" > 2. Choose "The Finer Points of Sausage Dogs" > 3. Choose a similar item > 4. Prev/Next still acts as though I am on the first result, which I am > not. I am on a fiction book, that while related to the the first result > in that search, would never show up under a search for sausage dogs. > > The point is, that when you browse, those links lose context. The user > is left to think, "Next what?" > > --chris > > > > Till Kinstler wrote: >> > Philip Shafer schrieb: >> > >> > >>> >> Thanks for the input Chris. The design looks good, and I look forward to >>> >> any updated releases in the near future. As far as next/previous links >>> are >>> >> concerned I don't believe they are very confusing at all. As a matter of >>> >> fact they are in most commercial catalogs which I have seen, and I >>> believe >>> >> they provide a great function, >>> >> >> > >> > OK, sorry, now it becomes fundamental: >> > Those (commercial catalogs) are not the reference, are they? >> > Navigation tools (like next/prev) may improve browsing experience and >> > discovery, sure: Discovery is essentially based on navigation. >> > But thinking about it: This next/prev is a very limited (to one >> > dimension: up and down a list sorted by one more or less useful >> > parameter) tool for navigating records. There are many others, like >> > facets, sort parameters, even the search box. And I am not sure if >> > current catalog interfaces provide easy access to their full potential. >> > I am not so much a user interface guy, but somehow this whole "search >> > box" -> "(one dimensional) short title list" -> "details/full title >> > view" concept sucks (just my own impression as user, neither tested, nor >> > based on deeper research into it): eg. when you dive into the detailed >> > data view you usually lose context and tools (eg. facets) you had with >> > the short list (though the breadcrumbs in the new "default" interface in >> > VuFind may help)... >> > Someone else feeling that way? Are there some user interface gurus >> > around? Ideas? >> > >> > Regards, >> > Till >> > >> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > VuFind-General mailing list > VuF...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-general |
From: Philip S. <sh...@ro...> - 2009-06-25 15:09:04
|
Is there a way to browse the SOLR index? I want to know if a title was actually indexed and I don't know how to verify whether is was or wasn't. |
From: Chris B. <chr...@vi...> - 2009-06-25 15:13:51
|
You can get to the SOLR admin panel through the browser: http://yourserver.edu:8081/solr/ (your port might be different) That should list your indexes. From there you can search using Solr query syntax: http://wiki.apache.org/solr/SolrQuerySyntax --chris Philip Shafer wrote: > Is there a way to browse the SOLR index? I want to know if a title was > actually indexed and I don't know how to verify whether is was or wasn't. > > > |
From: Philip S. <sh...@ro...> - 2009-06-25 15:33:22
|
Can someone decode this error for me and let me know if it can be fixed? Fatal error: Uncaught File_MARC_Exception Tag "�00" is not a valid tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line 103 Exception trace # Function Location File_MARC_Field->__construct('�00') /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.php:103 File_MARC_Data_Field->__construct('�00', Array, ' ', ' ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:374 2 File_MARC->_decode('01639cam a220037…') /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in php-5.2.4/lib/php/File/MARC/Field.php on line 81 ------------------------------ Philip Shafer Library System Services Rowan University Library 201 Mullica Hill Rd Glassboro, NJ 08028 856-256-4418 856-256-4924 Fax |
From: Andrew N. <as...@gm...> - 2009-06-25 16:26:39
|
Phil - this happens when the marc parser cannot parse the marc data. Im assuming this is coming from the record view page - which means the data coming back for the Holdings information is not valid marc data. There is a fix for this for the Voyager driver in SVN. Andrew On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> wrote: > Can someone decode this error for me and let me know if it can be fixed? > > Fatal error: Uncaught File_MARC_Exception Tag "�00" is not a > valid > tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line 103 > Exception trace # Function Location > File_MARC_Field->__construct('�00') > /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.php:103 > File_MARC_Data_Field->__construct('�00', Array, ' ', ' > ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:374 > 2 > File_MARC->_decode('01639cam a220037…') > /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in > php-5.2.4/lib/php/File/MARC/Field.php on line 81 > > > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > > |
From: Philip S. <sh...@ro...> - 2009-06-25 16:33:11
|
Can we just check out the current voyager driver from the SVN or is there a particular version you suggest? ------------------------------ Philip Shafer Library System Services Rowan University Library 201 Mullica Hill Rd Glassboro, NJ 08028 856-256-4418 856-256-4924 Fax From: Andrew Nagy <as...@gm...> Date: Thu, 25 Jun 2009 12:26:35 -0400 To: Philip Shafer <sh...@ro...> Cc: "vuf...@li..." <vuf...@li...> Subject: Re: Help with Error Phil - this happens when the marc parser cannot parse the marc data. Im assuming this is coming from the record view page - which means the data coming back for the Holdings information is not valid marc data. There is a fix for this for the Voyager driver in SVN. Andrew On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> wrote: > Can someone decode this error for me and let me know if it can be fixed? > > Fatal error: Uncaught File_MARC_Exception Tag "�00" is not a valid > tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line 103 > Exception trace # Function Location > File_MARC_Field->__construct('�00') > /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.php:103 > File_MARC_Data_Field->__construct('�00', Array, ' ', ' > ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:374 > 2 > File_MARC->_decode('01639cam a220037…') > /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in > php-5.2.4/lib/php/File/MARC/Field.php on line 81 > > > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > |
From: Andrew N. <as...@gm...> - 2009-06-25 16:35:01
|
Latest from SVN should do the trick. On Thu, Jun 25, 2009 at 12:33 PM, Philip Shafer <sh...@ro...> wrote: > Can we just check out the current voyager driver from the SVN or is there > a particular version you suggest? > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > ------------------------------ > *From: *Andrew Nagy <as...@gm...> > *Date: *Thu, 25 Jun 2009 12:26:35 -0400 > *To: *Philip Shafer <sh...@ro...> > *Cc: *"vuf...@li..." < > vuf...@li...> > *Subject: *Re: Help with Error > > > Phil - this happens when the marc parser cannot parse the marc data. Im > assuming this is coming from the record view page - which means the data > coming back for the Holdings information is not valid marc data. > > There is a fix for this for the Voyager driver in SVN. > > Andrew > > On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> wrote: > > Can someone decode this error for me and let me know if it can be fixed? > > Fatal error: Uncaught File_MARC_Exception Tag "�00" is not a > valid > tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line 103 > Exception trace # Function Location > File_MARC_Field->__construct('�00') > /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.php:103 > File_MARC_Data_Field->__construct('�00', Array, ' ', ' > ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:374 > 2 > File_MARC->_decode('01639cam a220037…') > /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in > php-5.2.4/lib/php/File/MARC/Field.php on line 81 > > > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > > > > |
From: Philip S. <sh...@ro...> - 2009-07-06 18:22:23
|
Andrew, is there anyway for me to urge another RC release with some of these updates (minus the new SOLR) that some of us have been complaining about. I’m not very comfortable running a production server from and SVN check out/export. IF this project is going to succeed then the implementing institutions need better support from the developers, which would require frequent updated releases. Just a suggestion. -Phil ------------------------------ Philip Shafer Library System Services Rowan University Library 201 Mullica Hill Rd Glassboro, NJ 08028 856-256-4418 856-256-4924 Fax From: Andrew Nagy <as...@gm...> Date: Thu, 25 Jun 2009 12:34:53 -0400 To: Philip Shafer <sh...@ro...> Cc: "vuf...@li..." <vuf...@li...> Subject: Re: Help with Error Latest from SVN should do the trick. On Thu, Jun 25, 2009 at 12:33 PM, Philip Shafer <sh...@ro...> wrote: > Can we just check out the current voyager driver from the SVN or is there a > particular version you suggest? > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > > From: Andrew Nagy <as...@gm...> > Date: Thu, 25 Jun 2009 12:26:35 -0400 > To: Philip Shafer <sh...@ro...> > Cc: "vuf...@li..." > <vuf...@li...> > Subject: Re: Help with Error > > > Phil - this happens when the marc parser cannot parse the marc data. Im > assuming this is coming from the record view page - which means the data > coming back for the Holdings information is not valid marc data. > > There is a fix for this for the Voyager driver in SVN. > > Andrew > > On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> wrote: >> Can someone decode this error for me and let me know if it can be fixed? >> >> Fatal error: Uncaught File_MARC_Exception Tag "�00" is not a valid >> tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line 103 >> Exception trace # Function Location >> File_MARC_Field->__construct('�00') >> /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.php:103 >> File_MARC_Data_Field->__construct('�00', Array, ' ', ' >> ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:374 >> 2 >> File_MARC->_decode('01639cam a220037…') >> /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in >> php-5.2.4/lib/php/File/MARC/Field.php on line 81 >> >> >> ------------------------------ >> >> Philip Shafer >> Library System Services >> Rowan University Library >> 201 Mullica Hill Rd >> Glassboro, NJ 08028 >> 856-256-4418 >> 856-256-4924 Fax >> >> >> >> > > > > |
From: Diaz, N. A <no...@pu...> - 2009-07-06 19:20:05
|
I agree and we would love an RC2 release. We were going over the changes we have done in the past few months to get our install up and going for a fall release and realized that we are so out of sync with the SVN trunk that it will be a major headache to merge back once a future release candidate gets published. Thus is the nature of beta software and of an evolving project like VuFind but it would be nice to have more frequent stable releases, at most to help new libraries that might be interested in joining to get up and going without the hassles we have encountered! :) -- Noel Diaz Senior Network Systems Administrator Information Technology Department Purdue University Libraries E-Mail: no...@pu... Phone: 765-494-1787 -----Original Message----- From: Philip Shafer [mailto:sh...@ro...] Sent: Monday, July 06, 2009 2:22 PM To: Andrew Nagy Cc: vuf...@li... Subject: Re: [VuFind-General] Help with Error Andrew, is there anyway for me to urge another RC release with some of these updates (minus the new SOLR) that some of us have been complaining about. I’m not very comfortable running a production server from and SVN check out/export. IF this project is going to succeed then the implementing institutions need better support from the developers, which would require frequent updated releases. Just a suggestion. -Phil ------------------------------ Philip Shafer Library System Services Rowan University Library 201 Mullica Hill Rd Glassboro, NJ 08028 856-256-4418 856-256-4924 Fax From: Andrew Nagy <as...@gm...> Date: Thu, 25 Jun 2009 12:34:53 -0400 To: Philip Shafer <sh...@ro...> Cc: "vuf...@li..." <vuf...@li...> Subject: Re: Help with Error Latest from SVN should do the trick. On Thu, Jun 25, 2009 at 12:33 PM, Philip Shafer <sh...@ro...> wrote: > Can we just check out the current voyager driver from the SVN or is there a > particular version you suggest? > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > > From: Andrew Nagy <as...@gm...> > Date: Thu, 25 Jun 2009 12:26:35 -0400 > To: Philip Shafer <sh...@ro...> > Cc: "vuf...@li..." > <vuf...@li...> > Subject: Re: Help with Error > > > Phil - this happens when the marc parser cannot parse the marc data. Im > assuming this is coming from the record view page - which means the data > coming back for the Holdings information is not valid marc data. > > There is a fix for this for the Voyager driver in SVN. > > Andrew > > On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> wrote: >> Can someone decode this error for me and let me know if it can be fixed? >> >> Fatal error: Uncaught File_MARC_Exception Tag "�00" is not a valid >> tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line 103 >> Exception trace # Function Location >> File_MARC_Field->__construct('�00') >> /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.php:103 >> File_MARC_Data_Field->__construct('�00', Array, ' ', ' >> ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:374 >> 2 >> File_MARC->_decode('01639cam a220037…') >> /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in >> php-5.2.4/lib/php/File/MARC/Field.php on line 81 >> >> >> ------------------------------ >> >> Philip Shafer >> Library System Services >> Rowan University Library >> 201 Mullica Hill Rd >> Glassboro, NJ 08028 >> 856-256-4418 >> 856-256-4924 Fax >> >> >> >> > > > > ------------------------------------------------------------------------------ _______________________________________________ VuFind-General mailing list VuF...@li... https://lists.sourceforge.net/lists/listinfo/vufind-general |
From: Greg P. <Gre...@us...> - 2009-07-06 23:58:12
|
>From USQ's point-of-view I'm happy to say involvement with an RC2 release is right around the corner. Our test site is moving to prod (beta) this week and will probably become our new homepage in the next two weeks or so (haven't heard a firm date yet), but my manager is in agreeance that our next step is aligning our codebase with the community and pushing for RC2. Andrew's work in the DisMax handler is probably the biggest question right now because it changes a lot under the hood. But I do want to acknowledge what a huge commitment this is for Andrew since he's no longer at Villanova. I certainly couldn't contribute so much if it wasn't my day job as well. Greg Pendlebury Electronic Services Officer (Systems Team) Division of Academic Information Services University of Southern Queensland Phone: +61 7 4631 1501 Fax: +61 7 4631 1841 -----Original Message----- From: Diaz, Noel A [mailto:no...@pu...] Sent: Tuesday, 7 July 2009 5:19 AM To: vuf...@li... Subject: Re: [VuFind-General] Help with Error I agree and we would love an RC2 release. We were going over the changes we have done in the past few months to get our install up and going for a fall release and realized that we are so out of sync with the SVN trunk that it will be a major headache to merge back once a future release candidate gets published. Thus is the nature of beta software and of an evolving project like VuFind but it would be nice to have more frequent stable releases, at most to help new libraries that might be interested in joining to get up and going without the hassles we have encountered! :) -- Noel Diaz Senior Network Systems Administrator Information Technology Department Purdue University Libraries E-Mail: no...@pu... Phone: 765-494-1787 -----Original Message----- From: Philip Shafer [mailto:sh...@ro...] Sent: Monday, July 06, 2009 2:22 PM To: Andrew Nagy Cc: vuf...@li... Subject: Re: [VuFind-General] Help with Error Andrew, is there anyway for me to urge another RC release with some of these updates (minus the new SOLR) that some of us have been complaining about. I'm not very comfortable running a production server from and SVN check out/export. IF this project is going to succeed then the implementing institutions need better support from the developers, which would require frequent updated releases. Just a suggestion. -Phil ------------------------------ Philip Shafer Library System Services Rowan University Library 201 Mullica Hill Rd Glassboro, NJ 08028 856-256-4418 856-256-4924 Fax From: Andrew Nagy <as...@gm...> Date: Thu, 25 Jun 2009 12:34:53 -0400 To: Philip Shafer <sh...@ro...> Cc: "vuf...@li..." <vuf...@li...> Subject: Re: Help with Error Latest from SVN should do the trick. On Thu, Jun 25, 2009 at 12:33 PM, Philip Shafer <sh...@ro...> wrote: > Can we just check out the current voyager driver from the SVN or is > there a particular version you suggest? > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > > From: Andrew Nagy <as...@gm...> > Date: Thu, 25 Jun 2009 12:26:35 -0400 > To: Philip Shafer <sh...@ro...> > Cc: "vuf...@li..." > <vuf...@li...> > Subject: Re: Help with Error > > > Phil - this happens when the marc parser cannot parse the marc data. > Im assuming this is coming from the record view page - which means the > data coming back for the Holdings information is not valid marc data. > > There is a fix for this for the Voyager driver in SVN. > > Andrew > > On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> wrote: >> Can someone decode this error for me and let me know if it can be fixed? >> >> Fatal error: Uncaught File_MARC_Exception Tag " 00" is not >> a valid tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line >> 103 Exception trace # Function Location >> File_MARC_Field->__construct(' 00') >> /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.p >> hp:103 File_MARC_Data_Field->__construct(' 00', Array, ' ', ' >> ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.p >> hp:374 >> 2 >> File_MARC->_decode('01639cam a220037…') >> /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in >> php-5.2.4/lib/php/File/MARC/Field.php on line 81 >> >> >> ------------------------------ >> >> Philip Shafer >> Library System Services >> Rowan University Library >> 201 Mullica Hill Rd >> Glassboro, NJ 08028 >> 856-256-4418 >> 856-256-4924 Fax >> >> >> >> > > > > ------------------------------------------------------------------------------ _______________________________________________ VuFind-General mailing list VuF...@li... https://lists.sourceforge.net/lists/listinfo/vufind-general ------------------------------------------------------------------------------ _______________________________________________ VuFind-General mailing list VuF...@li... https://lists.sourceforge.net/lists/listinfo/vufind-general This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email. The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt. The University of Southern Queensland is a registered provider of education with the Australian Government (CRICOS Institution Code No's. QLD 00244B / NSW 02225M) |
From: Andrew N. <as...@gm...> - 2009-07-13 13:47:32
|
Thank you all for your interest and encouragement. I can't really say much more other than - I'm working on it! :) If there is something that I can do better - please don't hesitate to let me know. I want to keep VuFind a community driven project - so if you would like to help in the cause - please pick something that you can help with and do it. I can facilitate anything that you need to do your part. Thanks for the help and thanks for your patience Andrew On Mon, Jul 6, 2009 at 7:57 PM, Greg Pendlebury <Gre...@us...>wrote: > > >From USQ's point-of-view I'm happy to say involvement with an RC2 release > is right around the corner. Our test site is moving to prod (beta) this week > and will probably become our new homepage in the next two weeks or so > (haven't heard a firm date yet), but my manager is in agreeance that our > next step is aligning our codebase with the community and pushing for RC2. > > Andrew's work in the DisMax handler is probably the biggest question right > now because it changes a lot under the hood. But I do want to acknowledge > what a huge commitment this is for Andrew since he's no longer at Villanova. > I certainly couldn't contribute so much if it wasn't my day job as well. > > > Greg Pendlebury > Electronic Services Officer (Systems Team) > Division of Academic Information Services > University of Southern Queensland > Phone: +61 7 4631 1501 > Fax: +61 7 4631 1841 > > -----Original Message----- > From: Diaz, Noel A [mailto:no...@pu...] > Sent: Tuesday, 7 July 2009 5:19 AM > To: vuf...@li... > Subject: Re: [VuFind-General] Help with Error > > I agree and we would love an RC2 release. We were going over the changes > we have done in the past few months to get our install up and going for a > fall release and realized that we are so out of sync with the SVN trunk that > it will be a major headache to merge back once a future release candidate > gets published. > > Thus is the nature of beta software and of an evolving project like VuFind > but it would be nice to have more frequent stable releases, at most to help > new libraries that might be interested in joining to get up and going > without the hassles we have encountered! :) > > -- > Noel Diaz > Senior Network Systems Administrator > Information Technology Department > Purdue University Libraries > E-Mail: no...@pu... > Phone: 765-494-1787 > > -----Original Message----- > From: Philip Shafer [mailto:sh...@ro...] > Sent: Monday, July 06, 2009 2:22 PM > To: Andrew Nagy > Cc: vuf...@li... > Subject: Re: [VuFind-General] Help with Error > > Andrew, is there anyway for me to urge another RC release with some of > these updates (minus the new SOLR) that some of us have been complaining > about. > I'm not very comfortable running a production server from and SVN check > out/export. IF this project is going to succeed then the implementing > institutions need better support from the developers, which would require > frequent updated releases. > > Just a suggestion. > > > -Phil > ------------------------------ > > Philip Shafer > Library System Services > Rowan University Library > 201 Mullica Hill Rd > Glassboro, NJ 08028 > 856-256-4418 > 856-256-4924 Fax > > > > > From: Andrew Nagy <as...@gm...> > Date: Thu, 25 Jun 2009 12:34:53 -0400 > To: Philip Shafer <sh...@ro...> > Cc: "vuf...@li..." > <vuf...@li...> > Subject: Re: Help with Error > > Latest from SVN should do the trick. > > On Thu, Jun 25, 2009 at 12:33 PM, Philip Shafer <sh...@ro...> wrote: > > Can we just check out the current voyager driver from the SVN or is > > there a particular version you suggest? > > ------------------------------ > > > > Philip Shafer > > Library System Services > > Rowan University Library > > 201 Mullica Hill Rd > > Glassboro, NJ 08028 > > 856-256-4418 > > 856-256-4924 Fax > > > > > > > > > > From: Andrew Nagy <as...@gm...> > > Date: Thu, 25 Jun 2009 12:26:35 -0400 > > To: Philip Shafer <sh...@ro...> > > Cc: "vuf...@li..." > > <vuf...@li...> > > Subject: Re: Help with Error > > > > > > Phil - this happens when the marc parser cannot parse the marc data. > > Im assuming this is coming from the record view page - which means the > > data coming back for the Holdings information is not valid marc data. > > > > There is a fix for this for the Voyager driver in SVN. > > > > Andrew > > > > On Thu, Jun 25, 2009 at 11:32 AM, Philip Shafer <sh...@ro...> > wrote: > >> Can someone decode this error for me and let me know if it can be fixed? > >> > >> Fatal error: Uncaught File_MARC_Exception Tag " 00" is not > >> a valid tag. in php-5.2.4/lib/php/File/MARC/Data_Field.php on line > >> 103 Exception trace # Function Location > >> File_MARC_Field->__construct(' 00') > >> /disk2/ApplicationStack/v1.0/php-5.2.4/lib/php/File/MARC/Data_Field.p > >> hp:103 File_MARC_Data_Field->__construct(' 00', Array, ' ', ' > >> ')</td><td>/disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.p > >> hp:374 > >> 2 > >> File_MARC->_decode('01639cam a220037…') > >> /disk2/ApplicationStack/v1.0/vufind-1.0RC1/web/File/MARC.php:246 in > >> php-5.2.4/lib/php/File/MARC/Field.php on line 81 > >> > >> > >> ------------------------------ > >> > >> Philip Shafer > >> Library System Services > >> Rowan University Library > >> 201 Mullica Hill Rd > >> Glassboro, NJ 08028 > >> 856-256-4418 > >> 856-256-4924 Fax > >> > >> > >> > >> > > > > > > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > VuFind-General mailing list > VuF...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-general > > ------------------------------------------------------------------------------ > _______________________________________________ > VuFind-General mailing list > VuF...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-general > > This email (including any attached files) is confidential and is for the > intended recipient(s) only. If you received this email by mistake, > please, as a courtesy, tell the sender, then delete this email. > > The views and opinions are the originator's and do not necessarily > reflect those of the University of Southern Queensland. Although all > reasonable precautions were taken to ensure that this email contained no > viruses at the time it was sent we accept no liability for any losses > arising from its receipt. > > The University of Southern Queensland is a registered provider of > education with the Australian Government (CRICOS Institution Code No's. > QLD 00244B / NSW 02225M) > > > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/blackberry > _______________________________________________ > VuFind-General mailing list > VuF...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-general > |
From: Till K. <kin...@gm...> - 2009-07-14 21:47:14
|
Sorry, this is a lengthy mail now, but I felt the need to write this... Andrew Nagy wrote: > Thank you all for your interest and encouragement. I can't really say > much more other than - I'm working on it! :) If there is something that > I can do better - please don't hesitate to let me know. Hmmm, how to put it right? I think it's not so much on you to do better, it's maybe more on all somehow involved in VuFind to do better. I feel, there are a lot of individuals doing things with VuFind, but there is no real community around it, at least no development community. We all maintain our branches, wait for something to happen in the main trunk, sometimes complain, that's all going on too slow, but on the other hand don't really contribute... Why? I started using VuFind about a year ago, because I needed some user interface for a bibliographic Solr index, hacked it to my needs and found some nice ideas in it. I really didn't care for a community or development processes. VuFind was something like Firefox or Ubuntu: Download and use it (in that case as starting point for my hacks). There were frequent updates in trunk, from time to time I merged the code with our hacks, fine... Then this year development slowed down, finally the trunk code was broken for a long time. And I finally noticed, that whole thing is more or less a one man show: Andrew is checking in the code, handling support etc... There is no real development community contributing code (or is it hidden somewhere? Hey, come out, you really don't need to hide because of that...! :-)). On different occasions in the last months, I met some others (VuFind users as well as some interested in using it) sharing that same impression (not to say: worrying or even complaining about the state of community around VuFind). I always told them: Hey, it's up to us to build a community, if we care. That's probably why I started really reading and answering mails on the lists, following (and somewhat commenting) code development and putting some of my dirty hacks into Jira. Maybe I have a wrong concept of an open source project community: I think there must be more than commit rights and code checkins. Some exchange and discussion about further development as well as about details, some ways to find and fix consense and finally (distributed) coding. Sorry, I feel that's missing around here. I am not sure about the reasons, though... But that's a pity, because VuFind is too good to end as another zombie open source project (just now, there is growing interest in VuFind among german libraries, would be ugly to confirm some common prejudice on open source software that way). Only thing, I think, you (Andrew) could do better: Commit more frequently, even if it's broken code, to get others involved (eg. in testing and bug fixing and finally coding), and more actively share/discuss your ideas on further development (I know, you answer any question on that, but if no one asks...), even in the way "What do you think about...? I haven't got the time to implement that, someone to do it?". Or to put it like this: Take the active role of a maintainer and catch/pledge others that may contribute... Just my 0.02€, tell me, if I'm completely wrong... Till -- http://twitter.com/tillk |