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 wrote: > Can anyone

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 pu

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.

Re: [CODE4LIB] A/B Testing Catalogs and Such

As Nielsen says in a 2005 Alertbox column, Putting A/B Testing in Its Place, 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

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 do

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 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...

[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 alw

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 eit

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

Re: [CODE4LIB] to link or not to link: PURLs

On Wed, Jan 26, 2011 at 5:11 PM, Jonathan Rochkind 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 wha

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 element has been > catching on with any other tools? Will any browse

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 a

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, 20

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

Re: [CODE4LIB] to link or not to link: PURLs

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 element has been catching on with any other tools? Will any browses, delicious extensions, etc., bookmark that, or offer the option to

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 wrote: > On Jan 26, 2011, at 3:24 PM, Erik Hetzner wrote: >> >> At Wed, 26 Jan 2011 13:57:42 -0600, >> Pottinger,

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 d

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 h

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 functiona

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. wrote: > Hi, this topic has come up for discussion with some of my colleagues, and I > was hoping to get a few other

[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

[CODE4LIB] Congratulations Seattle!

FWIW, I posted the news that the Seattle proposal to host Code4Lib 2012 had been accepted by popular acclaim in the face of no other proposals and the strength of their submission: See you all in Seattle in 2012! Roy

[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 ! T