User blog:FishTank/Articles on Fandom

We all know that wiki articles and other pages compose a wiki. The fundamental building blocks of a wiki, though, are its users and its content. Each community has its own tone and they commonly use guidelines and manuals of style to maintain a cohesive &quot;voice&quot;. The traditional guiding principles of big wiki communities &mdash; such as Fandom, Gamepedia, and Wikipedia &mdash; have an open model where articles can be potentially edited by many people. Constructing articles must be a team effort, with no one &quot;owner&quot; and flexibility on what makes for an ideal article. Articles make up the bulk of what most communities supply on a day-to-day basis, more than blogs or images or video.



To attract an audience and more contributors, as a best practice, content should be focused on attracting the reader rather than being geared towards the contributor. Contributors (otherwise known as editors) are most likely to get involved in a community if they are interested in the content. For most communities, that means articles are the most important ingredient to attracting new talented writers. Why is it important to attract new contributors? A leading contributing factor on why wikis become or stay successful involves their capacity to add new contributors and to evolve over time. While very few readers end up becoming contributors, fostering new talent and continually growing (even if that means periodic reviews and changes or loosening of guidelines) is the most reliable method to keep visitors coming back.

This is another case where Fandom and Wikipedia, while very different in scope and tone, can learn similar lessons. As with Categories, outside research outside the wiki realm can be limited. The links below include related pages where Wikipedia describes their ideal articles, which can help you design your own guidelines.

 Wikipedia links and rationale regarding these topics
 * Article size &middot; Readability &middot; Subpages &middot; Wikipedia's Manual of Style § Introductory text

Articles (aka content pages)
There's no one ideal length of an article; it should cover all the important and noteworthy points without being so lengthy that readers lose attention. While there is both clear and unclear research on the topic, an informational article should likely take about 7 minutes to read, and be somewhere between 1000 and 2500 words (not bytes). There are legitimate reasons for individual articles with 4000 - 5000 words of prose if they engage the reader and stay on-topic; beyond 5000 words, contributors should review a body of text for opportunities to summarize and break out potentially independent text into new articles.

Fandom articles, however, frequently include textual content more than narrative text &mdash; including infoboxes, data tables, citations, and navigational templates. Some are composed entirely of images or tables with no narrative at all. In general, the discoverability of a given article depends on narrative text to provide context to a reader; pages without such context tend to be unpopular. An exception to this regards game pages where tables provide the &quot;meat&quot; of an article; these tables should have context as well for the benefit of the casual reader who may not understand jargon and who may be fatigued by monotonous data. In printed media, long or verbose tables are often sent to appendices at the end of a body of work while short and concise tables remain in the main body. Adopting elements of this model may make for more comfortable reading. We'll talk a little more about tables below, and they will be the subject of an upcoming Best Practices blog post.

The readability of text of articles should be in accord with the nature of the audience, when it is known; otherwise, contributors should aim articles for the widest possible general audience. The tone of a Fandom community and its writing style (largely based on how encyclopedic the community guidelines promote) helps determine a good level for what the audience expects. In general, the readability of American newspapers is at 11th-grade level. Entertainment-oriented guides, such as TV Guide and Readers Digest, are written at the 9th-grade level. The most popular novels are written at the 7th-grade level. This supports the fact that the average adult reads at the 9th-grade level. It also shows that, for fun, people read texts that are two grades below their actual reading level. The most common algorithm to determine the grade level and readability of English-language text is the Flesch–Kincaid formula, frequently called the Flesch formula; it is one of the most widely-used, tested, and reliable readability metrics and strongly matches research on how much understanding readers get from reading a text.

Stub pages are pages with either short byte-count or those acknowledged to be placeholders with little information. The common wisdom has been that establishing stub pages are best even if the authors don't have a lot of content to go onto those pages. Google might see such stub pages as ineffective on established communities or topics if they are particularly shallow in depth. On the other hand, if the content or community is fresh, then stub pages can essentially serve as a &quot;foothold&quot; for SEO. Therefore, it is more appropriate to adjust our Best Practices from &quot;stub pages are always good&quot; to &quot;stub pages are only effective if the community already has a lot of content and a good reputation for quality&quot;.

