The Library Website as Place

Unexplored Map, Greenland
I spend a fair amount of time thinking about the relationship between the Libraries’ website and our physical presence. Much has been written about “the library as place” – a quick Google Scholar search brings up plenty of interesting material – and I am in strong agreement with those who suggest that library-as-place remains an important and useful thing for scholars, students, and citizens of all sorts, even in this digital age. But our website serves as our front door for a rapidly increasing percentage of users, and it needs to be at least as welcoming, as professional, and as helpful as our physical entry points are.

The metaphor of a website as “a place” dates back to the early days of the Internet. I still remember talking to a friend who was a very early adopter of AOL, around 1990 – this was before AOL was technically part of the Internet, but bear with me – and  being both confused and intrigued by her description of meeting someone via AOL and “following him from one room into another” online. (They eventually got married and have been together ever since, so stop laughing!)  Chat “rooms” were one of the earliest forms of social media; even the term “website” suggests a physical site or location; we still talk about “going to” a web page as if we were physically moving from one place to another; we refer to a website’s menu structure as “navigation.” We also talk about web “pages,” but overall, the most common metaphors for online presence are geographic rather than bibliographic.

So it seems to me that it’s not unreasonable to think of our website as a place, and to present it to our users as such. Some writers have discussed this concept specifically in regard to library websites, including Pomerantz and Marchionini and Gerke and Maness. The latter pair, in particular, note that “cross-channel experience consistency” between a library’s physical and electronic spaces can affect the user’s satisfaction (as measured via LibQUAL). This is the direction in which I’ve been thinking.

It means small things, like: if you have a big sign over the reference desk that says “ASK QUESTIONS HERE” but no sign that says “REFERENCE,” your website should probably direct people to the Ask Questions Here desk rather than the Reference desk. (Kind of like the gas station I frequent that says to “push the START button” but then there’s no button labeled START… just one that says PUSH HERE. You’d have to be a little dense not to be able to figure that one out, but for most people, using the library is more complicated than pumping gas!) And maybe, in that case, it makes more sense to label your chat-reference service as “Ask Us” rather than “Virtual Reference” – so that users recognize it as the same sort of service they access in person.

Consistency also means something bigger than labeling; for example, consistency of service. If you expect professional, knowledgeable answers from librarians at the reference desk, you should also expect the same level of service from whoever staffs your chat-reference system. While nobody expects polished, perfectly minted sentence structure in the context of chat reference, responses that are completely riddled with typos and misspellings can make the patron wonder whether the content of the answer is equally questionable – just as a friendly, business-casual librarian saying “How can I help you?” at the reference desk is more confidence-inspiring than someone wearing a ripped t-shirt and flip-flops, chomping gum and greeting patrons with “Yeah, whassup?” A library’s website, likewise, needs to be confidence-inspiring in the same way that the library itself is. A public library may find it most important to be welcoming and to present itself as a comfortable, fun place to spend time; an academic library may place more importance on the extent of its scholarly collections and its understanding of the research process. In either case, the website should probably reflect a similar attitude.

I could go on, talking about branding and other considerations, and noting that it can be useful to think of the library website as a digital branch library of sorts. But most of that is fairly common-sense; your website and your physical facility represent the same organization, so of course there should be a certain degree of consistency between the two. Though I don’t have data to support this (yet) I would venture to say that, at least in the case of the IUB Libraries, most of our patrons use both the website and the physical facility at some point. (For the purpose of this statement, by “website” I mean the Libraries’ website, IUCAT, and to a lesser extent our subscription electronic resources, though we have far less control over the user experience offered by our subscription resources.) Most patrons’ needs are not completely satisfied with one or the other; most need both at some point.

While there are commonalities in the reasons users visit both physical site and website – they’re usually looking for information to support their research – there are also differences in the reasons they visit and in their expectations of what they will be able to do once they arrive. While the website and the physical facility should be consistent with one another, they should also complement one another. This is both more complex and, honestly, more interesting. What does the conversation between the website and the building look like? How do users go back and forth between the two experiences? People definitely still want physical books for many purposes; my experience at the reference desk is that, when someone is looking for a book, they often tell me that the e-book is less desirable to them. (Is this equally true of website visitors? I don’t know.) How do researchers navigate – oh, those geographical metaphors again! – between the Libraries’ physical facilities and resources, and our website and its resources? And how does the way in which these resources are presented to them influence the shape and course of their research?

