Wikipedia talk:Categories, lists, and navigation templates/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Previous discussions are archived here:

Wikipedia talk:Categories, lists, and series boxes/Archive 1 Wikipedia talk:Categories, lists, and series boxes/Archive 2

Synergy

Some thoughts...

Categories, lists, and nav templates are tools. Thinking they compete with each other is like thinking a hammer, a saw, and a screwdriver compete with each other. Even though you can bang things with a screwdriver, and screw things with the blunt edge of a saw, you wouldn't want to. The wise carpenter puts all three tools in his toolbox, learns how to use each effectively, and learns how to pick the right tool for the job.

Being tools, categories, lists, and nav templates all have different abilities. That is why we use all three. A well done nav template or list can overlap or even duplicate a category and not be redundant with it. This is because the three tools provide different functions.

For beautiful example of this, check out Template:United States and Category:U.S. states. And notice how the U.S. states category contains at least eleven lists. The template provides quick and meaningful navigation, the lists provide additional information and alternate sorting, and the category provides overall organization and links to related groups of topics.

That is synergy.


- Pioneer-12 06:47, 19 Apr 2005 (UTC)


First of all, You appear to have done something that destroyed the ability to edit this talk page by section. Somehow, now the correct sections nolonger appear in the edit screen. Can you fix this problem?

Next, this is not what I asked for. I do not want a lecture. I would like for you to actually write the proposed text, rather than lecture me about it. In other words, I would like for you to actually contribute to the writing of this proposed text. Other editors should also participate.

So, why don't we start all over again at the very bottom of this talk page, and actually write text that could actually be inserted in the project page in lieu of the present list of advantages and disadvantages from the point of view of abilities (as your previously wrote on this topic). I am having trouble visualizing how this might actually look.

And, finally, synergy is only one small part of this proposal rather than the entire point. The major part is the listing of categories, lists, and ASB from a abilities point of view. I would assume that would then lead to a section of instructions regarding merging lists into categories, etc., etc., -- John Gohde 14:06, 19 Apr 2005 (UTC)


First of all, bug be gone. :-)
Next, this wasn't supposed to be article-ready text, but rather an explanation that could hopefully lead to article-ready text. A mini-essay, if you will. You call it a lecture, which implies a negative connotation when not in a university setting. Whatever. Just giving my thoughts on the matter.
Finally, I'm not sure what you're planning. Adding a couple of paragraphs on synergy? Moving all of the abilities sections to their own section? Adding something about when to turn lists into categories?
This is getting to be very tiresome. I would like to get back to actually discussing issues directly pertaining to the article. I have given my thoughts on synergy and how it applies here. I look forward to hearing everyone's thoughts on this. What do you think of the example? I think it should be in the article. - Pioneer-12 19:48, 19 Apr 2005 (UTC)

Advantages and Disadvantages

The contents of these sections have been bouncing around like a caffeine addict doing the Hokey Pokey. So many things have been moved in and out of these sections I'm not sure what should be in there any more. I think it would be helpful if people made a list, on a seperate page, of all the things they think should be listed in these sections, instead of reverting minor changes back and forth. I would especially love to compare Snowspinner's list to John Gohde's list. - Pioneer-12 03:09, 7 Apr 2005 (UTC)

Isn't this the sort of thing this talk page is for? The following subsections are from the 16:29, 10 Apr 2005 version of the article (one back from current - I couldn't figure out how to get an invariant URL for the current version). How about if in these sections we propose additions in italics, keep the current ones in regular text, and use strikethrough font for ones we decide to delete (no actual deleting allowed), and comment here before changing the article text? I added an advantage to lists (not following these conventions) listed below in italics, which is the difference between what's below and the current article. -- Rick Block 01:25, 11 Apr 2005 (UTC)

