| |
 |
Friday, August 02, 2002 |
|
Flash Communication Server MX
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]
11:18:17 PM 
|
|
|
Friday, July 05, 2002 |
|
Microsoft, NNTP, and the mismanagement of knowledge management
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.
10:02:55 PM
|
|
|
Tuesday, June 18, 2002 |
|
Steve Yost on ubiquitous collaboration tools
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.
11:20:29 AM
|
|
|
Saturday, June 15, 2002 |
|
Work narration and wanker management
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.
10:26:27 AM
|
|
|
Tuesday, June 11, 2002 |
|
Matt Pope on the Groove experiment: reaching closure
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.
10:38:34 AM
|
|
|
Monday, June 10, 2002 |
|
Managing identity in Groove public spaces
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.
9:40:06 AM
|
|
|
Sunday, June 09, 2002 |
|
A report from the Groove/weblog frontier
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!
12:41:35 PM
|
|
© Copyright 2002 Jon Udell.
|
|
