This week in links - week 41, 2008

John Tropea asks "How do wikis and blogs fit together?" and illustrates this with a typical flow at a solution centre:

One way is to think of the stock and flow model, wikis have perpetually re-edited pages, whereas blogs have a stream of date-based entries just like newspaper articles...//..Wikipages can be seen as more definitive, whereas blog posts are about currency, opinion, etc

(I think) a blog should not be a solution centre, whereas a wiki is ideal...//...I guess a Tips and Tricks blog is OK, but “solution” is a more definitive word, so a wiki is more suitable...//...A blog is simply a timestamped communication, similar to a newspaper.

A typical workflow

  1. A support worker is dealing with an error
  2. They check the solution wiki if there is a solution for this error
  3. If not, they search their community support forums or post a forum topic
  4. If they find a solution, they create a wikipage, then link to it on the wiki homepage
  5. If they feel this solution is a crucial find and needs to be shared, they can then create a blog entry
    A. This blog entry notifies people and points them to the wikipage
    B. This blog entry includes informal, experiential and contextual information that is not included in the wikipage solution. The wikipage solution is more focused and to the point, whereas the blog entry may explain the workings out, and what took place.
  6. If you like you can go back to the wikipage solution and put a link to the blog entry that expands more on the solution. If someone has feedback or a question after reading the blog entry they can leave a comment.

In the past you have to be in the same room when someone discovers a solution, otherwise you may not know. The benefit of being in the same room is that you were there and experienced the build up to the solution, you know all the details, and you could discuss it as well...//...The idea of wikis and blogs it to mimic what happens in real life, but extend it to a global village.

"Micro-blogging in the enterprise: an idea whose time has come?" by Ross Dawson:

So why should companies want to Twitter?

The reality is that I think that not many will, for a little while yet. Companies need to be very comfortable with experimentation, and to the development of diffuse communication patterns. If they are comfortable with this, then Twitter can be used in all sorts of ways: to ask quick questions on information people need, updates about what’s happening in the company, chit-chat, social events, human connection.

One of the problems that companies have had is that often this kind of communication happens on email, which clogs people's inboxes, are often not relevant, and are seen as annoyances.

However it is difficult to get engagement in forums and discussion boards – people have to make the effort to go there and look to see what is happening.

So something like Twitter combines elements of the best of both worlds. It’s like email in that it’s broadcast, though you choose who you receive messages from, and you don’t need to read everything. You presume that messages are non-essential, so you get to them as you can, and it’s non-intrusive.

"Groups and Networks" by Michael Idinopulos:

Stowe Boyd recently posted the following statement:

"I disagree with the notion that Enterprise 2.0 is about groups not the individual. On the contrary: Web 2.0 is based on the person and personal relationships in networks, not group membership."

It came in response to a post of mine about Enterprise 2.0 adoption where I wrote that:

"Enterprise 2.0 posits the group as the primary unit of activity; email posits the individual."

When Boyd says that Enterprise 2.0 is about personal relationships in networks and not group membership, I think he's saying that the point of Enterprise 2.0 is not to enable existing organizational groups, but to empower and mobilize social networks for getting work done in new ways.

Who's right? I think we both are.

Boyd makes a really important point about social networks. Web 2.0 is waking us all up to how powerful it is when social networks are made transparent. From a professional standpoint, a worker's long-term career development, sense of belonging, job satisfaction, mentoring and guidance, etc., are often driven more by social networks than by formal groups. That trend will accelerate as social networking takes off in earnest within enterprises.

But it's important to recognize that the fundamental unit of collaboration is the group. Departments, divisions, business units, teams, committees, etc., are the wheels on which almost all companies run. That's not an Enterprise 1.0 or an Enterprise 2.0 thing; it's a reflection of the fact that collaboration around tasks of any size requires continuity and accountability.

This isn't an either/or thing, however. The sweet spot for Enterprise 2.0 lies at the intersection of group collaboration and social networking.

"Costly & Inefficient Procedure that Wikis can Improve" by Stewart Mader:

The complex trade of documents over email, especially among members of a team, is one of the most time-consuming, confusing, and error-prone processes in organizations today. Everybody has been part of this at some point, and the more people involved, the more chaotic it gets.

In a guest post last week (Wikis at Work - Defining Requirements in a New Way), Jason Rothbart of GroupSwim discussed how a wiki can streamline this process by cutting down on the volume of email, changing from documents to pages that “pull” people’s attention in to one shared location instead of “pushing” out duplicate copies of a document to each person. This means that people automatically see and edit the most recent version of a page, and as soon as one person saves their revisions, the next person immediately has access to that version to edit. Once revisions are complete, it’s easy to export content out of the wiki and into a traditional format (Word, PDF, etc.) as needed.