Template classification is a fairly misunderstood topic within FANDOM. Many community members who have dabbled in it believe it to be a form of categorization; they don't understand why they can't have a classification called "template documentation", "episode links", "starship types" – or any one of countless others that their imagination can come up with. But here's the thing: classification isn't really about categorization. It has nothing to do with how MediaWiki defines "category". Rather, it's about telling the FANDOM-specific parts of MediaWiki how to render a particular template, usually on mobile; thus, classification is practically moot on the desktop skin of FANDOM. Imagine you have a template called "Happy Template"; whether you classify it as Design or Infobox, Data or Navigation, it'll look the same on the desktop. The only thing that might change is that, if Infobox is selected, then it might cause the default editor to become the Infobox Builder when using the desktop skin.
The biggest difference is what happens in Mercury (code-name for the mobile skin); ultimately, this means that template classification is intimately connected to portability. It tells the software whether to employ certain editing tools – like the Infobox Builder GUI – and it helps give an accurate census on which to base FANDOM's development priorities. As we take a closer look at portability beyond portable infoboxes, template classification will be even more important than it is currently. By and large, the FANDOM help page is a good place to start with template classification, but there are some things that contributors should know about the way that some of the classifications interact with Mercury.
This is perhaps the most confusing classification because it's the most antithetical to the term classification. Templates of any description can be classed as non-article. The qualification is merely that the template not be used in namespace 0 (aka "ns:0", "main namespace" or "article space"), or be used exclusively on the front page. Examples of what can go into this classification are documentation templates, main page modules, sub-templates, and image licensing templates.
"Non-article" does not mean, "This template won't appear on article pages". It means only that the template is not meant to be used directly on article pages. Templates classified as "non-article" will show up in Mercury; don't think that by putting a "non-article" classification on a template you'll hide it from Mercury. All you'll actually succeed in doing is creating an unformatted segment on any page using that template in Mercury.
Template documentation (namely, those in /doc sub-pages) should always be "Non-article", regardless of what they're documenting. In fact, in reviewing templates, your first task should be to go to Category:Template documentation (or the local equivalent) and bulk classify everything there as "non-article". You'll probably find that a number of unclassified or misclassified templates are immediately fixed.
Simply setting an infobox template to the "Infobox" classification doesn't make it a portable infobox by default; you need portable infobox code for that. But giving an infobox the classification of "Infobox" will help the server's census to identify infoboxes correctly and is therefore essential to the work of portability.
A template should only be classed as an infobox when its contents only and entirely create an infobox. Templates that help constitute an infobox – that is, parts of an infobox – are better classed as "non-article" templates. Conversely, if the infobox is merely a part of a template that creates a page – or a substantial part of a page – then it's actually better to use "Design".
Navboxes (or any element, in fact) that contain the
navbox class do not appear on Mercury, unless the immediate parent element has the class
article-table. For reference, they also do not appear on Wikipedia's mobile versions. This deliberate omission is the solution the Wikimedia Foundation have come up with for their collective mobile experience, and FANDOM has followed suit.
Unlike on Wikipedia's mobile versions, elements that use the
vertical-navbox class, known commonly as sidebars, will appear on Mercury.
Templates classified as Navigation that contain <div>, <table>, or <p> elements do not appear on Mercury. Consider using alternate elements if possible. If the navigation template is the same width as the infobox, and situated right underneath it, then you might give some consideration to classifying it as "Infobox" – particularly if migrating that template to portable code would be fairly trivial.
In many cases, the Navigation-classified templates are redundant; a reader using Mercury may not need it because of other links on the page. But, there are cases where fundamental navigation goes missing from a page when the "navigation" classification is applied. A good, if obscure, example is the Avatar Fanon Awards page. The large graphical element at the top will disappear in Mercury, because its classification is "Navigation"; it really should be classified this way, because otherwise, drop-down menus, buttons and widescreen graphics wouldn't work well in Mercury.
Notices do not appear on Mercury. Because of this, you need to consider whether it's appropriate for a notice message to disappear. The logic is that most notices (also referred to as tophats, hatnotes, or message boxes) are actually delivering editing notes (like "delete this page", "update these sections", or "clean up the links") – notes that most non-editing mobile users will disregard. However, understand that the implications of classifying a spoiler template under "Notice" will be that spoiler warnings will be gone – and that might not make casual readers happy. Notices meant for all readers should be classified as "Design"; if it links to an internal article (for example, a "spoiler warning" notice linked to the spoilers policy), Context-link may also be appropriate.
Context-links appears on Mercury as a block element – centered, with line breaks before and after. While other classification types are fairly flexible – "Citation / Reference" can be used well beyond the Help page's stated use cases, for example – there are a few instances where "context-link" makes visual sense on Mercury. It will dramatically increase the vertical height of a page, forcing a longer finger scroll for the reader. It's probably a better idea sticking to the stated use-cases of "See also" or "main article" links at the tops of article sections. If this classification is used, the results of the page render should be checked using a phone to ensure correct rendering.
Like "Non-article", "Design" is also a bit of a catch-all classification; anything that modifies how a page is formatted – from a template that merely italicises text to one that creates an entire page from a few Semantic MediaWiki variables – can be classified as "Design". However, there is an exception: a template that creates a whole page and includes an infobox is often itself misclassified as an infobox.
As a note, this category is most likely to have the greatest number of "holistic" portability violations — modifications like inline styles that make a page less portable.
An infoicon is a tiny graphic, usually no larger than 25x25px. Such an image will only render properly in Mercury when classified under "Infoicon". Otherwise, it is likely to render at full size as a block element on Mercury. An infoicon template will produce ONLY an image in Mercury, and not any text (even if the template produces text on desktop).
Quote is intended for lines, quotes, monologues, and dialogues; it strips most formatting and encloses the text as an italicized and indented block element in Mercury.
- The other four types
The remaining four types are uncontroversial and generally more specific than the above seven. There's not a whole lot that could be added to their descriptions that appear at the FANDOM help page. None of them – Scrollbox, Citation/Reference, Image/Video/Gallery, or Data – disappear in Mercury.