Stewart Mader blogs atWikiConsulting.com

In the September issue of Men’s Vogue, writer Michael Specter says of the iPhone, and Apple’s emphasis on design: “You can count on one hand the number of American corporations that take design seriously. There is target and Knoll, and then there is Apple…People want to make phone calls, but they also want to play with their music and look at pretty pictures. They want to have fun. Apple has shown it is possible. More than that, they have reminded us that elegance matters.”

Earlier in the piece, he says, “It is hard to make something simple.” Indeed. It is hard because most people think about design last - after the engineering, after the feature lists, and after trying to include enough to theoretically please everybody. What gets lost in the shuffle is careful thought about and attention to how things should work together, how they should feel to the person who uses them everyday, and gets to be intimately familiar with their functions, and shortcomings. “People aren’t looking for the interface to be exciting. They’re looking to it to be fast, reliable, and easy to use.” Jim Buckmaster, Craigslist CEO

For technology tools, creating buzz about something is easy, but creating something that generates its own buzz, and keeps that buzz going because people are genuinely excited about it, is a bit harder. In the long run, though, it’s the latter group that are the real game changers. This excerpt from an article about the iPhone helps explain why:
“That love-hate relationship we have with cell phones underlies the depth of our involvement with technology itself. Our everyday tools are the stuff of 1950s science-fiction novels. But though the digital age has widely expanded our abilities, the difficulty of accomplishing these tasks with ease often leaves us frustrated. When something comes along that promises to fulfill our ambitions, we pay attention. And when that something also promises to perform its duties with beauty and pizzazz—Apple’s trademarks—we get a visceral buzz that’s as much artistic enthusiasm as consumerism.” Why We Went Nuts About the iPhone, Steven Levy

The reason that people who use wikis become extremely passionate advocates - like Apple fans - and stoke successful grassroots growth in organizations is that they’re simple and understandable. People get how to use them very quickly, and genuinely like that they don’t have to fight with the wiki to do what they want. So wikis get used during projects (instead of after the fact), and the more they get used, the more their use grows because they become hubs for knowledge, interaction, and collaboration. An elegant experience goes a long way in making this possible.

• Comments Off

The Friday Flux is a new weekly series in which I’ll highlight a post from the archives on this blog. The idea for this stemmed from a recent post in which I highlighed an excellent post Dennis and Jeremiah Owyang wrote which is almost two years old but still as good as ever. Finding, and writing about, that post made me realize that when using a temporal mechanism like blogs, we shouln’t just let posts disappear into the archives - we should re-read and reflect on them as time passes.

The name “The Friday Flux” was inspired by the Flux Capacitor, the device “Doc” Emmett Brown described as “what makes time travel possible” in the DeLorean Time Machine he and Marty McFly used for time travel in Back to the Future.

This week’s flux is a post I wrote in August 2006: Wiki and the Memetic Marketplace. Enjoy!

• Comments Off

I got asked this question during a presentation earlier this week. It’s a simple question with a complicated answer - here’s why: Historically, whenever any new enterprise tool has appeared on the landscape, its proponents have told everyone that it was the next big thing (think KM systems) and would obsolete everything else so they should get on board as quickly as possible. Every time, without fail, this has not been the case. KM has largely not lived up to the extremely high bar set in its heady early days.

So when I answered the question, here’s what I said: in some cases it will replace and obsolete other enterprise tools, but in other cases it will coexist and work alongside - even in complement with - those other tools. Think that was a politician’s answer? In some ways it was, because it I said the same thing that’s been said countless times before - that it would unilaterally obsolete other tools - I would have immediately discredited myself because people know that’s not true and get scared when there hear things about a wholesale switch from one way of doing things to another.

In another way, it wasn’t a politician’s answer, because multiple tools can coexist and letting people choose can help them be more productive and enjoy what they do. Furthermore, when you introduce the wiki to your organization, there’s no need to immediately shut down and remove all other tools - that just sends a jarring and bad signal when the real benefit of the wiki is it helps return other tools, like email, to their optimal uses. Here are two examples where the wiki can coexist with other tools for the better:

