Reading/Web/Projects/Mobile Page Issues/zh

显示有关页面内容的消息的模板不会显示在移动维基媒体网站上. 这使读者不知道他们正在阅读的页面的可靠性. 从用户隐藏此信息可能会有问题. 在隐藏重要问题（例如考虑删除的恶作剧文章或文章）的情况下尤其如此.

读者网站团队希望改善移动网站上页面问题的处理方式. 目标是包括对问题本身的性质以及问题严重性的描述. 这些更改将帮助用户更好地判断他们正在阅读的页面的可靠性. 展示这些问题也可能使读者对维基媒体项目的工作方式感到好奇. 这可能会增加他们作为贡献者参与的可能性.

以下是这种改进看起来如何的一些例子. 欢迎反馈

介绍
当文章出现问题时，它们通常会在文章上方放置一个大的彩色框，通知读者和编辑手头的问题. 这些通知实际上是插入到文章内容中的特殊模板. 文章中的每个通知都有自己的模板，每个模板都使用名为 的元模板 （文章消息框）. Ambox使用名为Module:Message box的Lua模块. 其他MediaWiki名称空间（如分类和讨论页）也具有特定于其名称空间的通知. 这些通知已经存在了十多年，并且围绕它们的使用有许多惯例. 贡献者保留这些通知. 每个语言社区都可以自由地采用或发明自己的通知，特定于他们项目的需求. 例如，维基共享资源有许多许可通知，而维基词典使用完全不同的通知.

这些通知的范围和多样性使其难以标准化. 一个发生在2007年的英语维基百科上.

这种更新发生在现代移动网络甚至存在之前. 尽管维基媒体基金会后来努力将这些通知带入移动网络，但它们仍然不是非常适合移动设备. 作为起点，此提案将重点关注改进基于 的文章命名空间中的注意事项模板.

目前的移动版的“治疗方法”
在当前的移动维基媒体网站上，我们不会呈现整个 模板. 相反，我们会在文章标题下方显示一个带有“页面问题”文本的小灰色链接. 单击时，将显示包含问题列表的叠加层. 某些通知具有模板的“紧凑”版本的文本. 可用时，仅显示紧凑版本的文本.

限制
当前实现依赖于修改 模板生成的HTML. 对模板HTML的轻微更改可能会破坏移动设备上的此功能. 当前的实现不适用于所有wiki. 模板因语言而异. 例如，法语维基百科在2016年更新了他们的消息框. 他们现在使用与英语维基百科不同的模板. 这是他们的维护模块列表. 由于此更改，移动维基百科上不会显示法语警报.

有2016年英语维基百科的提案. 该提案认为，小的“页面问题”链接并未传达某些通知的重要性.

英语维基百科互助客栈的请求
2016年9月，社群批准在移动网站上公开页面问题的请求. 有明确的共识，一些警告模板应该在移动设备上可见.

""如果一篇文章是针对页面存废讨论并被标记为医疗资源不足的可能恶作剧，任何在计算机上访问该文章的读者都会被页面顶部的三个大红色和橙色框打开，其中一个带有警示停止标志. 如果一个读者在他们的手机上访问相同的恶作剧医疗文章……他们只是在文章标题下得到两个微小的灰色词页面问题……""

目的
该项目的目标是提高移动网络文章中对特定问题的认识. 我们将通过更改页面问题的视觉样式来实现此目的.

该团队将与社区合作，为样式模板提供指导. 这项工作将导致移动网站上问题的最佳格式化，而无需更改桌面上的格式.

该目标映射到读者年度计划的计划2，目标1. 使读者能够在阅读体验中评估文章的质量和可靠性.

关于严重性和简短描述的说明
我们只会显示包含“type”参数的模板的问题严重性. 关于类型参数的更多信息可以在每个项目和wiki的ambox模板页面上看到（这里是中文维基百科的页面）

同样，只有在模板本身提供简短描述时，才能使用简短描述.

工作流

 * 1) 用户访问包含页面问题的页面.
 * 2) 用户与“页面问题”元素交互.
 * 3) 将向用户发送有关页面问题的详细信息.

General
Mobile page issues will display the following:
 * 问题说明
 * 将在可能的情况下使用该问题的简短描述.
 * If no short description is available, we will display the beginning of the long-form issue description.
 * Issues length for both short and long descriptions will be restricted based on the space constraints.
 * Issue severity
 * Severity will be set according to ambox type as follows:
 * Severe: type=speedy, type=delete
 * Medium: type=content
 * Low: type = style
 * Notice: type = notice, type = move, type = protection
 * All other templates will display with normal severity.
 * Each severity level will have a custom appearance and position within the page.
 * If an issue contains links to other pages, the links will be removed. The links will appear on the page issue detail modal.

Single issue

 * For pages that have a single issue, severity will be derived from the template as defined above.
 * An example. If template has severity level "Medium", the article will have a single page issue appear at the Medium level. (example).

Multiple issues

 * Issue severity levels will be derived from the severity levels of the individual issues.
 * If an article contains the template, the issue level of the article will be the highest issue level available.
 * For example, if template has level "High", the article will have issues appear at High level. (example).
 * Each multiple issue level will receive unique copy, appearance, and position within the page.

Section issues
The initial implementation of this project will not display issues within individual sections. We will come back to this once we have completed the initial changes.

Initial updates to the page issue modal
To start, the Readers team made the following changes to the page issue modal. This change happened in late March 2018. The goal of this change is to expose more detail about the page issue itself. It also provides information to readers on how to fix these issues.

