Federated search products and Full Text/PeerReview limiting

It sounds like the work of determining if the Library has
access to an item before the link is displayed could and
should be extended to provide such information as:
The call number of a book, if the library has it.The link to
a pre-filled ILL request form ONLY if the library does not
have it.The exact location of the bound volume needed (enter
RFID & GoogleMaps mashup)A GoogleMaps mashup of other
libraries in the area who have the item (book or journal or
otherwise)Link to Amazon.com to order the book IF the
library doesn't have it I agree that our clients'
experience with our link resolver suggests that when the
link resolver's Web page appears, instead of article or
even the journal Web site, the search is over. That page is,
effectively, a dead-end.  That is why we are seriously
considering another link resolver which behaves slightly
differently: if it cannot resolve the link to the article or
issue level, it will send the user to the vendor's site. 
Even if they have to navigate the site to get to the
article, we surmise that this would be considered more
successful than seeing the "dead-end" page. 
True, the actual single-click-to-full-text success rate of
the resolver under consideration is, indeed, better than the
one we're using now; but I really think we would still
consider them even if that rate was the same.  The users'
overall experience is better if they do not see that page. 
 
My conclusion then is, if we can let the user know the exact
status of obtaining each citation at the exact point of
need, their experience with the Library would improve.  
 
Which leads me to what I was originally going to ask Roy: 
more details (about their project), please....
 
 
 
Karen R. Harker, MLS
UT Southwestern Medical Library
5323 Harry Hines Blvd.
Dallas, TX  75390-9049
214-648-8946
http://www.uts
outhwestern.edu/library/

>>> "David Walker" <dwalkercsusm.edu> 4/18/2006 2:48:51 PM >>>


>> Encouraging this behavior would encourage the 
>> students to ignore anything that is not easily
available

I understand your concern here, Karen.  I think libraries
need to seek
out opportunities to encourage students to look for the best
resources,
rather than just those that are easiest to get.  That's
important to
good research.

But I think Ross and Roy are entirely right here.  Forcing
users to
click on a link resolver button for each search result just
to determine
that item's availability does little or nothing to
encourage users to
look for the most appropriate resources.  It simply
frustrates them.

Likewise, we have to view each interaction with the library
as an
opportunity to win-over our users.  If our systems are not
easy-to-use,
our users have an increasing number of other places they can
go.

We need to meet students where they are, and design
metasearch and other
systems to better meet their goals and behavior.  Once
we've got them
hooked on using the library, we can, through instructional
sessions and
in reference encounters, encourage them to get beyond
immediate
full-text only.

But it has to be a carrot rather than a stick.

--Dave




-----Original Message-----
From: web4lib-bounceswebjunction.org
[mailto:web4lib-bounceswebjunction.org] On Behalf Of Karen Harker
Sent: Tuesday, April 18, 2006 11:43 AM
To: web4libwebjunction.org
Subject: Re: [Web4lib] Federated search products and Full
Text/PeerReview limiting

However, using such visual cues as the appearance (or
non-appearance) of
the link resolver button/link could only further the
reliance on
full-text. Encouraging this behavior would encourage the
students to
ignore anything that is not easily available, causing them
to miss a
still rather large segment of literature and information.



Karen R. Harker, MLS
UT Southwestern Medical Library
5323 Harry Hines Blvd.
Dallas, TX  75390-9049
214-648-8946
http://www.uts
outhwestern.edu/library/

>>> Roy Tennant <roy.tennantucop.edu> 4/18/2006 1:24 PM >>>

On Apr 18, 2006, at 9:52 AM, Dale Askey wrote:

> Besides, if you have a good link resolver, why limit to
full text  
> results? Just slap a link resolver button on each
result, and that  
> problem is largely solved.

I disagree strongly with this position. Slapping a link
resolver  
button on each search result does little to help the user
focus on  
only content that is available in full-text. Expecting the
user to  
successively click on a link resolver button for each and
every  
result, not knowing what they can expect, strikes me as
particularly  
user-hostile. Realizing this, places like the University of 

Rochester, CSU San Marcos, and now soon us at the California
Digital  
Library, are developing services that will do a lookup to
the OpenURL  
resolver _before_ putting the search results up, so we can
depict  
whether an item is available in full-text or not (with a
link direct  
to the source).

Even better would be to have the ability to limit search
results to  
full-text resources, but as has been said here that is still
 
difficult and often out of our hands (vendors need to
support it). So  
no, the problem is far from solved, at least from the
perspective of  
good user service.
Roy
_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/


_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/


_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

On Apr 18, 2006, at 2:27 PM, Karen Harker wrote:

> My conclusion then is, if we can let the user know the
exact status  
> of obtaining each citation at the exact point of need,
their  
> experience with the Library would improve.

Bingo.

> Which leads me to what I was originally going to ask
Roy:  more  
> details (about their project), please....

What we are attempting to do is to use the ability of SFX to
accept  
multiple OpenURLs in one resolving request to do a lookup
before  
sending search results to the user interface. Since we
haven't been  
able to get this to work yet, we are presently trying a
work-around  
in which we send multiple requests. This is of course not
optimal,  
but until we get a fix it will have to do. Luckily, our
initial load  
should be relatively slight to begin with. I do not have
anything  
publicly available to show yet, although we are getting
close to an  
early alpha prototype.
Roy
_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

People certainly had fun with my suggestion to slap a link
resolver 
button on federated search results. A couple of comments:

1 - Hey, in many instances, it would be an improvement over
offering 
nothing. I agree with everyone's criticisms, particularly
Ross's 
arguments about blind alleys, but one has to start
somewhere.

