Reading/Web/Projects/Mobile Page Issues/ja

ページの内容に関するメッセージを表示するテンプレートは、モバイル版ウィキペディアでは表示されません. そのため閲読者には読んでいるページの信頼性がわかりません. 利用者にこの情報を伝えない、特に大言壮語が認められる記事あるいは削除対象など重要な問題を隠すことになると、支障があります.

閲覧者部門ウェブ担当 では、ページが抱える問題の表示の改善をモバイル版ウェブサイトにおいて取り組もうとしています. 問題の深刻さに加えて、種類そのものの説明を含めることが目標です. これにより閲読者は読んでいる記事の信頼性をよりよく判断できるようになるはずです. また問題を表示することで、ウィキメディアのプロジェクトの仕組みに興味を持ってもらうこともでき、自分も貢献しようと思うきっかけを増やすことにつながるかもしれません.

この改善がもたらす効果の予想を以下に示しました（訳注：アイコンの違いに注目）. ご意見ご感想をお待ちしています.

はじめに
When articles have issues, they often feature a large coloured box above the article notifying readers and editors of the issues at hand. These notices are actually special templates inserted into the content of the article. Each notice in the article has its own template, and each template uses a meta-template called (Article message box). Ambox uses a Lua module called Module:Message box. Other MediaWiki namespaces like categories and talk pages have notices that are specific to their namespace as well. These notices have existed for over a decade and have many conventions around their usage. Contributors maintain these notices. Every language community is free to adopt or invent their own notices, specific to the needs of their project. For example, Commons has a wide array of licensing notices while Wiktionary uses entirely different notices.

The broad range and diversity of these notices makes them hard to standardize. One happened in 2007 on the English Wikipedia.

This refresh occurred before the modern mobile web even existed. Despite later efforts by the WMF to bring these notices into the mobile web, they are still not very mobile friendly. As a starting point, this proposal will focus on improving notices in the article namespace that based on the template.

モバイル版の現在の処理
On the current mobile Wikimedia sites we don't render the entire template. Instead we display a small grey link with the text "page issues" below the title of an article. When clicked, an overlay with a list of the issues appears. Some notices have text for a "compact" version of the template. When available, only the text for the compact version is displayed.

制限
The current implementation depends on modifying the HTML generated by the templates. Slight changes to the template HTML can break this feature on mobile. The current implementation doesn't work on all wikis. Templates are different across languages. For example, French Wikipedia refreshed their message boxes in 2016. They now use different templates than English Wikipedia. Here is a list of their maintenance modules. Because of this change, French alerts are not visible on mobile Wikipedia.

a 英語版ウィキペディアでは2016年に提案が寄せられ、「ぺーの問題」のリンクが問題の深刻度と釣り合っていないと指摘されたのです.

英語版ウィキペディアの「井戸端」の提案
2016年9月にコミュニティはモバイル版ウェブサイトでページの問題を顕示する提案を承認しました. モバイル版で特定の警告テンプレートを設けるべきだという点は明らかに同意されています.

""If an article is up for AfD and flagged as a possible hoax with insufficient medical sourcing, any reader visiting that article on a computer is greeted by three large red and orange boxes at the top of the page, one with a cautionary stop sign... If a reader instead visits the same hoax medical article on their phone... they just get two tiny grey words "Page issues" under the article title...""

目的
このプラジェクトの目標は、モバイル版ウェブブラウザで特定の問題に対する認知度を向上することにあります. その実現のため、視覚的表現を変更します.

The team will work with communities to provide guidelines for for styling templates. This work will result in the optimal formatting of issues on mobile site without changing the formatting on desktop.

This goal maps to Program 2, Objective 1 of the annual plan for Readers. "Enable readers to gauge the quality and reliability of an article during their reading experience".

深刻度のメモと短い説明
「type」パラメタのテンプレートでは表示は問題の深刻度に限定します. このパラメタの詳細はプロジェクトごとのambox テンプレートのページと、ウィキを参照してください（日本語版のリンクはこちら）.

同様に、短い説明がテンプレートそのものに用意されている場合のみ、それを表示します.

ワークフロー

 * 1) ユーザーが問題のあるページを開く.
 * 2) ユーザーが「ページの問題」の要素に触れる.
 * 3) ユーザーをページの問題の詳細へ誘導.

General
Mobile page issues will display the following:
 * 問題の説明
 * Short descriptions for the issue will be used where available.
 * 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.
 * 問題の深刻度
 * 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.

問題が単一

 * ページの問題が単一の場合は、深刻度を上記に定義したテンプレートから呼び出して表示.
 * サンプル. テンプレート の問題の深刻度が「中程度」の場合、問題が単一で深刻度は中程度と表示（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.

節の問題
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.

ページの問題点の様式ー最初の更新
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.

機能の評価
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? ページの問題点の通知を見たユーザーの反応は？ ページの問題点に気づくとウィキペディアに対する印象は変化するか？ その他のアンケート項目:
 * 量的調査：
 * 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?
 * 量的調査:
 * 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?
 * 量的調査:
 * 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?

技術的な難易点
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

心配な点

 * 文の長さ
 * The length of many Ambox messages are very long and not suitable for mobile devices.
 * デスクトップ用のHTML
 * Templates using make heavy use of tables for layout, which doesn't work on mobile.
 * 言語に特化したHTML
 * The HTML output is different across languages, making it nearly impossible to consistently extract the message content and repurpose it for mobile.

技術面の解決案
モバイル版に適したテンプレートCSS開発にTemplateStyles拡張機能を使う

''将来の繰り返し処理を見据えて議論する. ''

ページの問題の表示にページコンテンツサービスを利用

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.

CSS改良のデモ画像はこちら.

記事用テンプレートに構造化されたHTML の特質を追加 

''この解決方法にはテンプレートの修正が必要. ''

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.

モバイル版に適したページの問題点の目録
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.

縮小したとき非表示にする
これら変更の訴求範囲を調べるため、テンプレートの目録を作りました. テンプレートで 「縮小したとき非表示にする」という文言を含むものに着目しています. 集計結果は次の通りです. 詳細はファブリケーターのチケットT189132を参照してください.

方法

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.

免責事項

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.