It should be noted that many communities transclude (i.e. include from another page) content in article pages to reduce writing the same information more than once. This is not always helpful, as a reader (and a search engine) may find the same information in many places rather than a single canonical source; this may be both confusing and doing this on many pages may have a negative SEO effect. As a rule of thumb, each article should be at least 80% unique for best value. Like all publications, articles should add design elements (usually with templates to inform and to break up blocks of text visually. These visual placeholders improve the readability and usability of articles, and can improve discoverability. At the point that these dominate the narrative text, they begin to lose usability. The same is also true for infoboxes: moderately sized infoboxes make for good summaries of the article's topic and content, but overly long infoboxes &mdash; we've seen some that are as tall as some rooms! &mdash; are not helpful and drive readers away. An infobox suffering from too much information (i.e. &quot;infobox creep&quot;) should be reduced to the height of a screen on a typical desktop.

Portability is a discipline based on the idea of writing code or content once, and having the client or server shape the output into the most ideal (or at least equally readable) format for the device's screen. Fandom believes strongly in portability, as readers on mobile devices usually view pages more often than those on desktop devices. Showing different content between mobile and desktop experiences is usually considered a disadvantage to readers, and Google assigns penalties accordingly; such differences also accelerate Google indexing the more minimal mobile version first, which can impact how new readers discover your community.

Sections and Headings
For any lengthy article, it is a good practice to break up the content into sections (also known as chapters) using headings. For logic and readability, a topic header (i.e. an &lt;H1&gt;) should be reserved for the page heading (or title), and should not be used in article wikitext. Any sections / headings added to the page should start with a first-level header (i.e. an &lt;H2&gt;) and then downwards in hierarchy with H3 headers. Subsection headings shouldn't go beyond H4.

A table of contents generated from the headed sections is typically inserted after the lede and before the first section. It is left-aligned by default, but should be right-aligned using  for extra long tables of contents. The table of contents should not be suppressed in articles.

The first section of an article, before any headings, is called the lede or introduction. As this is a reader's (and a search engine's) first introduction to an article, it should contain one to two paragraphs of the summary of an article. An article should always have a lede. A lede is a good place for the article's primary infobox, but it is not a great place for quotes or navigation elements. Block quotes, when used in a relevant way to the page's topic, provide an discoverability boost to articles; however, for user experience and SEO purposes, it is preferred to place these lower in a section before they become part of the lede snippet in search results.

Long sections often benefit from having appropriate images alongside the text lower in the page. Galleries of images in their own section lower in the page (below the bulk of the text) are very good for articles, and are preferred to subpages of mostly images (e.g. &quot;/Gallery&quot;). Video should also be placed much lower in the page for best results. Fandom has historically featured videos at the top of some articles, and intends to revisit the strategy later given what we learned from the experiences.

When an article becomes long enough, it could have long sections that could reasonably be split into their own articles. For example, a character&rsquo;s narrative in a television season could be placed into  with detailed plot points and spoilers in that article. The base article could then replace a long section with a spoiler-free summary with the most important points, linked by a context-link hatnote above it (such as ).

When the Tabber extension was developed many years ago, we did not anticipate changes to the web would make it a less than ideal choice for content. We now know that there are several issues that go along with using tabbers in articles, and we do not feel they are a great solution overall. As we've mentioned before, the usability of tabbers can be very tricky and most readers tend to ignore everything on tabs after the initial one. We have done tracking studies to verify this, and always get consistent results. At best, the use of tabbers should follow the 12 design guidelines listed by the Nielsen-Norman Group. In practice, there are many communities that use tabbers properly. On the other hand, there are impacts to search engines (including recent changes by Google in how their algorithm and crawling engine work). Tabbers function by obscuring or cloaking content. Hiding content inside secondary tabs signals to Google that you don't value it; they would rather a user to be able to search something - click a result - and get their answer. If you have competition for the same information and another site satisfies Google's user, Google will begin to favor the site with more immediately visually obvious results. We strongly suggest moving to a model described in the paragraph above (linked subpages) if you feel pages are too long, rather than using tabbers to reduce the article size. We strongly suggest not using tabbers at all unless necessary, and to find alternatives where possible that are more aligned with the way the web works today.

