Browse functionality (was Whose elephant is it, anyway? (the OLE project))

I'm intrigued by the aspects of index browsing. I did some user testing (with a very small group) during an OPAC redesign some years ago, and concluded that index browse functionality was a great way of providing access to authors/editors (and actors/directors for films, composers/performers for music), journal titles and classmarks, but that most other browse functionality was not useful in the context we were working.

I can see an argument for subject browsing, but the testing showed that the users either didn't use it, or didn't understand it when they did use it.

From the discussion so far, and also a recent statement by Bernhard in the 'What do users understand' thread when he says "LCSH makes sense only when presented as an alphabetical list for browsing."- it seems to me that browse is not necessarily a single function across all different types of index.

Specifically subject browsing is different - or perhaps subject browsing LCSH is different. From what James says presenting LCSH as an alphabetical index doesn't actually make sense - it simply overwhelms the user with redundant information (I think I agree, and I think this explains the findings in the user testing I describe above)

I wonder - can anyone point me at (a) studies of user index browsing behaviour in the context of web based searching, (b) methods of helping users navigate a structured taxonomy or thesaurus?

Thanks,

Owen

Owen Stephens
Assistant Director: eStrategy and Information Resources
Central Library
Imperial College London
South Kensington Campus
London
SW7 2AZ
 
t: +44 (0)20 7594 8829
e: o.stephens_at_imperial.ac.uk

> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Bernhard Eversberg
> Sent: 12 March 2009 14:45
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] Whose elephant is it, anyway? (the OLE project)
> 
> Stephens, Owen schrieb:
> >
> > Just to understand what you are looking for in terms of Browse. The
> NLA implementation of VuFind has what I would regard as a Browse
> function - you can Browse the following:
> >
> > Names at http://catalogue.nla.gov.au/Browse/Names?browse=names&from=
> > Subjects at
> http://catalogue.nla.gov.au/Browse/Subjects?browse=subjects&from=
> > Callnumbers at
> http://catalogue.nla.gov.au/Browse/Subjects?browse=subjects&from=
> > Series at
> http://catalogue.nla.gov.au/Browse/Series?browse=series&from=
> >
> > Is this browsing as you mean it? If not, what would you require
> additionally?
> >
> Yes indeed! I'd say make the space narrower between the lines so you
> see
> more of it at once, but the way it works is just what I mean.
> 
> > (also you question the scalability - what scale are you thinking of?
> How it is affected by the physical growth of the data. Does it get
> slower with every million data, and how much?
> How long is it to create the index? Is real-time updating possible?
> Or overnight only? How many hours per million records for a complete
> re-index? Does this time grow linearly or exponentially?
> 
> 
> This discussion has showed again that the term "browsing" is not
> well enough understood or defined. Therefore, I said "index browsing"
> all the time and "browsable index", to distinguish it from browsing
> a list of records. The latter is always a subset and it is always
> the result of a guess really. Or two: the user first guesses what
> terms might be the best to use, then the machine makes some sort of a
> "guess", but in a much different way, what records might match the
> query. The machine's guess is opaque, but the user takes it at face
> value and then browses this list, not seeing anything that has narrowly
> escaped the machine's guess, and the larger the set is, the less likely
> will they make another attempt or think about the appropriateness of
> their initial guess. This whole business is, I think, not well enough
> understood. Who, if not our profession, should understand it in a
> thorough way, and wouldn't that require a clear agreement about the
> terms we use?
> 
> 
> B.Eversberg