Jon Udell: Collaboration

"Sir, were there reasonable alternatives at the time?"

2002-08-14T13:59:54-05:00

Having recently found his voice, Ray Ozzie is also finding that he has a lot to say -- both on his his blog and elsewhere. In an article today on news.com (the decorated version is better), he concludes:

Someday, some shareholder is going to lose quite a bit of money because an electronic message was "sniffed," or "spoofed." Someone's health or financial records are going to get into the wrong hands. A design will be compromised; someone will get hurt.

And at that point, network television cameras are going to be focused on a lawyer who's asking a company executive, or a government official, "Sir, were there reasonable alternatives at the time?"

(Also today, on his blog, Ray cites Charles Mann's extraordinary Atlantic Monthly piece on Bruce Schneier, which I mentioned here a couple of weeks ago, and which is now -- happily -- online. It's crucial for more people, and especially non-geeks, to understand Schneier's philosophical transformation and current thinking.)

For me, the most salient fact about Ray's career is that he has chosen to tilt at not just one windmill, but two: collaboration and security. We tend to preach both but practice neither. Partly that's because we care less about these things than we say we do and believe we should. Do you communicate with coworkers as often and as well as you'd like? (If not, why not?) Do you switch from your cordless phone to a landline when ordering a pizza with a debit card? (If not, why not?)

Partly, though, it's a matter of architecture. The path of least resistance rarely coincides with the path of highest value, but given the right architecture, it can. As Ray has discovered, blogging represents an architectural solution to some longstanding problems that have plagued public online discussion. Groove, likewise, aims for an architectural solution to secure collaboration. Since "security" and "collaboration" are contradictory and almost mutually exclusive from IT's perspective, that's quite a challenge. But it's inescapable.

Cyberspace is not really borderless. More accurately, it's resolving into sets of discrete, sometimes overlapping, sometimes concentric spaces. In these spaces, people and documents gather for moments, days, or years. Requirements for confidentiality run the gamut. Public and semi-public spaces need to advertise their existence, in order to promote awareness globally or within various groups. Private spaces need to be, well, private. Everywhere, strong identity (or at least strong pseudonymity) should be a given.

Weblogs don't yet offer an architectural solution to secure semi-public collaboration. Wrapping SSL and passwords around your blog can work, but the administrative hassles involved push this option far off the path of least resistance. Groove-style "always-on" and "complacency-immune" security sounds appealing, but it's not a solution yet either. It works by invitation only, and that cuts across the grain of blogging which thrives on linking and serendipitous discovery:

A collection of weblogs isn't just a pool of documents. It's also a knowledge network, where at each node human intelligence performs the routing function. The network's architecture is publish/subscribe. Its protocol is RSS (Rich Site Summary), a simple, powerful, and popular application of XML. Bloggers tune into other bloggers' RSS channels; they select and react to items flowing through those channels; they post items that also flow out on their own RSS channels. It's a kind of Krebs cycle where the input is individual thought and the output is group awareness. [Google and weblogs: best hope for KM]

So what's the architectural solution that will make the cells of this awareness network semi-permeable in the appropriate ways? Perhaps translucency is part of the answer. I'm not smart enough to see the endgame here. But I'm sure glad to see that Ray's on the case!

Addendum: The phrase "Patterns of cooperation without vulnerability" seems to capture the essence of the challenge.

Ray Ozzie: Why?

2002-08-06T15:47:39-05:00

From a remarkable essay by Ray Ozzie today, entitled simply "Why?":

We spent years and years at Lotus trying to convince people of the "higher order" value of collaborative processes, sharing, and KM. And I learned the hard way that fighting what appear to be natural organizational and social dynamics is very tough. Which is why eMail is the most popular collaboration tool on the planet: it works the way that people naturally want to work. And which is why Groove is built upon a client-side, personally empowering "email model" than an "app server" model. Mobile, instant, ad hoc, private. Effective collaboration tools strike a balance between personal need/behavior and collective/organizational need.

And so here I sit, typing into Radio. The personally-empowering client-side online/offline UI of Radio, in my view, like Groove, offers us a glimpse at a new model of interaction that may indeed make it more natural to post into a public space. Or maybe post into "semi-public" spaces, more naturally. Which is why I've been fascinated by what lies at the juncture between the eMail model, the Groove model, and the blog model.

I've spent many fewer years than Ray, but still a goodly number, trying to convey that "higher order" value. And I also learned the hard way that you can't swim upstream against what people naturally want to do. What is remarkable about the present moment is that the current may be shifting. Public or semi-public communication that once would have seemed odd or pointless can now (under the right circumstances) begin to be seen as normal and useful.

First, what kind of technology can be used to achieve a balance between "working in a virtual fishbowl" and "working in a virtual SCIF"? (Secured Compartmentalized Information Facility, for those not familiar with government lingo.) What are the useful points on the gradient between authentication and trust, and pseudonymity? What are the human interface mechanisms that might be employed in trust-centric environments such as Groove that might adequately communicate -- not just to the individual, but to the group -- that a certain set of shared information or activity is being shared outward? And how can this be done while still maintaining the OHIO principle? (Only Handle Information Once) - that is, if information must be entered in two places, it won't be.

These are all the right questions. To answer them, I think we have to do the experiment. When some of us tried one recently, it was illuminating all around, for Groovers and for bloggers. Effective communication always has required the ability to compartmentalize, to empathize with and belong to different groups, to manage multiple layers of meaning, to project a range of identities. Now that we have so many modes of communication to choose from, balancing the interplay of public and private modes has gotten trickier. For what it's worth, my gut tells me that we need to have a set of flexible frameworks in place, to get people using them in a variety of boundary-crossing scenarios, and then to adapt the technology as needs and opportunities arise.

Flash Communication Server MX

2002-08-02T23:18:17-05:00

Flash MX and the FlashComm server together deliver event-driven peer networking, streaming-media services, a productive scripting environment that targets networked teams of people, and powerful components that embody the essential tools of collaboration. We've seen all these ingredients before, but Macromedia has combined them to create something different and new: a killer framework for the rapid development of collaborative software. [full story at oreillynet.com]

Microsoft, NNTP, and the mismanagement of knowledge management

2002-07-05T22:02:55-05:00

Robert Scoble has a theory about why Outlook doesn't include a newsreader:

For more than four years now I've been asking "why doesn't Outlook have a newsreader?"

Microsoft almost never answers this question on the record.

But, when you get their product managers off in a personal conversation over beers, they admit "it's cause our corporate clients don't want their employees to be off in newsgroups while they are at work." [Scobleizer Radio Weblog]

I find this amusing because Microsoft's news server -- the NNTP service that was available for free in the NT 4.0 resource kit, and is included in IIS 5.0 (and maybe in 6?) -- was five years ago, and still may be today, the most effective groupware/KM tool I've ever used. Coupled with a modern NNTP newsreader like Mozilla's, or even the one in Outlook Express, the MS NNTP service is a killer app for knowledge management. I wrote a book exploring the groupware/KM possibilities of this combo. I'll sound like a broken record if I go into the details but trust me, there was more juice there than most people realize to this day.

If Scoble's theory is correct, there is extreme irony here. Microsoft says that collaboration is job one for the decade, and I believe they think so. Witness the Groove investment, for example. Yet they soft-pedal an existing solution -- the wonderfully capable NNTP service and its companion client -- to the very corporate clientele who are supposedly driving the KM agenda.

My theory is different from Scoble's, by the way, though it leads to no less extreme an irony. My take is that the NNTP service was too good. If it had been put forward as the KM solution it could have been, Exchange -- the annointed MS groupware backend -- would have suffered (badly) by comparison. Preventing Outlook from accessing the MS NNTP service leveled the playing field. The only mystery to me is why the NNTP service is allowed to continue to exist. My guess: to satisfy the ISPs that MS keeps hoping to lure away from Unix/Linux.

Steve Yost on ubiquitous collaboration tools

2002-06-18T11:20:29-05:00

Steve Yost, inventor and proprietor of QuickTopic, disagrees with David Weinberger's assertion that collaborative software fails to thrive because companies are afraid to "hyperlink the hierarchy." The real problem is more mundane, Steve says:

Lots of organizations are extremely interested in collaborative tools now. The main reason they can't successfully adopt collaborative technology is because you can't get people to all go use new technology at once, yet in the face of simple email and browser use, that's what's necessary: the new technology usage has to be unanimous. If one person in a group can't or won't use the new tech, the forum reverts to the least common denominator -- ubiquitous email. The Boston Globe article David cites says just this:

But two big challenges face Boston's merchants of collaboration software. First is the need for the technology to show real business results real fast - rather than just ''greasing'' the way work gets done in an intangible way. Some people believe that e-mail will remain the dominant collaborative technology, and it will be hard for other, more complex software packages to supplant it.

[Blur Circle]

Email's ubiquity remains its overwhelming virtue, and there is a bright future for systems like QuickTopic which recognize that fact.

There is a chance that blogging will also achieve ubiquity, and I hope that it does because it's a much richer platform for innovation than email will ever be. But we're not there yet.

Work narration and wanker management

2002-06-15T10:26:27-05:00

Dorothea Salo, commenting on a recent item of mine entitled What if being non-communicative weren't an option?, raises important points about work vs non-work identity, control of expression, and "wanker management":

Sure people want to talk. They want to know what’s going on, and they’re willing to share what they’re doing and what they know about doing it. The problem is not people. The problem is the wankers who manage those people.

Really, it’s bloody simple. If you want people to talk, giving them the technology to do so is necessary but not sufficient. You also have to ensure that talking is a safe activity for them. That means controlling it as little as possible. That means tolerating -- dare I say, heeding and understanding? -- well-expressed dissent. That means accepting that sometimes we all say the wrong thing to the wrong people at the wrong time. That means a firm injunction against messenger-slaughter. The identical instant some wanker makes talking unsafe, workers will retreat back into mute Worker personae. [Caveat Lector]

Maybe I'm an exception to the rule, but when I was a manager what I aimed to control was that open communication would occur, not what its content would be. I believe fear of messenger-slaughter wasn't a factor, though only those who worked with me can say for sure. I know for sure, though, that fear of consequences resulting from failure to communicate openly and transparently was a factor.

In an article on instant outlining I wrote about something that both Dave Winer and I believe deeply: the value of narrating work as it proceeds. Dave tells me that UserLand simply cannot employ people who are unwilling, or unable, to communicate in this way. To me this looks like clueful management, not wanker management -- provided, as Dorothea says, that there is "a firm injunction against messenger-slaughter."

In my report on Alan Cooper's talk the other day, I left out an interesting anecdote. It seems that not once but twice, US military personnel and Afghan allies were killed and maimed because they called down 2000-pound bombs on their own heads. The reason was a design flaw in the Precision Lightweight GPS Receiver (PLGR, pronounced "plugger"). Evidently if you transmit the coordinates of a strike, then replace the battery, the device boots up and transmits not those same coordinates but rather your present position.

There were clearly team discussions at some point about the rationale for this behavior. But was this aspect of the work narrated in a way that made it visible? The open source mantra, "many eyeballs make all bugs shallow," cannot apply when there is nothing to see. Narration of work will increasingly become an imperative. Management can and should try to make sure that this happens. The most clueful knowledge workers will simply choose to narrate their work, because it makes the work more interesting and rewarding. The most clueful management will encourage and reward this behavior.

Matt Pope on the Groove experiment: reaching closure

2002-06-11T10:38:34-05:00

Matt Pope reflects on the recent Groove experiment:

As John B. and Hugh mentioned and Jon U. reported, the dynamics of social or professional interaction change immensely when the transition from private to public happens. It felt unnatural and outside of Groove's domain to be in a shared space full of strangers. I lost context. The experience confirmed - for me - my original position; public space is the domain of programs like Radio, while private space is the domain of a program like Groove. Both are good, but they are different (reference Jon's list of strength and weaknesses for Groove and weblogs).

