Progressive Design

Everything changes. Some things remain classic and timeless, while others come into or out of fashion or evolve by necessity in function. When we're building communities, designing to benefit readers can also be a challenge. Our global audience here at FANDOM is shifting to mobile and "second screen" experiences. Whether on a smartphone or a tablet, readers want more than just what's on their televisions and games. Fans want to be in the experience, to get context and background, walkthroughs and guides, theories and perspectives — and for some, even spoilers. We can't ignore that most communities have a significant mobile reader base — sometimes as much as 60% of total page views.

What can you do to get the best experience for the long term health of your communities? Develop a good set of design guidelines that will draw in mobile readers, not drive them away. Anyone who looks objectively at the desktop experience knows that it's not well suited for small screens. In this article, let's examine some old habits that are still prevalent at FANDOM, but which don’t give the best experience to everyone in your audience.

Rethinking navigation

Classic holdovers from Wikipedia and other early wikis are navboxes. These groups of lists of short links, packed into a layout table,are not mobile friendly. Until recently, these were not shown on Wikipedia's mobile forms — for good aesthetic reason. Instead, there are several opportunities to make inter-article navigation more relevant, starting with proper categories and Mobile Main Pages; also, as the main element on mobile articles, the <navigation> tag in Portable Infoboxes can be employed.

At present, there's not a consistent way to use horizontal lists — in part because it's differently coded across communities — which makes for some very long navboxes. With styling stripped in Mercury, there's little reason to take up this screen space. For that reason, and because there are alternatives, navboxes are not shown on mobile devices.

Some rules of thumb:

If an article is part of a group of articles, and order doesn't matter, consider whether that navbox group should be a category instead. Categories are easily navigated using Mercury and Mobile Main Pages, and can be linked to in wikitext. They can also hold narrative or data content just like an article, which is seen in Mercury. Context and describing what that group is are more important to readers and search engines alike than a pool of links, as relevance and relationship are key to understanding.
If an article is part of a group, but has an ordered relationship with one or more of them (like a previous / next relationship), those are data fields that can and should be navigated in an infobox.
If an article has a one-to-one relationship with a parallel article (for example, it links to the gallery or some other subpage of the main article), links in the <navigation> tag of a Portable Infobox are ideal.

Tabs used at the top of pages to move through sub-articles and to parallel articles are still common on a lot of communities, but make for a very tricky design pattern. In some cases, the tabs used for navigation will cause a blank page to appear on mobile devices. For most articles, the easier way to link to articles with a specific relationship is in the infobox, as mentioned above.

Rethinking Tabbers

Tabbers can be an effective way of displaying and organizing some information, when used properly. An issue is that many communities use these inappropriately. Keep in mind that many communities have developed customized and specialized varieties of tabber that do not respond identically to FANDOM's <tabber> extension, but the design advice here applies to those variants, as well.

Stick to only one row of tabs. Multiple rows create jumping UI elements, which destroy spatial memory and thus make it impossible for users to remember which tabs they've already visited. Also, multiple rows are a sure symptom of excessive complexity: If you need more tabs than will fit in a single row, you must simplify your design. — Jakob Nielsen, Ph.D., one of the most recognized UI/UX design experts in the world

It is important to show the user what are the options. These should be things that are logically on the "same level". So if you are thinking in terms of a music player, it probably makes sense to have genres as tab items. If you are building a news app, then categories or topics should be what you are looking for. Don't mix and match from different categories. It confuses the user and doesn't provide a clean list to choose from. — Mobiscroll, a UI design company for web components

Present tabs as a single row above their associated content. Tab labels should succinctly describe the content within. — Google's Material Design Guidelines

Tabbers should be simple to be effective, and never be nested inside each other. If your community uses tabbers for images, particularly inside infoboxes, you should consider spreading those images appropriately throughout the article or inside a captioned <gallery>. On desktop, you will have a styleable classic gallery with pictures labeled; on mobile, you will have a sideways scrolling, bandwidth-efficient row of images that can be isolated and zoomed with a tap (where the captions will display). Using the advice above, for the users' sake make sure that a tabber is comparing the same type of item on that level.

