Of familiar things

Following the previous week’s work, where I single-handedly had to trudge backwards through the mess I had created, I came to a couple of realisations.

The first of my realisations was that, as I was doing use-case driven development, working on a user scenario, I should have been working on the system from the outside towards its centre; working my way through each layer writing appropriate tests and ensuring that those tests passed. This meant working from what the user needs in order to get their thing done, while I implemented the things necessary for this to happen — and only those things — through the rest of the system.

I had, however, started at the wrong end: I worked from the data at the centre towards the outside. It never occurred to me that this was a bad idea, even though I really know it is. I have pondered why, and I think that it has something to do with the fact that I have worked with systems where I know the structure of the data even before I have had time to analyse it. Sure, I don’t know the minutiae, but I do know in broad strokes that the design will be a familiar one.

In libraries, we have a lot of givens when it comes to data; we know that the data will largely be formatted in one of a few ways (realistically, we know that it will be formatted in core systems in one and only one way), we also know that it will be a bit of a mess with some odd workarounds.

There’s a comfort in being an expert in something arcane that is a highly dependable mess; you’re rarely fighting a competent generalist for a position; you’re rarely going to be surprised. You know what can and can’t be done.

Library data is sort of like a battered old sofa with a sweet spot, it is difficult to get out of, both because it is broken and because it is comfortable in an odd way.

Looking at things from a developer’s point of view, it is tempting to work from the know towards the unknown. It’s easiest to start with what you know best and let that flesh out the plan. Unfortunately, making assumptions at the core of the system colours the outcome for the user rather badly. It makes it very hard to encode the necessary qualities of the user scenario through the system and maps badly to actual needs. (Note also that really, the use case should be the known!)

It’s quite obvious in our various data initiatives that we’re a structure-first crowd that is heavily influenced by a proud tradition of solid, dependable data structures, even if we know that these are devoid of connection to real use beyond the production of monospace-font library cards — in paper or digital formats. We imagine we can do something new, never realising that our problem stems not from our format, but from how we view data and its place in our work.

It’s odd that we think that we can guess our way to a relevant data structure before we know how a user will react to the features we’re developing; it’s arrogance and laziness. We spend an awful lot of time in our committees and initiatives worrying about details of things that affect nothing useful. We think in terms of technology rather than usage; we think in terms of our professional community rather than the community of users we serve.

I note to myself that I write above about how data is at the centre of things — this is a familiar mantra from the library community and some might view me as saying that this isn’t the case. Let me address that: I’m firmly of the belief that data is at the very core of what we do and what we need to do — we can’t do anything without it; I just don’t believe that we can usefully talk about data structure independent of use cases and the specific systems that they bring into being.

Library systems will always be wrong until we stop working from the data out and start working from the outside towards the core.

Posted in Uncategorized
3 comments on “Of familiar things
  1. Adrian Pohl says:

    Thanks for the post, Rurik.

    I am curious how you get the user scenarios you start working from. Have you asked users in advance what they want? Do they regularly test your prototype and give feedback? Or do you just sit together from time to time and guess about user scenarios?

    • brinxmat says:

      Hi Adrian, sorry for the late reply — I have issues with alerts from WordPress at the moment.

      The user scenarios are provided by the product managers, who work closely with users to develop these. They develop over time, as does our response to them.

      The testing is automated, but is also tested with real users.

      That said, we’re very early in the project and methods and feedback-loops are still being developed.

  2. I think there is a profound truth in what you say here – designing library (and I would add Archival) systems, and their outcomes, is not about the de-facto shape of the data (aka the data structures of our catalogues and finding aids to be explicit) but what our users want to do with it or get from it.

    If that leads to questions about the de-facto shape of that data then as a profession we should not shy away from the challenge that asserts as to the relevance of our assumptions that created the data in the first place! This is not to say everything is short term and only immediate user needs driven (we are institutions that take the long view), but we should be better at listening to the users and responding.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s