The challenge is in making the transitions more organic.

Jeroen's public groovespace experiment helped crystallize why public groovespace is unnatural. In blogspace, interface and style and context are wholly personal. Not so in groovespace, where individuals share the space. I learned quickly when I met my wife that an unmade bed and messy countertops would be unacceptable in our shared space, i.e. our home. [Matt Pope's Radio Weblog]

Here's one other observation. The fact that this particular Groove space has been shut down might seem, from a non-Groove perspective, like failure. It wasn't. The space had served its purpose. This idea of disposable spaces is something Groovers take for granted, but it's a bit unusual from a web perspective. On the web, blogs and discussions form, and then either thrive indefinitely or fade away, but they are hardly ever explicitly terminated and deleted. The "Delete Shared Space" feature of Groove is quite an interesting thing. It brings closure.

As Michael Herman has been pointing out, content that ages and matures can flow to searchable archives. (And these may be public or private, according to need.) But Groove shared spaces, while they can be long-running, are also well suited to activities that have specific goals, and can come to closure.

Managing identity in Groove public spaces

2002-06-10T09:40:06-05:00

More notes from the Groove/weblog frontier. John Burkhardt:

The space started out with 4 or 5 of us, and in my mind a Groove shared space is private. Then the link got posted to the web, then the entire contents of the discussion got posted to the web. [John Burkhardt, via Scripting News]