Tabbers in content result in the contents of each tab being inserted (without label or heading) into the article. Whatever you are organizing inside the tabber set should also make sense if all of the tabbers are removed. If the content needs to be organized, putting the portions under section / chapter headings may ultimately make more sense. There's nothing wrong with long articles! 😀 The best question may be to ask whether hiding content with tabbers is necessary.

TabView is an extension that embeds the contents of a supplemental article inside an interactive tab. On desktop, this allows for switching between dense feature sections; on mobile, it appears as a list of links to the available sections. While not a bad practice (because all content is accessible), it should be noted that search engines will take a user to the linked page, not the initial article page, and that there should be a clear way to navigate to the main article. For this reason, it is suggested that all articles that embed content via TabView have the linked articles as a subpage of the main article (eg. [[Character/Season 1]]), which will always provide explicit navigation in the page header.

Rethinking data

Many communities don't think their articles contain data or infoboxes, and focus instead on narrative content. FANDOM takes the position that if an element contains a title, possibly one or more images, and describes an article's topic with properties with values, that element is a de facto infobox (regardless of the layout). The infobox at that point is the most straightforward and obvious anchor point for an article (which is why Portable Infoboxes are the primary / dominant element on mobile pages). Then, each part of an infobox (including titles and images, but excluding <navigation>) is considered a data item.

Ensuring that data is segregated is the essence of good maintenance. One of the easiest ways to do this is to use different infobox templates for different kinds of things. This could be as simple as separating, say, land vehicles from aircraft. As your wiki grows in complexity, you may find you need to delineate even further. Maybe you’ll need to separate SUVs from pickup trucks, or helicopters from airliners.

Realistically, individual data values should only contain a single type and format of value. In other words, don't mix numbers and words or different date formats if it can be avoided. If an object costs "100 gold pieces", the value written into an article's infobox should be "100"; the template itself can reformat the value to add the necessary context.

Lists of values are also very common inside infoboxes. From a data-centric perspective, a wikitext list is better than a comma (or semicolon) separated list. While there is not a universal method of creating horizontal lists, FANDOM does have methods that we recommend. A list is also more effective than having multiple parameters when the items are equivalent.

In other words:

| item1 = Apple | item2 = Banana

should be avoided in favor of

| item = 
* Apple
* Banana

While there's not an immediately visible benefit, the long term benefit of separating data items in this way allow scripts and crawler engines to more easily interpret what you're trying to describe, and screen reader devices (such as those used by readers with visual impairments) interpret these properly. Lists avoid translation and other linguistic ambiguity (as great debates have been waged over the Oxford comma). And, of course, alternating list items can be given special visual treatment by CSS-savvy designers.

Part of the appeal of Portable Infoboxes is their code simplicity, which also has server-side performance benefits. As they are constructed all at one time, they produce less load on the server than wikitext infoboxes that are constructed of several sub-templates. Each template is designed to do one thing, and one thing well. Given their priority processing state and rank on the server, it's also difficult to nest an infobox inside another. However, if you consider that each infobox should only describe a single thing, related (but separate) sub-topics are better placed in individual sections.

Finally, placing multiple infoboxes in an article to describe various levels or platforms of the primary topic is not recommended, as the mobile result is difficult to determine for the reader. Some communities organize infoboxes inside tabbers or dropdowns. There is no native support for that at this time, but many communities have reorganized such stats to place them in logical groups inside a single infobox. For example, a collapsible <group> with the "PC" version of statistics could complement the "PlayStation" group of the same traits, rather than placing them in an entirely separate infobox.

Rethinking images

People sometimes assume that more pictures are better. So they cram every single picture they can find into a single gallery. But this just hurls an avalanche of imagery in your reader's direction, without giving them much in the way of organization, relevance, or a way to navigate to pertinent content.

