May 2007 Archives
I'm in Barcelona, where I presented this morning a wiki I'm doing for a client[1]. A couple days ago, two of the contributors were arguing about the look & feel, one wanting to make things prettier, the other saying that it doesn't matter as a wiki is all about content. “It's ugly!” says one, “It's not, it's useful content!” responds the other. I was sure that this kind of conversation would arise sooner or later (actually sooner and on an ongoing basis). I did warn them upfront that this wasn't the kind of web site they're used to, putting the emphasis on both the content and the application sides that characterizes their wiki.
Of course, saying that websites are mostly good-looking empty shells while wikis are ugly piles of dry content is a bit extreme, but I'm sure you know the feeling. I came out yesterday with a metaphor to compare those. Traditional web sites are like whole milk, they taste great but can be fatty. Wikis are like skimmed milk, they taste like water but contain all the nutriments without the fat. One could arguably say that skimmed milk is healthier than whole milk, I personally settled on the half one although I love whole milk ;-).
More seriously, it's a fact that an empty wiki rarely looks good out of the box[2], and that may be discouraging or repelling for a lot of people. At the same time, it's also easy to fall into the classical trap of focusing primarily on the look, because it's easier (on the surface only) and funnier than producing and organizing content. Wikis are, in essence, web sites, so they don't escape the same design principles about usability, navigability, information architecture, etc. Another key difference here is that, with a wiki, everyone becomes an editor, and has a wide play-field that goes beyond simple content (just think about the importance of good hyperlinking for example). So the trick, for designers, is to find the right balance between making things look good while keeping the ease of use for both those who contribute and those who consume the content. Since not everybody is born a web designer, this explains why wikis are introducing a whole bunch of new roles, like gardners who will let people plant freely and later shape things up to help grow the wiki properly.
I would love to hear your experience about wiki design, and how that question impacts your choice of software.
Notes:
[1] For the curious, it's based on Confluence from Atlassian, and does a little bit more than just a bare wiki. I hope I'll be able to tell more about the client and its project, as it could make a pretty interesting case study (insert climax with web 2.0, folksonomies, RSS and a David against Goliath fight between the small grassroots wiki vs. the big top-down IT-baked one-size-fits-all portal. Who will win? May be soon on a blog near you ;-).
[2] I'd argue that most open-source wikis really suck in terms of design. You know who to blame: software developers aren't exactly the best web designers, and web designers rarely contribute to free software. In my initial evaluation, the cost of design and custom code developments to move MediaWiki up to par with Confluence for the needs of this particular project would significantly offset the cost of the license. Wikis, unlike blogs, offer a good market for software vendors and a few are really striving.
While watching the launch wreckage of Truemors, I came across a few interesting tips about managing online communities:
- It’s the social part that is the killer
- Some Community Tips for 2007, Seven tips on how to run a successful community (I love the rant about the term User Generated Content!)
- How To Keep Hostile Jerks From Taking Over Your Online Community by Cory Doctorow
- Spam, Trolls, Stalkers: The Pandora’s Box of community, very interesting tips about moderating conversations in virtual space, from Teresa Nielsen Hayden (whom Doctorow calls a “troll whisperer”)
Teresa uses a technique she calls Disemvoweling, which is the removal of vowels from text as a technique by forum moderators to suppress Internet trolling and other unwanted posting. I advise it too, and I successfully tested a similar technique on my French blog, by using the Debilitron service that turns a text into funny non-sense (I don't think it would work in English, but I'm pretty sure there is an equivalent for your Shakespearian trolls out there). It did indeed discourage the few trollers I occasionally get on a few heated-conversations here.
There are two Movable Type plugins for disemvoweling comments:
- shrpshr.pl which I find cumbersome because it forces you to hard-code trollers IPs in your templates
- disemvowel.tar.gz which requires MTKeyValues and allows you to moderate comments by simply editing them to add a few keywords (instructions are in the plugin archive)
It's by a search bot (!) that I found trace of my friend Cyril Fievet's new blog: ALLROBOTS.com, a blog/webzine on robots, robotics and Artificial Intelligence.
Two very interestering, and similar, perspectives in the recent Digg debacle about the publication of secret HD-DVD copy-protection keys:
Whatever the “right” decision was for Digg regarding whether or not to delete the offending post, Digg knows it is nothing without its passionate and participating members. The enlightened path should have been obvious to them: be completely transparent with users from the beginning. Before it took any action that stripped power from users, Digg should have shared its dilemma with the community, explained the conundrum and the legal advice it had been given, and then solicited candid feedback via its forum. Debate would have ensued, but everyone would have felt like they were part of Digg’s ultimate decision, even if that was deletion of the code. More than anything, passionate users want to be heard.
Thor: How Digg could have avoided a community revolt.
And in much shorter and more powerful way:
The people who man Digg want what everyone wants, respect. To be listened to. To be considered. Solicited. I think that's where the disconnect was.
Dave Winer: Why the users of Digg got pissed.
From my experience, lawyers, especially during a communication crisis, aren't the most subtle and communication- and/or business-savvy people. They tend to see things in black and white and focus on what they're paid for primarily: minimize legal risk. The expression « unleash the dogs » isn't pretty, but isn't baseless either! So, as much as the two advices above are good and rely on common-sense, it's not how lawyers function, and not every CEO is cold-headed enough to balance all risks, legal as well as business and image, during a crisis, when the dogs are unleashed and barking... Something tells me we haven't yet seen the end of this story.
I've read a lot of blog posts about Silverlight, and Jeremy Zawodny's Thinking About The Strategy Behind Microsoft Silverlight as well as Don MacAskill's Thoughts on Silverlight are really worth a read to grasp what's going on. Feel free to augment that in the comments.
Meanwhile, while Microsoft may gobble Yahoo!, Google can try one tactic to kill Silverlight in the egg: use DoubleClick to swamp the web with Silverlight-powered ads. That surely killed Flash on the intranet, why not try that trick again? ;-p
Greenpeace welcomes a greener Apple.
And now I know the portable Macs line will get an update sometimes this year, starting with the smallest screens.
Don't we love User Generated Content, all of it?
