Part of the fun of wiki editing is the flexibility and interactivity that come from templates and scripting, by building internal and external layers (respectively) onto page content. The more involved into wiki community building editors go, many will get involved with creating layers deeper or atop the wiki page through those templates and scripts.
|Want the tl;dr version? Jump here!|
While the most important parts of a community are the people involved and the content inside, these additional layers have best practices recommendations, too. Like icing on and filling in a cake, a solid foundation of content deserves details to make things interesting.
There are several scripts, particularly additions from Fandom's fan developer community, that add or change the way the skin works. There is no harm in adding these for your personal use when there are tools that make your reading or editing experience more enjoyable or easier. Some scripts are strictly marked for site-wide use, as opposed to personal use. Those marked for site-wide use will reach anonymous users and will have SEO implications — therefore, less is more.
mw-collapsible method of collapsing elements is well established, and built into MediaWiki itself; therefore, it is built into the mobile skin and works properly in most circumstances. The same caveats we have mentioned in earlier posts about hidden content apply, and content that is collapsed signals to search engines and readers (rightly or wrongly) that what's not shown on first load is less important. Tabbers magnify the effect by hiding multiple layers from immediate view.
Templates are the internal layers that make for reusable elements. Templates can be created with wikitext, sometimes in combination with internal pieces of software called ParserFunctions or extensions. An example of templates made with extensions are Fandom's Portable Infoboxes, which create a fast and fairly standard way to make a common element. ParserFunctions are utility software pieces that work as a small army of tiny tools changing or interpreting text before passing them along to the reader's browser.
A template that calls another template is called a "nested" template. To explain how this works and why it's important, the software that runs our wikis processes multiple passes where it expands templates into whatever their result is. If that result has more templates, more passes are required. This delays processing time and can be confusing for editors if they need to find a problem and need to dig through multiple layers. We recommend limiting to 3 or fewer layers of template nesting where possible.
It's always a good idea to label and comment your templates, when you make them, so that those who edit after you know what they are looking at. It is also a good idea to have user-friendly parameter names (those are the parts of templates that address specific labels, like
| name = Jon Snow). New editors will not always understand that ATK means "attack" (as is fairly standard in English-languages games); or worse, ATK without explanation means something other than "attack", which can be even more confusing.
Templates can also be created with a different kind of scripting language, called Lua. These can be very powerful and very fast, replacing many layers of nested templates and ParserFunctions. They are designed to be expanded and interpreted in a single pass, so that good Lua functional sets (called Modules) will import other modules, rather than expanding into wikitext and expanding again. This reduces the nesting functions issues, and usually makes the code easier to understand. It also provides much faster speeds than using ParserFunctions alone. However, please keep in mind that Lua is not for beginners and committing to a Lua path may mean fewer people being able to understand your code or fix it if it breaks and you are not available. Also, for simple templates, Lua can be overkill where the same effect can be accomplished by classic wikitext.
As a side note: many wikis add a
V·T·E link to their templates to direct them to the template documentation. Doing so has no proven user experience benefit, as those links historically have very few humans clicking through them. They also provide a visually inconsistent break in the template display that makes them more problematic to experience. Finally, the link provided forces search engines to attempt to crawl multiple times the template documentation code that we intentionally hide from crawling, resulting in the search engine experiencing a "404" or dead page, reducing the perceived quality and authority of the community in question. We strongly suggest removing these links in templates intended for use on article pages.
Wiki editors have long had to work with small amounts of input text and make as much output of it as possible. This sometimes results in having templates process the bulk or entirety of some pages. There are multiple failsafes within the server code to discourage using templates to produce a lot more output in relation to the input, and one of note is the "post-expand include size". For security reasons, this avoids having a massive output ratio from little template parameter input. A big failsafe is when pages become too complex or too hard for the server to process, they simply become inaccessible or in-editable. At that point, Staff intervention is often required and portions of the page should be split off to reduce complexity.
Smaller interventions can also have subtle but important effects. For example, relying on an infobox template calling a specific image based on the article's page name can seem very simple, but becomes more complicated if the article has a non-standard name or is copied to another page for testing.
Much of the habit of automation is geared towards making pages more simple for editors. It often has the effect of making editing simpler only for the small subset of editors that fully understand a process that is not always intuitive. New editors should, ideally, be able to understand what goes into a system with minimal education about the inner workings. The more complex any system in science or engineering becomes, the more working parts can potentially fail if the input is not entirely standard. As an added benefit, finding and entering information rather than having an automated system computing it for readers encourages more edits because the work is not already done!
Finally, it's a good practice to try to place as much content outside templates into the basic canvas of the article, because doing so simplifies the editing process. It may help to think of the basic article content as "organic food" and being a good idea to have it processed as little as possible and with as few steps as necessary before it is ready to eat. No more than an average of 30% of your basic text should be processed by templates. Automation should represent only the tip of the proverbial iceberg, because it makes editing itself more accessible to everyone.
Keeping it simple
- The tl;dr version
Best Practices moving forward
We've had a great start in 2019 with this Best Practices series, and have reached many communities with both timely and evergreen advice. Based on feedback, we're going to change the format moving forward; this will be the last post of the year, and we intend to come back refreshed in 2020. We hope that these have been helpful to you as suggestions and guidelines for communities both new and well-established. The conversation is always open in our Discord server's #best-practices channel, and we invite you to participate with questions and concerns.
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.
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!
- Hydra illustrations by Encredechine for Fandom, CC BY-SA 3.0