Usability, Findability, and Remixability, Especially Remixability

It’s been more than a year since I first demonstrated Scriblio (was WPopac) at ALA Midwinter in San Antonio. More than a year since NCSU debuted their Endeca-based OPAC. And by now most every major library vendor has announced a product that promises to finally deliver some real improvements to our systems.

My over-simplified list said that our systems failed us in the categories of usability, findability, and remixability, and now people are asking me what I think about what I’ve seen from the vendors so far.

In general, they all include improved search results, and everybody seems ready to address comments and user-tagging, though the system vendors seem to be leaving findability to OCLC’s WorldCat efforts.

What’s missing, I fear, is remixability.

Remixability is the quality of a system or data set to be used for purposes the original designers or owners didn’t predict or intend. If I can define one buzzword with another, remixability is what allows mashups.

In 1971, in the earliest days of ARPAnet, Ray Tomlinson showed his friend a project he’d been toiling on on the sly: email. “Don’t tell anyone! This isn’t what we’re supposed to be working on,” he’s reported to have said.

In a different world, with a slightly different set of circumstances, the at sign on our keyboards might be lost. If he had had to ask his bosses for permission, or if the simple structure of that nascent internet was less open, Tomlinson would have been finished before he’d even gotten started. But as it turned out, Tomlinon was able to remix computers from mathematical machines to communication devices.

Fellow remixer Tim Berners-Lee explains it well:

Twenty-seven years ago, the inventors of the Internet designed an architecture which was simple and general. Any computer could send a packet to any other computer. The network did not look inside packets. It is the cleanness of that design, and the strict independence of the layers, which allowed the Internet to grow and be useful. It allowed the hardware and transmission technology supporting the Internet to evolve through a thousandfold increase in speed, yet still run the same applications. It allowed new Internet applications to be introduced and to evolve independently.

When, seventeen years ago, I designed the Web, I did not have to ask anyone’s permission. The new application rolled out over the existing Internet without modifying it. tried then, and many people still work very hard still, to make the Web technology, in turn, a universal, neutral, platform. It must not discriminate against particular hardware, software, underlying network, language, culture, disability, or against particular types of data.

These innovations resulted not from management directive, but inspired moments urged along by a supportive network architecture. The value of the internet was built on it’s remixability.

There are two ways to look at mashups of today, like Flickr Colr Pickr. Some see them as amusements and question who would build such things, others wonder how they can build systems that are as open to reimagining as Flickr.

And while some remixes might be simple amusements, others can be much larger. Flickr user Dan Cat, who imagined putting Flickr photos on the map (and built a mashup that let Flickr users do just that), ended up being hired by the company to build those features into their official site. Amazon, meanwhile, says remixers — including the 180,000 registered Amazon Web Services developers — account for almost a third of their sales.

The lesson is that when you open up the tools of remixing, people will use them, and the innovations that result will offer value even for non-remixers.

Today, we’re likely to invest in the software architecture of our libraries on a scale that matches the expansion during the Carnegie era. We might do well to think about one of the remarkable features of that period:

The Carnegie libraries were important because they had open stacks which encouraged people to browse. The open stacks were more democratic. People could choose for themselves what books they wanted to read. The libraries were meant to be for people of all walks of life.

The crisis in library systems arose because the people who build them and those who pay for them couldn’t imagine them in any other way. Open, remixable systems will allow patrons of tomorrow the opportunity to build the information solutions we can’t now imagine.

Is remixability in your next RFP?

remixability, mashups, library, library systems. l2, lib20, library 2.0, libraries, api, soa

11 thoughts on “Usability, Findability, and Remixability, Especially Remixability

  1. This is of course a topic many of us have been thinking about. Here’s one way I’ve been articulating it in my head, preparing to articulate it to administrators and such:

    The data in the ILS must function as a data store for the unified business of the library. The software can no longer just be about supporting work flow, the data produced must be housed in something that can serve as a unified data store for our unified business.

    It was Lorcan’s pointer to the Australian report talking about ‘single business’ that got me thinking in these terms.

    This way of expressing it is in some respect less ambitious than what you describe, it’s not there yet. But I think we need to figure out a way to express this which makes sense to administrators, on the way to something which can be expressed clearly in a requirements list, so that less technical people (at our libraries who will be evaluating products) can still understand the requirement, whether or not they are qualified to evaluate it.

  2. Pingback: My Boston Library Consortium Presentation « MaisonBisson.com

  3. @Jonathan Rochkind:

    It would seem that one of the barriers to understanding remixability is in our historical role: many of the libraries I’ve visited view their role as primarily dissemination of knowledge rather than the development of knowledge resources.

    Consider how purchasing agents view open source software: it doesn’t make sense. Their job is to buy things, not build them.

    Mix that with an admittedly ambiguous use-case (if we open it, people will remix it) and limiting license terms on the data we have, and it’s definitely a hard sell.

    Still, one can hope, and, as you suggest, writing remixability into our product requirements is a big step.

  4. Pingback: Tim Spalding on Social Cataloging and the Fun OPAC: Notes « Digital Odyssey 2007

  5. Pingback: » Remixability vs. Business Self Interest vs. Libraries and the Public Good

  6. Pingback: » The Rules, 2007

  7. Pingback: » An Almost-Manifesto Masquerading as a Presentation...

  8. Pingback: » My Boston Library Consortium Presentation

  9. Pingback: » Introducing Phonepedia, a Voice-Activated Wikipedia Mashup

  10. Pingback: » Crime vs. Highways. Or, Internet Security Is A Social (Not Technical) Problem MaisonBisson.com

Comments are closed.