lawbooks.jpgThe legal term corpus juris is used to note a book or record that has legal ramifications. The U.S. Code is so massive, unfortunately, that judges or lawyers will often use the overwhelming volume as a tool for their judgements, even if the plantiff or defendant had no idea what was written in there. Who has time to read through the whole thing? nobody. Nonetheless, that ‘ignorance’ does not diminish the validity of the code.  Similarly, a wiki with thousands of pages can assume a similar characteristic: massive amount of data with poor visibility from the sheer size.

The wiki is a wonderful thing for producing documentation and letting 10,000 flowers bloom. As an intranet, we are seeing processes, proposals, ideas, vendor backgrounds, monthly reports, and a myriad of details throughout the company. There are over 11,000 pages so far in the company. Unfortunately, no one has time to read it all. Worse, the very passive nature of it, and now the sheer volume of text, loses the punch for communication between managers.

“Where are you on project X?”
—- “DId you look at the wiki page for it? We wrote everything down.”
“No, I don’t have time. So where is it?”
—- “Okay. Let me esplain it to you in a meeting.”

Ah, the meeting. Like an over-friendly guest, there is no escaping the meeting.

Even then, the dense textual nature of the wiki (great for encyclopedia or software documentation) discourages the interactive dialogue that people use to sell each other on their concept, or their interpretation of the data. Alas, we are still slaves to the Powerpoint presentation.

There is some redemption here– and this seems to be the best use: insist that everyone at least skim through the wiki page before the meeting. If you write well enough, they may actuall read the whole thing. The wiki page becomes the primer for the discussion. If everyone has read the script, the play will unfold much more smoothly in the meeting. Also, the wiki makes a great place to gather all the source material for that *gack* Powerpoint (or OpenOffice presentation as I prefer) slides when you have to put them together.

So, what have I learned in the last 2 years with a wiki as an intranet?

  1. Wikis are passive. They do not shout out and grab people’s attention. They are like great sponges that soak up facts, but are no good at reaching out and giving you those facts on a plate with a nice side salad.
  2. Wikis are very good at collaborating texts from disparate contributors. This requires some force to get going, but once people catch on, they’ll never go back to attached MSWord documents
  3. Wikis are good source material from which to build a presentation
  4. Wikis are lousy at the actual presentation (no showmanship)
  5. Wikis require a handful of bold editors and combiners, who will mash pages together and build those collaborative texts (see #2). Otherwise, every department would keep their own version of the story
  6. The Recent Changes page is addictive.

So, all told, I am very happy with the wiki as an intranet. I overestimated people’s level of reading through the liber. There is no escaping the showmanship and the summations that managers want to see. It’s a great tool to get everything written down– if anything to make sure your peeps are doing their homework and actually researching things. In otherwords, just about anyone can bullshit their way through some bullet list powerpoints, but it is very difficult to bullshit your way through the longhand text of a wiki page: people cannot write lies that long, unless they are going for absolute fiction, which shows up in the text soon enough.

Rush 2112We are the priests of the Temple of Syrinx
Our great computers filled these Hallowed Halls

How much data does a business need to store? How much does a dot-com need to store? What about SOX? The storage vendors must be pouring money into congressmen’s pockets to make requirements all the more heinous– every email, every photo, every random document and the full diff history of everything so far. EMC must be salivating at where the requirements are headed.

I’ve been trying to work it out on the thumbnail math level. The metric here should be 1) product, and 2) customer. Every product has a text description, photo(s), price history, qty, and a half-dozen other table entries. The photos are the biggest wildcard here– the other stuff is really just some text. The product metric is trackable. I (as CTO) can set it to what I want. I can tell Marketing that they get xx kilobytes per product, or rather they tell me what the want to do, and I can do the math pretty quickly, and tell them that storage will cost X.

Customers are another story. There is seemingly no end to the amount of data to track there. We’re way past phone number and shoe size. Every click, every photo uploaded, downloaded, product added to the cart, not added to the cart, and the timestamps on every freaking event since Goldstein set up the first cameras all over Airstrip One. Beyond that, there’s all the derivative data: take any two or three data points that I have mentioned so far, mash them together, and voila! A whole new data set that needs to be put somewhere, with it’s own little dashboard.

There is an economy of data– and it’s not the cost of physical storage. It’s the cost of eyeballs on all these little numbers running around. It’s the Kuhn-like convincing of truth (not Truth) to your peers that your statistics are the right ones to measure. Who wins in middle management? The person who can convince as many other employees that _their_ view of the numbers is correct.

