Last week I was asked about information management in Croquet. Editing and editorial are tough problems in any global information system. I don’t have a magic bullet, but I do think we have two general approaches.
1. I think there are things we can do involving progressive reveal, filtering, and spatial visual/aural representations, and these do go beyond what is possible in, say, the WWW. As just one example, consider how much effort has gone into unsuccessful attempts to show you what’s on the other side of a link without forcing you to follow the link and lose your present context. In Croquet, you can see through a portal to another space and get a pretty good idea of what’s there, without actually going through. It’s somewhat like looking through a shop window from the street, or as if some sort of magic book in Harry Potter showed you the animated action of the book even as you gazed at its closed cover or spine. So a bare link is a pure unit of information that we cannot manage at all (we have to use it first), while a portal we can see through allows us to manage it (e.g., evaluate it’s worth) even as we originally see it. As another example, we have constructed virtual magic glasses your avatar can wear or not, which allow you to see things (e.g., annotations) created by one particular person or group. You can stack any combination of such glasses, or remove any of them individually. (We’ll be presenting some of the latter at the upcoming C5 conference.) Here a single use of a magic glass (e.g., a single gesture to put it on or take it off) allows us to control a host category of information.
2. Croquet is fundamentally a collaborative environment. We’re very big on distributing the load. We distribute computational load over the participating machines. We also want to distribute the work of content creation, editing, and editorial among the participating users. The security model is intended to allow scalable management of individual capabilities for different activities on different objects by different users. We hope that this will generalize on the success of social editing such as http://wikipedia.org/. (We’ll also be presenting some edge-tools for content creation and development at C5.)
I don’t feel that any of these alone is clearly “enough.” Whatever that means. But are they collectively enough? I’m betting the answer is yes, and my reasoning is based on math. I think the key to managing information is to ensure that the ability to manage it scales at least as well as our ability to encounter it. For example, if Google presents N links per query, I need a way to manage more than N links per query. Google provides many such tools. For example, it ‘and’s the result sets matching multiple search terms, so that you only get the results that match both of what would otherwise be separate queries. It also orders the results by a measure of quality, and so forth. It works pretty well, but I think there’s a general feeling that at present, it produces results faster than users can manage. We want to even that up more.
Very loosely, peer editing (2, above) is meant to ensure that the same number of people producing content are also able to edit it. The ideal is to actually have the number of editors approach the number of users, rather than merely approach the number of producers. That isn’t generally true on the Web, but is true in various special cases of “social network” applications (such as Wikipedia). Whoever created and edited the information, we hope that scalable information interfaces (1, above) are able to present information no faster than we are capable of managing it.
Of course, to really use math to know if this works, we need a measure of information and a way to measure how well we can access it and how well we can manage it. I don’t have that yet. Besides, this a blog and not journal paper.