Interesting questions, which I’m just beginning to ask myself. I hope to do some further reading and perhaps eventually some research and maybe begin to formulate some answers. Meanwhile, I’ve just read an article about “The Library as a Map” that has me thinking about the dialogue between digital and analog materials, and wondering how a library website can best support that dialogue – or perhaps it’s better viewed as a travelogue. Traditionally, online search is easiest when users are seeking a known item, but discovery systems like OneSearch@IU (see Courtney Greene’s blog post introducing it) are beginning to expand our capabilities. Even with a discovery tool, though, many users – in my experience, particularly those in the humanities – prefer the physical browsing experience because it offers the possibility of discovery via serendipity. How can we improve the online experience for these users – not to replace the physical library, but to complement it? I’m intrigued by Megan Shaw Prelinger’s suggestions:

What I really see being needed is a way for query-based search to mimic the kinds of associative links that are formed by shelving different kinds of literature next to one another on a shelf. What if, when you typed in a search term, your result was a color-coded cloud of virtual book covers.

In the cloud, covers highlighted in one color would represent the straight response to your search query. Jackets highlighted in other colors, floating behind them, could follow any of hundreds of other associations. Perhaps you could select a half-dozen supplemental associative searches from a list before you begin your search. Then you see a layer behind your straight result that’s composed of satires, or other works by the same author, or public records that relate to your search term—or every work that’s cited within a given book’s bibliography! Features like those would inject intense excitement into digital search.

Search features like the one described here might work best for collections more limited than those offered by a major research library like ours; our collections are just so vast that it would not always be easy to make useful suggestions. But for browsing within a particular subject area or collection, it would be pretty interesting. I love the idea of fostering a useful dialogue between analog and digital resources, something more complex and more supportive of discovery via serendipity than a simple catalog or finding aid. Including pointers to analog resources within digital discovery tools, like the inclusion of IUCAT records in OneSearch@IU, is a good start. I’m interested in exploring how geographical metaphors, like “library as map,” can help us understand how to encourage and improve this analog-digital dialogue. If you have thoughts, please leave a comment on this post!


Gerke, Jennifer and Jack M. Maness. “The Physical and the Virtual: The Relationship between Library as Place and Electronic Collections.” College & Research Libraries, Vol. 71 No. 1 (2010): 20-31.

King, David Lee. “Chapter 1: What Is a Digital Branch, Anyway?” Library Technology Reports, Vol. 45 No. 6 (2009): 5-9.

Pomerantz, Jeffrey and Gary Marchionini. “The Digital Library as Place.” Journal of Documentation, Vol. 63 No. 4 (2007): 505-533.

Prelinger, Rick and Megan Shaw Prelinger. “The Library as a Map.” Contents Magazine, Issue 5 (2013).


Tagxedo, a Word Cloud Program

I’ve recently been using various word cloud programs to analyze interactions from our online chat service and reference desk log. I’ve been comparing word clouds from different points in the semester to find trends or anomalies in the questions being asked at both service points.

After exploring many different types of word cloud programs, I’ve found Tagxedo to be a favorable option for the flexibility in design and the ease of file creation.

The homepage includes several options for creating a word cloud. For this example, I decided to analyze the content of this blog, so I put the link in the (1) field.

For past projects, I had a text file full of words, so I clicked the “start now” link and was able to copy and paste those words into a blank text box.

After the cloud is initially created, there are numerous design options of the left sidebar. This includes color, theme, font, orientation, and layout. The cloud can also be morphed into various shapes, like an apple or word bubble.

Through the “Layout Options” link, the user can find a count of the most common words and choose to exclude any of those words from the cloud. I excluded a few words, such as ‘www’ and ‘edu’ from the following cloud.

After the cloud is finalized, the user can export the file in various sizes and as a .jpg, .png, or imgur.

Blacklight and Stemming

With the coming transition of the IUCAT public interface from the existing SIRSIDynix OPAC to the new Blacklight discovery layer there are a lot of exciting new features coming our way. Some examples include faceted searching, better results, an easier to use interface. Along with the change in the interface, we will see changes in how search works. One of these changes relates to truncation and word stemming.

Truncation is the ability to expand a keyword search to retrieve multiple forms of a word by using a specified symbol to replace a character or set of characters. The truncation symbol can typically be used anywhere within a word: at the end, beginning, or within a term. For example in the current IUCat a search for comput$ would find words such as:  computer, computers, computing, and computation. Truncation is a handy tool that can help bring back a lot of different results and it is a common search feature in most traditional OPACs and in many vendor databases. Blacklight, like other discovery layer interfaces such as VuFind, relies on a technique called word stemming rather than on truncation.

