Skip to content

The reference interview

November 30, 2010

One of the things I remember most about the coursework for my master’s in library science is the concept of the reference interview.  This is simply a conversation a librarian has with a patron, in order to clarify their needs and target the search.

A key part of this discussion is the “why” behind the request.  A person often comes into a library looking for something unknown to them (it makes sense, since if they already knew about it they wouldn’t be asking for help).  In this situation, it stands to reason that you may not be able to articulate just what it is you’re looking for (imagine a person who is not mechanically inclined going to a hardware store).  So if the librarian is able to ask why the patron is looking for the information, it can lead to a more informed interaction, which will often lead to success.  Think of it as contextualizing the request.

If you think about it, this is really just a basic communication skill that has been articulated within the realm of library science to describe an everyday occurrence.  But it can be taken beyond the library environment and applied to everyday conversations.  I mean, why not try to understand someone else’s motivations when you interact with them?  In every situation, whether it’s social or in the workplace, it’s important to understand the other person as fully as possible, and (within reason) it can’t hurt to ask someone for clarification.  It may shake things up a little, but it also may advance the conversation and lead to a breakthrough that you didn’t foresee.

So the next time you find yourself having a conversation, and you’re not entirely sure that everyone involved is working from the same assumptions, think about asking if everyone can agree on what you’re talking about.  I have often found that people are grateful if you’re willing to speak up, since they may have been unclear as well.

This isn’t a difficult concept, and it sounds logical, but I get the feeling that people are afraid of looking stupid, especially at work, and so they are afraid to ask questions.  Don’t be that person — ask, because if you don’t, you’ll just remain in the dark.  And the dark is a scary place to be.

Writing these DAM instructions

September 28, 2010

Over the past few months I have been developing a DAM system for a nonprofit institution.  The goal was to create a system that would enable them to locate images from their collections in order to publish them, either to the website or in print.  The project is drawing to a close and I am nearing the point at which I will hand it off to them.  One issue I’m now confronting is the need for some instructions they can take away from this.  The software I’m using is ResourceSpace, an open source package that I have written about before.  ResourceSpace is a great tool and it fits the nonprofit’s needs very well, and not just because there is no licensing fee.  It’s web-based, fairly easy to use, and it can handle many different file types in addition to digital photos.  But one area that I find a little lacking is in its documentation.  There is a wiki available, but it isn’t really a comprehensive user guide, and sometimes it seems like it is written for a user who is already somewhat familiar with the software.  The developers also published a user guide, but it is now a few years old and some of the features and appearance of the software have changed.

I have a little bit of experience with other DAM software, including Canto’s Cumulus, and Portfolio from Extensis.  If you have ever read the user guides that accompany some of these tools, you can appreciate how dense and unwelcoming they can be.  The user guide for Cumulus is well over 100 pages, and I’m willing to bet that you can’t find too many people who have read the entire thing from beginning to end.  Possibly not even the person who wrote it.  For another take on the issue, see Henrik de Gyor’s post about documentation.

So I’m working on a (hopefully) short, basic version of a user guide for ResourceSpace.  I want to convey the essentials of the system without overdoing it.  I feel that too much information can be just as bad as too little, as it can cause the really important points to get lost in a sea of needless detail.  And since the whole concept of digital asset management is to create efficient ways to locate key information, it is counterintuitive to make the documentation difficult to navigate.  But I’m discovering that writing clear and concise instructions for this system is harder than I thought.  Even with software that is reasonably intuitive, there are lots of little details, and different ways of working, and I want to provide my client with a comprehensive discussion of the key points.  After all, they are the ones who will be using the system, and I want them to feel confident that they can max out its power, and also that they got their money’s worth.