Properly labeling images increases SEO. You want this, because you need more people to come to your wiki. But even good labeling won't solve the basic problem of sensory overload. If there are 100 images in a given gallery, then labels can only help so much. An ideal solution? Trim down the gallery as much as possible, or get rid of the gallery entirely. Put some of the images inline, within the body of the article, close to relevant parts of the text. This will reduce the finger-numbing, seemingly-infinite finger-scroll that galleries can create on mobile. And it will use pictures how they're supposed to be used: as illustrations that complement text, rather than contrast with it.

Infoboxes aren't galleries. They’re not even theoretically supposed to be galleries. Instead, they give your readers general data in an easy-to-consume, attractive, compact package. Said another way: an infobox is just an introduction to the topic of the page.

That's why an infobox should only show images of the primary article topic, and they should be equal in value — such as Manga and Anime versions, not a full selection of outfits and accessories.

Additional image notes

Pictures alone don't make for great SEO. Sure, they help, but these pages must have enough text content on them to provide value to users. Pages upon pages of images alone could bring penalties for thin, low-quality content.
Make an image gallery a quality page. Keep your images focused on a single topic — preferably one that relates to an article (e.g. create a companion "Naruto and Ramen/Images" gallery that links to a "Naruto and Ramen" article page).
Use plain language to name your images. Remember: File names should be as descriptive as possible since search engines cannot tell images apart; spiderman_slinging_webs.jpg is better for SEO than img012.jpg.
Take the time to fill out the summary section of your file pages. These descriptions help search engines better understand your images. Think of them as the "advertising copy" for an image link, so improving them can bring more clicks and visitors to a page.

Rethinking layout and design

Sometimes, a page very visibly fails to look as it should on the mobile skin. This can be largely fixed by amending that code to be more responsive. Remember that while the desktop experience can be customized with CSS and JavaScript, mobile users only get to see static, un-styled content.

Tables are popular at FANDOM. Used properly, they collect and compare data in a efficient way. However, they’re of more limited use on mobile devices, as phones have small screens.

Remember:

Think of tables like spreadsheets.
Always check your tables on a real phone, held in portrait orientation.
Limit yourself to four columns, or roughly 600px. (Beyond that, the reader will have to scroll right or left with their finger, which may cause them to lose their bearings on large tables.)
Don't use colspan or rowspan.
Don't nest tables inside each other.
The table's caption is its "title". It's totally safe to use.
Use scope="col" or scope="row" when your heading applies to a column or row.
Tables are one of the few places inline CSS should be used instead of custom classes. However, if you want a consistent visual that's easier for your editors to use, you're better off restyling the existing official table classes: "article-table", "WikiaTable", and "wikitable" in Wikia.css.
These CSS classes are allowed, too: "mw-collapsed", "mw-collapsible", "noprint", "nowraplinks", "plainlinks", and "sortable".
Don't include images in a table if you don't have to. Text is often clearer to your readers than images, particularly on small screens. If you’re making a table on a games wiki, and that table needs to be populated with icons that are used in-game, make sure the icons are small, and all of the same size. Cut them all to between 22 and 25 px widths. That way, the images won't expand on your phone.
Try not to make new rows using templates. If the server has to take multiple attempts to add content, it won't know how to properly size the table for a given screen.
If you succeed in following all these guidelines, the mobile display of a table should be "zebra-striped", with alternating colors on each row for visual clarity.

On some wikis at FANDOM, there's a history of using tables for the purposes of layout and design. Don't do this. Tables are for data. And we've known that since at least 2004.

Any element with a fixed screen layout over 600px will encounter problems on mobile screens, regardless of whether or not the element is "portable" in nature. Even a Portable Infobox that has been expanded to full screen width with CSS may not work as intended on a mobile device, as it can strictly enforce illegible columns a few pixels wide. It's very difficult, time-consuming — and in many cases flatly impossible — to make full-width infoboxes work in Mercury. You should carefully consider whether it's really that important for your wiki to have boxes of this width. In fact, FANDOM's recommendation is not to alter the width of infoboxes from their defaults, as image scaling issues are introduced that way; Portable Infobox defaults (270px and 300px) represent the most commonly used and average infobox widths from samples across the network.

