Community Central
Community Central

Fandom is the most comprehensive source of information for fans of all varieties of what we love. Contributors from the most comprehensive chroniclers to devoted enthusiasts share every aspect of their fandom topics on wikis. This leads to a lot of material for readers to explore, and getting these readers to what they seek is the purpose of nearly every wiki.

Long Scroll 1 - Sanada Treasure Museum - DSC09604

This antique Japanese scroll is a very long page indeed.

Sometimes, though, such information is not as easily found because it is buried or scarce. Many wikis use tabs and tab panels (called "tabbers") to arrange their content. In this post, we're going to talk about how to organize some article content to make it more accessible to seekers.

Reducing misconceptions about page length

1024px-Felsenegg-Kante Tree Stump Autumn

A tree stump, incomplete

There's a big difference between building a space and maintaining a space. What a community should avoid, from both a user experience and search engine standpoint, is incomplete pages. Traditionally, a page known to be incomplete (particularly if it is a placeholder for known work) has been called a stub. Per Wikipedia tradition, stubs are often marked with a template titled "Stub" at the top; this does not provide explanation to new or potential editors as to what a stub is. Over time, some folks' idea of a stub has come to mean simply any short page, which is not particularly accurate.

The ideal experience is to make stub pages as complete as possible as quickly as possible. Whether that leaves behind a (complete) short page or a long page is not a question that concerns search engines, but instead is one of user experience. Neither short nor long pages are inherently bad; that itself is a bit of a myth. However, stubs do provide a bad experience because the readers and search engines that encounter them are left wanting more and an incomplete page (even if it is marked incomplete) has not been proven to "attract editors from the reader base to add to or expand the page" as was once assumed. Every day that a stub exists and remains incomplete is a day that bad experience persists.

Short pages are only bad when they do not have all the information for the page's given topic, and readers have to go elsewhere to find it. Short pages are not bad if they comprehensively cover all that we need to know to understand a page's concept. The classic example we use in the Best Practices Working Group is Aunt Barbara from "The Big Bang Theory". That page is complete, is not considered a stub, and while some might consider it short (or daresay too short), it's actually a perfect page for what it is describing. If a page meets the significance threshold of "Is this a page that needs to exist", and it's complete enough to not drive readers feeling they need to look elsewhere for the information they were seeking, and it links to and from other pages, then it's an acceptable length.

Conversely, long pages are only bad when the page contains too much information and the human reader's attention is overwhelmed. At the point where an author can encapsulate a long section of complete information, that's the point where they can split that section off and link to the split-off page. A community can choose to split sections off as subpages or not, though some think erroneously that subpages are bad. This is based on another misconception, having to do with Wikipedia disabling subpages in their main content space for technical reasons and many titles containing the "/" character. In fact, Google understands that subpages have a distinct parent relationship with the base page. If a single section would make a good book chapter with an unambiguous title, it can usually safely be split off. There's no problem with leaving behind a "CliffsNotes" summary of the essentials, and going into deep detail on another page.

Splitting an article

It's a good practice to have a base page that is complete, but not so detailed that it bores the reader by being too long. That's why we suggest the {{Main|/subpage}} + Summary split method. It allows more freedom to add detail on the subpage without losing track of the page topic. You can read more about this process, but because this is so important we want to show this method very clearly.

When a basic article becomes long enough, it could have long chunks that could reasonably be split into their own independent articles. For example, a character's narrative in a television season could be placed into "Character/Season 1" 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 {{Main|Character/Season 1}}). These subpages have a natural method to get back to the base article: they're linked from the top of the page!

If an author links, rather than embeds or adds more information about something that is extricable from the base page, they create a more understandable target for search engines (and humans). The result is shorter pages with less scrolling, but more intuitive understanding of the concepts the writers are trying to convey.