Punch cards begat tapes; tapes begat disks; disks begat databases; databases begat data warehouses; data warehouses begat “business intelligence”. BI begat dashboards. Everything up until that last step was sheer fecundity. The BI–>dashboard stage is the first step toward a “meta” level synthesis from all that data. We now have too much data to comprehend. But will the trend continue toward less presentation? Will it swing back toward the swamping? Who can trust the synthesised conclusions? Where is the rigour around the methodologies that produce these dashboards? What next? “data consolidation”? “derivative decisionment”? It doesn’t really matter to the storage people: every derivative, every summary, every consolidated report still requires that much more storage. Every time we breed one set of numbers with another, we need to store all the children.

Clapton is GodAmazon launched their Amapedia – a wiki of everything they and all their affiliates sell. I am not sure I get it, though. Just because something is wiki, it doesn’t mean I will get all fired up to go scribbling across their empty articles. Why should I fill in their content for them? Why should I help Amazon sell a bunch of books about fruit?

We all contribute to the wikipedia because we feel like we’re contributing to the Greater Good, The Source, The Permanence of Man. Make it in the wikipedia, and you’ve achieved immortality, in a way. My Grandmother made it– good for her. But where’s the feel-good for writing some ad-copy about a watch? Sure enough– the articles in the Amapedia with the strongest (only?) content are the ones about strategy games, computer games, and pop music. In otherwords, products gravitating towards subjective pop-fluff that the kids like to shout about. We have reached the corporate-sanctioned version of “Clapton is God”, where we delude ourselves to think that subjective opinion will battle it out toward some greater truth.

eCommerce _must_ embrace the community. Content must rely on the mass contributions of the customers. The problem is– how to involve the customers to the point where they feel like writing your ad copy for you?

I’ve mentioned before that my company uses MediaWiki as a platform for the intranet. this has been a huge success, but we’re still seeing some shortcomings. Namely: a lack of elegance around tabbed tables and spreadsheet-like numbers. Almost everyone in the company has contributed something to the”goat” (our nickname for the intranet), but more often than not, people still want to refer back to some excel (bleh) spreadsheet back on another fileserver.

Certainly, the mediawiki markup doesn’t handle tables very well. Ther are hacks out there to handle simple tabbed data, and convert it to a standard wiki table, but these are still ‘hacks’. Even then, there is no computational (read column sums for totals) abilities here. As such, managers still want to keep their inventory summary reports, marketing penetration reports, and general TPS reports in spreadsheets. It hurts the ‘quick communication’ that should come from a wiki– hence the name.

I think the core issue here may go deeper here. I have had numerous conversations with managers and others who try to publish on the wiki, only to see a cursory bullet list or series of abbreviations and summed numbers with no context nor explanation. The deeper issue here is that, despite all that time spent in humanities classes, I am convinced that most people do not enjoy writing. It’s easy to assume a shorthand when talking with other employees, as so much background and players in a conversation are common, and therefore “don’t need to be esplained”. This is an easy excuse to make, I fear. It deprives the reader of a proper context, and allows that reader to fill in his/her own details. No wonder specs go back and forth so many times.

For me, an important point to make between publishing on a wiki intranet and sending an email to your manager is: your manager knows almost everything you’re dealign with right now, and therefore may not need the full explanation; someone reading your wiki post may be clear on the other side of the company, or a complete newbie, or both. Without that context, the page will be of little use. Fortunately, wikis provide such easy linking that the context can be as simple as a few sentences salted with links to the entire background. Too bad so few writers see this.

What do you get when you mash up open directories and MeidiaWiki? Wikology, that’s what. Wikology is the wiki for all those who make their living in filthy lucre of commerce, rather than the high-brow banter over at wikipedia.

Continue reading »

Just remember where you got them…

I would like to make sure that everyone who sees these photos taken from my various journeys around the planet understands that the photos are hereby published under the GNU Free Documentation License. This basically states that you can use, modify, print, spin, fold, or mutilate the pictures in anyway you would like, as long as you grant credit back to where you found them (this website) and that you grant the same rights in kind.

Continue reading »

© 2010 Dave Jenkins contact me via twitter @davejenk1ns or via email blog at davejenkins dot com Suffusion WordPress theme by Sayontan Sinha