For at least 1500 years, Japanese artists have practiced suminagashi, the art of marbling paper with ink floating on water. The marbler uses brushes to place alternating drops of black calligraphy ink and turpentine on the surface of a full basin, then lays a sheet of paper down to capture the resulting patterns. They look like clouds, or smoke, or the grain of twisted trees. Each pattern is unique, unlike in Western marbling, where the creator can reproduce essentially the same design many times.
Ink, turpentine, water, paper. It seems so simple.
And it is very simple, but only after you accept one thing: you are not in control of the outcome. The ink goes where it wills, and the marbler can only follow. There are tricks to give the pattern an overall direction, such as controlling the amount of ink and turpentine or gently blowing over the surface of the water. But the heart of suminagashi is trusting what you can’t predict or control.
I recently read George Oates’s essay about the ways that Flickr created its community: Community: From Little Things, Big Things Grow on A List Apart. Two particular paragraphs really jumped out at me:
Embrace the idea that people will warp and stretch your site in ways you can’t predict—they’ll surprise you with their creativity and make something wonderful with what you provide.
There’s no way to design all things for all people. When you’re dealing with The Masses, it’s best to try to facilitate behavior, rather than to predict it. Design, in this context, becomes more about showing what’s *possible* than showing what’s *there*.
Flickr’s history has proven her right. There are any number of wildly varying communities on the site, many of them either accidentally or deliberately experimental. Flickr groups are even cited as a case study in Here Comes Everybody, Clay Shirkey’s recent book on online community dynamics.
And now it’s our turn.
Last year, my company (MediaLab, which makes a library search software package called Aqua Browser Library) released our new social library software: My Discoveries.
The essence of My Discoveries is this: allow users to add information to the library catalog. Let them tag things, make lists of related items, fill in ratings, write reviews. Then let others see what they’ve done. Turn the patron’s interaction with the library’s catalog into a conversation with the catalog, and with each other.
I’ve been involved in both the design and testing. One of the core principles we’ve kept in mind throughout the process is that we cannot predict what people will do with it1. Designing and testing in the light of that kind of uncertainty is very different, and much more interesting, than working to a known, restricted usage profile. It affects everything we do, from what characters are allowed in list names to which statistics we want to gather. How does one design metrics to detect the unpredictable?
Tags, lists, ratings, reviews. It seems so simple.
- Of course, we are not so naive as to think that all the new ideas that people come up with for My Discoveries will be good ones. I moderate a web community in my spare time, so I know how bad things can get. As a result, I have put a lot of attention into the administrative interface—and I expect do more on it in the future. If we give users room to innovate, we have to give librarians the wherewithal to detect and clean up misbehavior.
Oh-oh, you hit one of my current hot topics. I feel a rant bubbling up; I must take on my Aspect and wield my Attribute.
The system I’m working on now has some major design problems because some fundamental issues about valid character sets and the use and communication of metadata mixed with data weren’t addressed at all. These things are central to building a system that’s flexible, extensible, and allows mashups to be created without knowledge of the system internals (preferably without any sort of deep technical knowledge at all*).
I’ve been thinking about the sort of design criteria that are important in software that can meet these requirements. Here are my first thoughts; I’ll continue on my own blog as they develop, but you got the juices flowing now, so I’ll begin here if you don’t mind.
1. Quoting is vital. It must be easy to encapsulate any string of valid data (e.g., text characters, images, the basic vocabulary of a web page) so that the system can treat it as an opaque object except where the data really is meaningful. It shouldn’t be necessary for an admin or someone extending the system to deal with escaping characters significant to parts of the system, like ‘&’ and ‘;’ in HTML, or ”’ or ‘”‘ in SQL literal strings, or (oh, help me Noshabkeming!) spaces in filenames. Always remember that a filename can come from most anywhere.
2. Metadata is data to any system that doesn’t have to process it. Opaque objects have to remain opaque unless the software really needs access to the insides. Accidental access is a good creator of truly diabolic bugs. I created a test case yesterday with an object whose name contained an apostrophe. This caused the web application that read the name from the database to crash.
3. Objects shouldn’t have to have knowledge of each others’ lifecycles. If an object is created in one system and another system creates another object to collaborate with it, then either the first has to exist for as long as the second needs it (and that’s often not easy or even possible to guarantee), or the second system has to make sure that it copies everything the second object needs from the first, without creating any issues of staleness of the copies during the life of the second object (and that’s as close to an intractable problem in a distributed system as I know about). Anybody who’s ever slaved over request-scoped webapp variables has been bitten by this one.
Akk! This is growing from a screed into a tome; not what I intended. I’ll stop now and go get ready for work. Let me know what you think of this.
* Librarians are technically-oriented, but don’t necessarily have specific knowledge about the administration of software, especially web-based systems. The manufacturing workers who administrate my system are not technically sophisticated at all; they’re bright people, but don’t have technical educations, so they’re not familiar with some basic concepts that would make it easy for them to create a mental model of what they can do with the software. And I can’t expect to train them in something that’s irrelevant to their jobs.
“…I moderate a web community in my spare time…”
Spare time?
Can it be called spare time, if it’s to do something that IS a responsibility you can’t just ignore – one which you fulfill wonderfully well?
Is there any spare time left after you use your spare time?
Bruce Cohen, STM:
Please feel free to use this space to think aloud. When you write something, can you link it from here, too?
I’ll answer more of what you’ve said later, but one amusing thing from point 1.
About six months ago, we stumbled on a very funny bug around the XML files we use for our various system settings. Although we’re a Dutch company, we (and our customers) tend to use English-language installations of Windows.
So one of our developers was noodling around with a Dutch-language Windows installation. And it turns out that Windows tries to be smart when it parses Boolean values in XML files. It changed values like TRUE into WAAR. Taking those files back to an English language installation caused many amusing errors.
Lesson: use quotes and string values rather than Boolean values if you’re dealing with OS’s in more than one language.
Thanks for the use of the podium, abi. I’ll be back in a few days. I have a production release due on Thursday, and a colonoscopy on Friday. By the time I get back to writing about this I’m going to be feeling a little empty.
So, how did that go, Bruce? Mine was no big deal last year, and I was quite amused that it was done by Doctor Ming.
Serge,
Thanks for asking. The release got delayed until (very) late Monday because of some last minute problems mostly having to do with uniqueness in the configuration of the production environment. The colonoscopy went quite well; no evidence of any problems at all, so I don’t have to be screened again for another 10 years.
Much later than intended, but then, even the Creation ran over schedule (it was originally intended to take 5 days), here’s a link to the next in my series of rants about software. This one is titled “Of Languages and Wheels”. Just follow the link: http://rumblingsfromthespeaker.blogspot.com/2008/06/of-languages-and-wheels.html