[Sigia-l] integrated catalogues?

[Alexander Johannesen]

Hi there,

> For example, anyone here work on the British Library website?

Will the Australian do? :)

> They have
> quite a few catalogues, with separate search interfaces for (and
> different ways of presenting results, different sets of advanced options
> etc etc etc)
>
> Is this a technical limitation?

To some extent, yes, although less and less and technical solutions
mature and gets simpler and faster. There is always the question of
branding in the interest of radiating trust. For example, we have a
huge database of records, but have different interfaces into various
groupings of it; music, journals, etc.

One can argue - and lots do! - that a unified interface gives people
more of explorative information (for example, discovering resources
they didn't expect to find, such as a search on 'Monteverdi' brings up
not just his music but books about him, scores of his music, websites
that specialise in him, etc).

One can also argue, especially in the library world, that we often
serve specialists who look for very specific things. If they're after
an australian journal, they might go to the 'Journals Australia'
interface and expect only to search journals; they don't care that
someone wrote a musical based on the life of Hawkings or that there is
some gossip over there about his MC'ing career.

It's a battle back and forth between giving the user (an educated
guess to) what they want (directed interfaces) and what they want and
more! (federated interfaces).

> Like, each is in a different database
> and so they haven't got around to integrating them....or is there a user
> experience benefit in doing it this way?

Federated searches across databases have come a long way, so it really
isn't as huge a deal as it used to be. I think it now more is about
the focus of the search more than what it can actually do.

For example, "Libraries Australia" search everything we got, and then
some. "Music Australia" search only a (musical) subset of this. In
this is the idea of giving the user both, but how many specialised
interfaces into a common database can you create to make it
maintainable? All of these special interfaces are, indeed, special,
and must be manitained, which is costly.

> Obviously if you're looking for a particular type of content (manuscript
> as opposed to photo) you might expect to use a different search
> interface, but couldn't a drop-down list with several options handle
> this? Or even simply formatting each result record based on the type of
> material it represents?

Again, it's not so much what we can do, but what we *should* do.
Defining user-groups, their importance and how much money it's costing
us to define a special interface for that group, is really what it
comes down to.

> Any thoughts?

Too many. :) I've just scratched the surface. Sometimes we joke around
here that all we really want is a Google that only search *our* stuff,
and it pretty much declines from there.


Regards,

Alex
--
"Ultimately, all things are known because you want to believe you know."
                                                         - Frank Herbert
__ http://shelter.nu/ __________________________________________________