Tagged with 'wiki'

You know you’ve been there. You open your email inbox only to find a string of emails, replies and forwards regarding something as trivial as a meeting agenda. And because everyone involved has made a change to the original document you sent out, you hunt through trying to find the most recent copy because you’re in charge of the meeting and it starts in…5 min! Ugh.

There must be a better way, you say. And there is. Stewart Mader of Future Changes and author of wikipatterns gave a keynote presentation at the Web Content Conference this morning showing us how wikis can save the day where more familiar tools like email have failed us.

Many of us are drowning in email. What was once a “cool new thing” that made communication faster and easier is actually making us less efficient today. We have come to rely on it as our sole communication tool, when in fact there are better tools for collaboration, documentation and knowledge sharing.

If you’re new to wikis – or you think a wiki is an encyclopedia – don’t be discouraged. A wiki is simply an editable Web page. Start with a pilot wiki and host a workshop to get others in your organization acquainted with using a wiki. Once you get others in your organization to adopt wikis, as Stewart says, you can stop getting started on things and instead “get done.”

We’re becoming more accustomed to correcting small-ish errors on wiki web pages when we come across them. I catch myself looking for an “Edit” link on other people’s pages, but of course not all web pages are editable. But that habitual reaction has me wondering about web content mistakes and how best to correct them.

What’s the biggest web content mistake you’ve seen (or done?)

Michael Silverman told us about the six-year-old news article that went out due to inaccurate automation techniques, causing a 75% drop in a company’s stock price before it could be corrected, in Save $1 Billion with Web Content Management! Now that is a big web content mistake.

So, what’s the best way to correct someone else’s web page? Does it matter if that web page is a blog entry? I typically would email someone whose blog entry I wanted to see a correction in. And when I correct blog entries, I always show the text deleted in strikeout format so that it always remains in the original post. I don’t want to seem like I’m hiding anything if readers who read it before the change remember the content differently. I think that approach only works well with blog entries, though.

The Suxorz

SXSW Interactive was last week in Austin, TX, and they will once again feature the “hall of shame” for social media at The Suxorz. They feature the web content campaigns they consider to be the most embarrassing or most poorly executed.

One of the common mistakes from last year’s panel was creating all-flash based sites but hiding the metadata from search engines. There are certainly ways to solve that problem, though. One example from a panelist at SXSWi last year was an example from Samsung. They used Flex and AJAX to create a web-based catalog containing 20,000 SKUs of different TV models. To avoid the problem of a lack of deep search, they used XML site maps to get all the deep links that werere previously not findable.

This year’s Suxorz are being discussed on this Facebook Group. Hasbro shutting down Scrabulous seems to have a couple of votes, and really any campaign with the scent of dishonesty will get a vote or two. For example, Belkin paying for reviews on Amazon and New Egg stuck out to me.

What would you vote for as an example of poor execution on web content?

Want an easy way to hear what all your competitors are talking about? Think of the Fortune 500 Business Blogging Wiki as a dedicated channel for listening in on what they are saying and what customers are saying back. It’s also a good place to get free advice on what makes a good company blog and what doesn’t.

The Fortune 500 Business Blogging Wiki started as an idea of Wired Magazine’s Chris Anderson back in 2005. He wondered why some companies were blogging and some weren’t. One theory he and fellow tech expert Doc Searls were toying with was if companies started blogging as a last ditch effort to save a sinking ship. So they began compiling a list of Fortune 500 company blogs they defined as “active public blogs by company employees about the company and/or its products” to compare against the companies’ previous 12-month share performance. They also wanted to see if blogging made a difference in performance moving forward. In October 2007 their wiki combined with the Fortune 500 Blog Project Wiki (“another wiki project that sought to review all the Fortune 500 companies that blog”) in an effort to expand both projects. You can read the whole story on Chris Anderson’s blog.

In the early days of the wiki a scant 4% of F500 companies were blogging. Though they still lag way behind the Inc. 500 (blogging at a rate of 39% according to a recent study), the Fortune 500 Business Blog wiki has tracked an increase to 12.8%  of F500 companies blogging by November15, 2008.

