Recommendations for mobile friendly articles on Wikimedia wikis/zh

This document provides guidance, from experience, on how best to serve mobile users as an editor of a MediaWiki wiki. It is compiled by mobile apps and mobile web developers with up to 6 years of experience working with MediaWiki content. It is a practical guide building on some of the points inside Reading/Mobile_Friendly_Content.

On Wikimedia wikis, over 50% of traffic visits the mobile website and in many regions is the primary medium for accessing our content. Despite this, many of our articles are not as mobile friendly as they could be.

We recommend the usage of a template maintenance category e.g., w:Category:Templates that are not mobile friendly to help flag problematic templates on mobile and share the burden of fixing them.

Wrap wide images and tables
If an image or table is larger than 600px consider how it will display on mobile or smaller monitors. If the image should scale down, consider the use of TemplateStyles to define that behaviour. If the image should become horizontally scrollable you will need to use a `noresize` class on the image to disable Minerva optimisations as well as provide a containing element with overflow scrolling set. See w:Template:Wide image as an example.

 Bad example 

 Good example 

在跨維基的模板元件的HTML標記中使用標準化類別名稱
The output of cs:Šablona:Cedule is similar to en:Template:Ambox however the HTML markup is completely different.

The mobile website relies on describing content with the same language. To make the mobile experience consistent across different languages it's important to use a similar semantic language.

Given many projects copy and paste templates from English Wikipedia most "standard" names are English-centric, but we're very much open to change this to reflect the most widely used classes. In particular, the ambox names need a better defined language.


 * .infobox - a component that summarises facts (e.g. dob = 25th December 2018; name = Santa Claus Junior) e.g. en:Template:Infobox
 * .hatnote - appears at top of the page describing possible redirects or similarly named articles e.g. en:Template:Hatnote
 * .ambox - describes a problem with the page. e.g. en:Template:Ambox
 * .ambox .mbox-image - associates an icon with the problem e.g. en:Template:Ambox
 * .ambox .mbox-text-span - describes the issue (but not the fix)
 * .ambox .hide-when-compact - describes the fix for the issue.

 不好的例子 

Template:Infobox

 好的例子 

如果可能，不要將資訊框或圖像放在wiki文本的頂端
Putting an infobox first in an article, will impact the performance and readability of the article on mobile. Currently, the mobile software takes care of this problem, but in some cases it fails, so if possible, always use this arrangement or if not, please check the ordering has been corrected on mobile by testing your edits on a real mobile device.

In terms of readability, the placement of an infobox first, exposes readers to details on a subject prior to gathering context or and introduction to the subject, which can often be confusing. This issue was particularly heightened for topics unfamiliar to users, where they would be required to scroll through the content of the infobox to confirm whether they are reading the correct article. We implemented the change to create consistency between the mobile and desktop websites (on desktop, the first paragraph also has primary placement), as well as to expose users to the subject of the article prior to requiring them to scroll through the infobox.

From a performance perspective, shifting infoboxes to a secondary position, improves the performance of the site by significantly decreasing the average page load time, allowing users to see the content on the page faster than before.

更多資訊：

 不好的例子 

 好的例子 

元數據（包括坐標）應位於條目的底部
On desktop, coordinate templates (Coord template) tend to appear in the top right corner of the article, on mobile where space is not available and the top of the article is limited, this is not practical. Positioning them elsewhere in the article body e.g. bottom would allow more options for mobile while still allowing the position on mobile.

There are other benefits for positioning meta data at the bottom - it helps algorithms that power and the mobile web site to identify the first paragraph which is important for summarizing articles.

 不好的例子 

 好的例子 

對頂註（hatnote）、維護（ambox）、資訊框模板使用一致的順序
In mobile, content can be styled differently but it cannot be moved. It helps the mobile site and algorithms that it depends on if elements are grouped together by type.

In mobile we expect any components that are described as hatnotes (e.g. Template:Hatnote) to be followed by ambox (e.g. Template:Ambox page issues) and to appear at the very top of the page. Infoboxes and other content should appear below these.

If this order is not respected, the mobile site cannot optimise content and content cannot be optimised for mobile.

 不好的例子 

 好的例子 

行內樣式不應使用影響大小和位置的屬性
CSS properties including width, float, height are problematic on mobile.

