> Why have hundreds of disparate UI instances?
Because diversity is good. Giving libraries the option of designing their own interfaces will allow for greater ingenuity and creativity, which may, in turn, lead to new design ideas that other libraries can adopt.
If libraries are forced to accept only the interfaces that vendors provide, with little more than the option to "brand" it, then we end up with . . . well, the big, ugly, unusable mess we have now.
Why would not want to give libraries the option of building their own UI?
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Dobbs, Aaron [AWDobbs_at_SHIP.EDU]
Sent: Wednesday, June 17, 2009 9:20 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] Preliminary report on user research for eXtensible Catalog
Why have hundreds of disparate UI instances?
The search system provider can handle the generics of the UI with space for libraries to customize branding if desired. Less library bandwidth used (by outside the library users) and greater efficiencies.
The trick is to get the content providers to share their indexing with a content competitor if this competitor also had a popular search system.
E.G.
ProQuest owns SerialsSolutions which offers Summon (a centralized index which points to the various content providers); EBSCO doesn't want to provide ProQuest with EBSCO content indexing (and the reverse, insert many other vendors, etc.) since EBSCO would rather their customers use the soon to be released EBSCO product which does similar things.
-Aaron
:-)'
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Karen Coyle
Sent: Wednesday, June 17, 2009 12:11 PM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] Preliminary report on user research for eXtensible Catalog
As I recall, one of the issues with metasearch was that the searching
itself put a great burden on the vendor systems -- since they received
hits for every search done, even those not terribly relevant to their
topic or offerings. Moving the search out closer to the user, and having
the vendors only do delivery, should be appealing to them. What doesn't
work, IMO, is to replicate this search functionality on hundreds of
different systems. We need a middle man (or two or three) to provide a
robust search function that libraries can then hook into. That search
system can be optimized for search while libraries provide the UI and
the A&I vendors do fulfillment.
? Possible?
kc
Bowen, Jennifer wrote:
> Just to follow up, Jonathan asked me off-list whether we have active
> plans/thoughts about how to get this metadata from scholarly databases
> run by third party companies, and here's how I responded to him:
>
> This is going to have to be a negotiation process with these third party
> companies, and some companies are going to be more receptive to this
> than others, just as some of these companies have been willing to make
> MARC records available for their content in the past, and some have not.
> The rationale to use with the content vendors is that making metadata
> about their content more available through library discovery
> applications is going to increase interest in their products, and that
> this is better technology than metasearch because it doesn't impose
> limits on the number of resources retrieved from their database (such
> as, perhaps, the first 20 in a metasearch query). We need to also
> reassure vendors that we are building technology that will address their
> requirements, such as limiting access to the content itself to paid
> subscribers.
>
> Obviously, this is going to take some effort to get a significant number
> of content providers on board. Libraries that use XC and that subscribe
> to this content are probably in the best position to make a case for
> access to the metadata at the point when they are negotiating contracts
> - we can't really do it for them. We see this as one activity that
> could be coordinated by the not-for-profit organization that we are
> forming to support users of the XC software.
>
> Jennifer
>
> -----Original Message-----
> From: Bowen, Jennifer
> Sent: Wednesday, June 17, 2009 10:10 AM
> To: 'Jonathan Rochkind'; Next generation catalogs for libraries
> Subject: RE: [NGC4LIB] Preliminary report on user research for
> eXtensible Catalog
>
> XC's architecture is based upon aggregating metadata, and we are
> building a robust platform that will perform this aggregation, called
> the XC Metadata Services Toolkit (MST). This open source software will
> support metadata from scholarly databases as well as from library
> catalogs and repositories. We believe that this is a much more
> promising direction for future discovery interfaces than relying upon
> metasearch technology, although the two approaches may need to be used
> alongside each other in the shorter term. We just don't see a promising
> future in continuing to develop new software that uses metasearch
> technology.
>
> Jennifer
>
> -----Original Message-----
> From: Jonathan Rochkind [mailto:rochkind_at_jhu.edu]
> Sent: Tuesday, June 16, 2009 10:21 AM
> To: Next generation catalogs for libraries; Bowen, Jennifer
> Subject: Re: [NGC4LIB] Preliminary report on user research for
> eXtensible Catalog
>
> One of the things that stuck out to me in the report was user's
> confusion about whether they could find articles in the catalog, as well
>
> as user's unhappiness with having to learn new interfaces for additional
>
> scholarly databases.
>
> Are you considering trying to address the scholarly database issue with
> some kind of federated broadcast search, aggregated index, or other
> means of attempting to integrate scholarly article results in the main
> interface?
>
> Jonathan
>
> Montibello, Joseph P. wrote:
>
>> Jennifer,
>>
>> Thanks so much for sharing this useful and very interesting report
>>
> with the community. We talk so much about how we need to know what the
> users need. As you say in the report, this is not a comprehensive,
> end-all be-all type of report, but it answers a few questions and
> prompts even more.
>
>>
>> Cheers!
>> Joe Montibello
>> Class of 1945 Library
>> Phillips Exeter Academy
>>
>> ----------------------------------------------------------------------
>>
>> Date: Mon, 15 Jun 2009 14:08:48 -0400
>> From: Jennifer Bowen <jbowen_at_LIBRARY.ROCHESTER.EDU>
>> Subject: Preliminary report on user research for eXtensible Catalog
>>
>> (Posted on behalf of Nancy Fried Foster,
>>
> nfoster_at_library.rochester.edu)
>
>> The eXtensible Catalog project at the University of Rochester's River
>>
> Campus
>
>> Libraries is pleased to release the first report on the user research
>>
> that
>
>> we conducted in support of XC software development. We thank the
>>
> Andrew W.
>
>> Mellon Foundation and our user research partners - Cornell, Ohio
>>
> State, Yale
>
>> and the University of Rochester - for their generous support of this
>>
> project.
>
>> Use this URL - http://hdl.handle.net/1802/6873 - for a report that
>> summarizes the objectives, methods, and major software design findings
>>
> from
>
>> the data collected in the user research portion of the eXtensible
>>
> Catalog
>
>> (XC) project. A full analysis and interpretation of the data is not
>>
> included
>
>> in the present report and will be provided at the conclusion of the
>>
> project.
>
>> This report includes edited results from the brainstorming sessions
>>
> and a
>
>> list of the features that emerged from the analysis of those results.
>>
> (See
>
>> the eXtensible Catalog website at www.eXtensibleCatalog.org for more
>> information about the overall
>> project.)
>>
>>
>>
>
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Wed Jun 17 2009 - 18:22:27 EDT