User:Pi zero/essays/Wikiness

These are some of my thoughts on what open wikis, especially the wikimedia sisterhood, and most particularly Wikibooks, should be. The three major themes I address here are: what wikis are for, what sort of place a wiki should be, and what should happen there. This isn't a comprehensive vision, but rather a set of related ideas that share a common need to be expressed.

This essay is not, primarily, about the status quo of the wikimedian sisterhood. The sisterhood does great good in the world, and has the potential to do more; some aspects of it also do great harm in the world, and have the potential to do less; but most of that —good/bad, reality/potential— is material for some other essay. This essay is centrally about some aspects of potential we ought to strive for, touching on what is now done mainly to orient the direction of possible improvements.

I'm adopting in this essay a volunteer-contributor perspective. Alas, I've found this sharply at odds with a Wikimedia-Foundation perspective; and the Foundation's corporate culture defends itself with a dense web of mutually supporting assumptions. So, unless I want to be hopelessly distracted from my chosen themes, I have to set most critique, and all matters of reform, of the Foundation outside the scope of this essay, touching only lightly on critiques where they become particularly relevant to describing potential improvements.

Purpose

The purpose of the wikimedia sisterhood is to give "The People" —the rank-and-file citizenry of the internet— a voice in information-providing.

There should be absolutely nothing controversial about this. There should be absolutely nothing controversial about this.

Also, the purpose of the wikimedia sisterhood is to give The People —the rank-and-file citizenry of the internet— a voice in information-providing.

Did I mention that the purpose of the wikimedia sisterhood is to give The People —the rank-and-file citizenry of the internet— a voice in information-providing?

Seriously.

There does have to be a membership requirement for the wiki communities, but it's a pretty low bar: for the whole concept to work, the communities must limit themselves (with sufficient success) to people who support fact-based information-providing. "Fact-based" ought to go without saying as an obvious implication of "information-providing", but unfortunately we live today in the midst of a hot war between the fact-based and opinion-based worldviews — the difference between seeking objective facts as a foundation for developing informed opinions, or embracing opinions as a basis for choosing between, or even inventing, claims of fact. Though the war has been with us for thousands of years, it's heated up in the past few decades as the internet breaks down historical social dynamics of information flow. So "fact-based" does have to be said. One might be tempted to work the "fact-based" aspect directly into one's basic statement of the sisterhood's purpose, but by making it a separate addendum I hope to avoid the unfortunate fate of the Wikimedia Foundation's official mission statement, which mentions educational content but has been misapplied as a mandate for the Foundation to provide educational content to the world, using volunteer labor to accomplish the Foundation's purpose. I can't say this too many times, or in too many ways: education is the community's mission, not the Foundation's. The Foundation's part is to empower The People, not to wield them as a tool.

Some other crucial wiki principles follow from its People-empowerment purpose. A wiki is necessarily a self-organizing human community. Wiki content grows, organically, exercising the scope for sapient creativity afforded by a medium of simple, general building blocks (rather as an alphabet affords scope for literature). The success of the wiki concept is predicated on the ease-of-use-by-humans of wiki markup (historically, all the important formats that aren't just flash-in-the-pan are text-based; think of programming languages, still text-based despite decades of trying to make visual programming languages fly; or TeX and LaTeX; or UNIX). For that ease-of-use to have its full required effect (and the effect mustn't be shortchanged, as crowd-sourcing relies on the principle of the long tail), wiki markup has to be visible so that users pick it up by osmosis —as you make edits, you constantly see how things are put together, and because it's so simple, over time you pretty much can't help learning it as a result— and has to be ubiquitous, i.e., everything is done in it, without secondary formats for special purposes. Introduction of secondary formats tends to undermine the learning-by-osmosis process, and promotes exclusive high priesthoods of technical experts that undermine empowerment of the general internet citzenry. Note that WYSIWYG interfaces are inherently poisonous to wikis over time, as they, too, directly undermine the learning-by-osmosis metabolic process of wikis (if you think about it, the purpose of a WYSIWYG interface, as such, is to prevent the user from seeing how things are done).

Place

Human minds work best in a stable immersive context that defines and anchors their activities. For almost all of human civilization (figure at least forty thousand years), this need was served by physical places: kitchen, temple, playing field, guildhall, studio, office, etc. etc. Nobody would likely have thought to describe a physical place as an "immersive context", nor to remark on the fact that the use of a place could not easily be disrupted at will by any of vast numbers of people physically distributed over much of the surface of the planet. But then the internet happened, and we now notice these virtues of physical place because the internet doesn't have them. Just a few decades ago, with the coming technology looming on the horizon, people imagining its potential wrote of "jacking into cyberspace", an immersive computer-generated place; but so far the technology hasn't delivered. Instead of immersion, we get to peer at the internet through a narrow porthole, perhaps the size of a smartphone or at most a laptop screen.

I don't see us getting out of this fix by adopting some new sensory-immersion technology. Such technologies have been trying to happen for some years now, and eventually they will happen (just as 3D movies finally happened... after we'd known technically how but failed to adopt it for about half a century); but  (a) it's not likely to happen tomorrow, so we shouldn't wait for it,  (b) dominating sensory input doesn't imply high bandwidth or stability, and  (c) such technologies may inherently lack general-purpose practicality, as despite our internet connections we should always expect to still live primarily in the physical world. So we need to find a more effective sense of place on the internet without the deus ex machina of an unspecified technological revolution.