At Southwest Airlines interns are cool

So F500 companies are starting to catch up for all the obvious reasons, but their blogging approaches vary greatly. Some use lots of widgets and links to other cool tools (like twitter and flickr) and some don’t. Some get lots of comments and some get none. Some blogs even think interns are cool and let them blog right along with marketing managers and CEOs.

You might think nothing is more uncool than an F500 company. I have visions of guys in suits running around placating stock holders, too. But you might be surprised by what they are doing on their blogs and what types of communications they dispatch. It’s not all mea culpa posts about product recalls and poor customer service. Knowing what makes for good F500  blogging (if you don’t already) is a good way to know what’s good for our own blogs. After all, they remain on the F500 list for some reason.

There are lots of reasons to visit the Fortune 500 Business Blogging Wiki that I will write about in a future post. But one of the biggest reasons is that visiting often can help you make your own blog better. It’s the only place (that I know of) where F500 blogs are viewable from one location, are always current, and are routinely reviewed by other bloggers. So you can easily pick from any of the more than 130 blogs listed (companies such as Microsoft and IBM have multiple blogs) and do some informal research.  See what pulls you in and makes you want to stay for a while. What are the posts talking about? Are they all about product-speak? Which blogs are actively engaging in conversation? What kind of feedback are they getting from your mutual (or potential) customers?

While you are on the wiki take some time to read the assembly of reviews by other bloggers. The ones I read were thoughtful, constructive, and use what reviewers call “businessandblogging.com’s methodology for reviewing companies.” Though I couldn’t find reference to the methodology on the businessandblogging.com web site, it apparently rates blogs according to ease of finding, frequency of posts, engaging and relevant writing, and perceived honesty, among other things.

A good example of one review discusses the Southwest Airlines blog, Nuts about Southwest. Not only is Southwest blogging, they are Twittering, Flickring, YouTubing, Linking In and Facebooking.

You might think that’s overkill for an airline blog. Like Tony Chung said in his article last week, “Nobody wants to read a stupid blog.” And who would read and airline blog? Apparently a lot of people. Southwest consistently has several comments on each post. So they must be doing something right. You can read a review by Mack Collier at The Viral Garden to see what else they (or you) might be doing right.

Uh, BTW, that's a dumb name

In some cases even if the company is talking, no one is talking back much. But at least they are trying to engage in the conversation. For example Johnson & Johnson’s blog, JNJ BTW (Am I the only own who thinks that’s a dumb name?) has some interesting posts, but they rarely get any comments. Is that because they rarely reply to them when they do come in? You can read a review by Richard Young on his Whole Nine Yards blog.

Fortune 500 companies couldn’t ask for better, free, feedback on their blogs than this. Really, they should have to pay for it, and maybe they will some day, but that’s not the intent of the wiki. In the meantime the rest of us can use it for our own amateur research. Being better able to see what is or isn’t working on other blogs gives us some precious insight into what may or may not work on our own.

What about using a wiki as a war room, a single location for strategic action-packed activity surrounding a specific set of goals? Wikis have lots of great features that make it an ideal collaborative web space. We’re not the first to think of this either – this article from a wiki about using wikis for Project Management discusses Building a Virtual War Room. But Duo has an excellent example of using an internal wiki page as a command center, a war room of sorts.

Duo uses its internal wiki to document and collaborate on mission-critical projects, like Chicago Park District registration. When the throughput gets intense, the Duo Consulting team uses an internal wiki as a war room for troubleshooting a web application that contains underlying SQL queries to help Chicagoans register for park department offerings. The wiki becomes a strategic command center, a virtual room from which information is gathered and decisions are made. With a slogan for Chicago Parks like “Come out and play” a war room metaphor seems opposite to the end game, but the team must attempt fully concentrated efforts and strategic decision making from one location. There are a couple of reasons why the wiki is so useful:

