Recommendations for mobile friendly articles on Wikimedia wikis/ru

В этом основанном на опыте руководстве даны рекомендации редактору проекта MediaWiki о том, как сделать проекты удобнее для мобильных пользователей. Оно составлено разработчиками мобильных приложений и мобильных сайтов с 10 летним опытом работы с контентом MediaWiki. Это практическое руководство базируется на ряде положений, содержащихся в Reading/Mobile Friendly Content.

Более 50% трафика в проектах WikiMedia приходится на мобильный веб-сайт, который во многих регионах является основным средством доступа к нашему контенту. Несмотря на это, многие наши статьи не так удобны для мобильных пользователей, как могли бы быть.

Рекомендуется использовать специальную служебную категорию w:Category:Templates that are not mobile friendly для систематизации шаблонов, которые вызывают проблемы на мобильных устройствах, чтобы координировать работу по их улучшению.



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  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-разметке для компонентов в шаблонах
Вывод cs:Šablona:Cedule похож на en:Template:Ambox, тем не менее HTML-разметка совершенно другая.

Мобильные приложения основаны на описании контента тем же языком. Важно использовать семантически схожий язык для того, чтобы мобильное приложение выглядело на разных языках одинаково.

Многие wiki-проекты копируют шаблоны из английской Википедии, поэтому стандартные имена англоцентричны, но мы открыты к изменениям, которые могли бы отразиться в наиболее используемых классах. Особенно важно улучшить язык имён шаблонов на основе ambox.


 * .infobox - компоненты, которые резюмируют факты (как, например, dob = 25th December 2018; name = Santa Claus Junior или en:Template:Infobox).
 * .hatnote - наверху страницы появляются элементы, означающие редиректы или страницы с похожими названиями, например, ru:Шаблон:Другое значение
 * .ambox - описывают недостатки страницы.
 * .ambox .mbox-image - подставляют иконку для недостатка.
 * .ambox .mbox-text-span - описывают дефект (но не способ его устранения).
 * .ambox .hide-when-compact - описывают способ устранения дефекта.

Плохой пример

Template:Infobox

Хороший пример



По возможности не размещайте инфобоксы или изображения в верхней части викитекста
Расположение инфобокса в самом начале статьи будет влиять на производительность и удобочитаемость на мобильных устройствах. В настоящее время мобильное программное обеспечение берёт на себя разрешение этой проблемы, но иногда это ему не удаётся, поэтому по возможности всегда следуйте этой договорённости, в противном же случае не забудьте проверить, что в мобильной версии всё в порядке, путём просмотра ваших правок на настоящем мобильном устройстве.

С точки зрения удобочитаемости, размещение инфобокса в самом начале приводит к тому, что читатели сталкиваются с подробностями прежде контекста или введения в предмет, что часто может сбивать с толку. Эта проблема была особенно острой для тем, малознакомых пользователям, где им пришлось бы прокрутить содержимое инфобокса, чтобы выяснить, ту ли статью они читают. Мы внедрили это изменение, чтобы добиться согласованности между мобильной и полноразмерной версиями веб-сайта (в полноразмерной версии первый абзац также размещается в начале) и, кроме того, чтобы предмет статьи предъявлялся пользователям до того, как им потребуется прокрутить инфобокс.

С точки зрения производительности, смещение инфобоксов вниз повышает производительность сайта за счёт значительного снижения среднего времени загрузки страницы, позволяя пользователям видеть содержимое страницы быстрее, чем раньше.

Дополнительная информация:

Плохой пример

Хороший пример



Метаданные (в том числе координаты) следует размещать внизу статьи
В полноразмерной версии сайта координаты появляются в верхнем правом углу, но в мобильной версии с её недостатком места в верхней части страницы такое расположение непрактично. Расположение шаблона с координатами в другом месте статьи, например, внизу, предоставит мобильной версии больше доступных возможностей вёрстки.

Среди других благоприятных последствий перемещения метаданных вниз — содействие алгоритмам, которые генерируют и мобильную версию, правильно определить первый параграф, что важно для резюмирования статьи.

Плохой пример

Хороший пример



Используйте повсеместно один и тот же порядок для шаблонов шапки, ambox и infobox
В мобильной версии контент может быть перелицован, но не может быть перемещён. Группировка элементов статьи по типам помогает мобильной версии и алгоритмам, на которых она основана.

В мобильной версии мы полагаем, что за всеми компонентами шапки следуют шаблоны, сообщающие о недостатках страницы, и всё это расположено в самой верхней части статьи, а инфобокс — ниже.

В ином случае мобильная версия не может оптимизировать вёрстку, и вёрстка не может быть оптимизирована под мобильную версию.

Плохой пример

Хороший пример



Не включайте во внутристрочное описание стиля (inline styles) свойства размера и расположения на странице
CSS-свойства width, float, height создают проблемы в мобильной версии.

Также проблемы создают большие значения свойств padding, border и margin.

В общем случае параметры CSS, в которых используются значения 100px и более следует тестировать на мобильной версии.

В идеальном случае все эти параметры должны быть определены в классах, и медиа-запросах, чтобы в полноразмерной и мобильной версиях они обрабатывались различным образом.

Плохой пример

Хороший пример



Избегайте таблиц для представления чего бы то ни было, кроме данных
Не используйте таблицы для вёрстки. Оптимизация таблиц для мобильной версии представляет собой весьма сложную задачу, а табличная вёрстка при такой оптимизации почти неизбежно развалится. Табличную вёрстку следует заменять при помощи HTML-элементов.

Обычно, по недостатку лучшего решения, мы вынуждены просто скрывать такие элементы в мобильной версии, что наиболее заметно в случае навигационных шаблонов.



Вложенные таблицы
If you do need to use tables, note they are designed in responsive design/flex in Mobile version.

Make sure your main page is mobile friendly
There's so much to talk about here, this gets its.

Templates should use a single root element with a sensible CSS class
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.

Плохой пример

Хороший пример

Collapse issues with a multiple issues template
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.

Плохой пример

Хороший пример

Do not assume positions of images, infoboxes, tables in text
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.



Плохой пример

Хороший пример

Limit number of images in a page
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.

Плохой пример

Хороший пример

Making page issues (ambox templates) mobile friendly
There are several rules to follow to make page issues mobile friendly.

Use the ambox class and mbox-text if not using a table
Make sure the  class is present on the top level element of the page issue.

Preferably, the element should be a div, in which case the text portion of the element should have the  class.

Use supported ambox classes to clarify severity
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.

Limit page issue to two lines of text
Text beyond 2 lines should be wrapped in an element with the  class.

Плохой пример

Хороший пример (table version)

Good example (div version)

Mark the text portion of an issue
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 put links inside section headings
In mobile, section headings links are used to collapse/expand sections. Use of links inside the section headings are thus discouraged. Where these links are essential, it is advised that editors disable section collapsing on the page by wrapping the entire content in a DIV element.

Bad example

Good example

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  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