Word Stemming is when the catalog searches for the “root” of a word and displays all words with that stem. Rather than relying on the searcher to place a specific character to expand the search as in truncation, the use of word stemming initiates an automatic search for the “root” of a search term, then returns results with all words associated with that stem. This is similar to how Google searches, so users who use Google a lot won’t notice much of a difference.

Because this is an automatic process, oftentimes it is difficult or impossible to know or predict the “stem” terms for any particular word. For example, knees has a stem of knee, but kneel has a stem of kneel not knee. Another example of stemming is when you type the word “searching” or “search” or “searches” you’ll find they all stem to “search”. But “searcher” does not; it stems to “searcher”.

For searchers who are accustomed to truncation, there may be similar terms that would have been retrieved using truncation, but which will not be retrieved using word stemming because they do not share the same stem.

For many of our users, this change will not be apparent, but we hope this is a helpful explanation of this change for expert searchers accustomed to relying on truncation.

Discovery services in a Google world

Pete Coco’s recent post on the ACRLog discusses the ups and downs of discovery projects like EBSCO Discovery Service, a tool recently implemented at the IU Libraries as OneSearch@IU.  Coco writes that these tools may look like Google, with their sleek white single search bars and straightforward interfaces.  They may even act a little like Google, crawling through thousands upon thousands of resources to bring you only the most relevant, most perfect source you could possibly imagine.  Right?  Well, not quite.   According to Coco, who is a humanities liaison and library instructor at Wheaton College, although his students are usually able to find something using these discovery tools, they are not always able to find the thing.  One reason for that could, of course, be unreasonable student expectations.  Students often suppose that their sources must iterate their perspective verbatim, or cover the exact parameters of their research question.  Of course they’re not going to find a source comparing the ironic symbolism in Franz Kafka’s Before the Law with J.K. Rowling’s Harry Potter and the Sorcerer’s Stone.  Some things just don’t exist.  That said, student misconceptions about scholarship might not be the only issue at play.  While discovery services, acting as a sort of hybrid between Google and academic databases, are good for getting students into the research pool, often it leaves them in the shallow end.  Once students understand the scope of what’s available, more specialized databases might be just the ticket to finding the thing and giving students that tough-love push into the deep end of scholarship.

That is precisely why quality information literacy instruction is still a necessity in academic libraries – to help students find their scholarly legs in a strange new land of information.  In order to achieve that end most effectively, perhaps we should be emphasizing the differences between popular and scholarly modes of information gathering, rather than the similarities.  Despite OneSearch@IU’s outward resemblance to Google, the fact is that it is not Google, and we are not doing students any favors by marketing it as such.  Coco writes:

To find the scholarly articles that will meet the paper requirement, the student will need navigate a host of alien concepts, vocabularies and controversies that will, at least at first, drive his experience with peer-reviewed scholarship. And while some degree of anxiety is probably useful to his learning experience, there can be little doubt that the process would be easier and of more lasting value to the student who has support—human support—as he goes through it.

Advances in technology require more, not less, pedagogical attention to ensure that students comprehend the underlying structures of scholarly communication.  We often expect this generation of tech-savvy undergraduates to see a blank search bar and know what to do with it.  But the reality is, not all search bars are equal.  Effective library instruction serves to illuminate the unique function of academic databases and discovery services as compared to popular search engines.  After all, if what you want is Google, you can always go to Google.

Aside: Read this post by Margaux DelGuidice from In the Library with the Lead Pipe to see why librarians are oh-so-glad that discovery services are not Google.

Photo credit: Opening of Lincoln Park swimming pool 1925, courtesy Seattle Municipal Archives from

Music to our eyes: special considerations for discovery

We’ve written a bit about in this blog about discovery, and specifically about Blacklight, which will be implemented as a new interface for IUCAT next summer. One particularly interesting possibility opened up by discovery interfaces like Blacklight is the ability to create customized search views based on a variety of criteria – by format (like music, or film & video), or location (a specific campus), to name just two.

You can see an example of this in action at UVA – they have both a music view and a video view. In the music search, users have the ability to limit using both the standard facets, like language, and by facets specific to the subset of materials, like instrument – as illustrated below.

As you might imagine, with the ability to provide customized search interfaces come many important decisions about what data to index and display, and how to best to do so to fully optimize discovery.  Our colleagues in the Cook Music Library & the Digital Library Program have been engaging with these questions for some time through the Variations/FRBR project, one deliverable of which – the Scherzo search interface – is powered by Blacklight.

Last week, a subgroup of the Emerging Technologies committee of the Music Library Association released a draft document on Music Discovery Requirements, which can be found at – they are inviting public comment on the document through December 5th, and anticipate releasing a second draft early in the new year.

