[CODE4LIB] Call for proposals Elag 2011
This is your final chance to submit a proposal for Elag 2011. Are your proud of the work you have been doing ? Do you think you know stuff you should share ? Do you have a great idea ? Are you able to teach your colleagues something ? Make yourself heard by doing a presentation at Elag 2011 ! The theme of this year's conference is taken from the title of a 1994 article by Paul Saffo in Wired magazine. In the article, Saffo wrote It is not content but context that will matter most a decade or so from now. The scarce resource will not stuff, but point of view. More than fifteen years later, context has never been so important in providing information to library customers. Go to http://www.elag.org and submit your proposal to do a presentation, moderate a workshop or lead a pre-conference bootcamp at Elag 2011 See you in Prague !!! Peter van Boheemen Chair Elag
[CODE4LIB] to link or not to link: PURLs
Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). Thanks for your input. -- HARDY POTTINGER pottinge...@umsystem.edu University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/ No matter how far down the wrong road you've gone, turn back. --Turkish proverb
Re: [CODE4LIB] to link or not to link: PURLs
If you don't have any confidence in the URL, then why would you bother giving it out at all? Links are links. Make them active. On Wed, Jan 26, 2011 at 14:57, Pottinger, Hardy J. pottinge...@umsystem.edu wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). Thanks for your input. -- HARDY POTTINGER pottinge...@umsystem.edu University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/http://lso.umsystem.edu/%7Epottingerhj/ No matter how far down the wrong road you've gone, turn back. --Turkish proverb
Re: [CODE4LIB] to link or not to link: PURLs
If you don't have any confidence in the URL, then why would you bother giving it out at all? Links are links. Make them active. Hi, David, I agree. And thanks! My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). :-) Just to be clear, I think this is a good thing, and is a compelling argument for making PURLs/Handles active links. Any other takers? --Hardy
Re: [CODE4LIB] to link or not to link: PURLs
At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user’s browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. best, Erik Hetzner Sent from my free software system http://fsf.org/. pgp80PT94Qhgm.pgp Description: PGP signature
Re: [CODE4LIB] to link or not to link: PURLs
On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user’s browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. ...which is why I intensely dislike Handles and PURLs. Man-up (person-up? byte-up?) and make a long-term commitment to own the URLs you mint with your digital asset management system. Peter -- Peter Murray peter.mur...@lyrasis.orgtel:+1-678-235-2955 Ass't Director, Technology Services Development http://dltj.org/about/ Lyrasis --Great Libraries. Strong Communities. Innovative Answers. The Disruptive Library Technology Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
+1 for eric and peter. A resource's URL has to be the one in the location bar. That's the one the delicious bookmarklet will grab, etc. On Wed, Jan 26, 2011 at 10:51 PM, Peter Murray peter.mur...@lyrasis.org wrote: On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user’s browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. ...which is why I intensely dislike Handles and PURLs. Man-up (person-up? byte-up?) and make a long-term commitment to own the URLs you mint with your digital asset management system. Peter -- Peter Murray peter.mur...@lyrasis.org tel:+1-678-235-2955 Ass't Director, Technology Services Development http://dltj.org/about/ Lyrasis -- Great Libraries. Strong Communities. Innovative Answers. The Disruptive Library Technology Jester http://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
Peter, are you opposed to an abstraction layer in principle? My reading of your response is that there's an assumption that there is one system and that it will work in perpetuity. We are in the unfortunate but I think fairly common position of having multiple systems, of aspiring to pare that down, and fully expectant that we'll need to migrate at some point even if we find perfection in the near to mid term. Having a link abstraction layer would make those transitions easier on our users, and on the world of linked data in general. Tim On 1/26/11 4:51 PM, Peter Murray peter.mur...@lyrasis.org wrote: On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user¹s browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. ...which is why I intensely dislike Handles and PURLs. Man-up (person-up? byte-up?) and make a long-term commitment to own the URLs you mint with your digital asset management system. Peter -- Peter Murray peter.mur...@lyrasis.orgtel:+1-678-235-2955 Ass't Director, Technology Services Development http://dltj.org/about/ Lyrasis --Great Libraries. Strong Communities. Innovative Answers. The Disruptive Library Technology Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
as far as i can see, dislike of handles and PURLs doesn't mean commitment to one system which will work in perpetuity, but only commitment to own one domain in perpetuity. once you commit to that you may create an abstraction/redirection layer with mod_rewrite :) regards, robert On Wed, Jan 26, 2011 at 11:01 PM, Shearer, Timothy J tshea...@email.unc.edu wrote: Peter, are you opposed to an abstraction layer in principle? My reading of your response is that there's an assumption that there is one system and that it will work in perpetuity. We are in the unfortunate but I think fairly common position of having multiple systems, of aspiring to pare that down, and fully expectant that we'll need to migrate at some point even if we find perfection in the near to mid term. Having a link abstraction layer would make those transitions easier on our users, and on the world of linked data in general. Tim On 1/26/11 4:51 PM, Peter Murray peter.mur...@lyrasis.org wrote: On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user零 browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. ...which is why I intensely dislike Handles and PURLs. Man-up (person-up? byte-up?) and make a long-term commitment to own the URLs you mint with your digital asset management system. Peter -- Peter Murray peter.mur...@lyrasis.org tel:+1-678-235-2955 Ass't Director, Technology Services Development http://dltj.org/about/ Lyrasis -- Great Libraries. Strong Communities. Innovative Answers. The Disruptive Library Technology Jester http://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
Seems like your link abstraction layer should be baked into your system, so the URL your users see in the location bar IS the one that your link abstraction layer is handling and you are committing to persisting. There's no reason a URL has to begin with 'purl.org' to be part of a persisting abstraction layer, neccesarily. If your URL is http://myapp.myuniversity.edu/record/12345, then you can change systems all you want, the new system just still needs to be addressable at that URI, and still needs to know what /record/12345 is. But yeah, we've often got to deal with software written by other people that doesn't do that. On 1/26/2011 5:01 PM, Shearer, Timothy J wrote: Peter, are you opposed to an abstraction layer in principle? My reading of your response is that there's an assumption that there is one system and that it will work in perpetuity. We are in the unfortunate but I think fairly common position of having multiple systems, of aspiring to pare that down, and fully expectant that we'll need to migrate at some point even if we find perfection in the near to mid term. Having a link abstraction layer would make those transitions easier on our users, and on the world of linked data in general. Tim On 1/26/11 4:51 PM, Peter Murraypeter.mur...@lyrasis.org wrote: On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user¹s browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. ...which is why I intensely dislike Handles and PURLs. Man-up (person-up? byte-up?) and make a long-term commitment to own the URLs you mint with your digital asset management system. Peter -- Peter Murray peter.mur...@lyrasis.orgtel:+1-678-235-2955 Ass't Director, Technology Services Development http://dltj.org/about/ Lyrasis --Great Libraries. Strong Communities. Innovative Answers. The Disruptive Library Technology Jesterhttp://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
Re: [CODE4LIB] to link or not to link: PURLs
At Wed, 26 Jan 2011 17:01:05 -0500, Jonathan Rochkind wrote: It's sometimes not feasible/possible though. But it is unfortunate, and I agree you should always just do that where possible. I wonder if Google's use of the link rel=canonical element has been catching on with any other tools? Will any browses, delicious extensions, etc., bookmark that, or offer the option to bookmark that, or anything, instead of the one in the address bar? The W3C WWW Technical Architecture Group has some interest in making 302 found redirects work as they were supposed to in browsers [1], but there is not a lot of movement there, as far as I know. In the meantime I believe that we should strive in all cases to ensure that the URL in the address bar is the permanent URL. best, Erik 1. http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html Sent from my free software system http://fsf.org/. pgpTc0ywBEOv1.pgp Description: PGP signature
Re: [CODE4LIB] to link or not to link: PURLs
On Wed, Jan 26, 2011 at 5:11 PM, Jonathan Rochkind rochk...@jhu.edu wrote: Seems like your link abstraction layer should be baked into your system, so the URL your users see in the location bar IS the one that your link abstraction layer is handling and you are committing to persisting. Which I think is what UNT does(?) An example of how to do it? http://digital.library.unt.edu/ark:/67531/metapth60974/ Kevin
Re: [CODE4LIB] to link or not to link: PURLs
Yep,using a globally unique identifier like an ARK is better than my /records/12345 example,that's a better way to do it for sure. So in that example, http://digital.library.unt.edu/ark:/67531/metapth60974/ is what you access, http://digital.library.unt.edu/ark:/67531/metapth60974/ is what you see in your browser location bar, and they can switch software systems all they want, as long as the new system lives at http://digital.library.unt.edu, and can take an ARK and give you your think -- without a redirect. [One way to do that on top of a system that doens't otherwise care about it would be to use apache reverse proxy -- so long as the system has SOME url template with a slot for an ARK. Although the system has to care enough to _generate_ the right URLs in links too, I guess, but that sometimes just requiers changing at a view/template layer, that may be easier to change than the actual controller/URL parsing/handling layer. ]. On 1/26/2011 5:27 PM, Kevin S. Clarke wrote: On Wed, Jan 26, 2011 at 5:11 PM, Jonathan Rochkindrochk...@jhu.edu wrote: Seems like your link abstraction layer should be baked into your system, so the URL your users see in the location bar IS the one that your link abstraction layer is handling and you are committing to persisting. Which I think is what UNT does(?) An example of how to do it? http://digital.library.unt.edu/ark:/67531/metapth60974/ Kevin
[CODE4LIB] A/B Testing Catalogs and Such
There's a lot of resistance in my institution to A/B or multivariate testing any of our live production properties (catalog, website, etc...). I've espoused the virtues of having hard data to back up user activity (if I hear one more well, in my opinion, I'll just go blind), but the reply is always along the lines of, But it will confuse users! I've pointed out the myriad successful and critical business that use these methodologies, but was told that businesses and academia are different. So, my question to you is, which of you academic libraries are using A/B testing; on what potion of your web properties (catalog, discovery interface, website, etc...); and I suppose to spark conversation, which testing suite are you using (Google Website Optimizer, Visual Website Optimizer, a home-rolled non-hosted solution)? I was told if I can prove it's a commonly accepted practice, I can move forward. So help a guy out, and save me from having to read another survey of 12 undergrads that is proof positive of changes I need to make. Thanks! *Sean Moore* Web Application Programmer *Phone*: (504) 314-7784 *Email*: cmoo...@tulane.edu Howard-Tilton Memorial Library http://library.tulane.edu, Tulane University
Re: [CODE4LIB] A/B Testing Catalogs and Such
I've proposed A/B testing for our OPAC. I managed to avoid the torches, but the pitchforks...youch! On Wed, Jan 26, 2011 at 5:55 PM, Sean Moore thedreadpirates...@gmail.comwrote: There's a lot of resistance in my institution to A/B or multivariate testing any of our live production properties (catalog, website, etc...). I've espoused the virtues of having hard data to back up user activity (if I hear one more well, in my opinion, I'll just go blind), but the reply is always along the lines of, But it will confuse users! I've pointed out the myriad successful and critical business that use these methodologies, but was told that businesses and academia are different. So, my question to you is, which of you academic libraries are using A/B testing; on what potion of your web properties (catalog, discovery interface, website, etc...); and I suppose to spark conversation, which testing suite are you using (Google Website Optimizer, Visual Website Optimizer, a home-rolled non-hosted solution)? I was told if I can prove it's a commonly accepted practice, I can move forward. So help a guy out, and save me from having to read another survey of 12 undergrads that is proof positive of changes I need to make. Thanks! *Sean Moore* Web Application Programmer *Phone*: (504) 314-7784 *Email*: cmoo...@tulane.edu Howard-Tilton Memorial Library http://library.tulane.edu, Tulane University -- Bill Dueber Library Systems Programmer University of Michigan Library
Re: [CODE4LIB] to link or not to link: PURLs
What some in this thread are frowning on is having an abstraction layer such that the persistent URL for your web page or resource is not the URL that typical users see in their browser location bar when viewing that resource or web page. If your abstraction layer can make that so, then I don't think anyone in this thread would frown upon it. If your abstraction layer can't make that so... then I personally still agree it's sometimes an appropriate solution, the best trade-off, an acceptable evil. But it's worth spending some time thinking about if you can set it up to do that instead. Some shops have more technical capacity than others. If you are at a shop that can't even do their own apache install, then you are pretty much at the bottom of 'technical capacity' (which isn't an insult, that's where some people are), there isn't much of anything you can do, and you should be telling your vendors that you want them to provide you with software that does it right. That's pretty much all you can do. But STILL requires you to have enough understanding to tell the vendor what 'right' is and know if they've done it or not. If you can't even do that... well, you'll get what you get, so it goes. From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Shearer, Timothy J [tshea...@email.unc.edu] Sent: Wednesday, January 26, 2011 5:45 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] to link or not to link: PURLs Right, they are not the same, which is why I wondered if there was opposition to an abstraction layer in principle. A major problem for institutions who cannot afford to build is that they license systems. Licensed systems are often less than ideal. When an institution is in that scenario it either doesn't have the resources to tweak the system or the system is so closed as to be un-tweakable (or both). So your options, unless I'm missing something, are to stick with the bad urls your system provides, or to invest in an abstraction layer. I realize that the abstraction layer doesn't solve many of the problems (SEO, harvested indexes, user's re-use from the object they are looking at), but it does seem to solve some problems. Published urls (say in Worldcat, Open Library, and elsewhere). Taking advantage of linked data locally when you do have resources (e.g, an enhancing interface that extends functionality, or a preservation layer where a persistent identifier in the form of links would be handy). mod_rewrite assumes Apache, and that you may configure it. So I'm wondering if an abstraction layer is frowned upon in principle (as opposed to specific dislike or PURLS or handles). And, even if it's not ideal, whether it still presents utility, even in less than ideal implementations. -t On 1/26/11 5:09 PM, Robert Forkel xrotw...@googlemail.com wrote: as far as i can see, dislike of handles and PURLs doesn't mean commitment to one system which will work in perpetuity, but only commitment to own one domain in perpetuity. once you commit to that you may create an abstraction/redirection layer with mod_rewrite :) regards, robert On Wed, Jan 26, 2011 at 11:01 PM, Shearer, Timothy J tshea...@email.unc.edu wrote: Peter, are you opposed to an abstraction layer in principle? My reading of your response is that there's an assumption that there is one system and that it will work in perpetuity. We are in the unfortunate but I think fairly common position of having multiple systems, of aspiring to pare that down, and fully expectant that we'll need to migrate at some point even if we find perfection in the near to mid term. Having a link abstraction layer would make those transitions easier on our users, and on the world of linked data in general. Tim On 1/26/11 4:51 PM, Peter Murray peter.mur...@lyrasis.org wrote: On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues, and I was hoping to get a few other perspectives. For a public interface to a repository and/or digital library, would you make the handle/PURL an active hyperlink, or just provide the URL in text form? And why? My feeling is, making the URL an active hyperlink implies confidence in the PURL/Handle, and provides the user with functionality they expect of a hyperlink (right or option-click to copy, or bookmark). A permanent URL should be displayed in the address bar of the user零 browser. Then, when users do what they are going to do anyway (select the link in the address bar copy it), it will work. ...which is why I intensely dislike Handles and PURLs. Man-up (person-up? byte-up?) and make a long-term commitment to own the URLs you mint with your digital asset management system. Peter -- Peter Murray peter.mur...@lyrasis.orgtel:+1-678-235-2955 Ass't Director, Technology Services
Re: [CODE4LIB] A/B Testing Catalogs and Such
As Nielsen says in a 2005 Alertbox column, Putting A/B Testing in Its Placehttp://www.useit.com/alertbox/20050815.html, a large part of why A/B testing is successful or not comes down to the metric you're measuring to define that success. If there is no agreement on the value of that metric, it's unlikely to get adopted... Examples, however, of where it might work: Consider the suggestion to *add* a second link, or move a secondary link, to check account information on the homepage. If more people click that link (as measured via referrals or JavaScript) than use slower methods to get to the same page, you could win. If you time how long people take before they get to the account page, and it's shorter, then you've another win. But this assumes there's always an alternative to the change that's nearby, or that the user could ignore it if they choose. (E.g. color, left-or-right, spacing, order/ranking, image...) If not, I suggest restricting changes to a smaller subset -- for instance, those logged in to your site. Show certain accounts one thing, and other accounts another. This is especially useful for application functionality changes. You could even pull a Google Labs, if large enough, and allow people to opt-in to certain changes. Placing [x] buttons or collapsable heading arrows serves a similar purpose, and can tell you what features are used or ignored and when, if tracked. Ultimately, A/B testing, outside of advertising conversions, can be rather limited however, unless used in conjunction with other kinds of analysis and remote or local testing. Consider running a survey where participants opt-in to your questions and changes, so they know to expect things to shift around. People like surprises, if they ask for them and feel included in the end result. It's why people (like myself) run beta or dev copies of Google Chrome, so they can try the latest features and forgive you if things break. *Highly recommended reading:* (which I've bought as DRM-free PDFs and you can too!) 1. Driving Technical Change: Why People On Your Team Don't Act on Good Ideas, and How To Convince Them They Shouldhttp://www.terrenceryan.com/blog/post.cfm/i-m-an-author-driving-technical-changeby Terrence Ryan (The Pragmatic Programmers) 2. Clout: *the ART and SCIENCE of INFLUENTIAL WEB CONTENT*http://content-science.com/expertise/clout-the-bookby Colleen Jones (New Riders) 3. Remote Research: Real Users, Real Time, Real Researchhttp://rosenfeldmedia.com/books/remote-research/by Nate Bolt Tony Tulathimutte. However, don't expect much on A/B testing in any of these. As the third book says on page 127, it puts A/B testing (or what the nerds like to call multivariate testing these days) in a context of how to design your research, what tasks to perform, etc. For math, it recommends two books: * * *[By math, it refers to number-crunchy regression/conjoint/factor/quadrant analysis, optimization, or any of the multivariate stuff you learned in AP Calc.]* * * *Measuring the User Experience* by Tom Tullis and Bill Albert (Morgan Kaufmann Publishers) In this book you'll learn all about the kind of data analysis we sheepishly avoid. http://measuringuserexperience.com/ The other book, which goes into fine-grained, advanced automated research techniques is called *Beyond the Usability Lab: Conducting Large-Scale User Experience Studies* by Bill Albert, Tom Tullis, and Donna Tedesco (also tech. ed. for Remote Research). http://www.beyondtheusabilitylab.com/ Both of the above websites together have a ton of resources and examples. Ultimately, however, it's up to you to influence people and processes to improve both content and design in measurable ways. It all seems to come down to politics regardless. Good luck! Louis. On Wed, Jan 26, 2011 at 6:09 PM, Bill Dueber b...@dueber.com wrote: I've proposed A/B testing for our OPAC. I managed to avoid the torches, but the pitchforks...youch! On Wed, Jan 26, 2011 at 5:55 PM, Sean Moore thedreadpirates...@gmail.com wrote: There's a lot of resistance in my institution to A/B or multivariate testing any of our live production properties (catalog, website, etc...). I've espoused the virtues of having hard data to back up user activity (if I hear one more well, in my opinion, I'll just go blind), but the reply is always along the lines of, But it will confuse users! I've pointed out the myriad successful and critical business that use these methodologies, but was told that businesses and academia are different. So, my question to you is, which of you academic libraries are using A/B testing; on what potion of your web properties (catalog, discovery interface, website, etc...); and I suppose to spark conversation, which testing suite are you using (Google Website Optimizer, Visual Website Optimizer, a home-rolled non-hosted solution)? I was told if I can prove it's a commonly accepted practice, I can move forward. So help a guy out, and save me
Re: [CODE4LIB] to link or not to link: PURLs
So that will teach me to post a moderately controversial opinion, then leave to take the kids out for a pizza dinner. I agree with what has been said so far, an in particular with Jonathan's latest e-mail below. Abstraction layers are good. Hiding abstraction layers from users is even better. If the best you can do is an external Handle/PURL set-up, then it is better than nothing. If you have some control and institutional commitment to a URL space -- creating cool URIs [1] to your content, if you will -- then by all means do that. If you can also attempt to future-proof your URL space with something like ARKs [2], then I think it is the best of all worlds. [1] http://www.w3.org/Provider/Style/URI [2] https://confluence.ucop.edu/display/Curation/ARK Peter On Jan 26, 2011, at 6:23 PM, Jonathan Rochkind wrote: What some in this thread are frowning on is having an abstraction layer such that the persistent URL for your web page or resource is not the URL that typical users see in their browser location bar when viewing that resource or web page. If your abstraction layer can make that so, then I don't think anyone in this thread would frown upon it. If your abstraction layer can't make that so... then I personally still agree it's sometimes an appropriate solution, the best trade-off, an acceptable evil. But it's worth spending some time thinking about if you can set it up to do that instead. Some shops have more technical capacity than others. If you are at a shop that can't even do their own apache install, then you are pretty much at the bottom of 'technical capacity' (which isn't an insult, that's where some people are), there isn't much of anything you can do, and you should be telling your vendors that you want them to provide you with software that does it right. That's pretty much all you can do. But STILL requires you to have enough understanding to tell the vendor what 'right' is and know if they've done it or not. If you can't even do that... well, you'll get what you get, so it goes. From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Shearer, Timothy J [tshea...@email.unc.edu] Sent: Wednesday, January 26, 2011 5:45 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] to link or not to link: PURLs Right, they are not the same, which is why I wondered if there was opposition to an abstraction layer in principle. A major problem for institutions who cannot afford to build is that they license systems. Licensed systems are often less than ideal. When an institution is in that scenario it either doesn't have the resources to tweak the system or the system is so closed as to be un-tweakable (or both). So your options, unless I'm missing something, are to stick with the bad urls your system provides, or to invest in an abstraction layer. I realize that the abstraction layer doesn't solve many of the problems (SEO, harvested indexes, user's re-use from the object they are looking at), but it does seem to solve some problems. Published urls (say in Worldcat, Open Library, and elsewhere). Taking advantage of linked data locally when you do have resources (e.g, an enhancing interface that extends functionality, or a preservation layer where a persistent identifier in the form of links would be handy). mod_rewrite assumes Apache, and that you may configure it. So I'm wondering if an abstraction layer is frowned upon in principle (as opposed to specific dislike or PURLS or handles). And, even if it's not ideal, whether it still presents utility, even in less than ideal implementations. -t On 1/26/11 5:09 PM, Robert Forkel xrotw...@googlemail.com wrote: as far as i can see, dislike of handles and PURLs doesn't mean commitment to one system which will work in perpetuity, but only commitment to own one domain in perpetuity. once you commit to that you may create an abstraction/redirection layer with mod_rewrite :) regards, robert On Wed, Jan 26, 2011 at 11:01 PM, Shearer, Timothy J tshea...@email.unc.edu wrote: Peter, are you opposed to an abstraction layer in principle? My reading of your response is that there's an assumption that there is one system and that it will work in perpetuity. We are in the unfortunate but I think fairly common position of having multiple systems, of aspiring to pare that down, and fully expectant that we'll need to migrate at some point even if we find perfection in the near to mid term. Having a link abstraction layer would make those transitions easier on our users, and on the world of linked data in general. Tim On 1/26/11 4:51 PM, Peter Murray peter.mur...@lyrasis.org wrote: On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: At Wed, 26 Jan 2011 13:57:42 -0600, Pottinger, Hardy J. wrote: Hi, this topic has come up for discussion with some of my colleagues,
Re: [CODE4LIB] to link or not to link: PURLs
What a timely discussion. In the morning, Montana State Library will be attempting to answer the question: do we need to continue making permanent URLs to access our state pubs collection? It's not clear to me what the handiness of permanent URLs is. Just tried a PURL from our Montana state pubs collection. What appears in the address bar for bookmarking when the resource is access is NOT the PURL id but the target URL at the Internet Archive? According to a recent post here on a similar topic, John Kunze, the creative developer of ARKs, said for permanency to take place, one needs a reserve access repository in place. So, we set up and maintain PURLS at purl.org for a long-term horizon say 50 years. We setup a reserve repository. We create a bridge table for redirecting our targets from IA to the reserve repository when we need it. If we need the reserve targets, we modify the PURLS at purl.org. It takes two days, which is OK for legacy state publication because the current ones are still online. Are we are good to go for fifty years from now when a move is needed? In the meantime, the reserve repository fails, or purl.org fails, or nothing fails, but URL technology changes or repository technology changes. What we actually need 50 years from now is nothing like we have set up to help us make the transition to reserve repository. So, maintenance of permanency is more than creating permanent URLs, it means keeping up with 50 years of obsolescence. Why not tend to the links in our catalog. Plan in a detailed way to shift to a reserve repository understanding the target links required. Change this plan every time obsolescence rears its ugly head. When the plan is needed, do it. If there are still URLs, generate the new target list and the bridge table from current records if there is still such a thing. Overlay the records and be good to go with whatever actually is needed at the time its need? Say it take 30 days to do this. This would probably be OK for state publications. In the meantime, save time and money creating and maintaining permanent URLs that will be obsolete when we need them. What am I missing?
Re: [CODE4LIB] javascript testing?
Hey Bess, dunno if you're still looking, but a friend just mentioned this project running Jasmine tests headless with EnvJS: https://github.com/trevmex/EnvJasmine. I haven't tried it out or anything, but looks somewhat interesting. On Tue, Jan 11, 2011 at 7:21 PM, Bess Sadler bess.sad...@gmail.com wrote: Can anyone recommend a javascript testing framework? At Stanford, we know we need to test the js portions of our applications, but we haven't settled on a tool for that yet. I've heard good things about celerity (http://celerity.rubyforge.org/) but I believe it only works with jruby, which has been a barrier to getting started with it so far. Anyone have other tools to suggest? Is anyone doing javascript testing in a way they like? Feel like sharing? Thanks! Bess