Wiki + Email:
If you’ve been emailing meeting agendas, put them on the wiki instead and you’ll reduce the volume of emails asking you to do time consuming things like fix or add to agenda items. Instead, put the agenda on the wiki so others on your team can directly make changes themselves, then send out an email with a link to the agenda-containing wiki page. You’ve just reduced the email associated with that meeting to just one outgoing message, and the reduced volume means less work for you and people will likely pay closer attention to it since their inboxes will be less crowded.

Wiki + Website content management system:
Many firms use a content management system to power their websites, and the system is usually managed by one person, or a small team of people. The rub: they’re constantly overloaded with requests to edit the content of pages and have a difficult time keeping up with them in a timely fashion. A great way to solve this is to put the website content in a wiki space, with a wiki page corresponding to each page on the website. Now, people can edit the content on the wiki as needed, and just let the web publishing people know when it’s ready to go on the website. This reduces the web publishers’ workload from making lots of changes (which often requires emails back and forth to get content, ask for clarifications, etc.) to just copying the updated content over to the content management system.

• Comments Off

Over on the FastForward Blog, Bill Ives writes about some excellent ways to introduce wikis in organizations. He focuses on events and meetings - specifically holding asynchronous meetings on the wiki: “You should also encourage participants to sign their contributions, In a live meeting this is obviously part of the give and take. People need to know the personal context of remarks and who they are responding to.” That’s a great reason for explaining the value of associating your identity with your contributions. In a real-life meeting you’d have a tough time offering an anonymous comment on something, and even if you did try something outregeous like putting a paper bag over your head to feign anonymity, people eould still know who’s talking! People do need to know who they’re talking with so they can offer responses that are in the right context to have the best impact.

Bill makes a _great_ point regarding the need to follow what’s happening when they’re not on the wiki: “allow this to go somewhere besides the email inbox. I am not excited when a heated discussion on an email group suddenly drops twenty messages in my inbox. Take advantage of the common workspace here and do not drag in the sins of email spaghetti with its overlapping tangled mess.” If we switch to the wiki on the premise that it’s better, simpler, less tangled, and overwhelming than an inbox full of email, why would we want to take two steps back and fill our inbox with the same overload of messages, just generated by a different source? I’m a firm believer that to _really_ build a tight-knit community on the wiki, you have to be on the wiki itself and regularly, frequently contribute. Contributing a few times and then stepping back and just following from a feed limits the impact of the wiki. That’s not to say using a feed is bad and should be discouraged - just don’t let it be the only way you see what’s happening on the wiki. Being on the page itself lowers the barrier to contributing, since you can just click “edit” whenever you want to add or change something.

• Comments Off

In Wiki is the new FAQ Dennis Howlett looks at the Wall Street Journal’s coverage of wiki use at SAP and Intuit. At SAP, the Developer Network and Business Process Expert communities group found that online forums were inefficient because the same questions were being asked over and over, sometimes with people waiting a long time for answers. “It got to be a little much,” says Mark Yolton, vice president of the SAP Developer Network and Business Process Expert communities at SAP. So the group introduced a wiki and encouraged the community to contribute.

This is a smart idea because with forums, people might not think to search and see if their question has been answered before, or they might search with slightly different terms and not find the existing answers. With a wiki, all the answers to a question can be organized on a page, and people can easily edit, add to, or correct an answer.

At Intuit, the technology innovation group introduced a wiki for employees outside the group to contribute information on technologies the company might want to use in products. The problem is, contributions to the wiki haven’t taken off, so the director of the group is trying to stimulate activity by inviting product managers and designers to temporarily join the group and contribute to the wiki. Howlett argues this isn’t a good wiki use because Intuit isn’t giving people a reason to actively participate in the wiki community.