Feature evaluation
The Readers team wants to understand the effect increasing the awareness and prominence of page issues on the mobile website has, particularly on the perceived quality and reliability of pages by readers. Our goal is to help readers better gauge the reliability and quality of the article they are reading. Our hypothesis is that making them more aware of page issues will contribute to this goal.

We'd like to answer the following questions:

Does the new treatment for page issue notices increase the awareness among readers of page issues? '''How do users feel about being informed of page issues? How does awareness of page issues affect their perception of Wikipedia?''' Additional research questions:
 * Qualitative research:
 * Do readers notice the new page issue treatment more than the current treatment?
 * Do readers notice version B (with titles) of the new treatment more than version A (without titles)?
 * Do readers notice page issue notifications located after the lead paragraph more than if they are located at the top of the page?
 * Quantitative research:
 * Is there an increase in click-through based on the new issue treatments (from the article page to the issues modal)?
 * Is there any correlation between severity of the issue and click-through rate?
 * Qualitative research:
 * RQ1 - Do page issues make sense to readers?
 * RQ2 - Do readers care about page issues? Do they find them useful? Important?
 * RQ3 - Are readers familiar with page issues already? Have they seen them on other articles?
 * RQ4 - Do readers understand how page issues work? In other words, how they appear on a page?
 * RQ5 - Does becoming aware of page issues change readers’ perception of Wikipedia?
 * How do readers form opinions about the quality and reliability of Wikipedia pages in general?
 * Do readers care more about issues considered by Wikipedia to be of higher severity than issues considered to be of lower severity?
 * What feedback loops (if any) get activated as a result of increased awareness of page issues? For example, do mobile edits increase with page issues as referrer? Does the new issue treatment changes affect issue removal rates?

Technical challenges
The technical challenges of improving Ambox templates have a few areas of concern. To summarize, templates are inconsistent.

The output of is inconsistent in many ways. There is no consistent machine-readable way of extracting the template content.
 * across languages
 * across different types of templates
 * location inside the article

Areas of concern

 * Text length
 * The length of many Ambox messages are very long and not suitable for mobile devices.
 * Desktop specific HTML
 * Templates using make heavy use of tables for layout, which doesn't work on mobile.
 * Language specific HTML
 * The HTML output is different across languages, making it nearly impossible to consistently extract the message content and repurpose it for mobile.

Proposed technical solutions
Use the TemplateStyles extension to create mobile friendly template CSS

To be discussed for future iteration.

Use Page Content Service to display page issues

https://phabricator.wikimedia.org/T172002

Modify MobileFrontend/Minerva CSS to accomodate existing template markup

This solution would work within the existing template structure and probably only on English Wikipedia.

<Many templates contain a CSS class that marks text as. Using CSS, we could hide this extra text and only present users with the "summary" text. This is the same text that is currently presented in the page issues overlay. Many templates, notably deletion templates, do not have this CSS class. The issue of text length would have to be addressed on a per template basis.

Here is a demo of what modifying the CSS might look like.

Add structured HTML attributes to Ambox templates

This solution requires modifying templates.

As mentioned before, the HTML produced by the templates varies. It can change at any time and in any language. We shouldn't hinder these changes, but make sure that contributors can adapt them to new contexts, such as mobile.

Adding semantic attributes to the HTML could provide us with the necessary "hooks" to extract the Ambox content. We could then present it in an appropriate way on mobile. We could provide a standard set of attributes that template editors can insert into their templates. This would work regardless of the template used or language. These attributes could be "machine readable" which means they can be parsed or extracted. For example like the Page Content Service for consumption by the mobile apps. These semantic attributes would be invisible to readers. They would not effect the appearance of existing templates.

Semantic HTML attributes fall into the category of "microformats". The idea is to extend HTML with the ability to express very specific types of data, in a way that is machine readable. We could extend the Ambox HTML with attributes to identify the templates as "message boxes" with various properties. These properties could include things like priority, date, and actionable steps. This information could then be parsed. Consumers could include the mobile site and apps. Also presented to end-users in a mobile friendly fashion.

We could create our own standard, but there already exists a W3C recommended specification called RDFa. RDFa standardizes on how to use attributes to add rich meta-data to HTML.

RDFa defines rich data structures as "vocabularies" or sets of properties that define an data structure. We can define a custom vocabulary that describes the properties of a "message box", and use those properties in the HTML attributes.

As an example, RDFa uses HTML attributes such as,  ,  , and. The following example shows how to add them to templates.

Inventory of mobile-friendly page issues
The changes proposed above will improve most page issue templates. Two kinds of templates will receive specialized treatment. One are templates with defined short descriptions (those that contain text marked as "hide when compact"). The other kind are templates with defined ambox type. These templates will display the shorter more mobile-friendly form of the text. They will include visual indicators for the severity of the issue.

Hide when compact
To determine coverage for these changes we performed an inventory of templates. We looked at templates that contain text marked "hide when compact". The following were our results. Further documented in T189132.

Method

An extensive inventory of "page issue" templates was taken across a variety of languages using the MediaWiki API and this script. The script parses templates that belong to a specific category. For example, on English Wikipedia it parses all the templates that are members of the category Category:Article message templates. The templates are then rendered in an HTML table with CSS added to see which can be made compact or not. A sum of the compact templates is also generated.

Disclaimer

This method works for languages that actually have a category for all "page issues". Not all languages do, some only have more specific categories. Only the top-ten Wikipedias were used in this report.