At risk of revealing my advanced years and stating the obvious (at least
to those of us old enough to have been around "way back when"), Nathan
is correct. In the 1970s and early 1980s, I filed cards in a
departmental library at Yale. We did not file them in strict alpha
order; rather, punctuation within the headings on the cards (e.g., "--"
filed very differently than ",") was as determinative as the surrounding
alpha strings that the punctuation demarcated. Indeed, when we received
"sorted" packets of cards generated by RLIN, we actually had to begin by
*re-sorting* them to reflect the influence of the embedded punctuation,
before we could then file them in the catalogue. If memory serves, it
was a local adaptation based on (1941?) ALA filing rules. I'm sure
there are at least a few others on who will be able to correct/amplify
my memory.
It was somewhat difficult to teach this scheme, not only to our users,
but even to our filing staff. But once you "got it", it seemed logical
and enormously powerful. Moving to the strict alpha order of automated
environments seemed a huge step backward for anyone who understood this
filing order.
It was, in essence, the card-based analogue of today's faceted
discovery. Only in some ways, it was even better, because the facets
actually had a logical, hierarchical order about them. I'm sure that
someone who wanted to do so could express these in today's expandable
facets very elegantly.
cheers,
- mt
Rinne, Nathan (ESC) wrote:
> Qwen said:
>
> "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)"
>
> Owen, LCSH as an alphabetical index doesn't make sense *to most* as it
> is now, *but perhaps it could* if you had lists that contained
> expandable terms like the "World War, 1939-1945 +" idea Jim offered.
> That way, World War, 1939-1945 would not take up 25 screens, for
> example, in the index browse of your catalog [25 screens will only get
> you up through " World War, 1939-1945--Campaigns--Russia
> (Federation)--Murmansk." In the LC catalog :)]), but would just be
> reduced to one [expandable] term in such a list (initially at least).
>
> ~Nathan
>
>
>
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Stephens, Owen
> Sent: Thursday, March 12, 2009 10:29 AM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: [NGC4LIB] 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
>
>
--
*************************************************************************
Marc Truitt
Associate Director,
Bibliographic and Information Voice : 780-492-4770
Technology Services e-mail : marc.truitt_at_ualberta.ca
University of Alberta Libraries fax : 780-492-9243
Cameron Library cell : 780-217-0356
Edmonton, AB T6G 2J8
*************************************************************************
Received on Thu Mar 12 2009 - 13:30:35 EDT