FANDOM


The word "wiki" comes from a Hawaiian word, meaning "quick". The original idea is that pages can be rapidly constructed and threaded together by links to grow organically. It should come as little surprise that they don't always begin with organized models, and can flow quickly from one article to the next without putting them into more carefully considered structures. This can contribute to the rapid growth of small wikis, but can make maintaining large wikis with many articles and contributors harder to manage.

Hydra-Blueprints

Blueprints can be made to organize spaces before any construction is done.

Spaces like wikis can need a plan or blueprint to avoid the chaos. Well organized spaces come together either after there are pages, or when a wiki is first created. It helps to have a plan ready before multiple contributors start adding content, but it can be done even for well established communities. The essential best practices of organizing these spaces resides in the discipline, art, and science of "wiki topology". We talked about that briefly in a previous post, but will go into more detail in this one.

The word "topology" means "the study of spaces", and frequently refers to organization. How spaces like wikis are organized and laid out is very different from many websites that organize pages in folders. Owing to the quick nature of crafting wikis, articles are organized by name more than where they are. This makes for easier searching, but makes other challenges when you don't know the name of what you're looking for or want to see similar pages grouped together.

The three-click myth

ROTC-Ft Riley Obstacle Cource

Navigating a website should not be an obstacle course, but readers knowing they're getting closer step by step to what they want to find is important.

First, let's address a long-standing misconception. Once upon a time, some prominent web designers came to the conclusion that any website should be able to be navigated within three clicks to whatever page the reader was ultimately looking for. As websites grew and became more dynamic, including mega-sized e-commerce sites, this became less of a reality. The idea of information scent — the confidence that the link to the next page will get you closer to your goal — became a much stronger predictor of success. If readers remain confident that they're going to the right place with every click or interaction, the site is most usable; what turns readers off is if they have barriers, unnecessary steps, and dead-ends before they get to their intended destination.

As search became more accurate and useful, the need for drilling down through hierarchies is less important if — and only if — a reader knows what they're looking for by name. Search engines are also getting better predicting where a reader wants to go next, but they do need help linking to a reader's destination where even the reader doesn't know how to describe what they are trying to find. Grouping and linking with context and meaning (called semantics) is therefore sometimes much better for the reader when the search engine can't interpret the right keywords for a specific page.

The nature of wikis allows good linking between all points if the author knows where they should be linking. Wikis have a very flat design, with most content pages at the same hierarchal level; in other words, they're not inside trees of folders where a file can only be in one place. What makes wikis very different is the idea of how pages can be grouped dynamically, in categories, to make non-linear paths. Therefore, good organization and reader experience come from knowing how to arrange and manage categories, which reduces the number of false paths standing between readers and what they want to find.

  • Jakob Nielsen's usability tests found that "users' ability to find products on an e-commerce site increased by 600 percent after the design was changed so that products were 4 clicks from the homepage instead of 3." from the book Prioritizing Web Usability, quoted in Highlights from Prioritizing Web Usability.
  • Further UIE usability tests show that it's not the number of clicks but the well-labeled links with information scent that play a key role in usability. - Getting Confidence From Lincoln
  • A practical advice is to replace the three-click rule with the one-click rule: "Every click or interaction should take the user closer to their goal while eliminating as much of the non-destination as possible." - Breaking the Law: The 3 Click Rule

Organizing responsibly

Hydra-Organizing

Organizing articles into categories is the primary focus when we talk about topology.