There are other portable elements available on FANDOM besides <infobox>, all designed to be interpreted on a variety of screens. Often, the most versatile element is the <gallery> tag. Image galleries can be used for navigation portals, and for showcasing images in a dynamic portable manner; the tag is also bandwidth-efficient, and easier on the data plans of mobile devices. The <references> tag can be purposed for footnotes, and is a great replacement for lengthy tooltips. These tags will always be safer to use than their wikitext or JavaScript equivalents.

Many legacy templates use inline styling to declare what the colors of an element should be, declaring those colors in the article. We at FANDOM think there is a more forward-thinking way to approach that, which does not leave the article open to visual vandalism, mistyped hexadecimal codes, and other pitfalls. Using consistent themes (a form of CSS class) to convey the style of an element is more appropriate in many cases. While this does limit styles to those that can be secured at the admin level, the security and consistency (and the ability to make community-wide changes simply and easily) are worth the trade.

Color is a powerful tool in moderation. It must be used sensibly, not whimsically or randomly. Don't highlight in a bright pink because you can, do it only when that color naturally complements other colors on your site. Trying to impart meaning through colors — "color coding" for lack of a better phrase — is useless to the color blind segment of your audience. Instead, high contrast ratios — that is, the visibility of the text color against the background color — and a simple color palette are vital to ensuring that people of all visual acuities are included in your wiki. Likewise, page opacity should be set as high as possible for good accessibility, usually above 90%. It's extremely difficult to read text of any color if the page is transparent, revealing a busy background underneath.

Finally, pay special attention to the colors used by your wiki's topic. If you're on the "Supergirl Wiki", for instance, you should probably find some way to use basic reds, yellows, and blues in your design. If you're on "The Walking Dead Wiki", it's a good bet you're going to need some dark green and other earth tones. Take your color cues from your topic's logos, main title sequences and other signature elements. A key to getting these colors right is choosing a simple, consistent color palette, which will help ensure that the site is easy to read and attractive.

Rethinking interactivity

JavaScript is not available in our mobile devices for a variety of reasons. What we call content (actual narrative, other text, pictures, videos, etc.) is usually placed in articles.

When it comes to interactivity, utilities may no doubt be useful, but they are often better served in the capacity of an app, rather than through a browser.

On some communities, JavaScript mixes interactive elements (like graphs) with content in articles. Where this occurs, there should be a method defined to allow this to fall back gracefully. Ideally, such information would appear on all platforms, but this is not always possible when the element is excessively created in JavaScript. Using a CSS class to avoid or explicitly show an element on the mobile platform should be discouraged in favor of compartmentalizing that anchor code inside a Navigation-classified template (which will hide it on Mercury, but will not have adverse effects on desktop).

Where JavaScript creates the entirety of what's on the page, it can be argued this does not represent content at all, but a function of the site. Community-wide JavaScript code should live in the MediaWiki namespace. The output of the code — if it is fully interactive and contains no static content, such as a stats calculator — should be in a non-content namespace, such as Special: or Project: and out of the main article namespace.

Finally, be sure to check the page in Mercury, both in the edit preview and on your own mobile devices. If crucial information doesn't appear because of JavaScript (or worst, the article is blank on mobile devices), you may have eliminated half of your potential audience for that article. Don't be afraid to ask for help at the Portability Hub if you don't know what is causing the issue; the volunteers will be able to guide you to the best solution.

Flowing design is good design

Maintaining a lasting design takes a modicum of forethought. Your community should be able to operate without significant changes for years to come. Making smart design choices that will work on all platforms will help you attract and keep readers on any device, however they discover your site. Putting even a few of these guidelines into practice is time well spent for your community's long term health.