Advantages - Abilities of categories

  1. Auto-linking. Create a link to a category on an article page, and a corresponding link to that article will be visible on the category page.
  2. Multi-directional navigation. A category can contain multiple subcategories, and can also be part of several categories. They naturally organize into a web of knowledge. (See folksonomy.) Categories are organized within Wikipedia into a web of knowledge starting with Category:Fundamental.
    Proposed change - The statement simply is not true, since webs of knowledge created with lists or ASBs are easier to use do a better job of presenting the information. -- John Gohde 08:02, 11 Apr 2005 (UTC)
    • I disagree with the reasoning here. Even if categories were harder to use (and I don't think the real issue is ease of use, it's attractiveness of presentation), this does not make the statement untrue. How about Categories are organized within Wikipedia into a web of knowledge starting with Category:Fundamental? --- Rick Block 13:10, 11 Apr 2005 (UTC)
    *Can somebody please show me this web of knowledge created by categories? Where exactly is it? Does it fit nicely on one page or over 200? -- John Gohde 20:48, 11 Apr 2005 (UTC)
    • I'm not sure where it's written, but I believe the intent is that all articles will be added to at least one category. Per WP:CG, all categories except for category:fundamental are supposed to be parented by at least one category. Assuming both of these have been done wih a modicum of intelligence, any article within wikipedia should be linked to any other (by category traversal "up" toward fundamental and then back "down" via some other branch). Of course, the same argument can probably be made about regular links within articles but links within articles have no hierarchical relationship to a well defined "root". Does the "web of knowledge" induced by categories fit on one page? No. Does it fit on 200? Who knows, but probably not. -- Rick Block 21:45, 11 Apr 2005 (UTC)
    • Surely, it is not that mess in Categories? Where is the page where only the highest of highest levels of categories are displayed? It does not exist, does it? Kind of proves my point don't it? I shall repeat, where is this web of knowledge displayed with categories? -- John Gohde 22:01, 11 Apr 2005 (UTC)
    • I'm not understanding the issue. From category:fundamental (a category page, not an article page), one can (in theory) traverse via subcategories to a category containing any article. Hence, all articles are "linked" via some linkage of the form article -> category -> supercategory -> ... -> category:fundamental -> subcategory -> ... -> subcategory -> article. -- Rick Block 22:20, 11 Apr 2005 (UTC)
    • Anyone else have any comments on this change. Going once ... -- Rick Block 04:20, 17 Apr 2005 (UTC)
      • Going twice... -- Rick Block 03:39, 18 Apr 2005 (UTC)
  3. Dynamic schemes, such as categories, are good for categorizing items that are likely to change. Thus, categories are ideal for tracking items like best selling books, NPOV articles, and current events.

Disadvantages of categories

  1. Alphabetical order only (though you can control the alphabetisation).
  2. Their purpose may not be immediately apparent to new visitors to Wikipedia, since their names, being short, are not very descriptive of their key role in navigation on Wikipedia.
  3. Categories are not operational on most mirror sites.
  4. No formatting control over how articles and categories included in a category are shown.
    Addition of this item to the page was reverted by user:David Gerard as m:instruction creep. I suggest generalizing the first item to include this notion, perhaps Category listings are automatically generated, in alphabetical order (though you can control the alphabetisation), with no editor control over formatting. -- Rick Block 18:51, 12 Apr 2005 (UTC)
  5. Wikipedia's redirect feature cannot be used to create differently named, but functionally identical, categories.
    Proposed addition. -- Rick Block 01:53, 11 Apr 2005 (UTC)
  6. The default user skin places the display of categories at the very bottom of an article. Thus, visitors may not be even aware of their existence.
    Proposed addition -- John Gohde 07:11, 11 Apr 2005 (UTC)
  7. Being constantly recreated on a realtime basis, categories put an operational hardware drain on Wikipedia that has the effect of slowing the responsiveness of Wikipedia down.
    Proposed addition -- John Gohde 07:11, 11 Apr 2005 (UTC)
  8. When only a backup copy of Wikipedia is available for viewing due to server problems, categories are not operational whereas lists still offer an older version to navigate with.
    Proposed addition -- John Gohde 07:11, 11 Apr 2005 (UTC)
    • I think this is effectively the same as the previous one and should be combined. -- Rick Block 14:06, 11 Apr 2005 (UTC)
  9. A category cannot be edited collectively as one single page, even if annotated categories are being used. Editors must travel all over Wikipedia in order to changed a category, rather edit the category directly itself.
    Proposed addition -- John Gohde 07:11, 11 Apr 2005 (UTC)
    • This is the dual of advantage #1. I'd restate it so the relationship is much more obvious. -- Rick Block 14:06, 11 Apr 2005 (UTC)
  10. The reason an article is included in a category must be self-evident since there is no opportunity to visibly annotate within an article why it is included in a specific category.
    Proposed addition. -- Rick Block 12:54, 11 Apr 2005 (UTC)
  11. As category usage increases many articles, particularly biographical articles, end up being added to many categories resulting in a large list of category memberships. Display of the category membership listing, and due to the use of templates which include articles in categories even the ordering of this listing, is not under user control.
    Proposed addition. -- Rick Block 12:54, 11 Apr 2005 (UTC)
  12. Dynamic schemes, such as categories, are wasted on categorizing items that are not likely to change. Thus, categories should not be used to track items that will never change, like ancient Greek philosophers.