Padding, border and margin can also be problematic if larger values are used.

As a general rule, if your CSS uses a property with a value in pixels that is 100px or above, you should be testing your design on mobile.

Ideally anything that touches these properties should be using classes and and media queries to provide 2 different treatments for mobile and desktop.

 不好的例子 

 好的例子 

除了數據之外，避免使用任何表格
If you are using tables to create a presentational element, please don't. Optimising tables for mobile is extremely challenging and these presentational elements are usually broken by the optimisations we make for mobile. Instead, you should look to convert your table based layouts to div based layouts.

Usually, in lieu of a better solution, we have to regretfully hide these elements on mobile. Navboxes being the most notable example.

Nested tables
If you do need to use tables, note they are designed in responsive design/flex in Mobile version.

確保你的首面適合移動設備
There's so much to talk about here, this gets its.

模板應該僅有單個根元素且有合理的CSS類別
Wikipedia content is largely unstructured. One means of providing presentation hints for optimal parsing and display is to ensure that templates have only one outermost HTML element and that that element has a unique CSS class name shared across wiki languages. This can dramatically help software such as the mobile website, the Content Service, and the native Android and iOS apps to identify content properly.

 不好的例子 

 好的例子 

使用多個問題模板折疊問題
When an article has more than one issue use a single issues template to collapse them. Issues can take up value space on mobile and when collapsed more options to mobile friendly skins can take place.

In particular this is a problem when articles are nominated for deletion.

 不好的例子 

 好的例子 

不要假定圖像、信息框、表格在文字中的位置
Be careful when making assumptions about the presentation of an article. While two images may be floated and positioned in a certain way on desktop, it won't necessary display the same on a mobile device. Thus avoid sentences such as "the table on the right shows" or "the image on the left shows".

It's important to think of the article as being fluid and subject to change.

If referring to the image is essential, consider vertical stacking which is a safer alternative.



 不好的例子 

 好的例子 

限制頁面中的圖像數量
Due to the fact that the mobile site lazy loads images, articles with large amounts of images will timeout on mobile.

You can determine the number of images in a page by using a JavaScript developer console and running: Ideally, a page should have no more than 100 images (regardless of how small). Note if you have more than 10,000 images in your page, the page will be inaccessible on mobile.

In the case of tables you might want to consider using emojis or unicode characters.

 不好的例子 

 好的例子 

讓頁面問題（ambox模板）適合移動版
There are several rules to follow to make page issues mobile friendly.

使用ambox類別
Make sure the  class is present on the top level element of the page issue.

使用支持的ambox類別指明來嚴重性
For compatibility with the Minerva skin, which will screen scrape these templates to understand the meta data implied by these classes, ensure images have the class  (or are wrapped in an element with the   class). You can add additional classes (per below) to ensure the issue is scraped with the correct severity level.

 不好的例子 

 好的例子 

If present (and editors adopt this), Minerva can use this to choose the appropriate icon.

限制頁面問題為兩行文字
Text beyond 2 lines should be wrapped in an element with the  class.

 不好的例子 

 好的例子 

標記問題的文字部分
Given page issues can contain multiple elements, images, and meta data, it's really important to help our clients identify which part of the template explains the issue.

For this task, most projects use one of the  or   classes (message box text). This helps us reduce clutter on mobile resolutions and pull out the key parts of the message.

 不好的例子 

 好的例子 

Do not wrap infoboxes
A commonly observed pattern/mistake is to wrap an infobox either by incorrectly using wikitext or intentionally via HTML tags. The problem with this is it makes it difficult for mobile optimisations to apply as the infobox cannot be properly identified. If you must wrap them use the `infobox-container` class.

 Bad example 

 Good example 

Do not style infoboxes in MediaWiki::Mobile.css
While infoboxes appear on most pages, they do not appear on all pages, so it is better to ship any styles for styling infoboxes using Extension:TemplateStyles.

Using MediaWiki:Mobile.css is highly discouraged as this can result in a cumulative layout shift. This is because Mobile.css unlike desktop loads via JavaScript and is not render blocking.

 Bad example 

Template:InfoboxExample:

MediaWiki:Mobile.css:

 Good example 

Template:InfoboxExample: OR

Template:InfoboxExample:

Template:InfoboxExample/styles.css