My take on it is that the Intuit group’s effort should be focused on the people inside the company first. If the people in the technology innovation group aren’t contributing to their own wiki, it’s not likely that those outside will contribute either, because there’s no core community. Having people temporarily join the group to contribute to the wiki might get content into the wiki for a brief period of time, but what happens when those people leave the group? They might continue to contribute, but then again thy might go back to their usual work and just not have time for the wiki anymore.

Furthermore, having temporary contributors build the wiki is risky because they don’t fully belong to the community like those in the technology innovation group, and it’s the full time “residents” who should set the tone and guidelines of the community so that it has a clear purpose. Intuit’s wiki might work, but I think SAP’s has the strong foundation that I’ve seen in other successful wikis.

• Comments Off

Dennis Howlett recently wrote about how NYK Shipping & Megacarrier is using Confluence and Lotus Domino together to power their intranet. NYK is a global shipping company (one of the world’s largest, in fact), and Alek Lotoczko, who runs the company’s intranet, was looking for a way to increase collaboration after seeing that only about 50 people regularly contributed to the Domino-based intranet. He first used the open source DominoWiki in January 2007, and by June, with just word-of-mouth, contributors had more than doubled to 117.

By that time he started talking with the corporate communication department, which was also looking for a wiki for its own use, and the two decided to switch from DominoWiki to Confluence. Alek was able to secure funding from this, and he points out that using a free, open source tool allowed him to get things started and demonstrate the value of a wiki before spending any money. Bear in mind that this isn’t to say all organizations should start with one wiki that’s free, and then switch to another, because that can create its own set of issues. In fact, with the low cost of wikis in general, and the fact that you can often get a 30 day free trial, it’s fairly easy to start directly with the tool of your choice.

So where does NYK’s wiki/intranet stand now? “The Domino system isn’t going away because that’s NYK’s corporate comms standard. Instead, it is being used to prime the wiki project which Alek hopes will eventually reach about 2,500 employees.” This is a great example of two enterprise software tools coexisting, and the wiki is being used for its strengths in attracting and building a consistent level of collaboration. This is an excellent example for organizations to learn from as they think about how a wiki can become a succesful part of their computing landscape.

• Comments Off

The InfoWorld blog points to a recent survey showing that corporate email is becoming more expensive than ever. The survey, conducted by Osterman Research, looked at just over 100 enterprises with an average of 6,636 email users and found that a majority are concerned about the expense associated with migrating to Microsoft Exchange 2007. The survey showed that organizations face steep costs to migrate to the new email server, and, “messaging storage growth is a serious or very serious problem.” Regarding messaging storage growth, the problem people think they’re facing is having enough available storage space for archives of message, but I think the bigger problem is that all those stored messages aren’t doing much good because people can’t do much with them. Email is not an archival tool for information, which makes accessing and reusing that information difficult.

The survey was commissioned by a Linux-based competitor to Exchange, so it might be construed as biased, but the bigger issue here is that organizations have to look at how email is being used, and what activities would be better served by other tools, like wikis and blogs. Email has become a crutch in business communications because it’s being stretched far beyond its intended use as a communications tool. Organizations are trying to use it to collaborate and it was never designed for this, so it makes a very poor collaboration tool.

If you and I were working together on a document, there are a lot of steps in between when I work on the document itself, and when you work on it. To send it to you, I’d have to create an email, attach the document, and send it to you. Once you receive it, you’d have to download the attachment (insert worry about viruses here), open it (let’s hope you have the right software to do so!), and finally you can edit it. That may not seem like much, but imagine doing that every time we pass the document back and forth.

And, what if I send you the document, then get a great idea for something to add. Should I wait until you’ve had a chance to edit it and send it back, or do I add my new content and send it again? If I do the latter, it open up the possibility that you might edit the wrong copy of the document, and my content either gets lost in the process, or has to be added back later. This is why email isn’t a good collaboration tool, and using a wiki can return email to it’s proper use, such as when I send you a message to tell you the wiki page with our document is ready for your input. Then, if I have a great idea I can add it to the wiki page, which ensures you’ll see it when you look at that same wiki page.

• Comments Off