Advantages - Abilities of lists

  1. Lists can be annotated. That is they can include additional information beyond the item name. For example, a list of soccer world championship teams can also list when the championship was won. This ability can be used to explain why a particular article is included in a list, which is sometimes useful for sensitive or controversial lists. This also allows a list to include similar, but not quite identical, types of articles that might require multiple categories. One example might be nominees for an award. In a list, the winners can be indicated. Conveying the same information in categories requires separate categories for winners and non-winning nominees.
    Add the bit about similar, but not identical. -- Rick Block 04:20, 11 Apr 2005 (UTC)
  2. Lists can include items for which there are no articles (red links); categories can only list things for which there are articles, unless stubs are created.
  3. List items can be sorted using a variety of methods and can be manually formatted like any other wikipedia article. An article can be listed several times or in different ways in the same list, or shown both in its major category as well as in several different subcategories.
    Proposed formatting addition. -- Rick Block 04:13, 11 Apr 2005 (UTC)
  4. Lists that intelligently show relationships are easier to use than their respective category.
    Proposed addition -- John Gohde 06:57, 11 Apr 2005 (UTC)
    • I would change "easier to use" to something like more comprehensible and include this in the previous item. I think this follows from the ability to control the formatting. -- Rick Block 14:16, 11 Apr 2005 (UTC)
  5. Just like the index of a book, an article can be listed several times or in different ways in the same list.
    Proposed addition -- John Gohde 06:57, 11 Apr 2005 (UTC)
    • Not in quite these words, but this seems to be already mentioned in #3, above. -- Rick Block 14:16, 11 Apr 2005 (UTC)
  6. It often desirable and physically possible with a list to have an article shown both in its major category as well as in several different subcategories.
    Proposed addition -- John Gohde 06:57, 11 Apr 2005 (UTC)
    • This is already mentioned above, in #3. -- Rick Block 14:16, 11 Apr 2005 (UTC)
      • It should at least be stressed more in #3 as this is explicitly prohibited in the implementation of categories by this guideline. This fact makes categories less comprehensible. -- John Gohde 21:02, 11 Apr 2005 (UTC)
  7. As currently implemented, lists which are file based put less of an operational hardware drain on Wikipedia then categories which continuously have to be created on a realtime basis.
    Proposed addition -- John Gohde 06:57, 11 Apr 2005 (UTC)
  8. All lists could be linked together, creating a web of knowledge, by use of a complete set of glossaries in the form of annotated lists. With a little work, list of glossaries could be developed into a complete web of knowledge.
  9. Static categorization schemes, like lists, are excellent for listing items that are not likely to change.
    Proposed addition -- John Gohde 04:05, 19 Apr 2005 (UTC)

Disadvantages of lists

  1. Not auto-linked, as categories are.
    Proposed change - Do we really need to say that not having the properties of a category is a disadvantage? And, why is this property being singled out? To me, not being auto-linked is clearly an advantage rather than a disadvantage. -- John Gohde 08:08, 11 Apr 2005 (UTC)
  2. Lists are often redundant with categories. In order not to be redundant, a list must do a significantly better job of presenting the articles than the respective category.
    1. Redundant lists are potentially subject to being deleted, merged, or redirected to the preferred use of a category. In order not to be redundant, a list must do a better job of presenting the articles than the respective category.
      Proposed change -- John Gohde 07:15, 11 Apr 2005 (UTC)

Advantages - Abilities of article series boxes

  1. Provide a consistent look and navigation system for related articles (though not between different topics — there is no standard format).
  2. Faster to navigate than a category.
  3. Although controversial, navigational boxes can be used as an extended see also footer for geographical articles containing direct links to multiple types of articles (cities, counties, etc.).
    Propose addition. -- Rick Block 04:26, 11 Apr 2005 (UTC)
  4. The presence of an ASB within an article encourages the reading of articles shown within the respective box.
  5. A number of ASB's have already been developed that provide a complete web of knowledge, such as Wikipedia:Browse by overview and Wikipedia:Browse.
    Proposed additions -- John Gohde 07:20, 11 Apr 2005 (UTC)
    • I would like to add that of the the three choices, a blue box does the best job of presenting the web of knowledge on Wikipedia to the public in a form that is very compact and comprehensible. Thus, the artifical restriction of Snowspinner of restricting ASBs to just linear series is just plain stupid and should be dropped. -- John Gohde 21:09, 11 Apr 2005 (UTC)

Disadvantages of article series boxes

  1. Almost always replaceable with a category. It can be difficult to give more detail than a category can give without the box becoming unmanageably large.
  2. Article series boxes are often considered unsightly. Multiple boxes are generally considered a blight.
  3. Often inadvertently push a POV — suggesting that one aspect of a topic is more important than others, being used to advertise obscure topics in prominent places, or asserting project proprietorship. Many templates go to WP:TFD because they appear to push POV. People often add more series boxes to try to remedy this, exacerbating complaints of unsightliness.
    1. Wikipedia's NPOV policy might mean that multiple ASBs would be required in some articles in order to avoid the appearance of promoting only one point of view.
      Proposed change -- John Gohde 07:18, 11 Apr 2005 (UTC)

Categories naturally organize into a web of knowledge, NOT?!

Isn't it queer than when categories naturally organize into a web of knowledge, that our beloved Main page doesn't have a single category on it? Isn't it odd, that Main page uses a list, and a template no less, to organize the entire web of information on Wikipedia? Gee, I wonder why? Could it be that plain old lists are easier to use than categories?