• there are so many people involved, with so many time-critical tasks and dependencies, that one central location that shows the progress prior to registration helps keep the team on track as a team
• during registration itself, there are so many people monitoring so many different aspects of the application all at once that they need one central location to store that information, as well as knowing who is responsible for following up on any immediate issues
• the wiki engine itself does an awesome job of syntax highlighting and storing SQL queries
• the team can use the wiki as a task list, crossing off items as they’re done.

A specific scenario as an example: one team member might log an issue where a patron can’t register for a particular class. The site is giving the user conflicting information about whether the class is sold out already or not. Another team member might throw up the raw database SQL for that class display on the wiki, and a third team mate might closely analyze that SQL for clues as to what the underlying issue really is – all within minutes, because it’s so important for people to be able to register for these programs as quickly as possible. It’s like the wiki page is the heads-up display in the war room.

Kelly Tetterton, director of development at Duo says, “In some ways, I would imagine working on Chicago Parks Department registration is not entirely dissimilar from working at the air traffic control tower at O’Hare – it feels like that kind of high-pressure, high-intensity experience.”

I’d say that wiki updates give more immediate answers to questions than emailing and waiting for a reply. Wikis make all decisions known to all who monitor the pages. Wikis let you display mission-critical information in a heads-up display or you can print if you happen to like your clipboard or three-ring binder. Wiki’s history pages give you the path to the decision made, and wiki discussion pages can contain lively back and forth while the main page maintains the “truth” decision for the time being.

Let’s hear some war stories – how are you using internal wikis as your strategic project war room?

Last week, I attended a brown-bag lunch on social media organized by the Association Forum. While we started the discussion talking about blogs and various other social media, the conversation soon gravitated to the pros/cons and dos/don’ts of corporate wikis. And if the Society for Information Management’s Advanced Practices Council (APC) study is accurate, it’s no wonder: the study predicts that by 2009, at least 50% of organizations will use wikis as important work collaboration tools.

The APC identified 7 strategies after surveying more than 160 “active corporate wiki users.” I’ll focus on integration and culture.

Integration
I know I’ve already talked about integration in my last two blog posts, but I can’t emphasize this point enough. Just like you wouldn’t hire someone and then seat them in a faraway corner, separated from everyone else, new media has to be fully integrated within the company for it to truly be effective. As the APC report states, the wiki should be integrated as “one of several important tools in an organization’s IT collaboration architecture.”

Culture
One of the APC’s recommendations is to understand that “wikis are best used in work cultures that encourage collaboration. Without an appropriate fit with the workplace culture, wiki technology will be of limited value in sharing knowledge, ideas and practices.”

At Duo, collaboration is one of our core values. To facilitate collaboration, we started an internal wiki two years ago. “At first, I thought only the tech guys would use the wiki, but I’m amazed at how quickly everyone in the company embraced it. Now the project managers use it regularly… and the wiki has become a repository of shared knowledge, great for troubleshooting issues,” said Jason Priestas, a senior developer.

For companies where active collaboration and open sharing of information is not so much a part of the work culture, a fellow participant at the Association Forum brown-bag lunch recommended some ways to make wiki use a habit. For example, instead of simply answering questions over email, people can be incentivized to direct each other to the wiki instead. The APC also suggests assigning a champion to each wiki.

Interestingly, the State Department has its own internal wiki, Diplopedia, a resource that contains biographies of political and business leaders, reading lists and even instructions on how to order lunch. It may surprise some that such a top-down organization is actively using grassroots technology – especially technology that allows anyone to change entries. But according to Noam Cohen, “Diplopedia does not allow anonymous contributors, so bad actors could be tracked down.” Such safeguards have, so far, successfully prevented people from “committing career suicide,” as Mr Johnson from the State Department’s Office of eDiplomacy puts it.

—

To learn more about wikis and how to implement them effectively, come listen to the wiki master and evangelist, Stewart Mader, give his keynote address at the Web Content Conference 2009 in Tampa Bay, Florida! Mader is the author of Wikipatterns: A Practical Guide to Improving Productivity and Collaboration in Your Organization and founder of Wikipatterns.com.