Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
For the last year or so, I’ve been telling everyone I meet about the Empty Wiki Problem. But getting the story into this post has been a real challenge. If you can see what I’m driving at, and can think of a way to improve the story, please, let me know!
So you finally won the Enterprise 2.0 argument. You did your homework. You created beautiful ROI charts. You convinced the powers-that-be to move forward with a collaboration solution. You’ve purchased the hardware and the software. You had consultants analyze your business and configure the system. You brought in technical experts to migrate data. You hired a team of trainers demonstrate the new tools. You launched an internal marketing campaign. The solution went live with great anticipation and much fanfare.
But there’s one guy over in the corner, shaking his head. He’s the cynic. He says, y’know, we saw this with the content management system we rolled out last time. And the portal we set up before that. And the intranet we tried before that. You can detect the hint of a smirk on the cynic’s face as he tells you that it won’t work this time either.
And once the excitement and buzz start to wear off, your tiny inner voice starts asking whether the cynic might be right. But after all this time, effort, and expense to implement a state-of-the-art Enterprise 2.0 solution, isn’t the project a success? Aren’t we done yet?
No. Your business is never done. And that’s when you start to realize that you’ve still got a problem.
Almost as soon as the consultants pack up their laptops and the dust settles, the content in your new, shiny E2.0 solution starts to get stale. People get caught up in their inboxes again and forget to post things to the server. Meeting agendas, dutifully posted in the first few weeks after launch, never get paired with the meeting minutes, lost in the shuffle of getting things done. The first half of an email thread gets cataloged, but somehow, the second half — the part with the final decision — never makes it in to the repository. The searches on the portal become less relevant. As the results become less useful, people stop visiting. People stop remembering to update and post new material. Slowly but surely, everyone starts relying on the ol’ standbys to get things done.
And the cynic nods as if to say, I told you so.
The short answer is that the new system wasn’t adopted.
But what caused people to reject the solution? And why were so many other collaboration and information sharing tools similarly rejected?
I don’t believe it’s our hypothetical organization’s fault. It’s not that the culture is biased against sharing. As Jack Vinson reminded us in a recent blog post, we shouldn’t confuse a refusal to use a KM Tool with a refusal to share knowledge. Most people love to talk. It’s hard to get them to stop talking. And the whole point of an organization is to get people together to work on a shared goal. The purpose of business is to harness collaborative effort.
So let’s not blame the victim here; organizations don’t reject these solutions because the organizations themselves are fundamentally flawed. There must be something fundamental, something subtle in the way that these people interacted — or failed to interact — with these tools that was the problem.
I think most solutions don’t cross the threshold of sustainability for one reason: The value that individuals get out of them doesn’t outweigh the effort to put things into them.
If too many folks decide it’s too much trouble to upload stuff to the server, the solution will fail. If enough people decide that filling out metadata profile forms is a waste of time, the solution will fail. If too many employees decide that the reports or search results don’t meet their needs, they won’t maintain the system, and the solution will fail.
The adoption pattern of these systems is a classic tipping point problem. Each user draws their own conclusions about the usefulness of the system. Getting user adoption is a matter of reaching critical mass. If you can get critical mass, the usage of the system will explode. If you don’t get critical mass, nothing happens. The solution will languish and fade. With collaborative software, you typically see either runaway successes or dismal failures.
So if we want to defeat the Empty Wiki Problem, we can either decrease the individual effort needed to maintain the system, increase the value that each user gets from the system, or — ideally — do both things at the same time.
A few items I found this week on the noisy Internet started me thinking a bit about our industry, and why content management is actually interesting. No really, stay with me on this one….
When I was a kid, I always figured that one day there would be a super awesome computer that I could ask to do anything and it would instantly comply. Factual things, like “How far is it from here to the moon?” tasks like “Design for me my own awesome personal car based on things I like” or “Do my homework” and other, more esoteric things like “Does that girl in Math class who keeps poking me with her compass really like me?”
Now that I’m something of a grownup, we’re a lot closer to that kind of a solution actually existing. In fact, the Internet could potentially do pretty well at all of these questions. And yet, things aren’t exactly as I imagined them.
For starters, when I imagined my computer, I figured it would, you know compute things. Like, it would somehow measure the distance between here and the moon. And that it would build me blueprints for my new car by computing complex algorithms and lots of, you know — computery figuring out of stuff. The magic of the Internet as we know it is not really powered by computation at all. It’s people powered.
At its heart, the most useful things on the Internet are all just content management. They’re reordering, re-indexing and re-presenting existing information. For its almost limitless usefulness, Google itself doesn’t “know” much of anything. The only thing Google actually computes is how to relate existing content in the form of webpages, and how to present it at the appropriate time. (That’s no easy task, either, by the sounds of it. Just look at the amount of power they consume to bring those results to us.)
Which is why I was particularly intrigued to hear of Stephen Wolfram’s new project, Wolfram Alpha. It looks like this is an effort to produce a computation-based system, more in line with the computer of my juvenile fantasy. Unlike Google, Wolfram Alpha plans to actually compute answers, not just find them. It’s taking a seriously hardcore computer science approach to the problem of knowledge. I would dearly love to see this thing succeed, but I suspect that it won’t live up to pre-launch expectations.
At the other end of town, the other thing that got me thinking was Amy’s new project for South by Southwest (SXSW), the Pepsicozeitgeist. It’s a near-realtime, twitter-powered look at interactions between people at the conference. (It’s largely inspired by her original Twistori site, which does much the same thing for Twitter.) As well as being a fascinating time-waster, it’s a classic case of remixing people and their content, slicing and dicing information from the twitter data cloud. The computation going on in these solutions is all in looking for patterns in the content — finding the best ways to relate things — in divining commonality and relationships, and counting results.
In fact, when I look at all the amazing products and innovations that have arrived since web 2.0′clock, they all share this common element. Reasonably lightweight, simple computations being quickly processed against a collectively valuable, up-to date content repository. That’s what lets you find things, and learn new things, make new associations. And underneath it all is Content Management. Regardless of whatever it used to be about, it is now about preserving, maintaining and making these data repositories current, available, and interoperable so that value can be derived from them. Which is actually pretty interesting and important.
These new data libraries of information we are building for enterprises need to be constructed more like Twitter, and less like virtual paper archives if they are going to be useful to us in these ways.
At least, until some giant Hal 9000 type computer can do all our thinking for us. Meanwhile, I guess we should all just keep typing.
Color makes an impact. It’s one of the strongest visual cues you can use.
When we started Infovark, we knew we wanted to make something different. Gordon and I had just come from the enterprise software arena. We were tired of boring press releases and the battleship gray applications.
And then we stumbled upon the name Infovark. And our lovable mascot. Suddenly, we not only had an idea for a software company, we had a way to express it.
One of the things that caused us to reach out to Amy Hoy for help with our user interface design was her bold use of color, which you can see on Slash 7, her principal blog, and also on her projects twistori and freckle.
One of her first questions to us was about the adjectives we wanted associated with the project. What sort of impression did we want to make? In addition to “new and different,” we provided answers like helpful, friendly, enthusiastic, accessible, earthy, natural, and intuitive. Clearly, our approach to creating software, the company name, and the critter all had an influence.
We had already taken one pass at the user interface for our application, but it still retained too much of the drab, corporate look so common in applications today. Even paragons of design like Apple and Adobe use neutral tones like brushed metal and charcoal gray. Microsoft is noted for Windows’ blue and white scheme. Amy’s advice:
My suggestion for fixing the aesthetic problems can be summed up in two words: Be bolder. Ditch the color waffling: go bold. Ditch the lighter shades, commit to the bright ones. Kill the grey. Get rid of borders and boxes. Get rid of gradients. Ditch the icons, unless you can get bold, iconic ones that can do the job with just one color.
You can see that advice at work in the new look of this blog and the Infovark Underground. And we hope you’ll see it in our user interface, too. The screens aren’t ready for primetime yet, but you can see our color palette below.

The Infovark color palette
These are not the exact colors you’ll see in our application, but it’s provided the inspiration for our scheme.
Have I mentioned that I’m the son of an interior designer? I may sling code all day, but I appreciate good design. And for me, these colors have meaning. I won’t bore you with color theory, but if you’re at all interested in color, marketing, and branding, it’s worth looking at the Usability Post‘s Guide to Choosing Colors for Your Brand and Smashing Magazine‘s Colors in Corporate Branding and Design. Both provide insight, advice, and lots of examples of how color influences our impressions of companies and products.