I hope those of you with expertise in this area will review and comment on the draft document, and we also invite comments and questions on the topic of optimizing discovery of music records here.

More about Blacklight, the new interface for IUCAT

Since the last post about Blacklight, we’ve been asked a lot of questions about Blacklight and its development in IU Libraries. Those of you who missed reading it might want to check here. This post will focus on some of the questions that we have been asked most frequently.

What sorts of changes will there be in the new IUCAT?

People involved in the development phase are working hard to insure that a new discovery interface not only retains the functionality of IUCAT currently available, but also delivers improved functionality.

Most next generation type catalogs have a simplified search box, which is easy and quick to use for users with a simple question. Blacklight provides a simple format for the basic search and facet structure for limiting searches.

The generic Blacklight interface is customized according to the library’s individual needs and specific environments. Here are some examples that adopt Blacklight’s basic format.

  • University of Wisconsin – Madison

  • Stanford University

  • University of Virginia

  • Johns Hopkins University

The new IUCAT will have a single search box for the basic search, and faceted searching on the left side will allow users to constrain searches by controlled vocabulary items. There will also be an advanced search screen for more focused searches.  As the development is still in progress, your comments and ideas will be highly appreciated.

How do Apache Solr and Ruby on Rails work to index library resources?

Blacklight’s two fundamental technologies are the Solr search server and the Ruby on Rails web application framework. Developed by the Apache Lucene project, Apache Solr is used for indexing and searching records, while Ruby on Rails is used to create the front end. Here is a nice graphic representation of the Blacklight system.

Sadler, B. (2009). “Blacklight Infrastructure.” In Project Blacklight: a next generation library catalog at a first generation  university. Library Hi Tech, 27(1), 57 – 67.

A java-based program SolrMARC reads, indexes, and exports library’s MARC records to Solr and custom Ruby scripts are used for non-MARC items to map document metadata to Solr. The Ruby on Rails application looks to the Solr server for its data, passes search queries, and formats search results.

If you are interested in what others are doing in Blacklight, you can ask a question on the Blacklight mailing list and see its codebase at GitHub.

A new interface for IUCAT: Blacklight

As you may have heard, work has begun on a new interface for IUCAT. The IU Libraries OLE Discovery Layer Implementation Task Force (DLITF) will be overseeing the implementation of a new discovery layer, powered by Blacklight, to overlay our current SirsiDynix system. Development work is going on during this fall semester and a public Beta will be launched in spring 2012. This is a good time to share some background information around the new discovery interface, Blacklight.

What is Blacklight?

Blacklight is a free and open source OPAC (Online Public Access Catalog) solution developed at the University of Virginia (UVA) Library; check the project site for detailed information. While some OSS (Open Source Software) systems, such as Evergreen and Koha, were developed to replace a library’s entire ILS (Integrated Library System), Blacklight has been designed to work with a library’s current ILS to assist in reengineering the library’s searching tools.  It uses Apache Solr for indexing and searching records and Ruby on Rails for its front end.

What are some of the features?

Blacklight features faceted browsing, relevance based searching, bookmarkable items, permanent URLs for every item, and user tagging of items. As it is capable of searching both catalog records and digital repository objects, digitized images or repositories become more discoverable for users.  Unlike MARC records, which use similar templates for different types of objects, the use of Ruby on Rails allows librarians to define behaviors that are specific to certain kind of objects.

Where can we see examples?

The Task Force will begin soliciting feedback on the local beta implementation in the near future, but in the meantime, if you would like to see more, there are other mature installations of blacklight you may review. The University of Virginia, Stanford University, Johns Hopkins University, and WGBH are the principal contributors to the code base. There are dozens of sites worldwide and here are some of heavy users:

If you have questions about the task force or the project, feel free to contact us!

Additional reading:

Sadler, B. (2009). Project Blacklight: a next generation library catalog at a first generation  university. Library Hi Tech, 27(1), 57 – 67. Access the full text.

Sadler, B., Gilbert, J., & Mitchell, M. (2009). Library catalog mashup: using Blacklight to expose collections. In Engard, N. C. (Ed.) Library mashups : exploring new ways to deliver library data. Medford, N.J. : Information Today, Inc. Access the record in

New & Improved: OneSearch@IU

Not only are branded services easier to publicize, they are also easier to talk about. Since we see the launch of a discovery tool such as EBSCO Discovery Service as a logical next step in the process of better enabling discovery across all our collections, we have adopted the already existing OneSearch@IU brand, thus enabling EDS to be promoted and publicized at the Bloomington campus as “an all new, improved OneSearch@IU.” (This will have no effect on other IU campuses, or on existing OnCourse library services.)