One straightforward method:

  1. Identify a section of information that can stand alone as an article, either because it is long and complete or describes an aside or subtopic.
  2. Decide on the appropriate page title, which applies to the section you are transplanting and only that section. If your community uses subpages, this may be a candidate for making a subpage. The title should be recognizable for whatever the user is searching for, so "Naruto Uzumaki/Part II" should be well understood by those seeking that part of his narrative. If it's describing a totally different topic (not a derivative of the original), it should not be a subpage (e.g. "The Matrix#Sequels" should be "The Matrix Reloaded").
  3. Create that page, cutting the content of the original section and pasting it into the new page. Include any subheadings (which should be adjusted up from H3s to H2s), images, galleries, asides, and infoboxes that are inside that section.
  4. For any infoboxes just transplanted, the information described should apply only to what is in that section and only if the page represents a different entity. In other words, (in the above example) Naruto Uzumaki shouldn't have a data-filled infobox just for what happened to him in the arcs of "Part II"; that infobox should still reside on his base page. However, if we're talking about a different character or type of thing being split off, that would have its own data-filled infobox. In either case, you can also use an infobox to navigate between pages to avoid using navigation link tabs or similar button and icon templates.
  5. Once you have published that page, back in the original article you can still insert a way to link to what you split off. A method that traditionally works is to leave the same section header, place a hatnote template (typically "Main", which is a simple indented one-line text note that indicates where the main article for a summary is located, classified as a "context-link") at the top of the section immediately below the header, and write a brief (approximately one to two paragraph) summary of the major highlights of the section you just transplanted. This preserves the completeness of the original article, with deeper insights available to the reader with a desire to know more.
Would you like to know more - Starship Troopers meme

Tabs

Tabs are a controversial element on wikis, with polarized opinion divided between love and hate. Many wiki leaders prefer them for aesthetics and use them as functional ways to make pages seem shorter on a screen or to contain discrete pieces of information. Despite a common conception that tabs are to be avoided at all times, they can indeed be an effective means to split content as well. The biggest problems with using tabs stem from the two very different ways in which they are typically used: to selectively hide content, and to direct content to other pages. There are far fewer examples where they are used well than there are those that introduce challenges or issues, so it is a good idea to explain the best ways to use them and when (and how) to move away from using them.

The guidelines for tabs, which are very well researched by usability experts over time, are something we use as an objective benchmark here. Those guidelines are the results of studying how readers interact with websites.

Navigation link tabs

Lots of folks are of the opinion that tab navigation between pages is good. The main driver of this opinion is ease of navigation. When tabs are presented clearly, they can indeed be an easily identified opportunity for navigation.

The #1 guideline is:

Use tabs to alternate between views within the same context, not to navigate to different areas. This is the single most important point, because staying in place while alternating views is the reason we have tabs in the first place.

With any experience given to a reader, it's important to them that they know what the result will be when they do a click or tap action. When using tabs to go somewhere else (e.g. to another page), the metaphor of the tab fails, because the expectation is that they're not leaving the first article; the reader thinks (because it works this way pretty much everywhere else, which is why this guideline exists) they're seeing another view of the same page. If they want to go to another page, they click something that is an obvious link to go to another page in the expectation that is where they will end up.

So, on the face, what's really desired is something that acts like a link, which is not something that usually happens when one clicks on a tab. When clicking on an inactive tab, they think they're un-burying a panel of a hidden view. Which brings up guideline #2:

Logically chunk the content behind the tabs so users can easily predict what they'll find when they select a given tab.

Since it's an unexpected effect that is at odds with users' intuitive expectation, we try to avoid that when we design user experiences. Logically chunked content is consistent, so a tab designated for apples should not also talk about oranges.

Guideline #4 is also very relevant.

Design tabs that are parallel in nature. If the tabs are significantly dissimilar, users will interpret them as site navigation.

In this case, the expectation is that tabs will take a reader to a different part of the site, not a related article. The extra navigation layer confuses folks about the difference between the navigation toolbar, tools for operating on the page, and the local intention to send to a highly related article. An example of parallel tabs would be individual episodes or games, not galleries and transcripts.

Which brings up guideline #12, which sums things up nicely.

Tabs should all look and work the same. Consistency is important in GUI control design because it builds the user’s feeling of mastery over the interface in several ways:

  • Recognizability. When something always looks the same, you know what to look for and you know what it is when you find it.
  • Predictability. When something always works the same way, you know what will happen when you act on it.
  • Empowerment. When you can rely on your past knowledge of all the available features, you can easily compose a set of actions to achieve your goal.
  • Efficiency. There's no need to spend time learning something new or worrying about the effect of inconsistent features.

