KC Lemson

By KC Lemson [MS]


How long is too long for a KB article?

  • Comments 19
  • Likes

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 :-)

  • 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).

  • 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.

  • I agree with the searchable comments.
    My objection is not that the KB pieces are too long, but that sometimes they are too short

  • 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.

  • 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?

  • Good point Jeremy. If the KB could link to the white paper, that would be a fantastic interim solution to making whitepapers searchable.

  • 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.

  • Keep them short with a root cause and resolution steps.

  • 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.

  • 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.

  • 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"

  • 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.


  • 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.

  • 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