The Venn Diagram of Social Media

I should have used this diagram in our Web 2.0 workshop.

The answer's always in the question

I'm probably the only person in the known universe who's going to be doing this but it's worth my noting it down as a reminder of the general principle.

We've bought into smartsm, which is an evidence-based stock management tool. We're working on Dynix, which provides a ton and a half of really useful data but which provides far too much detail for everyday working. The idea is that we can use smartsm to pull together the data into reports which can be run by front-line staff who can then take whatever action is appropriate. (The idea's a bit more and a bit bigger than that, but that'll do for the purposes of this narrative.)

Dynix is an old library management system and interoperability isn't it's strong suit, by a very long chalk. The good news, though, is that it's very easy to do snapshots of any combination of data and then export that out as text. Being an old Pick system, the data's not held in tables like you'd see in an SQL database; the best way I can describe it is that for all practical purposes the data's held suspended in mid air connected together by bits of string. These bits of string ("dicts") are one of the most powerful data manipulation tools I've had the pleasure of playing with and I'll miss them greatly when we eventually move onto a new LMS. They do three jobs:

• They define which piece of data you're looking at;
• They define how you're going to see the data; and
• They can link the data in one file to that in another file.

So, for instance, the dict called BARCODES in the bibliographic record file called BIB reports the data found in the first line of a BIB record in columnar format 16 characters wide. The dict called L-COLLECTION reads the data in the first line of a BIB record, uses those barcodes to look for the appropriate records in the HOLDINGS file, reads the code in the fifteenth line of each record, translates the code(s) into the appropriate collection labels and reports these in Title Format in a column 40 characters wide. And once a dict is set up and shown to work OK you can forget about all the intermediate steps and just get the data.

So what's this got to do with smartsm?

We need to do a monthly extract of our catalogue data providing the bibliographical data for each item plus its location, collection, current status and its use. And smartsm need this as comma-delimited data in a set format so that they can map it against their reporting processes. Most of which is easy enough to do: if you tell me that you need the title of each book up to a maximum of 100 characters it's literally less than a minute's work to do. You want it comma-delimited, it'll take a minute or two to remember how to impose a constant comma in front of the reporting data. And for the most part it really has been that easy. In some cases I've wanted to aggregate the data into something more useful, for instance we have umpteen item statuses providing different reasons why these items are not available for loan (being repaired; being boxed up for transfer to another library; audio items bought then held back under the terms of the performance licence, etc.), which are usually useful when you're looking for a particular item but drag in a bit too much confusing detail for reporting purposes, so I set up a dict that just reports these as "not available." A few bits were more complicated but I got there in the end.

And then there was the date format.

Date formats are a pain in the arse, no two ways about it. The data extract had to provide the dates in a particular format, which isn't any of the date formats available on Dynix. I spent six weeks trying, and failing, to write a dict that jiggled the components around a bit to give the right format. I was beside myself with frustration.

On the bus home one night I realised I'd been a prat.

We need comma-delimited data, right? If I downloaded the entire catalogue database and stuck a comma at the beginning and a comma at the end this would be treated as one piece of data, one column wide and one row deep. I didn't need a dict that juggled the day, month and year data. I needed a dict for day, a dict for year and a dict for month. With a comma before the day data. Which was five minutes' work the next day.

Note to self: in future, pay attention to all the question. The answers come easier that way.

Customer service skills: a collaborative training event

There's a nice bit of live-blogging of a useful workshop discussion on the ALA Learning web site. Don't be put off that the results conveniently fall into a "top ten" list: the ideas presented are simple and entirely do-able. In fact they're uncannily similar to the topics I used to include in customer care training sessions in the early nineties, so I might have been getting something right.

In principle I'm torn on live-blogging. On the one hand it's a good way of delivering a running account of a discussion or workshop. On the other it can be a bit off-putting for participants to be hearing the tap-tap or click-click of the recording angel. When it works it can be extremely useful. I think success hinges on the working brief:

• It has to be an appropriate topic - there's no point in live-blogging somebody doing a PowerPoint presentation, for instance.
• It has to be an appropriate audience - if the participants are going to be paying more attention to the recorder than the facilitator it's a waste of time. (I'd argue that live-blogging any activity involving young children is a hiding to nothing.)
• It has to have an appropriate purpose - you need to be doing something with the results or else you've wasted your time.
• The recording angel has to pay attention to the activity, not the recording thereof.

While I'm on the subject of customer care in the library, there are some useful notes about communicating in the virtual reference library environment on the Association of College & Research Libraries web site.

The problem with self-service checkouts

Although this piece in the BBC News Magazine is about self-service checkouts in supermarkets there are still a few things we can learn from it. (And no, we still haven't done anything about putting self-service issue in any of our libraries, so my interest in this is purely on a precautionary basis.)

• Self-service means that the customer is doing all the work. We need to make sure we're not also making them cope with a pile of unnecessary inconvenience.
• We also need to make sure that we're not making the customer do anything that would make them realise that they're doing all the work and it might be quicker to just take the items to a staffed issue desk.
• You need staff to support customers using the self-service facility. (We knew that already but too many self-service developments have been funded on the basis that there'll be an immediate saving on staffing costs.)
• Many customers want the interaction with a human being, we are social animals after all. We need to respect this added value to the transaction (and get it right!) as this often makes the difference between a repeat visit or not.

Library Management Systems: Development directions

I'd entirely forgotten I'd written this. The library management system market is in a state of flux at the moment (the moment being the best part of a decade now!) and one of the questions we're all hoping will go away is: "why do you need a library management system in the first place?" Other council services have customer databases and keep track of customer transactions. And/or have resource management systems that include acquisition, distribution and use to end of life. Why are libraries different?

Well, we are different in many ways. We have international database standards for our catalogues so that we don't have the pain that many public sector document management systems are going to have over the next ten years. Most of our base data can be easily mapped from one system to another, from one library service to another so we can do collaborative work like regional loans and consortium working. (An argument that will be easier to pursue when library management systems deliver their promises on interoperability with non-library systems.)

But are we different enough to satisfy an entirely understandable corporate wish for a nice, simple one-stop solution? That's entirely down to the library service's specification of functional requirements (the UK Core Specification being just a fraction of what a modern library service needs) and the business case supporting that functional specification. If it turns out that a one-stop solution delivers to that specification, excellent, everyone's a winner. If it doesn't and some other solution does then some hard choices need to be made.

I don't know what, if any, input I'll be allowed to have on our choice of a new library management system; I suspect very little. I will keep making the case for a functional specification and a business case, though. There's no point in telling somebody to paint your front door any old colour and then spending a decade complaining that it was painted red.