Category: Blogging

Dave Pollard has nice, clear, useful, but non-definitive guide for when to use different communication media.

Tool or Medium	Some Unique Advantages
Face-to-face	Conveys body language, allows sidebar conversations, builds trust, coordinates multiple communication media best
Telephone	Fast iteration of a few people’s ideas and knowledge , conveys tone
E-mail, Letter, Memo (anyone remember memos?)	Makes the organization of complex ideas visible and easy to grasp, leaves a trail, can be saved
V-mail	Conveys tone, can be saved
IM, Chat	Immediate access, fast iteration of a few people’s ideas and knowledge
Weblog	Provides context of communicator’s other work, categorizable, allows comments back, can be saved
Newsletter, Newspaper	Brief, immediate, categorizable
Radio, TV, multimedia	Compelling, reach
Videoconference (room)	Visual, inexpensive
Videoconference (P-to-P)	Next best thing to being there
Forum, Collaboration Tool (project, team)	Egalitarian, leaves a trail
Wiki	Openness, multiple voices
Format	Unique Advantage
Conversation	Iterative, flexible
Interview	Structured
Presentation	Can use multiple media

Some of these items are subject to debate:

• Implies that you’d use a weblog as a last resort if there isn’t another more appropriate medium.
• Implies that voicemail is better than email for short messages — without taking into the account that email is easier to archive.
• Implies that wiki is the tool to use if you *don’t* need fancy formatting; vs. being the tool to use if you want to focus on collaboration on content *prior to* formatting.
• Also, it doesn’t distinguish between forum discussions, which are suitable for exploring, brainstorming, and other open-ended pursuits, and weblogs, which are conducive to converging on a result.

Despite these quibbles, the article makes the right underlying assumption. There isn’t one best communications medium; each mode has its strenghts and weaknesses; different modes should be used in different situations.

The Seattle blog portal sparked some reflections about what makes a metablog successful.
Seattle’s blog portal, and the Austin metablog, come out of existing communities. People want to read other people’s posts.
The TopicExchange for the Clickz Jupitermedia Weblog in Business Conference was successful at gathering posts from the conference. I remember the aggregator for Kevin Werbach’s Supernova conference last year was excellent, too.
They were successful because there was a community of people, in the room and outside of the room, who wanted to follow people’s takes on the conference.
Thought that the Sam Ruby wiki should have a trackback aggregator; looks like TimA may have got to it already.
Communication patterns:
* A real-time event with people following in-person and remotely, or
* An active project, where people are working individually and together, or
* An ongoing community, where people are blogging individually and want to stay in touch

Beautiful design, blue-green, very Seattle feel, lovely map, and seems like a nice community.
via Anita Rowland on #joiito.

At the JavaOne conference, Sun launched Java.net, the first commercial developer community to incorporate wikis and weblogs (disclosure: Socialtext consulted on its design). Ross Mayfield covers the announcement, here.
The Java developer community has pre-existing blog and wiki communities, including JavaBlogs.com, Freeroller.net, and JSPWiki.
The communities take different approaches.
JavaBlogs.com is a classic metablog — a portal which aggregates Java-related blogs using RSS feeds. The organizing unit is an individual java developer with a weblog.
The organizing unit in Java.net is the development project. Sun wants existing development projects to affiliate with Java.net, and gives them a set of tools including mailing list, weblog, wiki, and cvs.
So far, content is produced using an editorial model: articles from O’Reilly, plus bloggers who are invited in. Any Java developer can sign up to join a mailing list. But you need to join a particular project, or be invited to blog. Java.net also plans to use RSS to aggregate content from other communities.
The discussion on the Java.net and JavaBlogs shows some classic tensions between a commercial software vendor, which wants to support a community of developers, and developer community, who self-organize, and want support from the commercial vendors.
It will be interesting to see how the communities evolve. Will there be syndication and federation techniques that bridge communities in different locations, or will developers choose affiliations?
Meanwhile, this is a strong sign of commercial interest in the value of weblog and wiki tools in supporting developer communities.
As with the hybrids between independent blogging and traditional journalism, the interesting question isn’t the “purity” of any model. It’s the process of evolution at work creating new variants. The most compelling new variants will survive.

Gratitude and admiration to Sam Ruby for catalyzing productive discussion about weblog standards.

Blogger Ed Cone talked to Rep. Rick Boucher, a Virginia representative who focuses on technology policy. Boucher says that the Hatch vigilante proposal would find limited support in congress.

Orrin Hatch has been catching hell around the blogosphere for advocating that the RIAA should be able to destroy the computers of customers it thinks are stealing.
If we’re legalizing vigilante justice, why stop there? Lessig suggests that along those lines, we should be able to “bomb the offices of stock brokers thought to be violating SEC regulations. Or bulldoze houses of citizens with unregistered guns.”

Tim Appnel clarifies what he meant yesterday:

What I meant to say (and did rather poorly I suppose) is that a wiki does not sufficiently facilitate discussion over time or communicate reason for the change nor does it alert me to the change which may change the context of the collaboration elsewhere. I have to really dig for it. (Perhaps this is just my experience with MoinMoin the wiki Sam Ruby is using.)

Part of this social process, not technology.
Several classic wiki pages on techniques for effective wiki-based conversation:
* How to Converse Deeply on a Wiki
* How to use Thread Mode in a Wiki
* Soft Security
It seems to me that some of the small confusions can be cleared up (and are being cleared up) with these types of techniques. For example, a person who disagrees with a sentence shouldn’t change the meaning of that sentence, but should add a signed comment. When discussion converges, create a new document in Document Mode, not Thread Mode.
I agree with you that it’s good to use wiki with other communications tools. In a membership group, it works nicely to have the back-and-forth conversation in email. In this case, the community is open and ad hoc, so the public modes (wiki and weblog) are a good fit.
Completely agreed that email notification would be useful. I don’t know if MoinMoin has that feature or not.

Sam Ruby wrote a blog post about the components of a well-formed weblog entry, and started a wiki to flesh out the picture.
It looks like the discussion on the wiki is percolating nicely.
Tim Appnel is somewhat concerned about the use of the wiki; because people can edit the pages, he’s worried that people will go into loops, changing the meaning of content.
But a well-formed social process can assuage that concern.
It looks like they’re doing a good job abstracting the discusion, and using the data model diagrams to express emerging concensus.
This is a good example of using the different modes in a decision cycle.
* Start with people bouncing ideas back and forth using a mailing list or weblogs
* Use the wiki to converge the discussion. Generate a prototype document and build shared definitions of concepts and terms
* Use individual weblog posts to explore particular ideas in depth, and link back into the discussion
* Once the wiki conversation has reached agreement, use the document as the starting point for the next phase of action.

SimpleTracks is a hosted application that lets people without trackback send entries to a metablog.