How long is too long for a KB article?
I'm sitting in a meeting where we're discussing consolidating KB articles, and one of the issues that's come up is that most times when we go to consolidate two or three or fifteen KB articles into one, we end up with a 20 page KB article that's really a white paper. The KB team usually tries to keep KBs to two or three pages.
My personal opinion is that long KBs are just fine, the more information the better, assuming of course that the search actually works to get you the results you want (and if the search on support.microsoft.com doesn't, then use whatever search engine you prefer with a +site:support.microsoft.com, for example). Since the content in whitepapers isn't searchable today, I prefer having it in the KBs which you can search from one place.
But since I might be biased, I wanted to ask the question in public: Is it OK for KB articles to be really long? Or is there a length after which it ceases to become useful?
Add any feedback as a comment to this post and I'll roll it up and present it to the KB folks. Even if the consensus is different from my personal opinion, I promise I'll still give the feedback :-)
Comments
- Anonymous
March 24, 2004
If the whitepapers were searchable, I would agree with the KB guys. The purpose, as I understand it, is to provide a quick reference point on a specific issue or topic.
The issue has become that there, really, are often 5-6 KB articles covering an issue you might be having.
So from that perspective it does make sense. However, if it gets longer than 5 pages, it really does approach white paper status and that area should be rethought.
So, make it a white paper, but make the whitepapers searchable as a subset to the KB (or something). Not having white papers searchable is an incredible pain. I now have to Google on whitepapers, which isn't very helpful as they are often what I need, not KB's (I do a lot of initial setup, not a lot of troubleshooting). - Anonymous
March 24, 2004
The more information, the better. Most people searching the KB (at least for development or error info) are adept at using their browser's search functionality.
Liberal use of anchors to help jump to sections of longer documents would be nice, too. - Anonymous
March 24, 2004
I agree with the searchable comments.
My objection is not that the KB pieces are too long, but that sometimes they are too short - Anonymous
March 24, 2004
KB articles are great because they are usable quickly. I agree with "the more info the better", but if they get longer than 3-4 pages, just make the KB a summary of the whitepaper (and link to it). That way the KB search will be an efficient way to find the available information. - Anonymous
March 24, 2004
Good point Jeremy. If the KB could link to the white paper, that would be a fantastic interim solution to making whitepapers searchable. - Anonymous
March 24, 2004
Am I the only one to hate a search system that won't work without cookies enabled? How low can they go? Isn't a support site suppposed to help users? - Anonymous
March 24, 2004
Long KB articles are bad. When people are reading KB articles, they have a problem at hand, and they want to find specific answers to their specific problem fast. They don't want to go thru a 20-page white paper. - Anonymous
March 24, 2004
Keep them short with a root cause and resolution steps. - Anonymous
March 24, 2004
I would like KB articles that completely cover and article. I don't know how many times I have had to go through a dozen articles that are almost the same, but each have a slightly different story.
I do not mind length, I just want to be able to find the information about the problem.
I am also disappointed (and have been for years) that EventIDs are practically useless. My event log kicks out an error, but I can't look that error up anywhere. I've always thought that since Microsoft went to all of the trouble to add all of those event IDs into the applications and operating system, they would let us find out information about the message based on the event ID. - Anonymous
March 24, 2004
Long articles are fine as long as they provide good, solid information - a list of 3000 files included in this service pack is not my idea of good reading.
Generally, the more info about a complex subject/fix the better as it saves routing around different resources to find it. How many times have you picked up an article only to be redirected to about 5 different links to find all the detail you need. - Anonymous
March 24, 2004
Consolidated is good. If someone is worried about quickly finding their solution then a Table of Contents should suffice.
I've been through a few KB's that linked to other KB's that linked to more KB's etc. I think this is more of a waste of time than having everything in one consolidated place.
One idea is to do what MSDN code samples do with multiple languages. Use DHTML with a "click here for c#/vb.net" etc and use this for versioning "click here for the solution for Win98/2000/XP etc" - Anonymous
March 24, 2004
Tough call - I think I'd opt for the KB having the problem and resolution, with a link to the white paper for more in-depth treatment of the subject.
Just have to do a good job with the keywords so that the KB article comes up making that white paper essentially searchable.
-B- - Anonymous
March 24, 2004
Long articles are fine with me
Length doesnt matter so long as I can get all the info i need from one place rather than tons..
Ben has a good point though but all the info should be accessible in no more than 3 clicks.
In the consulting docs im writing right now, we point to the specific chapter in a specific deployment guide for reference so that the stuff actually gets used.
We found that if it was more than 3 clicks away, they dont bother. - Anonymous
March 24, 2004
I'm with BY, I use KBs to find a solution to a problem at hand. I don't need to know the theory behind a technology, just give me the problem and solution. Then give me the link to the longer article so I can get more info if I need it or want it.
As for the person who wanted Event ID info try
http://www.microsoft.com/technet/support/eventserrors.mspx - Anonymous
March 25, 2004
Well,
I am on the troubleshooting side most of the time (supporting users or fixing "unfixable" problems) and like the short and quick KB's that explain the problem and solution and then have a link to bigger KB or withepaper if you need more info.
As a suggestion I will try to merge really similar KB documents into a single one but with different "steps" on it.
Saludos,
Benjamin Mateos - Anonymous
March 25, 2004
I agree with Becky. Give me enough to solve the problem with a link to something I can read later. BUT please add enough key words and update it as new products are released. (I've had trouble lately finding info on Server 2003.) - Anonymous
March 25, 2004
Of course I want it to quick explain how to solve the problem, but sometimes it is important to have more information. So I agree with Becky, Kelly, B.Y. ... Should I have been named with a 'Y' too ? :-) - Anonymous
March 25, 2004
I personally find all Microsoft search quite horrible, so if good search for long kb's is part of the mitigation strategy, you'd better come up with a better strategy.
Search aside, I prefer short, to the point entries. Linking to other entries is fine. If entries are too long, they aren't too useful for "I just got this error and need to resolve it ASAP" fixes, which, I suspect, is what many people use the KB for. For paterns and practices (e.g. not "I need an answer now!!"), I think long white papers or how-to's are just fine...in fact they are desirable, because they have to cover a great many scenarios and show admins/devs an issue from many angles.