If a wiki has two different things that look like tabs (page navigation tabs and Tabbers), a reader expects them to operate the same way, which is very much untrue when these are used on the same community. So, while there is not anything inherently bad about having one or the other, there are some additional concerns that lead us to prefer suggesting alternatives to both.

Navigation inside infoboxes

Humans intuitively process (what we technically call) semantic data and relationships. These describe how one topic or object or page relates to another.

M16 Infobox at Battlefield

Data rows pointing to other related pages

In some cases, there is a clearly defined informational relationship between pages. In other cases, this is purely navigation information.

Navigation line in an infobox with interpuncts

Navigation links on a line, with interpuncts

On the rich viewports of a desktop, it can be tempting to add as many navigation options as possible in creative ways. A lot of the time, these manifest as tabs or icons at the top of the page content. However, because of those links being content (made from templates) at the fundamental level, they are not as readily recognizable to readers that visit multiple wikis. The more creative these tabs get, the more they tend to be avoided due to "banner blindness". Integrating such links into more familiar elements, especially when that aids in human (and machine) recognition of semantic relationships, provides readers with more understandable and consistent anchors to find the related information they seek. It also has a side effect of bringing more content "above the fold" and visible, reducing the perceived page size.

Mobile appearance changes the look of elements to a more minimal (for smaller screens with more limited display capabilities and data plans) or more finger-friendly design. As navigation tabs are inherently links, they appear as simple unstyled links on Fandom's mobile skin. Sometimes, this results in a poor mobile experience that is less comprehensible to mobile readers.

This is why we believe that placing these as part of another, stable element like a <navigation> area of Portable Infoboxes is an overall better solution than creating custom navigation elements. Even if you're not using Portable Infoboxes, placing navigation links inside the infobox adds a consistent place for readers to look and intuit relationships between pages. Doing so leads to more integrated, informative, and shorter-seeming pages. We add some more context for doing this in "Navigation boxes and bars and beyond". The result can be a "navbox"-style navigation box blended into the infobox, which presents navigation options at the top (so that readers can find their sought-after correct page more quickly) rather than at the bottom (where they have to go through the whole article to find what they want).

Infobox navigation at Star Wars CS

Infobox navigation at Czech Star Wars

