WikiAsFloor

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Here's a question to ponder: What's the difference between filing an e-mail in a wiki and "filing" a memo on the floor?

If you can't visualize the latter, say you took all the paper in your filing cabinet and decided to file it in a flat space, just like most wikis' flat namespaces. That is, you threw everything onto your flat floor. You might create piles of paper, but they'd get shuffled about, lost, and they'd end up cluttering your workflow. Plus, the meaning of one pile would be opaque to others, unlike a well-labeled folder.

Using a wiki to organize information is often like piling data on the floor. Even the best structured 'hypertext' wikis are chaos. The best structured wikis are user manuals with a hierarchical table of contents.

Organizing is about predictability (cf. ObjectiveSpace?, OrderChaos). You should know where something goes or is without having to think about it, and in information space (cf. SematicSpace?) like a wiki that system should be understandable by anyone, not just you. The conventional solution to solving organizational problems is by introducing furniture, like tables, shelves, and even special purpose furniture like filing cabinets and map drawers.

Wikis function when they are collaboratively constructed by TheCollective, so that the SocialSemanticSpace? has become CommunityLore. One generation passes onto the next generation understanding of where things are and where things go. Yet these mappings are not embedded in the structure of the wikis, at least not commonly, and so they are fluid. This is a great power, and therefore often a great source of failure. On one hand, people can renegotiate boundaries, piles, locations, relationships, values, relevance, meanings, and interpretations. On the other hand, valuable knowledge about those categories can disappear after a mass exodus of veterans, and the wiki begans to decohere.

Generational knowledge is best kept in architecture. ArchitecturalCollaboration? is the best way to compel future generations to maintain some tradition. But architecture is also static, unbending. Embedding a value such as where to put railroad tracks so as to cut off black people from your community may hamper future generations who no longer wish to live under that value. In the microcosmic environment of SocialSoftware, the difference between a CMS and a wiki is that a CMS has a lot of architecture. It also means that CMSes are easy to maintain until the environment changes and they need to adapt. Wikis are tolerant to adaptation, but also equally never efficiently adapted.

In short, a wiki is just an empty room (cf. WikiAsRoom). -- SunirShah

Floors have affordances. With a floor you can stack, pile, sort, re-sort, shuffle, and heap. Stray bits of paper can be corralled in folders, or dumped in the trash can. You can use the floor as working storage for a project and then sweep things up when it's time to have guests over. FloorsSupportArchaeology? - the top strata is probably "new", and the bottom strata is probably "old". And you can see a *lot* if you arrange things on a floor carefully, even if the stable state of your project is for paper to all be piled neatly in labelled folders. -- EdwardVielmetti?

See also FloorChart

I'm a great believer in LocalIndex?es (locally known as RoadMaps), basically pages on wiki which are just lists of other pages about a particular theme. These seem to me to play the right role in MiddleSpace between one big, TopDown? taxonomy, and the completely unarchitected "floor". Local indexes are not the same as CategoryCategory (which is completely bottom up) : someone deliberately goes round and decides that these ten pages need to be clustered within a theme, and makes and maintains a page for that theme. (eg. something like http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?OnCities). At the same time, the local index page doesn't itself need to be part of any particular higher level structure. Nor is there a problem with cross-linking between two of these indexes (with each as a list-item of the other) so you don't force hierarchy.

Knowledge of such local indexes can be "lore". But it's also easy for newbies to learn. At the same time, there's no harm if other people who don't understand the structuration build their own alternative. They can quickly be connected with a "read with" or manually merged and on, #REDIRECTED to the other.

(also : http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?WikiAsAFloor)

-- PhilJones

WikiAsFloor

Discussion