The question is, then, how to maximize the user's sense of place within a mostly-text-based wiki medium. Some means are already around, if we take thought to apply them. Text-based UNIX shells are stronger on sense-of-place than most graphical computer interfaces, due to UNIX's characteristic pervasive use of path names. Even peripheral devices are located at a place in the tree (recall the phrase "flames to /dev/null"?); and, moreover, the user has a location in the tree, a current directory that defines relative pathnames and therefore determines what the user can readily "see". With a bit of technical appreciation of what's going on around you, changing —going— to the root directory of a UNIX system can feel rather like descending to the subbasement of a large building, where you're surrounded by the plant services that maintain the more frequented spaces above (I always feel in such places as if there ought to be background sounds and smells, perhaps a hum or thrum of machinery and odors of concrete and metal). That UNIX shell sense-of-place is only about a step below that of a text adventure, using words to draw the player into its virtual world. ("This is an open field west of a white house, with a boarded front door. There is a small mailbox here. A rubber mat saying 'Welcome to Zork!' lies by the door.") A well-chosen metaphor, confidently projected, can provide elements of both immersion and anchoring; a moderate current case on Wikibooks is the Wikibooks Stacks.

On further thought, perhaps it's not an accident that UNIX shells have a stronger sense of place than graphical user interfaces. I've already remarked on the longevity of text-based formats. Notice too the extreme difficulty of adapting most good books into movies; words can appeal directly to readers' imaginations while movies suppress most visual imagination and can only evoke other kinds of imagination indirectly. The implication is that for purposes of appeal to the imagination —which, we may suppose, is extremely valuable for on-line sense-of-place— words are effectively a far higher-bandwidth medium.

One way or another, we should be looking for ways to project a stronger sense of place. Reaching into my pre-internet experiences of a good academic library, I recall entering through glass doors, past a reception desk where someone is on duty and probably reading or doing paperwork, to a main rotunda with a physical card catalog —cabinets of deep trays of three-by-five index cards—, reading desks, magazine racks and a few shelves, and doors leading off into the main stacks. Wikibooks atm has a long way to go to match that immersive experience.

Interaction

Interaction is key to human experience.

I believe this calls for a tiny addition to wiki markup. On one hand, the advantages of wiki markup multiply from its being small and simple. On the other hand, wiki markup has a huge leverage advantage so that a tiny change there can have a huge impact (one of those Archimedean places one might stand from which to move the world). I am therefore, gingerly, introducing a small set of elementary interactive primitives into wiki markup; see Help:Dialog. Learning to wield them effectively is, I think, going to be an even bigger adventure than implementing them (an open-ended proposition already underway now for several years); but that's a discussion for elsewhere, my concern here being why and for what one would want to use them. I see two major domains of interaction: interaction with the reader, and interaction with the contributor.

There's a lot more to a well-taught class based on a textbook, than just reading the textbook. Ideally, one studies assigned parts of the textbook; then attends a lecture on the material, by a human instructor with much wider, and perhaps more current, context; and works exercises and gets feedback from human graders. Depending on circumstances and instruction style, various interactive means may be used to heighten context-sharing between the lecturer and students. On an educational wiki, while the medium doesn't lend itself much to real-time instructor-student interaction, with the addition of a few strategic general-purpose interactive elements to wiki markup (!), it should be possible to offer an interactive experience at-one-remove between the student and the wiki authors of the book who contribute to growing the interactive elements.

On the technical side — hence, for contributors — the interactive elements should also provide direct relief from the dual problems of mechanical tedium, and poor take-up of out-of-process instructions. Mitigating mechanical tedium, with its attendant elevated workloads and gratuitous opportunities for error, presumably needs little remark. Out-of-process instructions may need some explanation.

There's an old joke, "When all else fails, read the instructions." That's from the user's point of view. On the tech support side, the joke is "RTFM". Wikis are chock full of instruction pages of various kinds, and it's not wrong for some such pages to exist, but separate instruction pages —especially when you have to stop what you're doing to go off and study them ("out-of-process")— are evidently not in themselves a highly efficient way to disseminate knowledge of how to perform an immediate task. This is especially true on wikis, which depend for their success on the long tail principle — that is, there are a lot of people on the internet who, though they wouldn't make a large initial contribution to a wiki, would willingly make a small contribution if it's made easy enough; so that if you make contribution —especially entry-level contribution— easy enough, the sum resulting increase in contributors and contributions is large enough to create social momentum for a wiki community. The trouble is, requiring the user to go off and study a separate instruction page isn't inexpensive. As users become more engaged by a wiki they'll read some such pages, but usually not when they're in a hurry to get on with a specific, seemingly simple, operation. Alternatively, given (again) simple interactive primitives within wiki markup, one might grow interactive semi-automated assistants —wizards— to guide users through various wiki tasks, lifting tedium while providing the particular instructions, in-process, that are directly relevant at each moment.