Clicking on Article overviews produces one of those dreaded ASBs which just happens to do an even better job of helping visitors to Wikipedia find what they are looking for. Likewise, clicking on BROWSE produces a very useful ASB. Compare these two ASBs to Category:Fundamental and try to tell me that the category does a better job of presenting its respective information!

Clicking on SCIENCE unfortunately produces a category which is nothing but a total mess of unorganized information. A bulleted list, intelligently showing relationships, or an ASB would do a much better job.

Categories naturally organize into a web of knowledge, NOT! -- John Gohde 23:00, 10 Apr 2005 (UTC)

Categories DO naturally link together into web of knowledge. The concepts of "every article belongs in a category" and "every category belongs in a category" facilitate this. It's true that they don't necessarily form a well-organized web--but this is due to the distributed nature of Wikipedia: Just like as article takes skill and effort to become high quality, a well organized web of categories takes skill and effort. - Pioneer-12 05:58, 19 Apr 2005 (UTC)
I partly disagree - CURRENT categories have no way to structure the data, because they have no properties their elements should carry. This is a lack of structure in wikipedia and consequently results in a bunch of problems -see below

Objections to proposed additions

I like very little of the proposed additions. Some might be appropriate for a discussion page on the advantages and disadvantages of categories, lists, and/or series boxes, but let's remember that that's not what this page is. This page is a guideline on how and when to use each one. Massive lists of advantages and disadvantages - particularly when some of them are as idiosyncratic as these (Don't work during server downtimes - applies, what, four days a year?) make this harder, not easier. Most of these seem to me to be m:Instruction creep rather than helpful expansions. Snowspinner 13:04, Apr 11, 2005 (UTC)

Please discuss each one individually. The point of listing them all here (on the talk page) is to provide a record of the discussions and, I hope, provide a more controlled mechanism for adding to and/or changing the actual list on the guideline page. I believe the feedback is that at least some editors are not happy with the guidelines as currently written and being bold has resulted in an unmanageable number of changes to the guideline page. -- Rick Block 14:50, 11 Apr 2005 (UTC)
I have to say, "discuss 13 changes individually when a blanket objection to the idea of adding to this page without good reason" and "controlled" don't seem to go together to me. How about I go on record opposing all additions that are not offered with substantive justification for the instruction creep. As a general rule, I oppose additions that go beyond identifying an area of difference and a broad statement of the nature of the difference. So I would prefer "lack of control over how categories are ordered" and "Inability to annotate individual entries" to a description of every effect of these. Yes, the inability to annotate means they need to be obvious. But that's overly specific for the guideline. This is not Philosophy of categories - it's a functional guideline. The onus is on the proposal to show that it aids in functionality, and is not just using a guideline page to conduct a philosophical discussion on systems of organization within an encyclopedic project. For these things, meta and talk pages exist. Snowspinner 16:25, Apr 11, 2005 (UTC)
Agreed. The onus is on the people trying to triple the length of the page to show why this is a good idea. Read m:instruction creep and try to learn its message. Conciseness is essential in a usable guideline - this is supposed to be something an editor can refer to quickly and get a good idea of how common sense works out in this area. Omit needless words. - David Gerard 17:08, 11 Apr 2005 (UTC)
I am not suggesting we triple the size of the guideline page. I am suggesting we discuss potential additions before changing the guideline page. Perhaps I came to the party late, but from what I can tell user:Snowspinner and user:John Gohde both have valid points, but have essentially stopped listening to each other. I'm trying to help by providing a place (here) where both can be heard. Snide comments (from an arbitrator!) are not helpful. -- Rick Block 20:10, 11 Apr 2005 (UTC)
I don't think David was being snide here. It's just that... well... John has never really offered an explanation for his additions, beyond his clear hatred of categories. And so before I spend time getting into a thirteen-pronged discussion with him over each and every one of his additions, I want him to actually offer an explanation of them - what do they add that is both of general yet non-obvious interest that is not covered elsewhere. Why do they make the decision of which organizational system to use clearer rather than more opaque and complicated. I don't really have time to spend arguing points that John can't be bothered to articulate in the first place. These are basic questions that need to be answered whenever somebody is trying to add to a policy or guideline. Snowspinner 22:05, Apr 11, 2005 (UTC)
My apologies if I offended; I wasn't meaning to come across as being snide. I was, however, intending to come across as blunt. Instruction creep is bad. A guideline must be concise. Read m:instruction creep and hack away at excess verbiage in guidelines - David Gerard 18:51, 12 Apr 2005 (UTC)
Conciseness is good. As "The Elements of Style" recommends, "Omit needless words." However, beware of oversimplification--guidelines need to be concise AND thorough. This isn't meant to be a summary; this is meant to be an explanation. Things need to be spelled out (but spelled out in the most straightforward way possible).
Thus: "Omit needless words, but don't omit needed words." or "Make things as simple as possible, but no simpler." - Pioneer-12 22:13, 13 Apr 2005 (UTC)

m:Instruction Creep

On a side note, I don't know why everyone keeps referencing m:Instruction creep. That page is about the "how to use this page" instructions found on pages such as Village pump and Featured article candidates. It's not meant as a style guide or as a commentary on Wikipedia guidelines in general. - Pioneer-12 23:52, 13 Apr 2005 (UTC)
I comprehensively disagree. It applies to anything that's instructions, and that certainly includes guideline pages - David Gerard 01:18, 14 Apr 2005 (UTC)
I completely disagree. m:Instruction creep is not even a part of Wikipedia. If it was that important, it would be a part of Wikipedia. -- John Gohde 02:01, 14 Apr 2005 (UTC)
Furthermore, I recently took a closer look at meta and it appears to be just a colossal garbage dump. Meta's main page does not even indicate clearly what meta contains. There is no apparent meta web of knowledge. But, getting back to my original point. What do Wikipedians go by: NPOV or m:NPOV? Quite obviously, we go by NPOV. The same logic applies to m:Instruction creep. If there was any merit to your comments, you would be referencing Instruction creep. It don't exist. Therefore your point is mute and you are exercising bad faith for even bringing it up. -- John Gohde 19:53, 15 Apr 2005 (UTC)
Indeed, we do go by NPOV. And we know that we have to go by NPOV because of m:Foundation issues. Snowspinner 20:06, Apr 15, 2005 (UTC)
Okay, Fred Bauder's fork Wikinfo project uses a sympathetic point of view rather than NPOV. So, what? Unless you show a direct connection to m:Instruction creep, your reply is besides the point. -- John Gohde 20:23, 15 Apr 2005 (UTC)
My point is that Meta contains pages that apply to all of the Wikimedia projects. So, while NPOV applies only to en, m:Foundation issues shows us five rules that must apply to all projects hosted by the Wikimedia foundation. Other pages on meta like m:Instruction creep. m:MPOV and m:Don't be a dick are important also - not because they're policy, but because they're really good ideas. Snowspinner 20:38, Apr 15, 2005 (UTC)
Says, you and David, but no one else. Itis really very simply, if there was any merit to your comments, you would be referencing Instruction creep just like you can reference NPOV. Furthermore, as both you and I have painfully pointed out m:Foundation issues does not include any reference to m:Instruction creep. Ergo, it is not required to be used in Wikipedia per your own words that you just wrote above. -- 01:52, 16 Apr 2005 (UTC)
Ummmm... what? Foundation Issues are five things that Jimbo and the Foundation have said are non-negotiable for a project to be hosted by the Foundation. That doesn't mean that they're the only generally applicable pages. Instruction creep is bad on any Wikipedia, and so it goes in Meta. It's not foundation-mandated, but that doesn't mean it's somehow a good idea, any more than m:Don't be a dick is bad advice because it doesn't stem from the Foundation. Snowspinner 13:09, Apr 16, 2005 (UTC)
Another Freudian slip, I suppose? -- John Gohde 06:17, 17 Apr 2005 (UTC)
I'm not sure you understand what Meta is. Snowspinner 02:52, Apr 14, 2005 (UTC)
I am not sure that you understand the implications of referencing meta? I can, also, quote Larry Sanger from Meta [1]. Meta is not Wikipedia. Just thought that might want to know. -- John Gohde 04:07, 14 Apr 2005 (UTC)
Hmmm. I think we all agree that m:Instruction creep is not official policy but is something worth considering. More important, though, is: What exactly do you think it is saying? If you think it's saying "omit needless words--keep instructions concise" then I agree with that principle. If you think it's saying "Less detailed instructions are inherently better" then I completely disagree.
Actually, I think the page is misnamed; it should be called "Procedure creep", as it is more about tedious bureaucratic procedures then helpful "how-to" instructions. (Reread it if you don't believe me.) - Pioneer-12 07:07, 19 Apr 2005 (UTC)

I think that this guideline should be as big as it is required to be and no smaller. Furthermore, we have just begun to make this guideline useful. I still want a separate section discussing synergy and redundancy and precisely how editors are supposed to know when a list or ASB should be deleted or merged into a category. The real work has just begun. Otherwise, this whole guideline should be deleted as so far it is clearly redundant and totally unnecessary. -- John Gohde 20:42, 11 Apr 2005 (UTC)

Feel free to mark it for VfD, John. I think you'll find, though, that this would be considered a violation of WP:POINT by a lot of people. Snowspinner 22:05, Apr 11, 2005 (UTC)
Speaking of getting bigger, Wikipedia:Categorization clearly mandates that this guideline is supposed to cover infoboxes per [2]. -- John Gohde 23:43, 11 Apr 2005 (UTC)

Issues with the current guidelines

Here are my issues with the current guideline page:

  1. The article essentially starts with a "how to" for categories repeated from WP:CG. Not only is this redundant, but it reinforces the notion that categories are the most desirable option.
  2. The article fails to mention performance implications. Perhaps we should get a comment from a developer, but from what I can tell large categories are essentially BAD for wikipedia and led to the 200 articles per page limitation.
  3. The article at least strongly implies the first choice organizational method should be category ("the policy on lists is generally fairly permissive"). IMO, categories have gotten to the point where they are ridiculously overused. For example, see category:Best Supporting Actress Oscar Nominee (film), a category for films casting a non-winning nominee for the best supporting actress oscar (note to cburnett if you're reading this - it really isn't anything personal). I listed this category at WP:CFD, but there were no votes either way. There is no guideline I can point to to support my contention that this is a ridiculous way to organize these articles and, in this case, a list should be used (see, for example, List of Best Supporting Actor nominees and List of Best Supporting Actor nominees (films)).
  4. The article fails to mention a number of significant advantages and disadvantages and doesn't exactly hit the essence of some that it does mention. Specific examples:
    • Category disadvantage #1 - the crux of this is that category listings are automatically generated in alphabetical order, 200 entries per page. You can control the order, but nothing else.
    • Category disadvantage #2 - not only is their purpose not readily apparent, their very existence is not readily apparent since with the default skin they are listed at the bottom of an article (often following a large chunk of whitespace).
    • Category disadvantage not mentioned - no real way to provide synonyms (redirects) for categories.
    • Category disadvantage not mentioned - the list of categories an article is in (as opposed to the category listing itself) is auto-generated with no editor control of the formatting (including the order due to template-based categorization).
    • There are more, but I don't have time to re-list them all here (see above, and I'll admit that not all of the additions proposed above are significant).
  5. Wording for some of the advantages and disadvantages that are listed could stand to be improved.

I wouldn't say I hate categories (yet) - a large percentage of my more than 10,000 edits on wikipedia are category-related. On the other hand, I definitely think categories are currently overused and it pains me that there isn't a guideline to point to to justify WP:CFD votes for deletion in cases like category:Best Supporting Actress Oscar Nominee (film). I'd like this guideline to be the place. Categories ARE useful, but so are lists and so are navigational templates (and not just for series!). -- Rick Block 20:03, 12 Apr 2005 (UTC)

I basically agree with your issues listed in this section. But, I still want a separate section added that discusses synergy and redundancy and precisely how editors are supposed to know when a list or ASB should be deleted or merged into a category. It is very important that redundancy be precisely defined and how one is supposed to know when redundancy occurs be explicitly pointed out even if some editors think that it is self-evident. -- John Gohde 04:23, 13 Apr 2005 (UTC)

Advantages... or abilites?

This page is a guideline on how and when to use each method. In order to know how and when to use each method, I need to know what each method can and cannot do. That is, I need to know the abilities of each method. The purpose and utility of the "advantages" sections is to let readers clearly know the abilities of each method.

However, some people have seen these sections as a competition and as a podium to show that "categories are good" or "categories are bad". (How silly!)

Perhaps it would be better if the advantages sections were renamed "Abilities". This would:

  1. More directly relate to what the readers are looking for.
  2. Make the content of the sections more objective and concrete. (An "advantage" can be a matter of option. An ability is a matter of fact.)
  3. Reduce arguments over what should and should not be in those sections. (I hope.)

- Pioneer-12 22:15, 13 Apr 2005 (UTC)

I do believe that the idea is to modify the above blue box on the talk page until a consensus is reached. So, I suggest that you implement your above suggestions in the blue box. -- John Gohde 23:52, 13 Apr 2005 (UTC)
Section titles changed... but I think the entire box's content needs to be reevaluated using the perspective of "abilities". We may need a new box. (And the "blue box" is grey, not blue, in my browser. :-p) - Pioneer-12
I wasn't too happy with the additions of the 'advantages/disadvantages' lists going in (did I mention how much I hate instruction creep?), but they're looking useful (e.g. how to avoid your shiny new template becoming a candidate for WP:TFD) - David Gerard 01:18, 14 Apr 2005 (UTC)

Focusing on abilities will also make these sections shorter and more cogent, as non-ability related items will be removed. It also, I think, makes the "disadvantages" (or "lack of ability") sections unnecessary. They could be replaced with notes on "when not to use".

Being shorter and to the point should make a number of people, including Dave Gerard, Snowspinner, and myself, happy. - Pioneer-12 20:05, 19 Apr 2005 (UTC)

Replace "Disadvantages" with "When not to use"

Here you go. This fits in with the whole abilities point of view. I think these sections should replace the current "disadvantages" sections. Interestingly, by thinking in terms of abilities and "when to use, when not to use, and what to use instead", you see how these tools complement instead of compete with each other. It's synergy, baby! - Pioneer-12 22:33, 19 Apr 2005 (UTC)


When not to use categories

When it is a grouping that it not a "classification" or a grouping that requires annotations. In these cases, use a list instead.

When it is a grouping mainly for navigational convenience. In these cases, use a navigational template instead.

When not to use lists

When it simply duplicates a category and adds no meaningful annotations. In there cases, use a category instead.

When not to use navigational templates

When articles that are in the same subject but not meaningfully related to each other. For example, Eli Whitney, Adolphe Sax, and Levi Strauss are all inventors, but they have have no significant connection to one another. Navigational templates should only be used when one would want to directly navigate from one topic to other. For general classification, use categories.

For long lists of items. If a navigational template is too large, it clutters up an article and distracts from the article-specific content. In these cases, the template should be converted into a list or category.

Proposed rewrite of project page

from an abilities point of view

Categories, lists, and series box synergy

Categories, lists, and nav templates are tools. Thinking they compete with each other is like thinking a hammer, a saw, and a screwdriver compete with each other. Even though you can bang things with a screwdriver, and screw things with the blunt edge of a saw, you wouldn't want to. The wise carpenter puts all three tools in his toolbox, learns how to use each effectively, and learns how to pick the right tool for the job.

Being tools, categories, lists, and nav templates all have different abilities. That is why we use all three. A well done nav template or list can overlap or even duplicate a category and not be redundant with it. This is because the three tools provide different functions.

Synergy is the interconnections between categories, lists, and series boxes and the benefits that Wikipedia expects to realize from their intelligent use. Here we will describe a complementary approach where none of these tools compete with each other. This section is a guide on how and when to use each tool.

Applications that categories excel at

  1. Dynamic schemes, such as categories, are good for categorizing items that are likely to change. Thus, categories are ideal for tracking items like best selling books, NPOV articles, and current events.


Applications not suitable for categories

  • xxx

What is getting to be very tiresome is working with a contrary editor, who absolutely refuses to help reach a consensus with at least 2 other editors on anything, even on their own ideas. You are a breed of editor full of ideas, or hot air depending on your perspective, who for what ever reason refuses to articulate their own ideas into workable text in the above box of whatever color. Either you are either incredibly obnoxious or extremely dense.

Therefore, as far as I am concerned, I consider the abilities idea offically dead until you develop something that I can actually see. Feel free, to do whatever. I am back to developing the advantages/disadvantages approach.

Just incase you, truly don't know. The editing capabilities of this talk page remain destroyed. -- John Gohde 22:43, 19 Apr 2005 (UTC)

Two things:

  1. Stop the personal attacks. My actions speak for themselves. I find your view of me to be lacking any basis in reality.
  2. The section editing works for me (most of the time). There seems to be a bug in the software where it doesn't always work. What's causing it? Perhaps the use of html-style section headings.... I replaced the html with wikitext, and everything seems to be working now. - Pioneer-12 23:35, 19 Apr 2005 (UTC)

General objections to the rewrite

I like very little of the proposed additions. Some might be appropriate for a discussion page on the advantages and disadvantages of categories, lists, and/or series boxes, but let's remember that that's not what this page is. This page is a guideline on how and when to use each one. Massive lists of advantages and disadvantages - particularly when some of them are as idiosyncratic as these (Don't work during server downtimes - applies, what, four days a year?) make this harder, not easier. Most of these seem to me to be m:Instruction creep rather than helpful expansions. Snowspinner 13:04, Apr 11, 2005 (UTC)

I agree: idiosyncractic and POV advantages and disadvantages are not helpful to the reader. They would be great for a seperate page but don't belong here. What do you think of changing the advantages sections to abilites? (See my thoughts above.) - Pioneer-12 23:50, 19 Apr 2005 (UTC)

navigational templates =? article series boxes

There's an old issue that as far as I know has never been resolved regarding the wording about navigational templates that are not article series boxes (the article says these should be replaced with categories). I've started a discussion on this topic at Wikipedia talk:Navigational templates#Many_navigational_templates_in_violation_of_WP:CSL,_what_to_do?. If you're interested, please commment there. -- Rick Block (talk) 19:31, Jun 8, 2005 (UTC)

Modification to category/sub-category rule

I think there's a case that calls for modification of the rule on articles not being in both a parent category and a sub-category (besides the existing exception of when the article defines the sub-category.) I'll lay out a hypothetical case that illustrates why this second exception makes sense; please bear with me as I lay out the (imaginary) facts:

  • Thurnald Humdingler and Weskell Beanwexler are famous as perhaps the two most noted critics of the artistic movement of Neo-Wootzlerism.
  • Humdingler, before he became a passionate critic of the movement, was one of its primary adherents.
  • There is a parent category, Category:Neo-Wootzlerism, but at the start of our story it has no sub-categories.
  • Someone creates the sub-category Category:Adherents of Neo-Wootzlerism, for past and present adherents of the movement.
  • Because Humdingler was an adherent once, his article is added to the category Adherents of Neo-Wootzlerism.
  • Humdingler's article is then removed from the general category of Neo-Wootzlerism, because according to a rigid interpretation of the category scheme, an article should not be in both a parent category and a sub-category (barring the definition exception.)

This is where the meat of the problem shows. Humdingler is relevant to the parent category in two ways: as a former adherent, and as a critic. However, because one of those two ways has its own category, it is (incorrectly) being presented as if it was the only way he was relevant to the parent category. Beanwexler is a prominent critic, which earns him his place in the parent category, but Humdingler, an equally prominent critic, is deprived of his place in the parent category because he once was an adherent.

For this reason, I suggest we add language which explains a second exception: when the article has a relevance to the parent category that does not fall under any of the existing sub-categories -- even if it has other relevance which does. -- Antaeus Feldspar 01:03, 14 July 2005 (UTC)

Yes, this makes sense. For instance, in our category of French revolution figures, I believe that many of the leaders of the revolution are all divided up into subcategories by their means of death. It is absurd that this subcategorization should remove them from the main category. john k 01:19, 14 July 2005 (UTC)

Similar problem in the Category of Linguists, there are also Categories of Linguists by Nationality (why? sure beats me. Isn't boolean AND by category possible?). All linguists would presumably fall in both the general Linguists cat. and the cat. for linguists of their particular nationality. Some linguists have been sorted under both, some under just Linguists and some just under <some nationality adjective> linguists.
Now, let's say some linguist (like me) would like to see which of his/her colleges are mentioned in wikipedia, by following category-links instead of searching for N thousand names by hand. As it is, he/she must know in which country the colleague was born or currently has citizenship, since the number of actual linguists listed on the Category:Linguists are very few indeed. And what happens if a linguist changes nationality? Rather silly, no? It might be that nationality is very important in some fields but linguistics is not one of them, for that we are too few, and those who go for tenure-track often ends up living quite a nomadic existence. --Kaleissin 20:25:10, 2005-08-20 (UTC)

does the rule against vertical over-categorization apply to categories as well?

The project page guidelines specify that an article should not be in both a parent category and a sub-category, unless the article defines the sub-category. Does this apply to categories themselves as well as articles? That is, if Category A is in Category B but does not define it, and Category B is in Category C, does the rule specify that Category A shouldn't be also a direct sub-category of Category C? That's what is implied by making the same rule on articles apply to categories. -- Antaeus Feldspar 15:19, 17 July 2005 (UTC)

Proposed at Pump

I have marked this as {{proposed}} since there was no policy tag and parts of it seem to lack consensus. My comment on this can be found at the village pump. Dragons flight 01:40, August 13, 2005 (UTC)


Proposal: Semantics, properties and navigation

It seems that the problem of categories, lists, series boxes, navigation bars etc. could be resolved in a structured way, just by building a semantic system. Here the proposal:

  1. add properties of lemmata within a category: (i.e. Lemma:Missisippi, category:river with properties: length:..., continent:..., country:..., ..., etc.) Properties might be images as well (i.e. image of Missisippi) and might have multiple entries (i.e. cities at the Missisippi).
  2. create a standard access scheme for property lookups: i.e{{table category:Mountains country="NewZealand" sortby="elevation in metres" start=1000 columns="Name|elevation|longitude|latitude" title="Mountains in New Zealand above 1000 metres"}}
  3. replace/enhance category by template for category: including display of properties and a "sort by" and "start" + "end" option. This makes lists within articles obsolete and nicely structured
  4. replace lists by category templates (table lookups): lists should only be a part of a category and should not destroy the flow of an article
  5. replace "wild grown" property boxes by real category-property-templates (table lookups): (i.e. within the lemma Missisippi one can just insert the temaplate category:river and everything is nicely laid out, no need to format a huge unmaintainable table anymore.
  6. add/refine navigation and article series templates by lookup tables: Allow for templates that can access the properties within one lemma to directly navigate to the appropriate category, select one of the properties, display the ~5 closest entries within the property (including links, of course) - this replaces "wild grown" navigation bars
  7. add an option to activate/deactivate navigation bars in the preferences and/or keep them minimized, with an option to unfold them on demand
  8. add a property editor, that is activated when editing a lookup table (to edit the property-entries of the category in a structured way)
  9. allow for dynamic sorting if a table displays multiple properties.

This would structure the content in an efficient mannor, while keeping the code and structuretransparent and easy to maintain. See also bugzilla entry

--BoP 08:17:08, 2005-09-02 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Categories,_lists,_and_navigation_templates/Archive_3&oldid=1089226277"