Where can you see OneSearch@IU in action?

  • Top Recommended Resources: OneSearch@IU appears as one of the top recommended resources, listed on the Libraries’ home page and on the Find Information page (see below for more on that!).
  • Search results: Results from OneSearch@IU will be returned as part of the existing search results page (the orange box, or ‘resource discovery’ search). Icons indicating item type, and when available, book covers, will be presented as part of the results. We will be conducting user testing in the fall focused on the content and presentation of results returned on this page.
  • Subject Guides: In lieu of the federated search, which was always limited to a small subset of available resources, we will be implementing OneSearch@IU as a tab within research guides (example: Gender Studies). Our intention is to provide easy access to this resource for all users while retaining the carefully constructed resource listings maintained by collection managers. (Speaking of which – collection managers, you can also add OneSearch@IU to your resource lists.)
  • Find Information: The Find Information page has historically served as the page to which databases refer users upon ending or exiting a session. While many vendors have moved away from this behavior, the page still sees reasonably heavy use: it indexes high in Google search results for IUB Libraries, and the library link for some OnCourse course sites points here. We see an opportunity to begin to integrate search behaviors that we would like eventually to expand throughout the site – tabbed search box, etc. — and to evaluate and improve our approach.

What do you think? We’d love to hear your comments.

Discovery: questions & answers

As many of you may know, DUX has been working for nearly a year to implement EBSCO Discovery Service (EDS), and we’re happy to be launching for the fall semester as a new, improved OneSearch@IU.

Let’s start at the very beginning – a very good place to start, as they say. We’ve asked and answered a lot of questions throughout this process, and this post will focus on a few that I think are most fundamental.

What is a discovery tool, anyway?

Here’s one way of thinking about it: a discovery tool integrates a collection of disparate data sources so that search results are presented as a single, merged set.

How is this different from federated search?

I’m so glad you asked! It’s true, federated search products allow a single query to be simultaneously delivered to multiple information resources, and then collect those results and display them as a single set.  To accomplish this, the tool must generally rely on “translators” which enable communication with the varied sources, with varying levels of success. Also, the ability to include content in the search is dependent on the existence of a translator. In contrast, a discovery tool relies on a unified index created by bringing together data from a wide array of publishers, vendors and other sources (including library catalogs and institutional repositories) into a single integrated set. This results in improved relevancy ranking, and the ability to broaden the scope of searches to include local and subscribed content, and both print and digital materials from an array of disciplines.

This is better how?

While not exactly apples to apples, it’s a whole lot closer – one big set, indexed “all of a piece” improves relevancy across the board to increase the precision of the results returned. Catalog records may be bananas, but it’s a lot easier to properly weight the distribution of bananas and apples if you can put them in a single barrel, then teach the system to recognize them and sort accordingly. (Actually, I think I know what’s bananas – and it’s this illustration.) Also, the discovery tool typically presents an attractive interface designed to meet user expectations for ease-of-use, sharing, and other functions common to commercial sites such as Amazon or Google.

What does EDS include?

A quick answer to that question is: IUCAT records, all EBSCO content, and content from a large number of other vendors & sources (including Wilson, JSTOR, Elsevier, GPO, HathiTrust, Sage, MUSE, Web of Science, Wiley-Blackwell, Alexander Street Press, and others).

Who’s going to use this? Are we aiming this at undergraduates?

Clearly, this sort of tool is likely to appeal to undergraduates with its single search box,  interdisciplinary coverage, lots of full text, and easy export/print/share capabilities. I’d venture to propose that those same features might find fans amongst other user groups. I don’t think it’s going out on a limb to say that while the ways, or the reasons, that graduate students, faculty and researchers might use this tool may differ from those of undergraduates, there are plenty of use cases for those groups too. Personally I’ve found it very helpful to do a quick survey of what we have on a topic for myself, or at the reference desk – I like being able to easily retrieve articles, books from the collection, and other items with a single search.

Just what is this “discovery” business, anyway?

(Reposted from the April DUX Newsletter.)

You’ve been hearing a lot about the EBSCO Discovery Service, which we’ve just recently implemented here ( You may even have tried it out yourself for some searches, or given it a whirl at the reference desk. But you may still be struggling to explain (to faculty, students, or just to yourself) exactly what it is, how it’s different from federated search, what it’s good for, and why we have it anyway.

Look no further – Library Journal has published a very good overview that covers the problems we’re trying to solve, the history of how we’ve tried to solve them, evaluation criteria used in selecting discovery tools, how people are using them, and implications for the future. Check it out at and let us know what you think!