Dave Winer:

By design, Radio makes it easy to make things public. On the other hand, Groove wants to keep everything private. The connection between the two products should reflect their nature. Publishing should be an overt act in Groove, something you do deliberately. [Scripting News]

I hope nobody felt "outed" by Jeroen's posting of the .GRV link (that is, an open shared-space invitation). It's not normal protocol, but in this special case I think it was exactly the right way to put some crucial issues under the microscope.

One of them, which I didn't mention yesterday, is the way in which an open-invitation shared space, if not configured to require confirmation of acceptance (as Jeroen's wasn't), exposes Groove vCards to public view.

John Burkhardt:

I might not want anyone in the world to get my vcard - but now they can! ... So, yes, its relatively easy to cross the boundary, but one has to be aware of the considerations. You can also, of course, allow someone to inject the .grv, but still require confirmation when they want to join.

One solution to this dilemma is to project a secondary identity into such a shared space. In Groove, the notion that you can maintain multiple identities and selectively project them into spaces is a basic principle. Because we lack cultural traditions for doing this kind of thing, it's probably not much utilized.

So, to sum up some lessons learned over the past few days:

- A Groove shared space, in toto, is not usually the best place to have a public-discussion that's open-ended in terms of the number of people who can join. Why not? Relatively heavyweight, more intimate than necessary for the purpose, not really compatible with Groove's trust model.

- But in special circumstances, it can be configured this way. Why? To maximize the "horizon of observability," demonstrate Groove capabilities to non-Groove users, or leverage Groovey capabilities not otherwise available in ordinary public web spaces.

- In such cases, the space is implicitly available for blogging and other exportation of content.

- However, the policy should be stated clearly up front.

- Groove's Welcome page is not yet a well-established way to advertise such policy.

- Identities should be projected into such public spaces with care, as they are exposed in ways not really compatible with Groove's trust model.

A report from the Groove/weblog frontier

2002-06-09T12:41:35-05:00

The collaboration in the public Groove space started by Jeroen Bekkers continues to serve (I think) a useful cross-cultural purpose. As I mentioned before, at issue is not merely how to connect the two environments -- weblogs and Groove -- but more fundamentally why? What problems will integration solve, and how?

I'm an early Groove user who has not found many close Groove collaborators over the past few years, and also an avid blogger. Most of the others in the space are, I would say, much more avid Groove users (and developers) who are now venturing into blogspace. These observations are, necessarily, biased according to my own perspective.

A couple of points about etiquette and convention. The space has both persistent chat and a threaded discussion. One day I showed up to find that the chat content had been moved to a discussion item. It made sense to do that, but I wondered whether the protocol should be that the archiver of the chat should leave a link, in the chat, to the discussion item that is the archive. The next time the chat was archived (today), that's what happened. My sense is that these kinds of conventions are still evolving in Groovespace.

The relationship between the persistent chat and the discussion tool is an interesting one. Here was my observation:

This is a little like parties at my house. We always try to get people to move into the living room (aka, the Discussion tool). But they keep on congregating in the kitchen (Chat tool). When we moved to a new house that is bigger, but with a smaller kitchen, I thought it would solve the problem. But nope. Everybody still piles into the kitchen :-)

One of the things I've been asking myself is, how is this space different from what could be accomplished in a QuickTopic discussion? Somebody dropping in from the outside with no Groove experience might think, "Not much, this is just a heavyweight version of that idea." Although the persistent chat adds a new wrinkle, that assessment would not have been far wrong. But then, Hugh Pyle added something that made the experience truly Groovey: an RSS reader. Suddenly the experience became qualitatively different. This news aggregator was a group resource. I immediately saw it as a way to work more effectively with (for example) my new colleagues at InfoWorld. I know of no other way to focus the attention of a group on a stream of news which is guaranteed to be identically and persistently available to everyone, and at the same time to be able to support collaboration around that stream -- i.e., discussions about which items to pursue.

Various protocol issues arose regarding the newsreader -- which, to be clear, is an incomplete project begun and then shelved by Agora, where Hugh worked before joining Groove. I wondered whether it had the Navigate Together capability common in Groove. It didn't. My understanding (which Hugh will of course correct if it's wrong) is that the GDK framework might provide such capability more or less "for free" but that this particular tool does not because it relies on HTML and Flash controls.

A second thing I noticed is that Groove's Copy Entry as Link feature, which would enable a discussion item or chat fragment to refer (through a link) to an RSS item in a news feed, wasn't working.

Finally, Michael Herman noted that the newsreader was triggering a space-wide unread notification (versus a tool-specific unread notification) with every new item. Effectively, this made the whole space appear unread all the time.

For these reasons, the tool was withdrawn, and another space intended for experimental exploration of tools was formed.

From Hugh's perspective, meanwhile, there were issues arising from the unusually public nature of this shared space. He wrote:

Every time a stranger appears in a group, the dynamics change. You go from feeling like a small bunch of people sitting around a table over coffee, to "who's that Sean guy", to "He's OK, writing some useful things." But that process takes a while, and affects also my feelings about past writings. Am I writing this stuff with a Groove Networks Inc. hat on? No, of course not; it's more informal than that. Could a stranger quote out of context, and make me hold to my words? Of course; I like the Rheingold-type "you own your words"; but the public-private boundary shouldn't be too fluid!"