It may help to think of organizing articles along the same lines as humans organize species of living things. We have a robust and specific system to identify any of the 1.3+ million identified and described species on the planet with only two or three declared names for each species. We can trace the ancestry of those species into larger groups, likes classes, orders and species. Even if we were uniquely identifying each article on a massive wiki into a single category (which we're not!), we can still distill a lot of value in classifying articles into a handful of simple and straightforward categories. Organizing articles into categories is the primary focus when we talk about topology.

Remember that the categories should also make sense to others as much or more than they make sense to the experts. 99.95% of your community's readers are not editors, and may not be experienced in the way that your community's leadership expects. As a reminder, all category pages should have at least a short text description (a lede) which helps define and identify what a category is to be used for. "Blonde characters" is almost certainly not a great category. Categories that are subject to change (a character can often dye their hair) and hold little meaning unless something specific can be said of them. Treating properties of a subject as categories quickly devolves into a chaos of too many things being used to describe a subject, making for maintenance and navigational problems.

Navboxes are helpful when a known and static set of links should be grouped and subgroup into specific orders that are not alphabetical. The history of navboxes shows they were created before the Category: system existed, and that article categories were designed in part to be dynamic replacements for navboxes. However, navboxes can also present a number of challenges in how mobile users interact with them. Overuse of them can also cause problematic experiences for desktop explorers. Search engines can become confused by them as well. If a navbox is created for use on articles, it should almost always have a category that corresponds to it. For more information on Navbox best practices, see Categories and Navigation.

Finally, we should note that Fandom currently does two (related) confusing things that cause annoyance and issues for many editors. Most articles allow easy association with any category using an element at the bottom of the article page, whether that category currently exists or not. If the category does not exist, there is no indication that it is missing. This gives the illusion that any category associated with an article exists and is valid, which can become very aggravating when local wiki leaders find nonsensical or missing categories while doing maintenance. When the right categories do exist, they are not easily found. We had the best of intentions at the time (rapid growth, easy editing tasks) we made these choices, but we did not correct them thereafter and hope to do so in upcoming updates.

Naming of categories

Like article pages, consideration should be given to the special characters (beyond letters, numbers, and spaces) used in the titles of categories. Part of the reason is that search engines do not easily process URLs with non-standard punctuation characters. Wikis are not exempt from this, but the traditions of wikis are understood by search engines and some rules may be eased. The names of categories should, however, be as close to the pattern that a general reader would search for as is possible within the reason of what is being described. Those names should avoid most punctuation (including quotation) unless that punctuation is absolutely crucial.

Page qualification — putting a qualifier in parenthesis — should be avoided unless the original name (i.e. the one most likely to be searched for) matches exactly the concept of another page. "The Walking Dead (comic)", "The Walking Dead (television)", and "The Walking Dead (mobile game)" are all valid. However, a category referring to the TV series "Fear the Walking Dead" should use that wording in the name, where possible, rather than "Episodes (Fear)", as that will not be immediately understood by readers (or search engines).

In some communities, namely some anime and some game wikis, articles are assigned to both a foreign language (e.g. Japanese) category and a local language (e.g. English) category that has an identical meaning. The lede should include the terms in both languages (particularly for search and descriptive purposes) and the foreign language category redirected to the local language category, to avoid duplication. This does not associate the articles with the new category, which will have to be done manually. The assumption in most cases is that searching will be done in the local language by most users, even if they know the foreign term; however, this varies in practice between communities.

Category types

As this guide mentioned the naming and classification of species before, the descriptions of these category types may make sense in that context.

A wiki's particular "kingdom" has to start somewhere, and the root category that contains the top levels of all the others should be marked "X Wiki", or whatever your community's name is. The domain, in this case, is the wiki's own domain name and the kingdom can be considered the language-specific expression of that domain.

500px-Taxonomic Rank Graph.svg

The taxonomy of species makes for a good structural model for how we organize a wiki's space.

General category

A good example of this is a basic level category, such as "Characters" or "Games" or "Weapons". At least one of these should be the first category assigned to nearly any article. It should be rare that more than one is assigned to an article, and the article should be examined carefully if it is describing more than one thing that can or should be split into a separate article.

General categories should be included in the root category, but their members should not. Another way to say this is that the General category pages should be in the root category, or that they should be a subcategory of the root; the articles in the General category pages should not also be in the root category.

Specifier category

This is a little more specific, and often defines an era or group. For example, "Season 1" in a television series or "Game A" in a multi-game franchise. It is recommended that one of these be in an article, only if appropriate. However, this is not always the case: a television or game series might have the same main character across multiple seasons or games, so adding these may be (and typically is) unnecessary. A family category or intersection category (see below) might be more appropriate. When in doubt, don't attach an article to a specifier category.

Specifier categories should be included in the root category unless they are part of a family category (in which case the family category should be included in the root category instead).

Family category

Some communities cover related and semi-independent areas worth mentioning, which become new families. Pixar Wiki, for example, covers the "Toy Story" franchise. Marvel Cinematic Universe covers the "Daredevil" family. The Walking Dead Wiki covers "Fear the Walking Dead". When an article is part of these families, it creates a strong association that will help readers navigate and understand what they're looking at.

Some subjects understandably may have crossover into another family, but the category should only be associated if they are a typical fixture in that family. For example, Supergirl appears in a limited number of episodes of "The Flash", but is not a regular character there and should not have this family declared on her article. They may be related, but they're not exactly the same family. Therefore, only one or two of these is appropriate for a given article in most circumstances.

Family categories should be included in the root category.

Order category

Some families belong to families of their own like "Netflix shows". These should not be associated directly with the typical article. For example, Jessica Jones (the character), should be associated with the family category, but as she herself is not a television show it is not fitting to add the character to "Netflix shows"; it is, on the other hand, a category that both the "Jessica Jones (television series)" article and the "Jessica Jones" family category should be applied to. In another sense, this order might define "trading card games" as different from "video games", where both exist on the same wiki. It should be very rare or impossible to associate more than one of these with a given article.

Order categories may or may not be included in the root category, depending on which makes the most sense. If the family category is included in the root, it's most likely that the order does not need to be there. Doing so may provide too much clutter, as the root is presumed to be fairly crowded at this point. Rest assured that the information scent will lead those on a family category page to their parent.

Class category

Even above order categories, there might be a different way to clarify the family to which an order belongs. For example, on a large franchise wiki it is not unheard of to have "Anime", "Manga", and "Games" — all of which are valid class categories.

Class categories almost certainly should not be included in the root, for the same reason as order categories.

Variety category

Going the other direction, some categories represent a more specific variety than is provided by a general category. "Ranged weapons" or "Submachine guns" are a good subset that fit this idea. Variety and general categories are the most likely to be represented by navboxes, and if there is a navbox in the article it is likely it can be replaced by a category. Variety categories are also good opportunities to link to from infoboxes in a navigation block, as members of these categories are often closely related and navigating to others in the group is very common.

On the other hand, it becomes very easy to flood an article with many variety categories, and this may result in overuse. Some variety categories, like "Main characters", are generic and indistinct or arguable. This is where it becomes necessary to consider whether there is anything worth saying about this category, and a lede can be a good test for that.

Variety categories are the exception to where we would suggest more than one of this type per article. These are the true facilitators of moving between articles. They should not, however, be included in the root. They should be subcategories of general categories.

Intersection categories

"Weapons in Game A" are what we call category intersections. This can occur when any direct combination of general, specifier, family, or variety category defines a set of pages. There are extensions to MediaWiki that help define these combinations, such as DynamicPageList, but these are not always a good fit for communities. An article in "Weapons in Game A" should also be in "Weapons", "Game A", "Weapons in Game A" and potentially other variety and family categories.

True intersection categories should not be in the root, should be subcategories of each category they are combined from, and should themselves be hidden categories. This avoids visual category overload on article pages. If necessary (and it is not distracting), intersection categories can be linked to from infoboxes in a navigation block or navboxes.

Special cases

A wiki's maintenance categories like "Candidates for deletion" should be both hidden and associated with the root category. To preserve the idea of reader-first presentation, it is always a good thing to signal to a wiki's explorers the issues that only editors deal with. Those explorers are there to enjoy the wiki, and editor issues should not create an off-putting or intrusive experience that drives them away or makes navigation more difficult for them.

Fandom has not found "Featured article"-type categories to be a good driver towards explorer attention. They are a reward for quality editor work, but that does not always result in exploration of the article provided. We continue to research this, but ultimately do not recommend this type of category.

Family categories and Specifier categories work in harmony, and organizing them this way presents some special rules. Typically, we would not recommend using "/" in a category name, as it implies a subpage relationship (which can be confused with a nested category or a subpage). Because subpage rules do not apply to categories, there is more flexibility in naming them. A proper and valid specifier name for the category of episodes describing the second season of "Fear the Walking Dead" is "Category:Fear the Walking Dead/Season 2". This is because "Season 2" applies to the primary television series "The Walking Dead" on that community. This should not be confused with the comic series by the same name, nor the multiple video games with the same name.

Putting it all together

This was a lot of guidelines! We want to make sure your communities are getting the best experience. That means a balance between too much choice (or information) and not enough. Regulating and either increasing or decreasing the number of links in articles to a reasonable and responsible limited set helps to improve the user experience and get them where they want to go. With good topology, getting to what they want to see is intuitive and not confusing.



FishTank-100×100

Isaac Fischer Fandom Staff

Isaac rose from the ranks of Fandom contributors to join the Community Technical team in late 2015. He is now an Editor Experience Specialist, with a focus on User Education. Isaac is a television and book fanatic, a sucker for the great outdoors, and a lifelong learner. He's been coding since before attending school but didn't discover Fandom until 2010. Even now, he's hard-pressed to identify his favorite fandoms.
Want to stay up to date on the latest feature releases and news from Fandom?
Click here to follow the Fandom staff blog.

Interested in learning more about community management on Fandom?
Click here to view our community management blog.

Would you like insights on wiki building and usability?
Read through our Best Practices guides for keeping your community growing and healthy.
Want to get real-time access to fellow editors and staff?
Join our Official Discord server for registered editors!

Community content is available under CC-BY-SA unless otherwise noted.