FAQ about Mercury

I hear this word sometimes; what is Mercury?

Mercury is FANDOM's mobile-centric user experience, or "skin". It has been designed to ensure that content is displayed in a consistent format across mobile devices.

What's the difference between Mercury and the mobile skin?

These days, there is no difference. There used to be a different mobile skin named "wikiamobile", but it is no longer in use.

What's the difference between the mobile skin and portability?

FANDOM and Vanguard have often used the terms "mobile" and "portability" in the same breath, but they are not the same. Portability refers to the way our content displays across all devices; mobile describes the way most mobile devices display our content.

There are cases when we get lazy and use the terms interchangeably. For instance, the display of a portable infobox on a phone is both a mobile and a portability concern. Understand, however, that portability is the wider topic. Content is said to be truly portable when it displays without error on massive widescreens, laptops, tablets and small phones simultaneously.

Why don't the Community Apps look like Mercury?

Community Apps use a custom rendering system independent of the Mercury skin. This is a short-term arrangement. In the near future, the Community Apps will begin using Mercury. Some features from the Community Apps will be folded into Mercury during the switch. As of November 2016, the Community Apps do not respect all of the features that Mercury does.

Why design for portability now if all we can see is the mobile skin?

Portability is as much a philosophy as it is a technical implementation. Going forward, the framework of portability will ensure that FANDOM content can work across any device in the future.

Why can't I use JavaScript?

JavaScript may not consistently operate on mobile devices and may hinder the performance of the skin. On mobile devices, memory and processor usage is often at a premium relative to the time of the user, and a balance must be struck between the functionality FANDOM offers vs. the cost of doing so. This is also true of bandwidth, where additionally downloaded data eats into expensive data plans or is outright unavailable in some nations. Additionally, the most common aspects of using JavaScript to re-write already rendered content means that devices like Braille terminals and screen readers (as well as Siri and Google), cannot access that dynamic content properly. To be considered portable, the content can only be displayed on screen once and not reformatted once it is downloaded. The exception is "lazy-loaded" content: like static images that only download when they appear on-screen.

Why can't I use my own CSS in Mercury?

FANDOM and Vanguard probably get this question more than any other regarding portability, and it's important for us to convey not only why Mercury was developed, but also the challenges that the skin presents and the hurdles that we as developers need to address.

Browsers are not created equally; mobile browsers even less so. As a simple trip to caniuse.com will prove, code that works on Android browsers won’t necessarily work on Safari for iOS.

Mercury must necessarily attempt the highest level of compatibility, and this means stripping down to the basics. To be most effective, we must separate content from presentation, and we need to limit lightly-supported CSS from being introduced, whether by inline declarations or separate stylesheets. While this does limit customization, it ensures your content will reach the widest possible range of readers.

Why is Mercury so ugly / bright / basic?

As explained above, Mercury was developed to ensure that the article layout worked well with mobile devices. The skin was designed to achieve visual legibility, vertically stacked elements and a color scheme consistent with itself.

That said, FANDOM recognizes that there is a strong desire for local theming on local communities. FANDOM is currently researching ways to allow Mercury skin customization while retaining cross-browser compatibility.

Why is Mercury so crucial to future FANDOM content?

The growth of mobile users has meant that a new, unified approach had to be designed to ensure that your favorite content displays correctly, no matter what mobile browser you choose.

Does the Mobile Main Page feature use Mercury?

It uses the same base code as Mercury, with a few unique bits of formatting.

Communities without a Mobile Main Page set up will see the desktop main page interpreted by “normal” Mercury code. This is undesirable, as most main pages simply don’t render well in Mercury.

Setting up a Mobile Main Page lets you take advantage of the specialized Mercury code designed especially for main pages. Most significantly, it allows you to have one design for desktop users and another one for those viewing on a mobile device.

Can I edit using Mercury?

You can through the mobile editor, which will show the source code of the page, like on Source Editor of desktop version. Mobile editing is actually more common than most people think, and is the norm in some nations like Japan where a full desktop setup is less common.

Can I see ALL my community's content in Mercury?

No. Essentially, Mercury is for the main content of your wiki: articles in the main namespace. Other namespaces are rendered in the desktop skin (except blogs).

Why not use a tag that shows on only mobile and / or never on mobile?

It's better to have content that works as well on desktop as it does on mobile. It's typically very easy to create a design for your wiki that will *not* require them. Especially if you're hiding something that won't work on mobile (like interactive "AJAX" JavaScript), consider why that is not available on all platforms. Rarely, you will see FANDOM Staff using <nomobile> tags on a design. They do so sparingly on a case by case basis when the need arises.

When we speak of portability, which pages, articles, and features are included?

The technical distinction is: A page is any wiki page (including templates, help pages, blog posts, talk pages, etc.), but an article is typically a page in the main namespace (those without a prefix). Portability is measured for articles only -- and any templates used by those articles.

What does portability affect? Can that be seen by the increasing mobile views on a wiki?

Mobile views are one way that portability success is measured, and they grow significantly in proportion every year. Mobile views represent over 50% (and climbing) of the total views for most FANDOM traffic. However, portability also affects how information is used across other non-browsing media, such as when third parties use the MediaWiki API, alternative browsers, voice response systems, and other websites and apps that use FANDOM data (including search engines). Not all of these are by official partnership with FANDOM, which itself is permitted to use the content under the terms of the CC-BY-SA 3.0 licensing model.