Challenges for Wiki-Based Consultations

This week saw an unexpected focus on wiki-based dialogue and deliberation. To round out the series, here’s a list of shortcomings or challenges I observed back in 2007/2008 when I was reviewing the examples listed yesterday.

With regard to Politicopia (January 2007):

One challenge I see with a pure wiki approach in this context is the fact that in order for participants to contribute they must make edits. And while that is ok when collaboratively writing a document, it does not scale well when it comes to any type of polling or voting.

Secondly, the unstructured nature of the data makes filtering, aggregation, or visualization — in short, anything that helps with the consumption of large amounts of data — very difficult.

With regard to Virtual Petition (January 2008):

Here are some of the issues I see with a pure wiki approach:

• Unstructured, flat text — Almost impossible to slice and dice data in meaningful ways (generally true for most wikis, as far as I can tell): Which arguments or ideas are viewed more often than others? Which are considered relevant? What’s the level of agreement for each item?
• Little to no process support — Workflow, business logic etc. are practically non-existent on most wikis (and while oftentimes that is exactly the reason why they are so useful, in this case it’s a considerable weakness)
• Scalability issues — Ever try to run a vote on a wiki with 1,000+ participants? Now try that while the content of the item you’re voting on is in flux.
• Fairly limited (or at least very loosely structured) social networking capabilities — Who are my friends? What do they think? How can they help me filter information or peer activities?

Note that wikis have come a long way (what with folks integrating IBIS), and it all depends on the use case you’re trying to support, really. Four years later, some of my initial reservations may be a bit dated. What do you think? Do they still apply today?

Original post