So far I have spent several hours on the document, and every time I feel like I’m getting close to completion I find something that I either a) failed to include, or b) included that I want to take out.  I suppose it may never be perfect, but I’m going to spend some more time with it over the next couple of weeks, in the hope that I can refine it enough to consider it a finished product.  It’s part of the agreement I signed with them when I took the job, and I feel like it will be almost as important as the DAM system itself, because it will make the system much more accessible.  Also, if they hire new staff who will be using the DAM I would like them to be able to hand my instructions to the new person and have it make sense.

Another reason that I’m putting this much time into it is that, as a part of the open source community, I have been considering making this user manual a contribution to the product.  I’m not a programmer and I won’t be able to add much value to the underlying code, but if I can offer up some useful documentation, I will feel like I have done some small part for the good of the community.

So I’ll close by saying that if any of you have any good tips for writing something like this, please let me know.  And, if you are feeling especially generous of spirit and would consider critiquing my work, let me know that, as well.

DAM video thoughts

June 21, 2010

A couple of recent conversations have prompted me to think a little more about digital asset management for video.  I have been doing some DAM work already, but it has been with still images and I haven’t yet had to deal with the added complexity of video content.  The obvious issue with video is the size of the files, along with the fact that it (usually) contains audio, including speech, and thus requires so much more storage space and accompanying metadata than still images.

The first conversation was with a former colleague of my wife’s who is now handling sales of a suite of products that supports litigation teams.  One of the services they offer is video deposition support.  This includes taping the deposition and supplying a transcript of the deponent’s testimony with time codes inserted so that the user can easily locate the video footage of the testimony in question.  Depositions are so important in litigation, although you don’t usually see them portrayed in films or on television, because they consist of sworn testimony equivalent to testifying in open court.  Therefore, attorneys need to analyze deposition testimony in preparation for trial.  You can imagine how useful it would be to have the video along with the searchable text of the deposition.

The second conversation was with a married couple at a social event my wife and I attended last night.  The woman is a master sommelier who has a website where she features educational videos about wine.  Her husband handles the videography for this content.  I mentioned that I am involved in digital asset management and explained a little more about the issues DAM tries to resolve and they immediately got it.  They gave the following example of an instance where they could use some help classifying the footage they shoot: Say they are producing a clip about a certain type of wine, but during the video shoot someone brings up a topic that was not previously planned.  This couple described a scenario in which they would like to be able to return to that footage at some point in the future, possibly because they are now producing content about the second subject.  But if they are classifying their footage by the primary topic of the shoot, it is extremely difficult to go back and locate the clip they want to retrieve, because at that point it becomes a question of remembering something that took place weeks, or even months, prior.

So I started thinking about how to apply the concept of a time coded transcript to the wine-related content.  I know this is probably nothing new to people who deal with a lot of video footage, particularly people who work in scripted television or film production where the content is predetermined.  But in situations where the content is more free flowing, like in interviews or casual conversations, you are not working from a script and so you don’t know beforehand all the subjects that may come up.  This same scenario is at work in a deposition (although most attorneys certainly try to guide the conversations as much as possible), or in a conversation about wine.  People will say things without planning them in advance, based on where the conversation leads.

The question then becomes: Is it feasible to have someone transcribe the content for the wine productions and then feed it into a DAM system where the text is searchable?  I like to think that it is.  Perhaps we need to find a court reporter who has a little bit of extra time and would take wine in trade for their services.  After the transcription is complete, of course.

DAM Internships

May 25, 2010

As someone who is looking to break into a new field (digital asset management), I’m always curious to learn about opportunities to gain experience. A leading expert in the field, Henrik de Gyor of Another DAM Blog, has just announced an internship program in an effort to link up those of us who are interested in moving into DAM with employers who may have opportunities available. I don’t know about taking an unpaid internship, but if I saw something that looked promising I would definitely think about it.

I’m happy to see that someone is putting in the effort to connect DAM-interested workers with organizations that could use the help. Digital asset management is a mature field with established tools, methodologies, conferences, etc., but it seems to me that it has not yet attained the status of an actual discipline, such as accounting, library science, or computer science. There are no real academic programs in DAM, and there is not a certification that an employer can look at to quickly vet a potential digital asset manager. It may be coming, and it may end up being an outgrowth of library and information science (Full disclosure: I have a master’s in library science), or possibly computer science/information technology.

