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?
11 Comments
Comments RSS TrackBack Identifier URI
Leave a comment
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.
[...] « Usability, Findability, and Remixability, Especially Remixability [...]
@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.
[...] however, while discussions about usability, findability, and remixability have been quite popular in the biblioblogosphere, the concept of “funability” could [...]
[...] åŠ Remixability) 已經一年多了，他如何看這一年來 OPAC 的發展或變化呢? 他觀察到：目å‰å¤§éƒ½åœ¨æª¢ç´¢çµæžœæœ‰æ‰€æ”¹é€²ï¼Œä¸¦ä¸”大家好åƒä¹Ÿéƒ½æº–備好 書評(comments) åŠ [...]
[...] been talking a lot about remixability lately, but Nat Torkington just pointed out that the web services and APIs from commercial [...]
[...] Like open source, remixability and APIs engage a larger pool of talent than is available inside any company and serve two very important audiences: those who want features and those who care about their exit strategy. Neither group is remarkably large, but both are influential, passionate users. (More: Usability, Findability, and Remixability, Especially Remixability.) [...]
[...] some of the affordances of open source further, remixing and mashups have shown the power of open systems and common, easy to use protocols. Those mashups are pointing [...]
[...] A bunch of stuff I would have emailed you about. « bsuite Bug Fixes (release b2v7) Usability, Findability, and Remixability, Especially Remixability [...]
[...] speaking in the voice of a real person). And the thing about Jott that got me interested was the remixability of the service. They call it Jott-Links, and it allows any user to connect external applications to [...]
[...] offers Twitter as an example, but Ray Tomlinson offers an even better one. According to the legend, the man who invented email told his friend “Don’t tell anyone! This isn’t what we’re [...]