Notices
Notices have two purposes: to inform readers about the status of given articles, and to point editors and potential editors at what's wrong in an article. Neither should be particularly intrusive, and many articles suffer from notice overload. There are two general varieties of notices. Hatnotes are thin, and usually have a minimal or no framing box around the text; most often, they are a single line or sentence pointing to another page or list of pages. Hatnotes are intended to answer the user's question &quot;Am I on the right page?&quot; and direct them to the proper page if they are not. They are particularly useful at the top of sections to point users to a broken-out subpage or more detailed article. The other type, message boxes, are usually thicker and bolder with heavier frames. Message boxes have traditionally been used to mark important informational notices, such as spoiler warnings. They are also commonly used to indicate a page needs some maintenance task.

Where hatnotes (commonly classified as &quot;Context-link&quot; templates) are shown on mobile devices to help navigate between articles, message boxes (commonly classified as &quot;Notice&quot; templates) are not because they are frequently used for maintenance. The general size and visual impact of message boxes can provide a very intrusive experience on articles, and their use should be limited. Hatnotes also should be limited to a maximum of two per section as a general rule.

Tables
Tables can be a vital resource in any article. They are also frequently created with little regard to readability, usability, or data science; this is understandable, as the average contributor is not well versed in how to present data nor should they be expected to be data scientists or web designers. Tables should never be used for full layout of pages. In general, they should not be used for creating individual elements, either, unless the end result is a tabular block; this use case is deprecated unless the element can not be created by other HTML or wikitext elements. The ideal use case for a wikitable is a spreadsheet-like grid.

Individual wikitables can contain a wide variety of columns and rows. Exceeding the natural width of a desktop viewport or skin with a rigidly defined (rather than responsive) template presents problems with usability and readability. Contributors are encouraged to:


 * provide a table caption (which acts as a title)
 * provide a summary for accessibility (though with the summary attribute deprecated in HTML5, a paragraph above the table is more appropriate)
 * provide sortable headers where the column contents for a given row are a single item
 * not mix data types within a table
 * not nest tables inside each other
 * allow tables with many rows to be collapsible
 * break up wide tables logically into smaller tables where the width approaches or exceeds the desktop viewport width
 * not use long narrative blocks (such as descriptions or episode synopses) in the midst of sortable tables (see expand-child on Meta's Help:Sorting)

Pages constructed entirely of tables for layout are a particular concern, as these rarely work well on mobile devices and often do not age well when the browsing experience or skin evolves over time. Web designers have said, in no uncertain terms for the last 20 years, that this is a bad idea. Some Fandom communities tend to think of themselves as more data-oriented, keeping some articles and pages as code chunks or data blocks (such as infoboxes or tables) without any narrative text. This is also strongly discouraged. Having some narrative text on your page, not inside tables, is imperative for search engines to understand your page and for mobile devices. Also, constructing pages with complex templates tends to slow the speed at which they are processed and loaded, and sufficiently complex templates can and will cause pages to crash where they can neither be viewed nor easily edited.

Page naming and URLs
Page names should be as close as possible to the typical search term for a reader's intent. A page name for an episode should be that episode's title, rather than the episode's number or production code. However, these codes can be placed somewhere in the article (usually in the infobox). For page topics with strange characters in their names, it is sometimes helpful to have the standard (searchable) article title and to use the DISPLAYTITLE function. For example, an article should have the page title  and use   rather than use the slash and colon in the article.

Google suggests to |keep the same URLs for the long run, which applies to both site URLs and individual pages. Given how easy it is for wiki pages to be renamed, this should be done infrequently. Having a vast number of redirects for variant spellings, misspellings, and potentially obscure identification numbers (which should be in the article) is not very helpful in most cases, and only creates confusion and maintenance headaches. The search function is usually very good at finding the right page based on text in the body.

Getting more help
We know that many of these Best Practices can be challenging, thought-provoking, controversial, and sometimes difficult to understand. Today, we also are launching a Discord channel (#best-practices on our Fandom/Gamepedia server) where our users can get help and discuss them in more detail. We want to be able to assist our communities on both the large and personal levels, and invite you into the further conversations about making your community the best it can be. I look forward to seeing you!


 * Hydra illustrations by Encredechine for Fandom, CC BY-SA 3.0