Then there's also a mix of people who have met face-to-face and not. For me, I've met: Jeroen, Tim, Michael, Sanjay, Clive, Mark... and I've read your writings [that is, mine, Jon Udell's] often, so I know a little of who you are. But I don't know sydbarrett74 (say). Everyone is "present" in a concrete way, unlike a newsgroup or many other discussions.

This was subtler way in which a visitor from outside would find things different from a conventional public web discussion. Groovespace is far more intimate and immediate. You're alerted when somebody shows up, when somebody moves from one tool to another, even when somebody is typing a message. It's more intimacy than we have or expect in public web discussions.

Groove is optimized for a closely-collaborative working group, not a broad-based public discussion. This particular shared space, with its wide-open invitation, is therefore slightly pathological. Still, I think Jeroen did the right thing by opening it up so people can have the chance to see and experience a working Groove space -- just as UserLand's developers were, for a while, conducting their business using open instant-outlining spaces. It's vital to open windows into these worlds. Wrote Sean Heffernan:

Being able to publish selected discussion postings to a blog, as you manually did Jon in replicating your posting in your Radio, in a sense broadcasts what is taking place "in the kitchen to those still hanging in the living room", you are in essence attempting to lower the activation threshold ... or at least making others curious as to what's up in the kitchen, perhaps even enough to make them wander in.

There has been much useful discussion about how to manage the public/private boundary. Wrote Andy Swarbrick:

Whether space content is or is not made public should not be a matter of debate. The space owner (a non-existent entity in Groove) should set out clear terms and conditions of membership. If one of those is stated clearly that one or more tabs is to be blogged onto a website -- then who can complain!

This is where the debate around public/private issues should exist: what public information exists about a space before one joins the space. Groove 2.x began to think about the isse with the Welcome tool. But unfortunately it missed the boat. It misunderstood the question, imo, and went for an easy but useless answer. I mean, in a busy space WHO will actually use a Welcome tool! It is just a waste of space!

The only current value-added of the Welcome tool is the description. But does Groove push the boat out and ask the question should / can the welcome information be made available to non-members? No it does not. It ducks out of the question, possibly afraid of the answer.

The Welcome tool is a recapitulation of the policy document that was traditionally the first record in a Lotus Notes database, which described the nature and purpose of the database. Apparently, it's not yet a stable Groove convention.

How people find out about spaces, and manage the "horizon of observability," is a really important question. John Burkhardt blogged:

I just joined one of Andy Swarbs spaces of spaces. It's an interesting idea. Imagine that a blog is a human router for web content. This is a human router for Groove spaces. If you haven't been there, its basically a files tool with a bunch of .grv files in it. And he has an outliner in there too with links to each space, and some categorization.

Of course, I always want more. I imagined his space as kind of a hub. But in that hub I want to see where all the other links will take me. I'd like to see, for example, the member list, or the list of tools, or the most recent post. But I have to dive in. This gets back to your other point of the weakness of Groove being that you have to have everything on your machine. So it makes the process of joining a space a heavy weight process. It could be a completely different experience if coming and going was easier.

With Edge Services, it would be possible (and I think this might be what Dave would call a "Mind Bomb") to write a tool that could extract information from other spaces. So I could write a space aggregator tool, that could pull information about other members' spaces and display them in a hub space like Andy's. We could use this to in essence, publish what else we are doing in groovespace.

(BTW, following andyswarbs' Groove contact info to this website, I think it's actually Andy Swarbrick, is that right, Andy?)

I agree with John. This is another example of the "Heads, decks, and leads" principle I keep invoking.

Hugh, meanwhile, has blogged a tantalizing glimpse of a smoother on-ramp into Groove using a link of the form:

groovetelespace://rhj3q267ujfxhvgye5cxsrsu8s6netjdvrnf4vs/

Michael Herman's been thinking along the same lines. This is a great idea, especially if complemented by an information architecture that makes following such a link less of a leap of faith. Mechanisms to summarize activity in spaces, enabling would-be joiners to evaluate before taking the plunge, will be really helpful.

There's more, but that's enough for a Sunday afternoon that's just turned sunny. I'm enjoying this exercise in cross-fertilization immensely, though! Thanks to everyone for playing along.

Update: Tim Knip has exported the discussion part of the space (which also archives all the chat to date) to OPML, viewable here. Thanks, Tim!

Onramps, offramps, Groove, and blogs

2002-06-06T14:57:22-05:00

Jeroen Bekkers demonstrates that the membrane separating blogspace from groovespace is already more permeable than you might think:

Lots of activity in the Groovespace i started yesterday., Hugh Pyle, Tim Knip , Jon Udell, Matt Pope, John Burkhardt, Michael Herman and others are discussing possible integration scenarios for Groove and Radio. For people who would like to join this discussion, right click on this link and save the .grv file to your desktop. Then open it and you'll be invited to this space. (I'm sure better onramps from Radio to Groove from will appear soon) [Jeroen Bekkers' Groove Weblog]

For those disinclined or unable to download/use Groove, here is my response, in that space, to Michael Herman's question: "What problem are we trying to solve?"

There's more at stake than 2-way unfettered interop among various collaborative tools. I've done a boatload of that over the years. Have done NNTP to Web, email to Web, all the combinations. Making Groove a peer of these others is not, in itself, interesting to me, or a solution to anything.

To me the problem to solve is: can the different strengths of these different modes complement one another?

Strengths of Groove:

- context assembly (all the parts kept together)

- well-defined groups

- private/secure

- space is truly shared, interaction is direct

Drawbacks of Groove:

- don't always need all the parts here on my disk, the web's approach (pointers) is often easier/better

- don't always need well-defined groups, the web's fluidity and loose affiliation can be easier/better

- don't always need private/secure, can work against the "horizon of observability" effect

- don't always need shared-space direct interaction, weblogs that federate but are individually controlled are a different and useful model

Strengths of Weblogs:

- pretty much the inverse of above

Drawbacks of Weblogs:

- pretty much the inverse of above

I think the first thing to solve is for everybody to get clear that both of these modes are valid, and to understand in which circumstances to use one or the other, and how (and why) to transition between them.

Jeroen's public link to this space is essentially the QuickTopic (http://www.quicktopic.com/) (formerly TakeItOffline) strategy. A simple, natural way to connect the two worlds. What we are doing here is more informal and immediate than if we were writing for our weblogs -- "for publication" so to speak. And yet, Jeroen has extended the horizon of observability by pointing to the space. If collaboration here needed to "Take It Offline" still further, a subgroup could decide to move into another space into which the public would not be invited.

I think, basically, that more people need to experience these modes and transitions, using the existing/available tools, before anybody goes too far down the road of building anything. And hopefully by the time there is more awareness on both sides -- bloggers of Groove, Groovers of blogs -- things like edge services will allow rapid and iterative development of whatever glue is needed, in a bootstrapping mode that can be used, and reacted to, in an immediate and interactive way.

Matt Pope on collaborative flow between Groove and blogspace

2002-06-05T10:01:01-05:00

Matt Pope muses on how collaboration can flow into and out of Groove:

When the conversation merits multi-channel, synchronous dialog, a natural and seamless transition into a Groove shared space from Radio would be very cool. Within Groove, the communication is private and secure between the small group of individuals that need to be intimately engaged. It's like email except exponentially better because it truly is secure, and it is more dynamic, and it can be synchronous, and it can incorporate context (e.g. documents, pictures, markup, etc.) more readily. When the Groove communication ends, the thread, along with any supporting data, can be integrated back to the Radio environment for a wider audience to see. That would be nice. With Tim Knip's wares and edge services, this type of integration is becoming much simpler. This is just one example touch-point for Radio & Groove through SOAP. There are innumerable more. Perhaps we should start a brainstorm on that issue? I do think this is how we begin to maximize Groove's horizon of observability, which Jon Udell is aptly inquiring about. [Matt Pope]

I am very interested in trying that experiment. It doesn't have to wait for completion of edge services, or Groove blogging integration, either. I have been thinking about the dynamics of scoped zones of collaboration for a long time. It's really just a technique which can be applied using any collaborative tool. For me, years ago, the shared-space technology was the NNTP newsgroup.

I would love it if, in the kind of situation Matt describes -- where an issue arises in blogspace that really does require more tightly-coupled interaction -- I could experience Groove instead of email as the framework for that interaction. If you are a Groove user, find yourself in such a situation, and would like to involve me in a short-term discussion, please do invite me into a Groove space made for that purpose.

Groove 2 debuts

2002-04-15T20:41:53-05:00

The collaborative styles woven into the Groove fabric, such as instant messaging and peer-to-peer sharing, can make IT departments nervous. Here Groove 2 shines. The product is embedded within a framework that strikes an ideal balance between users' need for freedom and spontaneity, and IT's oversight requirement. [read more at InfoWorld.com...] ...

Wiki/weblog integration points

2002-04-04T15:44:32-05:00

Tony Bowden writes:

Having a wiki output OPML won't work, as it requires creating structure that isn't there. Having a wiki input OPML, on the other hand, might produce much more useful results.

Going the other way, RSS is a great connector. I just introduced myself to Sunir Shah the other day. I was going to suggest that MeatballWiki offer an RSS feed of its RecentChanges when I looked again and lo, it already does. Even nicer would be to include the first diff in that feed, so that somebody scanning a lot of feeds can make better choices about what to read. Heads, decks, and leads. The Wiki naming style makes for nice heads, and some items in the feed have nice decks (short descriptive tags) as well. The first diff would make a nice optional lead.

The model according to which Wikis federate is something that the blogging community could profitably study. Peter Thoeny explained it all to me once. Now I want to look into all that again.

Here's a column from two years ago that compares Wiki and newsgroup collaboration. It ties together several of these themes.

Soft security, Wiki, blogging, IO

2002-04-02T21:08:43-05:00

Dan Green, aka DotNetDan, passes along a really thoughtful page from the MeatballWiki on tenets of SoftSecurity. It begins:

AuditTrail. An audit trail tells you who did what, when. It doesn't necessarily allow you to undo what they did. It does let you know who was responsible.

ReversibleChange. If anything that can be done, can be undone, no damage need be permanent. Version control is one way of making changes reversible. You can reverse a change without knowing who made it originally.

DelayAction. When you can't reverse a change, delay that action until PeerReview has a chance to prevent disaster.

EnforceResponsibility. Knowing who was responsible is not enough. There must be consequences.

PeerReview. Your peers can ensure that you don't damage the system.

Dan also wonders how Wikis and blogging/IO compare. I'd say the most basic difference is that Wikiites inhabit shared spaces, while bloggers and IOers occupy individual spaces which they then agree to federate in various ways. But it's a continuum, not an either/or distinction. Wikis also federate, and blogs and IOs can become shared spaces. Many modes to explore, many ways to learn and share.

Writing in Mozilla

2002-03-15T11:41:31-05:00

I've been waiting for a very long time for Mozilla to become dogfood. The good news is that 0.9.9 finally is. The bad news is that my breath is going to smell like dogfood for a while. But that's OK. There was a ton of stuff in Netscape 4.x which was never fully understood or appreciated. As Mozilla resurfaces and extends that functionality, it's important to understand and document what's happening.

From my perspective, some pieces of Netscape/Mozilla that seem ancillary to others are of vital interest to me: the mail/news client, and the message composer. That's because I've always thought two-way communication, not one-way publishing, was the true purpose of the web. Messaging tools and environments were always at the heart of this, for me. The Netscape 4.x suite of apps -- browser, mail/news client -- made remarkable advances, more than is generally understood or appreciated. The vision, never fully realized, was to unify the browser and mail experiences. But when the air went out of the balloon, that hadn't happened. It still needs to, and eventually it will.

There's explosive activity in blogspace right now. Mozilla can add even more fuel to the mix. I'm writing this essay in Composer, and will post it through XML-RPC to my blog, courtesy of Hannes Wallnöfer. The same Composer is used in the Mozilla mail/news client. There's tremendous synergy possible when a standard (and sufficiently powerful) writing tool is available in both domains. Of course, that was as true in 1996 as it is today.

This Composer is a little better than it used to be, but it's not five years better, yet. I think that's because improving it never seemed to matter to many people. Writing email was something everybody did, but writing email that's rich with images, links, tables, vector images, and equations -- in other words, writing email on a universal canvas -- wasn't something people expected to be able to do at all, never mind easily and routinely. Writing for the web was something some people did, and those people would have liked to be able to write on a universal canvas, but didn't demand it loudly enough.

The blog phenomenon, I hope, will finally push things over the activation threshold. If so, a number of latent issues will resurface. I've dealt with a lot of them before, and plan to write about them again as they come up, in various venues including this one. Here are some of the issues I see on the horizon:

Hypertextual writing. The experience of writing this document in Composer can improve in limitless ways: drag-and-drop link and image creation, smarter table editing, CSS stylesheeting, and much more. Implementing these things is hard. Doing it in a way that makes sense to users is infinitely harder.
Compound documents. Netscape 4.x did a clever thing. Its cid: protocol enabled messages containing images to refer internally to those images. This bundling effect is still missing from the web. Writers new to Radio can too easily create documents whose parts don't hang together. Fear of embarrassment prevents many from trying to write compound documents. This fear needs to be eliminated.
XML metadata. After I post this essay, I'll use Radio to add metadata (title, link). Happily, that shouldn't be necessary for too much longer. But as Sam points out, things keep changing. Our writing and reading tools need to empower users to create, exchange, and use metadata-enriched documents -- and to do the enrichment themselves.
Identity. As the problem of identity fraud worsens, the need for ways to assert identity becomes clearer. Here too, mechanisms have been available for years, but not widely used. Mozilla's mail client almost (but not quite) recreates the S/MIME capabilities that Netscape 4.x had in 1996. As soon as I can get a Thawte or VeriSign cert to work in Mozilla, I'll be able to use it to sign mail, as I routinely do. But the signing interface that's available in Composer, when writing email, isn't available in the instance of Composer I'm writing in now. I think we'll need to unify identity management across all our methods of communication. Doing that in a way that makes sense to people, not geeks, is the challenge.

To the Mozilla community: thank you for making, and eating, the dogfood. Rewriting was a huge risk. Even though Joel said not to, what's done is done. Time may have been lost, but most of the really important issues are still on the table waiting to be solved. It's not just about the browser, not by a longshot. People are writing more, and differently. It's part of a trend that brings the web right back to its roots. For my money, the tool through which those keystrokes flow is vastly strategic. Is this going to be an important one of those tools?

We are reaching critical mass

2002-03-13T10:40:07-05:00

This is so cool! Everybody is figuring it out [John, Sam, Peter] all at once. Along the way, Peter asks some cogent questions:

What would Emily Post say about attributing links we've gotten from Link Mavens and Connectors?

How do we balance the needs of the larger network with the needs of the individual nodes (aka people) in the network? [Peter Drayton]

Peter's essay especially interests me because it cites John Hiler's excellent piece about how blogspace makes Malcolm Gladwell's ideas visible. I've been thinking along similar lines for years, and had recently raised the subject again. I wondered whether John's article was influenced by my recent item, though it doesn't say so, and quite possibly wasn't -- these ideas are, after all, simply "in the air." Then I wondered whether my older article, which I know was influenced by Gladwell's Jan 1999 New Yorker story, cited that story. I was sure that I had, but in fact, when I went back and looked, it turns out I hadn't.

I wish I'd cited Gladwell in my own 1999 article. But I've cited him often since then, and associative software would easily connect the nodes Udell and Gladwell in the social-networking dimension of concept space. Now here's something to ponder. As our reading and writing activities become increasingly transparent, it becomes feasible to automate citation cross-referencing. Consider, for example, how some of my sources are visible to you in the right column of this page.

How far do we want to go in this direction? I really don't know. It's an experiment I've wanted to do for the longest time. As we reach critical mass, the conditions are finally right to do the experiment. I can't wait to see what happens next.

Ways of paying attention

2002-03-10T23:46:09-05:00

Shelley asks:

Can RSS let people know that Jonathon Delacour's weblog has something worth reading? [burningbird]

Yes, if he writes a good title, one that draws me in. And if my software enables me to follow him (if I choose) on a titles-only basis. And if his allows me that choice.

Jonathon notices:

Previously, when I've written for books and magazines, I've left it to the editor and publisher to package my writing in a form that allows readers to experience it with minimal inconvenience. There are rules to follow; by-and-large, publishers follow the rules and readers are (unconsciously) grateful. [Jonathon Delacour]

Exactly. Jonathon is a wonderful writer. So is Shelley. Many, many more are emerging. Given that I can't pay attention to everyone all the time, my choice should not be all or none. I'd like to be aware of as much of what's available as I can, and to choose according to my (fluctuating) needs and interests.

It's important to note that this principle of structuring information is only one of many strategies. Not the only one, not the most important one. Blogspace is evolving other ways to manage the scarce resource of attention, even as it ratchets up the demands on that attention. One of the most crucial is the way in which we can rely on people, not software, as our filters -- a variant of the Google principle, or what I used to call Web mindshare.

"Paying attention" is an interesting phrase. It acknowledges that there is a cost.

Bootstrapping the knowledge network

2002-03-10T06:15:32-05:00

Bootstrapping the knowledge network

In the first stage, the tools encourage a degree of commentary and reaction to what you find or create (in k-logging mode). However, it also encourages a degree of stream of consciousness style. Progress, in that it can represent a contemporaneous record of the contextual issues that were top of mind. Problematic, in creating new content that eventually needs to be revisited and processed at a level once removed from the moment. [McGee's Musings]

It's true that I'm impatient for knowledge networking to reach critical mass. I thought the singularity would occur years ago, and I was wrong. I hope it's happening now, and while I could be wrong again, it's clear that something has changed. People are doing what I spent years of my life and hundreds of pages of my book advocating. They are migrating communication that is not necessarily private and interpersonal into spaces that are public and group-oriented. This behavior lays the foundation for all else that may follow.

We want nothing to interfere with the evolution of this behavior. In particular, we don't want burdensome rules and complex protocols to slow things down. The lesson of HTML, vis-a-vis SGML, must never be forgotten. At the same time, we would like -- if possible -- not to foreclose options unnecessarily.

It's been a while since I reviewed the forked path of RSS. In RSS .92 even the title of an item was made optional, which seems heretical to a metadata maven (like me) but makes sense when you are trying to bootstrap flow. RSS 1.0's approach, which requires item titles (as .91 did), and provides optional modular extensibility for arbitrary metadata, makes a different kind of sense.

I would say that RSS .92 (what Radio uses, BTW) is about promoting flow, and RSS 1.0 is about not foreclosing future options.

There was hot controversy surrounding these differing approaches. But nobody outside the relatively narrow world of users of RSS-oriented software heard a word about it. Just as well, as it turns out, because until there is a reason to care, people won't.

The progress that Jim McGee cites in his posting is becoming a reason to care. Once enough people do care, the problems he cites can be addressed. Maybe you could say that RSS .92 is the booster rocket, and RSS 1.0 the payload.

I don't think the boost phase would be compromised by enabling (not requiring) Radio writers to exercise the titling option in RSS .92, and then enabling Radio readers to scan titles (from .91. 1.0, and perhaps .92 sources). But in truth, it can wait. Until we get ourselves into orbit, it won't matter.

Heads, decks, and leads

2002-03-08T22:15:33-05:00

Heads, decks, and leads

I don't write in RSS, but by some kind of accident you can read my writing fairly coherently in a RSS aggregator. I never think about RSS when I'm writing Scripting News (unless I'm writing about RSS). I just write as it makes sense to me. I judge the result by how it looks in an HTML browser. Why? That's the way I've done it for the last few years. [Scripting News]

Dave, this isn't a discussion you have time for, during the upcoming "what passes for a weekend." You have a product to ship. So, file this for later. But, for the record, I do not wish to read blogs in the aggregator, where (as Shelley rightly says) they are stripped of context. I want to read blogs in situ. I want to scan for items to read (in their native context) using the aggregator.

Ideally, my aggregator would have a Pref like:

Show [Heads, Heads/Decks, Heads/Decks/Leads, All]

Default: Heads/Decks

The principle of heads, decks, and leads is a cornerstone of journalism. I don't consider myself a journalist, really, and wasn't trained as such, so I've come around to an appreciation of this principle more from an information engineering perspective. In engineering terms, we think about optimal allocation of resources. The resource of interest here is one of the most precious there is: human attention. Newspapers and magazines structure themselves using heads, decks, and leads because they know that human attention is a finite resource, and must be conserved.

A strategy that will work in Radio today is:

- Write standalone stories.

- Separately, write heads/decks, or heads/decks/leads, and publish only these to the homepage and category pages, with links back to the full stories. For completeness, the stories should recapitulate the heads/decks/leads.

People could do this, but in general they won't, it's too much work. If they want to blog in a way that respects the attention demands on readers, who -- as blogspace grows and diversifies, must process more and more flow, and will increasingly rely on RSS to help them do that -- they need some help structuring what they publish.

The UI issues are non-trivial, I agree. It's easy to say "just offer a template in the WYSIWYG editor" -- but in practice, it's never so easy to make this work smoothly.

This not something that needs to get solved today or tomorrow. But I believe it has to be dealt with at some point, or the knowledge network that is growing around this technology will be unnecessarily stunted.

RSS, supernodes, and Gladwellian Connectors

2002-03-08T11:45:29-05:00

RSS, supernodes, and Gladwellian Connectors

Both Jonathon's article and its commentary are of interest. In the article, Jonathon concludes:

The answer seems simple: offer the option to publish the title but not the content to RSS. Michael points to a side benefit: "It would give the art of writing headlines a whole new life."

In the commentary, Dave says:

Write as it makes sense to you to write.
The RSS is secondary to the HTML version.
Let the RSS readers pick and choose what makes sense to them.

To me, it makes sense to write like this:

[item]

[link]...[/link]

[title]...[/title]

[description]...[/description]

[/item]

It makes sense because I want the RSS readers to be able to pick and choose what make sense to them. This is, to me, an engineering principle that helps the RSS network to scale, as I believe it needs to do by orders of magnitude.

To Shelley's point:

I like being notified when a person's weblog is changed, and check weblogs.com regularly. But to strip a person's thoughts and plunk it into a queue that gets spit out to me on this plain white background -- this isn't a true group forming and communication process, is it?

In and of itself, no. It's only one piece of the puzzle. Blogspaces today are relatively few, and relatively homogenous. The degree of overlap among blogrolls, or (what shall we call them, channelrolls? [1] [2] [3]), is quite high. This will change, I am certain, as blogspaces become many and diverse. Means of interconnecting these communities then become critical. HTML and RSS renderings will work in tandem to accomplish that interconnection, as they already do, but I foresee an even larger role for RSS.

To explain why, I refer to Malcolm Gladwell's original New Yorker story on Lois Weisberg. Here for the first time I was introduced to the notion of what I call the human supernode. We all know a few people who are wired like this, people who seem to know everyone. In geekspace, Tim O'Reilly is one such, and Dave Winer is another. Gladwell's story shows how the essential quality of Lois Weisberg is not simply "knowing everyone" but, to me more profoundly, "belonging to many quite different groups."

Elsewhere, Gladwell quantifies just how different these supernode invididuals are from ordinary folks. He ran an experiment (was this in The Tipping Point? I can't find my copy to check it) in which he presented a list of hundreds of surnames to a set of test subjects, and asked them to count the number of surnames belonging to people they knew personally. The result was not a bell curve. Most people knew a handful of the names. A very small number knew a whole lot.

My conclusion: we all want to achieve the effects that supernode inviduals do. But most of us aren't wired with the natural ability to be tuned in to many diverse groups, an ability that a lucky few are gifted with. Part of the future of RSS, as I see it, is to help the rest of us have some of the social power that those lucky few already possess.

2002-03-07T10:03:02-05:00

Trading RSS channels like baseball cards

Jenny sorted out the problem with her RSS display. She hadn't upgraded Radio.exe. Now, she's got it working. Excellent! Let the trading commence!

Actually, I guess baseball cards are the wrong metaphor. This kind of trading is, as they say in intellectual property circles, nonrivalrous.

Are we ready to address messages to spaces?

2002-03-06T09:38:34-05:00

Are we ready to take the next step, continued

My environment currently consists of a large group (say, 50 people) made of several interdependent teams (sub-projects). Some people belong to more than one team.

A lot of communication takes place via email that reaches a few people from this team and a few people from that team, in order to accomplish some task. So these are little sub-teams that spring up around a task and then disband.

A significant problem is getting the right people to know about new issues that the sub-teams form around. Those people may want to be a part of the sub-team, or simply track their progress.

With a tool like Radio, those sub-teams may be able to form around an issue, and communicate with each other, out of their own self-interest, just as with email. (Or enough like email that the members do not feel an extra burden just to reach people who may or may not be interested in their issue.)

Others can "listen in" on the conversation via Radio in ways that are simply not enabled by email. Almost everyone in the larger group would soon benefit from this ability to see into the day-to-day conversations of sub-teams they otherwise would not be aware of until much later, sometimes too late, or wastefully late.

I thin this transparency offered by Radio can help avoid the sub-teams from losing focus and thinking too much about people outside their focus. [Patrick Logan's Radio Weblog]

Absolutely. And you're spot on when you say "enough like email that the members do not feel an extra burden." This was the opportunity I thought I saw, way back when, when I noticed that:

- email was ubiquitous

- email clients were closely coupled to news clients

- news was a groupthink medium

Once I set up the private news server that unlocked the latent power of the already-universally-deployed news client, which shared the same message composer as the mail client that was in constant heavy use, I thought I was all set. There was essentially no new software to deploy, or to learn.

Why didn't a lot more people catch on to this? Why, even in my own environment which was, like yours, made of overlapping subgroups, didn't it have the effect I thought it should have?

I say again: it wasn't primarily about the software. It was about the willingness of people to work transparently, for their own benefit and for the common good. And about the ability of people to think in terms of messages addressed to spaces, rather than messages addressed to people. This is a deep anthropological issue. As a species, we are now being invited to communicate in ways more abstract and indirect than tens of thousands of years of cultural history have conditioned us for. I know we can adapt, and will. The $64,000 question for me is: how soon?

Cultural evolution and K-logs

2002-03-05T22:31:59-05:00

Are we ready to take the next step?

Some people are taking the concept of weblogs and applying it to the wider concept of knowledge management. The result is k-logging ("knowledge-logging"). But will it catch on - will your employer dump Lotus Notes databases in favour of browsers and blog-style brain-dumps? [WriteTheWeb]

From the story itself, an email interview with John Robb:

John Robb: Within a corporate context, K-Logs make it possible for any employee to add knowledge to an Intranet. It's easy enough to use (start-up in less than five minutes) that it overcomes resistance. Further, K-Logs provide people that use them two immediate benefits: 1) it is a highly visible way to enhance personal brand and 2) it is a great organizing tool that you can share with co-workers (it organizes your most important information over time). There is no other better way to get employee knowledge off the desktop and out of their heads and onto an Intranet where it can be archived, browsed, and searched.

I know. I've been there, done that. When I turned in the first draft of my book, my editor -- Tim O'Reilly -- said, "This is great, but I worry that you expect too much from people." It was true. We technologists like to think that if we can just come up with the right tool, all those wonderful k-logging benefits -- which are quite real, I can say from my own experiences -- will simply flow. But even then, I knew it wasn't just about the tools:

The cultural problem is far more difficult. The methods I'll present in the next few chapters presume that groups really want to collaborate - that is, share documents, move communication from interpersonal to group spaces, pool knowledge. "Our people are our only real asset," corporate executives like to say, and they mean it. They understand that their success depends mainly on what their people know, not just individually but collectively. A Lotus executive once claimed that there is an infinite return on an investment in Lotus Notes. Infinite! That sounds like brash computer-industry hyperbole. In fact it's arguably true when Notes captures organizational knowledge as it was designed to do, and is capable of doing. But mostly that doesn't happen, for lots of reasons. People tend to focus only their own tasks, and associate only within their own workgroups. People don't want to document everything they do. People don't want to think carefully about how they communicate, with whom, for what purposes, with what results. People don't want to share what they know, if they believe that doing so will threaten their own security. [Practical Internet Groupware]

So why am I suddenly deep into blogspace, hoping once again to achieve what Notes never could, and what my own brand of Internet groupware never could? Because culture evolves. What's more, as Richard Dawkins and Susan Blackmore argue, culture is evolution. Fifteen years ago, most people weren't ready for the kind of collective mind-meld that makes k-logging work. Five years ago, most people still weren't. Today...well, the jury's still out, but the mainstream interest in blogging tells me that maybe, just maybe, we're close to having a critical mass of people who are ready to live transparently, to narrate their experiences in order to better understand them, and to be informed by the narrations of others.

I hope it's going to happen this time around. But whether it does or not, let's be clear about one thing. Although the software needs to have a certain set of properties, software's not the gating factor. People are. There's really no mystery as to why the Web didn't go two-way from the start. If most people wanted it to, it would have. Maybe now they do. I hope so.

Using people as filters

2002-03-04T17:05:39-05:00

Using people as filters

Rael Dornfest: "The result is that when I wake up in the morning, I get to see a lot of the stories that come through Slashdot or from the New York Times that are interesting to me, without having to wade through Slashdot to find them." [ORN interview with Steven Johnson]

Rael's comment goes to the heart of what's happening here. As individuals become both producers and consumers of RSS feeds, they can use one another as filters. Today, Rael reminded me of some non-Radio RSS aggregators -- including his own Peerkat, and Carmen's Headline Viewer. Historically there wasn't a huge demand for these, since the centralized aggregators do a fine job with the canonical set of available channels. When channels proliferate, and when they inhabit spaces that the centralized aggregators can't see, it becomes clearer why a desktop aggregator is useful.

Sam's encounter with manufactured serendipity

2002-03-04T14:58:20-05:00

Sam's encounter with manufactured serendipity

Jon is right that Radio is a lab for group-forming, but one thing he apparently missed is that there is enough data out there for Google to be a part of the equation. [Sam Ruby's Radio Weblog]

Absolutely. The fact that blogs are exposed to public search engines is a key ingredient. I tend to take this for granted, though it bears repeated mention.

The tricky thing, looking forward, is keeping the manufactured serendipity going when you start to cleave off private or semi-private spaces. Years ago Netscape's Collabra handled this nicely. All your private newsgroups were indexed, but search results were appropriately filtered on user credentials. Even so, there were subtleties. When you play the game of information hiding, it's easy to forget what has been hidden from whom, and why. And since information sources are never homogenous, you also have to think about federating different search engines.

It's lovely when we can all share a common, open, and relatively flat infrastructure, as we do here. When we get to a world of overlapping and federated zones of collaboration, with differing policies about access and sharing, there will be hard problems to solve. In solving these kinds of problems, it will become much more obvious what all the SOAP/WSDL/UDDI plumbing was for. There will also be fascinating UI challenges.