This is a continuation of my previous post about the SDK wiki. We had decided that the best way to document the development tools that came with our ECM product was to create a wiki site. We stood it up in December 2005.
It worked well. We were improving the quality of our documentation, because our developers and technical support teams worldwide could help maintain it. We were reducing the volume of calls coming into our support line. We were helping to advertise the capabilities of our product. You could say it was the victim of its own success.
At the start of the project, we'd sent out an email or two to staff about the effort. During the next few months, we quietly promoted it to select partners and customers. It proved to be a valuable resource for those that knew about it. A few customers even thanked us for making the information available. The information had always been in the documentation that shipped with the product, of course, but in today's Internet Age, if it isn't online it doesn't exist.
Six months after going live, we announced success. We posted a note to the site itself and sent out an email to staff. By this stage, the technical teams were doing most of their documentation for new features on the wiki itself. We thought the concept had proved itself.
Midnight Raid
Then, when the corporate homepage was redesigned in the middle of 2006, we decided to include a link to the SDK wiki. It was the link that caught the eye of a few reactionary folks in the company. I recieved an IM in the dead of night from one of the members of the R&D team: "They're going to shut the SDK wiki down!"
Ok, I'm being a bit dramatic. Everything sent to me from the R&D team arrives in the dead of night, because R&D is in Australia and I'm in North America. But it was still a shock.
Frankly, I'd expected one of our other experiments to have caught the attention of management first. On the heels of the wiki success, we'd decided to create a separate wiki site regarding the best practices for implementing our software. It, too, was publicly viewable, and much of the content was still under construction. We were using that wiki as a way to both aggregate knowledge about our software deployments, consolidate lessons learned, spur discussion and debate, and publish good ideas. Radical stuff for a company that had been afraid to mention the word "product" on its homepage.
Or it might have been triggered by the new online user forum, where customers could post questions and recieve public answers about our product. This was also controversial, because the company maintains a listserve for this information. The listserve had fallen prey to abuse from time to time, so I could see how the idea of an online forum might be met with resistance.
But the SDK wiki? What sort of problem could that be? Our first reaction was disbelief. What on earth could be the problem with posting our API documentation online?
Social Leper
The wiki was locked away behind a registration and login scheme.
Yes, that sounds relatively mild, but it's actually the kiss of death for many websites. The only sites that survive a login scheme are those with compelling, known content. The New York Times can get away with it. Everyone is familiar with what sorts of content a newspaper has to offer. In the case of the New York Times, most folks have an idea of the quality of that content as well. But a site describing the features of an API belonging to a little-known software firm? It might as well be invisible.
And it is invisible to the most powerful eyes on the Internet: Google. When locked behind a password, no search engine can index the site. Since almost everyone uses a search engine to find content on the Internet, making these search sites blind to your website is the modern day equivalent of becoming a hermit.
So it's not something to be done lightly. Why was it done? That's the subject of the next post.
No comments:
Post a Comment