uses versus users

Something else came up in a number of discussions here recently that really struck me. We were talking about different types of users -- faculty, graduate students, undergraduates -- when the topic turned in a interesting direction. No user is a single type -- a faculty member might be ordering reserves one day and looking for a DVD to check out for the weekend on another day. A graduate student might a faculty member's proxy one day, doing their own research another day, or looking for beach reading in July. We all know this.

So, why don't we talk about uses rather than users?

Browsing. Searching. Research. Reserves. These cross many demographics. Let's analyze our services and interfaces from these standpoints, and not in terms of what "the faculty" or "the undergraduates" need. In other words, not a persona but a category of use. I don't have these ideas fully formed yet, but as someone who has spent a lot of time doing individual usability testing, I'm going to continue to give this some thought.

discussion of blogs and rss

I led the second in our "Not for Geeks Only" discussion series last week on blogs and rss -- 40 people signed up! We really seemed to have struck a nerve , and our Library staff seem really pleased to be introduced to these topics in a personal, targeted way rather than wandering through every random page on the web trying to find what's relevant.

It's not comprehensive, but covers some blogs that I and my colleagues here use every day to help us do our jobs.

http://staff.lib.virginia.edu/HR/training/classdocs/blogs.ppt

Coming up in the future -- GoogleScholar and Google Book Search, flickr, del.icio.us/social tagging, and firefox extensions.

planning our future(s)

For the past few weeks we have been planning for a visit from some folks from SirsiDynix, our ILS vendor. A number of people prepared presentations on various topics -- ILL requests, circulation, acquisitions, cataloging, user expectations -- and presented them over a two-day period.

It was highly illuminating.

We have a lot of staff who are very engaged with how we might improve not only our business operation and transactions, but how we might improve the user experience for our community. I was particularly impressed by the presentation on user expectations, which incorporated many Library 2.0 ideas that make sense for us -- rss feeds, "did you mean?" search facilitation, faceted browse, personalization, and recommender systems. While I was forewarned, it was still a amusing to see the content of my blog entry of September 5 (and my picture) illustrating the first slide describing the ubiquitousness of digital services as informing user expectations. I was described as the Library's "ubergeek." I cannot deny that I like being thought of that way. It's similar to the time in a job long ago when we we looking to create a new job title for me, and my boss suggested that it could simply be "Maven."

Another presentation that impressed me was the one dealing with cataloging. In part it was about improving efficiencies in the software used, but much of it was about how to best create shareable metadata that can be used for many purposes and by many systems. A great discussion followed about context and repurposing metadata and how to deal with authority control across systems.

There was also an excellent discussion about how our systems require too much data duplication. Why do we need to create and maintain tables of course names and numbers for reserves when students services already maintains such a data source? Why do we need to create tables to track payments when our procurement office already does that? Why do we need out own authentication system when the university has its own?

There was also an interesting presentation on ILL requests, and crying out for better implementation of standards and protocols so our systems can better communicate and our staff don't have to do as much work manually as they do now. OCLC was mentioned many times.

If the presentations from that day are ever made publicly available, I'll post links.

it's all about the metadata

Last week I attended the NISO "Managing Electronic Collections" workshop. I spoke about our Digital Library Repository implementation, and was gratified to have a number of people ask me questions over the course of the two days that I was there. One question really struck me -- "What is the most important thing that you learned in your process that we should take into account in our project?"

It could almost be a one word answer: metadata.

Of course it's a more complex answer than that. What metadata do you need to capture? Technical, preservation, administrative, descriptive? In what format? What's the minimum? We have experimented a lot in this area, and there has been a certain amount of "lather, rinse, repeat" as we've refined our metadata. In some cases, encoding standards have changed so mappings had to change. Or workflow tools have changed, requiring review of what metadata we can automatically capture, and in what form. Or standards have developed, such as those for the preservation or rights, so we need to review what we're capturing.

One of the most significant change agents has been evolving end-user services. Why? Because you can't support functionality and services (and often usability) if the needed metadata isn't there, or is in the wrong form. Having an extensible architeture is vital. Identifying standards to be used, and having production workflows that can process appropriate content in a timely fashion is key. But really, it's all about the metadata.

Ex: We want to be able to support sorting and grouping of search results by creator or title, which is easier if there are pre-generated sort names and sort titles (doing it on the fly takes a lot of processor overhead).

Ex: We want to create aggregation objects that bring together multi-volume series or issues in a serial title, which is easier if you have the most complete enumeration possible and identify scope to as granular as level as possible (e.g., volume, issue, article).

Ex: We want to supported faceted subject navigation, which is easier if the subjects terms are broken out in a granular way from their post-coordinated forms, such as identifying geographic vs. topical vs. temporal parts in the subject.

Each of these requires a change to our DTD and/or the patterns of our encoding, and, sometimes requires us to regenerate the metadata from the originals sources. But each time we both better document the objects and improve the services and the interface that we provide, so it's worth it.

If you're interested in what we've delved into so far:

http://www.lib.virginia.edu/digital/metadata/