2 - Unless talented library programmers/developers such as
Ross and 
David Walker can clone themselves, or unless we're all
suddenly blessed 
with the development capacities of the CDL, the more exotic
features 
you're describing need to be a whole lot easier to
implement (say, 
integrated into the vendor's product, ideally). There's a
reason why the 
rest of us salivate when we see Cal State San Marco's SFX
installation, 
but it's not something that libraries of all sizes can just
do without a 
lot of assistance.

To that end, I would ask who out there has documented their
extensions 
and modifications to a link resolver to do some of the
things described 
in this thread. If we're going to declare a service
standard, we need to 
share the love, don't we?

Dale

Roy Tennant wrote:
> On Apr 18, 2006, at 2:27 PM, Karen Harker wrote:
> 
>> My conclusion then is, if we can let the user know
the exact status of 
>> obtaining each citation at the exact point of need,
their experience 
>> with the Library would improve.
> 
> Bingo.
> 
>> Which leads me to what I was originally going to
ask Roy:  more 
>> details (about their project), please....
> 
> What we are attempting to do is to use the ability of
SFX to accept 
> multiple OpenURLs in one resolving request to do a
lookup before sending 
> search results to the user interface. Since we haven't
been able to get 
> this to work yet, we are presently trying a work-around
in which we send 
> multiple requests. This is of course not optimal, but
until we get a fix 
> it will have to do. Luckily, our initial load should be
relatively 
> slight to begin with. I do not have anything publicly
available to show 
> yet, although we are getting close to an early alpha
prototype.
> Roy
> _______________________________________________
> Web4lib mailing list
> Web4libwebjunction.org
> http://lists.we
bjunction.org/web4lib/
> 

-- 
Dale Askey
Web Development Librarian
KSU Libraries
118 Hale Library
Manhattan, KS 66506
(785) 532-7672
_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

On 4/21/06, Dale Askey <daskeyksu.edu> wrote:
> 2 - Unless talented library programmers/developers such
as Ross and
> David Walker can clone themselves,

I think I can speak for David as well as myself when I say
"be careful
what you wish for".

> or unless we're all suddenly blessed
> with the development capacities of the CDL, the more
exotic features
> you're describing need to be a whole lot easier to
implement (say,
> integrated into the vendor's product, ideally).
There's a reason why the
> rest of us salivate when we see Cal State San Marco's
SFX installation,
> but it's not something that libraries of all sizes can
just do without a
> lot of assistance.

I cannot agree with this more.  This is a /huge/ problem
with our
current slate of software options.

>
> To that end, I would ask who out there has documented
their extensions
> and modifications to a link resolver to do some of the
things described
> in this thread. If we're going to declare a service
standard, we need to
> share the love, don't we?

This is a good point, and, Dale, I'd be willing to work
with you on
such an endeavor.  In fact, in a presentation I'm going to
give in 40
minutes, I'll mention how I've been horribly remiss at
contributing
/any/ documentation for what I'm talking about (despite
complaining
about the lack of documentation available).

Is this something appropriate for the Library Success Wiki
(or whatever it is)?

Also, in regards to link resolvers in general...  I would
like to
suggest that we build a microformat for the link resolver
results
menu.  Not everyone has a link resolver that outputs XML,
but with a
microformat, that wouldn't be necessary and it would allow
people to
include the output of their resolver menu in other places.

-Ross.
ps. due to flaky internet connectivity, that presentation
was actually
about 2 hours ago.  And, yeah, I mentioned just this.

>
> Dale
>
> Roy Tennant wrote:
> > On Apr 18, 2006, at 2:27 PM, Karen Harker wrote:
> >
> >> My conclusion then is, if we can let the user
know the exact status of
> >> obtaining each citation at the exact point of
need, their experience
> >> with the Library would improve.
> >
> > Bingo.
> >
> >> Which leads me to what I was originally going
to ask Roy:  more
> >> details (about their project), please....
> >
> > What we are attempting to do is to use the ability
of SFX to accept
> > multiple OpenURLs in one resolving request to do a
lookup before sending
> > search results to the user interface. Since we
haven't been able to get
> > this to work yet, we are presently trying a
work-around in which we send
> > multiple requests. This is of course not optimal,
but until we get a fix
> > it will have to do. Luckily, our initial load
should be relatively
> > slight to begin with. I do not have anything
publicly available to show
> > yet, although we are getting close to an early
alpha prototype.
> > Roy
> > _______________________________________________
> > Web4lib mailing list
> > Web4libwebjunction.org
> > http://lists.we
bjunction.org/web4lib/
> >
>
> --
> Dale Askey
> Web Development Librarian
> KSU Libraries
> 118 Hale Library
> Manhattan, KS 66506
> (785) 532-7672
> _______________________________________________
> Web4lib mailing list
> Web4libwebjunction.org
> http://lists.we
bjunction.org/web4lib/
>
>
_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

I've been away and am just catching up on this interesting
thread. One added
point to the issue of links to titles that aren't
available.  It would be
nice if the stats packages from the resolver vendors
included a list of
unavailable journals with data on how often they were
requested and what
years were needed. That would give libraries a chance to do
something about
the turnaways.

Given that resolver use will never be a complete picture of
journal use,
data on what's not found really would be more useful than
the data most
resolvers now provide on what was found, though adding that
useful feature
would make life harder for the salespeople who could no
longer just say "and
of course we're fully COUNTER compliant" and go on to
something more
interesting.

- Jim Campbell
CampbellVirginia.edu

_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/