For about a year now, wikis have peeved me. Not the software, which can certainly be useful, but its heedless deployment as the groupware of choice. In both corporate and academic contexts, wikis are thrown up as project intranets, but in many cases what escapes attention until after the fact is the flatness of the data they tend to collect. What I mean by flatness is posts tend to accumulate as linked lists, heaped up like middens with all the latest material at the top. Of course, wikiware also offers the advantages of searchable text, change logs, and revision histories, but do these eliminate the need for logical (editorial) ordering of uploaded “items?” Or, might it be that these flat, automatic ways of setting relations among posted items, deceive us in to thinking that order arises automagically from the nodes and links of user-generated hypertext?
Wikipedia, which is probably the best known wiki, is a perfect match of task and tool because the simple structure of term and entry is sufficient architecturally for an encyclopedia. But encyclopedias are a special case. And they differ markedly from the various other forms collected knowledge takes in everyday life–from that random-access classic, the book, to online databases and corporate intranets. Encyclopedias, dictionaries, glossaries and the like: these are remarkably uncomplicated instances, structure is axiomatic, everyone already knows how to play, more or less. But even here I’d venture that on projects with any longevity, wiki gnomes edit people’s edits, educate and evangelize through other channels, and chastise rule-breakers in whatever hallways those channels afford. Which is to say, even in the most uncomplicated cases, meaningful order does not turn out to be an emergent property of shared, stored communications.
My gripe against wiki-mania, as I came to call it, first became fully apparent to me last May. At the time I was preparing to teach (TA) an anthropology course with a multimedia production component through USC’s Institute for Multimedia Literacy. The professor I was assisting had planned to scan a bunch of images of art, ritual and everyday objects, and photographs from her books (it was a course on the changing image of the Pacific in the Western imagination), so I suggested it would make sense to build on that work to create a database to which students could contribute and around which they could do their projects. That way, I thought, we’d all learn together about creating a networked, multimedia resource of this kind, and we’d be able to collect material and build and refine that resource over time. It seemed to me a perfect plan and, looking back, that should have been my first clue. Such illusions are made to be shattered and, quite shortly, mine were.
To create this online, multi-author, course database, I dutifully wrote a paragraph describing what we wanted to do, listed out all the capabilities we’d need, and asked the tech folks in charge of this particular sector of the grid (by way of a managerial intermediary) what type of software they would have me use. Having run a Mac/Tango/Filmaker site in the early 1990s that shared a FileMaker Pro (FMP) database over the Internet with a community of contributing users, the functionality requested seemed reasonable to me and I’d read about several current open source content management packages what sounded like they’d work just fine. The answer that came back, however, was, “You can use a wiki.
I was less than delighted, but that didn’t register until later because I was stunned by the curricular implications of the reply. Of course I could use wikiware to try to mimic the capabilities of a database, but why? That didn’t seem very sensible given that we were trying to teach something about the nature of records and databases, about the benefits and limitations of what Vannevar Bush called “associative trails”:
Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities…Vannevar Bush, As We May Think, The Atlantic Monthly, July 1945.
How would we teach them to think about different kinds of data structures? Not as computer science students do, but in terms of the tradeoffs of involved in representing, archiving, appending, and organizing any collection of information? The wiki format doesn’t lend itself well to the model of designing records with fields and coming up with a template for records, then seeding the database with partial records to give students some examples of the kinds of media projects that would fulfill the course objectives. We wanted to create a sort of fill-in-the-blank treasure hunt which could serve students and instructors alike as a resource in which to explore relationships of general structure (i.e. categories, fields, data types, associative trails) and specific entries, thereby discovering in the collected data patterns insensible in more limited scope. Databases are perfect for this sort of thing. Moreover, it would seem to me that understanding something of the various the ways humans have represented and archived knowledge and information through the ages–which today would include knowing the difference between a database and a wiki–would be an essential component of the “multimedia literacy” we were here to teach and which, quite logically, was the subject of our first teaching assistant orientation. Of all the fancy software suites, digital video production equipment, and multimedia labs on tap at this program, there was not one networked database application to be had. It seemed an astonishing oversight to me.
This was right about the time I began to find the ubiquitous wiki irksome. I began to have nightmares of Wikipedia as the deceptively attractive harbinger of that age-old (and to me most savage) dream of reason–knowledge without a knower. I began to wonder if we didn’t need some sort of later-day Braudel to make sensible to us the structures and practices of daily life in the recent past. Like back in the late 1980s when most administrative assistants had a working knowledge of some database program like FileMaker.
Braudel’s The Structures of Everyday Life (1979) is famous as a work of historical imagination which makes palpable the weight, number, and quotidian realities of the pre-industrial world and the capitalist system that emerged within its material order. The book I’m daydreaming about, The Data Structures of Everyday Life would be far less ambitious, but it would give some overview of the history of archives, memory machines, data storage and retrieval (álà J. David Bolter, not in abstraction, but applied in a variety of specific tasks and contexts. “Think about your email,” it might say, “how is that kind of communication structured? Do you know what ‘cc’ and ‘bcc’ stand for?” And in the telling of such prosaic histories would seek to preserve knowledge of the invention of thousands of otherwise invisible wheels, pulleys, levers, and gnome systems, for the retention, retrieval, transmission and use of all sorts of shared bits and nibbles.