Templates are more than just Infoboxes. As we've seen, there are plenty types of Templates. However, some Templates are simply more portable than others. That's important when you are designing for future-proof communities (that aren't just using Desktop and Mobile). As part of being future-proof, our entire communities should be able to be seen on any platform; that's the essence of Portability. Most editors think of how things look on a desktop browser, but they need to think about how things will also present in other devices (especially those with smaller screens). The real benefits will come when smart devices and special interfaces, like virtual reality become more commonplace over the next couple of years.
This series of articles is about making your whole wikia more Portable. For some, this is a bit of a paradigm shift. We're presenting to you the best practices for making your content the most accessible it can be for years to come.
Checklist: Do's and Don'ts[]
Most of these Do's and Don'ts apply to how your wiki will render on the mobile skin. Tablets are more forgiving, but can have many of the same problems as phones. Mobile devices (under Wikia's "Mercury" skin) can present in many forms, including Community Apps.
Don'ts[]
- Inline CSS styling won't work everywhere.
- "class =" isn’t always included in HTML tags on mobile skin.
- The "colspan =" and "rowspan =" cell attributes in tables is not considered "portable".
The first two of these Dont's are about separating presentation from content (as we'll explore more below). Using them as a way to organize content may not give you the results you're looking for in the future, and they display differently in browsers. The reasoning for the third is that tables notoriously have issues (primarily with inflexibility on resizing) when viewed on smaller screens and browsers render them differently.
Do's[]
- Use Curated Main Pages for mobile main page design. This replaces Special:Promote and Special:CuratedContent. The idea is that your wikia should be able to be organized and navigable natively, regardless of how it’s being viewed. Every article, if it’s categorized, should be able to be browsed to using CMP.
- "class= hidden" for hiding on mobile skin. If you absolutely must hide something in mobile, this is one way to do it. It might be better, however, to reconsider why this is to be hidden, and to make the content more portable so that you don’t have to do the same work twice.
- Properly classify your Templates. That way, what's inside can be interpreted correctly. At present, templates classified as "Navbox" and many "Navigation" templates are eliminated (hidden from view) for Portability purposes. Navigating is going to be a different experience using different devices, and as said before, should be organized in Curated Main Pages.
- Remember that you may not be the only one maintaining these in the future, so leaving behind good documentation for your successor might be very helpful.
Separate content from presentation[]
This is what makes templates "future proof". Content refers to the information, text or media in a page while presentation or the appearance of page is determined by style (e.g. style = "color:green"). What your wikia is saying is much more important than how it looks, and not everyone sees it the same way you intend. One example is in accessibility for people with disabilities: color blind users, or outright blind users will not be able to see the highly stylized experiences on many desktops. Another example is intelligent assistants: Siri, Google Now, Alexa, and similar voice or minimal interfaces will not be able to interpret what you're trying to say and relay it to a user if those pieces of software do not understand it.
So, like a book can be adapted into a stage play, television, or a film, your content (the underlying story) should remain as true as possible and embrace the benefits of using those different forms.
Meta-Templates, or Template "Inception"[]
One popular way of designing involves having templates call other templates (which often call other templates, etc). With wikitext, the effect on the server tends to be minimal in most cases; each time the server "thinks about" the page creates slightly less mystery in what is generated on screen. While this is a historically helpful way of doing things, it is ultimately less portable. It's also very difficult to achieve with Portable Infoboxes. Portable Infoboxes should not try to call other templates for large elements (small, inline templates like Infoicons are okay), and can not call a master template for elements.
This meta-template idea extends beyond Infoboxes. Tracking down one template that calls another, layers and layers deep, is hard for humans to do, too. At most, one template should call another one or two layers deep, for efficiency’s sake; this eliminates a significant number of issues when bugs arise.
Templates just for styling, or "how many licks to the center"[]
Wikitext has a lot of useful features already built in. Making text bold or with italics for emphasis is straightforward and usually well understood. Using "style = font-weight: bolder;" inside a template is not nearly as effective. The underlying systems that power your wikia are much better at understanding wikitext and making it show up the best way on any device than the same HTML or CSS. So, whenever possible, it’s better to use the native features of wikitext. Using a template as "syntax sugar" to make wikitext is also bulky and unnecessary. For example, using {{plural|Article|Label}} instead of [[Article|Label]]s or [[Article|Plural label]] may save a few keystrokes, but is worth the trade-off in how the link is presented.
However, changing the decoration of some content is sometimes not possible without using CSS. Using templates to create inline styling is a similar "fast track" to making your content less portable. Instead, consider that the same effect should be consistent throughout your wikia, and place it with a "class" attribute in your sitewide CSS. It’s fine to use inline CSS for a quick test, but you should try to migrate it to sitewide CSS as soon as you can. Remember you can test CSS with your personal page (Special:MyPage/wikia.css) to see how moving it to the sitewide CSS would look.
For example, with a Wikipedia link ({{wp|Article|Label}} vs [[wikipedia:Article|Label]]): even if that link has special styling, like your community adding an icon next to it (as some communities do), adding it using CSS is significantly more portable (and interesting!) while saving you trouble maintenance-wise in the future.
Unbalanced templates, or "LEGO blocks"[]
Some wikis transclude sections of tables or parts of the document. These are very hard to classify because the template won't show up properly unless all the pieces are there. Whenever possible try to avoid these and create complete templates. This type of segment template is a prime Portability offender, since atypical and non-standard markup tends to be eliminated when the page is read. In fact, generating a table with a Template is generally not considered Portable. Templates are still better self-contained, rather than being split into multiple components. Case in point, some wikias use (before converting to Portable Infoboxes) individual components named "Infobox component", which are wrongly identified as being full Infoboxes.
JavaScript, or "Superman still managed to destroy Metropolis"[]
JavaScript is simply not portable. Many devices or even the desktop browsers may disable it or not support certain features that make customization work. For instance, tooltips cannot be seen on mobile because they require a "pointer" to hover over them. There are CSS solutions that are much friendlier than JavaScript, but as "hovering" is a foreign concept in non-mouse based interfaces, these are technically acceptable but not always practical.
If you must use JavaScript for something, try to make sure the effect of it being disabled is not catastrophic to what the user will see or how what you're using it on will function.
Closing remarks[]
Try to always separate the content from the markup that defines how it will appear because this facilitates future changes. Try to keep styling consistent and centralized for easier management and more portable friendly changes. When making templates, keep in mind that they need to be flexible to changes in article flow and screen size. Ask for help! The Wikia community is an amazing resource for solutions, tips, and tricks.
Be sure to tune in for Part 2: All-Terrain Tables and Part 3: Native Navigation (aka Curated Pages)!