 |
 |
> in order to provide decent user experience you need to be > able to present some results "sooner" than others. I would actually question whether this is really necessary. A few years back, I did a big literature review on metasearch, as well as a looked at a good number of usability studies that libraries did with metasearch systems. One thing that stood to me out was that the literature (written by librarians and technologists) was very concerned about the slow search times of metasearch, often seeing it as a deal-breaker. And yet, in the usability studies, actual students and faculty were far less concerned about the search times -- within reason, of course. I thought the UC Santa Cruz study [1] summarized the point well: "Users are willing to wait as long as they think that they will get useful results. Their perceptions of time depend on this belief." Trying to return the results of a metasearch quickly just for the sake of returning them quickly I think introduces other problems (in terms of relevance ranking and presentation) that do far more to negatively impact the user experience. Just my opinion, of course. --Dave [1] http://www.cdlib.org/services/d2d/metasearch/docs/core_ucsc_oct2004usability.pdf ================== David Walker Library Web Services Manager California State University http://xerxes.calstate.edu ________________________________________ From: Code for Libraries [[log in to unmask]] On Behalf Of Kuba [[log in to unmask]] Sent: Tuesday, May 18, 2010 9:57 AM To: [log in to unmask] Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts That is quite unfortunate, as we were looking at SRU 2.0 as a possible candidate for the front-end protocol for Index Data's pazpar2. The main problem with federate/broadcast/meta (however you want to call it ;) searching is that the back-end databases are scattered in different locations or simply slow in their response times and in order to provide decent user experience you need to be able to present some results "sooner" than others. Waiting for the slowest database to respond is usually not an option. On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress <[log in to unmask]> wrote: > On 18 May 2010 15:24, Ray Denenberg, Library of Congress <[log in to unmask]> > wrote: >> There is no synchronous operation in SRU. > > Sorry, meant to say "no asynchronous ..... > > --Ray > -- Cheers, Jakub