Tools for Dialogue and Deliberation on Wicked Problems
How are you approaching scalability?
This is a clip/paste from an email I just wrote, but if you're thinking about a global IBIS system, it might be a perspective you haven't considered.
Today's IBIS systems require a moderator to organize a map. They assume that the unit of work is creating a map or sections of a map. In a massive IBIS system, the unit of work can be a single node.
The sheer size of the group creates different opportunities for work distribution and different methods for controlling map organization. Think social generative programming. [1] In a massive generative system, users don't have to worry about creating well-formed maps, they can just worry about creating a single node. Instead of worrying about how moderators organize the maps, (Which is harder to scale), I'm more concerned with building an interface that leverages social norms and behaviors to produce well-structured IBIS maps from many uncoordinated asynchronous actions.
Consider also that massive systems include groups of people that don't exist reliably in business teams. Let's say that 1% of users create nodes, and 5% of users critique the nodes that others have created. [2] What sort of system will encourage 1% of users to post anything, even badly formatted single nodes, then get the 5% of critiquers to refine it over the following month?
So... in thinking about scaling the problem, I'm not thinking of scaling using the same kind of top-down organization that IBIS currently relies on. I'm thinking "How can we leverage individual and group behaviors to stimulate single node creation, iterated node refinement, and self-organizing maps that minimize the need for moderators?" That approach makes user interface design much more difficult (i.e., deceptively simple). However, if it's done correctly, scaling will be a beautiful thing to watch. And that's why I'm still working on the mockups right now. ;)
Adam
[1] Mitch Resnick's "Turtles, Termites, and Traffic Jams" http://books.google.com/books?id=K8P1rX8T4kYC
[2] http://www.forrester.com/Groundswell/profile_tool.html or see the book "Groundswell"
Today's IBIS systems require a moderator to organize a map. They assume that the unit of work is creating a map or sections of a map. In a massive IBIS system, the unit of work can be a single node.
The sheer size of the group creates different opportunities for work distribution and different methods for controlling map organization. Think social generative programming. [1] In a massive generative system, users don't have to worry about creating well-formed maps, they can just worry about creating a single node. Instead of worrying about how moderators organize the maps, (Which is harder to scale), I'm more concerned with building an interface that leverages social norms and behaviors to produce well-structured IBIS maps from many uncoordinated asynchronous actions.
Consider also that massive systems include groups of people that don't exist reliably in business teams. Let's say that 1% of users create nodes, and 5% of users critique the nodes that others have created. [2] What sort of system will encourage 1% of users to post anything, even badly formatted single nodes, then get the 5% of critiquers to refine it over the following month?
So... in thinking about scaling the problem, I'm not thinking of scaling using the same kind of top-down organization that IBIS currently relies on. I'm thinking "How can we leverage individual and group behaviors to stimulate single node creation, iterated node refinement, and self-organizing maps that minimize the need for moderators?" That approach makes user interface design much more difficult (i.e., deceptively simple). However, if it's done correctly, scaling will be a beautiful thing to watch. And that's why I'm still working on the mockups right now. ;)
Adam
[1] Mitch Resnick's "Turtles, Termites, and Traffic Jams" http://books.google.com/books?id=K8P1rX8T4kYC
[2] http://www.forrester.com/Groundswell/profile_tool.html or see the book "Groundswell"
Views: 61
Replies to This Discussion
-
Permalink Reply by Andy Streich on
-
My only contribution at the moment is that you are asking the right questions -- very good questions.
-
Permalink Reply by Adam on
-
Thanks Andy.
I just found out yesterday that Mark and the Collective Intelligence folks at MIT are thinking along similar lines with Collaboratorium. Very cool.
Here are the mockups I mentioned above. As they stated in the Collaboratorium overview doc, "careful design of the rules of community interaction" took a while. It still needs some work. Due to my other work here at Save the Children, I don't have time to clean them up as much as I would like, or make more to show how most parts could work, so they'll have to do for now.
http://1button.org/collective-mockups-2008-09-16.pdf
-
-
Adam, along with many other things this has been in my "respond to" queue for a while.
I like your mockups at http://1button.org/collective-mockups-2008-09-16.pdf and think it's just brilliant that you're able to present such detailed UI ideas. Rather than critique them, in the little time I have just now I'd like poke the community to think about how to integrate UI work like this into the sensemaking paradigm.
One critical aspect of all sensemaking applications that's neglected in nearly all of them due to the desire to deliver them as web-apps is state-of-the-art UI design. Thus, the question becomes how do we combine your expertise like yours (and, to be bold, sensibilities like mine) with current suite of sensemaking tools?
We need rich client apps. There's only so much that can be done with an Ajax UI and most of that has already been done, Google Docs being a salient example. Sensemaking apps are more like CAD, vector graphics, and bitmap graphics applications. "Are" or "should be". That is, we need to be able to click and drag to move items or draw relations between items. We need to be able to zoom in and out. We need to be able to work in 3-D not just 2-D.
These are the sort of properties you now only find in Compendium which is, as one would expect, a desktop application. Web apps today have serious UI constraints. The concept of rich-client-apps is being addressed by a host of competing companies (e.g. Sun, Microsoft, Adobe) but there is as yet no clear winner or standard.
What to do in the meantime?
Groups
-
Developing the toolkit...
26 members
-
Human Nature
14 members
-
Steering Committee
13 members
-
Population
10 members
-
Energy Challenges
9 members
Videos
Photos
Badge
© 2024 Created by David Price.
Powered by