One difficulty for DAM is that it crosses various boundaries: there are elements of computer science (or at least information technology, since software is an integral part of it); library science, with its focus on classification, metadata, taxonomies, etc.; arts and creativity, since creative assets are generally what goes into a DAM system.

Perhaps it is that cross-disciplinary nature of DAM that makes it a slippery concept. It may be difficult for an organization to fully appreciate the need for a DAM solution, or, if they realize the need for it, it may be easy to decide that it is an IT issue and buying the software is the only hurdle to getting a DAM system in place.

As I research digital asset management and connect with experienced practitioners, one of the things I have heard consistently is that the purchase of DAM software does not solve the DAM needs of an organization. It requires planning, many conversations with stakeholders across departments, and constant effort and refinement. And it requires staff dedicated to the success of the DAM system. Without staff to shepherd the system and train the users and maintain the metadata/taxonomy/controlled vocabulary, the organization will face the same problems they faced before purchasing the software, only now it will probably be even more difficult to figure out since it involves a new (and often complicated) system.

Initiatives like Henrik’s are a positive step toward making digital asset management seem more substantive and credible to those (potential) employers who (possibly) see the need for a digital asset management system, and a digital asset manager on staff to run the operation. As someone who is on the outside looking in, I hope that DAM practitioners will look to sustain and grow the industry by seeking out those of us who want to make a contribution. For now, I’ll continue to monitor DAM Internships to see if anything looks promising. If you hear of anything, feel free to pass it along. I’m available.

Cumulus demo

May 19, 2010

I have recently been part of a team investigating DAM software offerings for a large implementation. It’s at Stanford University, and the hope is to unify a few existing installations, while also enabling new departments to take advantage of the availability of DAM software and expertise on campus.

One of the packages we are reviewing is Cumulus, a fairly common DAM tool. There are already a few separate Cumulus installations on campus, and so it is under serious consideration, since it would be fairly easy to merge those separate installations, if that is the way they want to go. Yesterday a couple of consultants came in to provide a demo of the software and to answer questions that our workgroup may have.

I found the demo to be pretty informative, although in an hour it’s difficult to see everything that a DAM tool will do for you. That must be a difficult aspect of being a consultant in the DAM field — trying to quickly convey the strength of the software you are selling, when it’s capable of doing so many things. I suppose you need to get a feel for your audience and determine the features they will find most useful.

The other package we are looking at is ResourceSpace, an open source tool that I like quite a bit. There is definitely some interest among our group in ResourceSpace (Selfish note: I got to demo my own installation of ResourceSpace for the group, complete with pictures of my dog, so I feel responsible for bringing it to everyone’s attention). One aspect that people appreciate is that there is no cost to license the software. With Cumulus we are definitely looking at some substantial licensing costs.

Another feature of ResourceSpace that resonated with our group, and this one surprised me, is that it’s open source. Even our IT staff is into the fact that it’s open source (for some reason, I thought IT might not be enthusiastic about an open source product — I guess I assumed that their view would be that it means they have to provide all the support). There are a couple of other open source advocates on the team, and I think ResourceSpace is definitely in the running.

All that being said, I feel that the Cumulus consultants did a good job showing us the software’s features. They have obviously done it before, and in fact, they already have a few of our campus departments as clients. It makes sense, as they appear to have a monopoly on Cumulus implementations in the Bay Area.

Now we are supposed to provide feedback to the project coordinator on our view of Cumulus vs. ResourceSpace. In a way, I would like for us to go with ResourceSpace. It’s the DAM software I’m most familiar with, as I’ve been using it for over a year now. But at the same time, there is something to be said for hiring professionals to come in, set up the software, and support it going forward. I’m sure that’s what they would want to hear.

If you have any thoughts on the matter, leave a comment here.