If you're using Portable Infoboxes, this is usually easy to do with data rows (if you're pointing to derivative pages and you need to provide links in the page level of the template, such as "| hardline = [[M16 (Hardline)]]"; see the weapon appearances illustration) and / or navigation rows (for related pages that don't need links supplied at the page level; see the episode illustration). As wikitext, these can also have logic applied with ParserFunctions (inside the format, default, and navigation tags) to make them adapt to the pages into which they're embedded. If you're using classic wikitext infoboxes, finding a way to integrate the wikitext functions to augment your templates would also be a good solution. A secondary effect which is forward-thinking is that Fandom will also be able to use the data and navigation relationships supplied in infoboxes to provide semantic data tools when they are further developed.

Tabbers

Tabbers are block panels with content divided into sections, each labeled by a tab on top. Traditional tabber methods operate using a JavaScript method which "hides" content until it is needed. The main information should be visible as-is without user interaction needed. Fandom's standard <tabber> extension displays the content of all tab panels on mobile, unlabeled and unseparated, because it can not be operated on mobile. It is difficult to find examples on the web where tabbed interfaces are used well on mobile devices, which led to Google producing Material Design guidelines regarding their use. When non-standard, home-grown JavaScript solutions are used, we can not predict the results consistently on any platform.

If a reader wants to have a browser tab open for the stats of one weapon, and have a related weapon in another browser tab to compare, they should be able to do that (many browsers allow putting these windows side by side). That's not as easy to do when the two items are on the same page and the reader is flipping back and forth across tabs.

In the words of our SEO director, "If content is important enough to be on the page, why would you hide it in the first place?". Heat map analysis shows a precipitous drop in engagement / clickthrough on every tab after the first, even when the content is intended to be at the same importance level. In other words, only the first tab on any given tabber is likely to be visited. On average, there is a 70% drop in interest on every next tab, so a second tab is only exposed 30% of the time, a third tab is seen 10% of the time, a fourth opened 3% of the time, and so on. Extrapolating from the experiences of timed progression of tabs in a carousel, this is not an uncommon problem throughout the web.

Further, the code involved in using the Tabber extension on a page is not intuitive to new editors, and the source wikitext can confound even experienced editors by creating and requiring vastly complicated blocks of text framed by limiting syntax. It also frequently confuses Visual Editor, which disrupts the sometimes fragile code in the page.

While this explanation does not go as far as saying "Don't use Tabber", it is important to know what the problems are in doing so and to recognize when alternatives like splitting pages, using galleries, and infobox-centric navigation are more effective ways to show off content and still keep pages from being overly long.

TabView

Let me be clear. Please don't use TabView anywhere it is not currently being used.

Tabber is a way of encapsulating content inside a panel on a given page. TabView creates a tabbed interface and transcludes (copies from elsewhere) content of a different, already standalone page, and inserts it into the invoking page.

There are many issues with TabView that bring us to this suggestion.

  • TabView presents usability problems for editors, because it is not clear where the content lives.
  • TabView interferes with other elements, because the transcluded content is unaware of what margin limits to set, so elements get positioned on top of each other in layers. Also, if the content transplanted from another page uses JavaScript, that script does not function properly. CSS selectors also do not consistently work with content transplanted from elsewhere.
  • The labels of TabView tabs are hypertext links which present the same issues as links in headers. Having links inside headers produces user experience problems on different interfaces (e.g. ambiguity on whether tapping on the header of an collapsed mobile section will expand that section or go to another page) and less consistent understanding for readers (e.g. "Do I need to go to this other page first?", "What is the relationship between this section and the page being linked?") and software like screen readers and search engines that do not understand the dynamics.
  • TabView creates a large discrepancy between mobile and desktop views that cause Google to consider downranking the community based on content quality, and doubles down on that by having large swathes of duplicate content (which is itself also bad for search engine crawling).
  • When the JavaScript is eventually processed on desktop, the resulting code causes a slowdown because of the method used to pull information from the other page. Additionally, this is done on the viewing device, which eats into the reader's data caps quickly.
  • Pages being transcluded don't appear consistently in Analytics as page views, making actual counting of those views difficult.
  • And on mobile, TabView produces a list of links that are not clear why they go where they go because there's no context.

Rather than using TabView, we would urge using the "Splitting" method above.

Tabs and search

So, with that out of the way, let's talk about how page tabs and tabbers and TabView and so on affect search engines.

As said in the "Stubs" section above: what we want to avoid — from both a user experience and search engine standpoint — is incomplete pages. This is for the same reason for both humans and search engines, which should not come as a surprise when one thinks about how search engines are designed to work to mimic the way humans respond.

Where you have a distinct "content entity" — which is a formal way of saying "a unique independent object", whether that's an individual person or object or location or any kind of specific noun — it should generally be on a single base page (not a subpage). Any subpages should be for things that are derived from it and can't exist without the base page. When you're talking about [[Jon Snow/Season 1]] or [[Cloud Strife/Final Fantasy VII Remake]], it's understood that you're talking about specific aspects or narratives of the base page.

From a search engine's perspective: if it's on the same browser page (even if it's embedded from another page), it's describing the topic of the base page. So, putting information for "FishTank#Sword" may make Google think I am a sharp hunk of metal rather than a person. Therefore, it is better that my sword — there are many like it, but this one is mine — be on a separate page with its own URL.

As alluded to above with the "why would you hide content" mention, when content is obscured on a secondary (or beyond) panel, it is marked as hidden via a combination of CSS and JavaScript and revealed with interaction. Images loaded lazily (as in, loaded upon entering the viewing window) are not seen effectively or quickly until the JavaScript is unfolded on their servers in a delayed queue. From Google's perspective, any text or images hidden in this manner are less important than what is visible immediately after loading the page. Further: the additional JavaScript required for interaction adds to the overall payload required and slows down page loading time. Therefore, content behind hidden panels is not generally a good search engine relevant (SEO) practice.

Matters of size

Pages of any size can be considered complete. Keeping readers interested and finding the answers they are seeking are key. Whether you are reducing the size of your page by tabs or other means, ensuring the pages stay complete is a path towards good wiki health. Using tabs and tabbers should be done in a carefully considered way, and there are alternatives that can better expose all your great content.


FishTank-100×100
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.

Click here to sign up for the From the Desk of Community email newsletter.

Want to get real-time access to fellow editors and staff?
Join our Official Discord server for registered editors!