Reading/Web/Projects/Mobile Page Issues/th

แม่แบบที่แสดงข้อความเกี่ยวกับเนื้อหาของหน้าเว็บจะไม่แสดงในไซต์วิกิมีเดียแบบเคลื่อนที่ ทำให้ผู้อ่านไม่ทราบถึงความน่าเชื่อถือของหน้าเว็บที่ตนอ่าน การซ่อนข้อมูลนี้จากผู้ใช้อาจเป็นปัญหาได้ โดยเฉพาะอย่างยิ่งในกรณีที่ประเด็นสำคัญ เช่น บทความหลอกลวง หรือบทความที่ถูกพิจารณาเพื่อลบจะถูกซ่อนไว้

ทีมงานเว็บผู้อ่านต้องการปรับปรุงการรักษาแม่แบบปัญหาของเพจเหล่านี้ (เริ่มต้นด้วยแม่แบบ ambox และตัวแปรข้ามวิกิของตน) เป้าหมายคือการใส่คำอธิบายลักษณะของปัญหาหรือแจ้งให้ทราบด้วยตัวเอง เช่นเดียวกับความเข้มงวดของมัน การเปลี่ยนแปลงเหล่านี้จะช่วยให้ผู้ใช้ตัดสินใจได้ดีขึ้นในความน่าเชื่อถือของหน้าเว็บที่พวกเขากำลังอ่าน การแสดงปัญหาและคำบอกเล่าเหล่านี้อาจทำให้ผู้อ่านอยากรู้เกี่ยวกับโครงการวิกิมีเดีย นี่อาจเพิ่มโอกาสในการมีส่วนร่วมของพวกเขาในฐานะผู้มีส่วนช่วย

ด้านล่างนี้คือตัวอย่างของการปรับปรุงที่อาจดูได้ ยินดีต้อนรับคำติชม

17 ธันวาคม ค.ศ. 2018

 * เราได้ใช้คุณลักษณะนี้กับวิกิพีเดียทั้งหมด ยกเว้นวิกิพีเดียภาษาอังกฤษ

16 ธันวาคม ค.ศ. 2018

 * เราได้เสร็จสิ้นขั้นตอนสุดท้ายของการวิเคราะห์ผลการทดสอบ A/B ของเราแล้ว: https://phabricator.wikimedia.org/T200794

1 ตุลาคม ค.ศ. 2018
เราจะเปิดตัวการทดสอบ A/B ของคุณลักษณะในวิกิดังต่อไปนี้:
 * การทดสอบจะใช้เวลาสองสัปดาห์
 * เราจะติดตามประสิทธิภาพของคุณลักษณะเชิงปริมาณ แต่ก็หวังว่าจะได้รับคำติชมจากผู้อ่านและผู้แก้ไขเช่นกัน
 * เราจะติดตามประสิทธิภาพของคุณลักษณะเชิงปริมาณ แต่ก็หวังว่าจะได้รับคำติชมจากผู้อ่านและผู้แก้ไขเช่นกัน

24 กันยายน ค.ศ. 2018
เราได้เปิดตัวการทดสอบ A/B ของคุณลักษณะในวิกิพีเดียภาษาลัตเวีย

บทนำ
เมื่อบทความมีปัญหา ก็มักจะมีกล่องสีขนาดใหญ่เหนือบทความที่แจ้งผู้อ่านและผู้แก้ไขของปัญหาที่ส่งให้ ประกาศเหล่านี้เป็นแม่แบบพิเศษที่แทรกลงในเนื้อหาของบทความ แต่ละประกาศในบทความมีแม่แบบของตัวเอง และแต่ละเทมเพลตใช้แม่แบบเมทาที่เรียกว่า (Article message box) แอมบอกซ์ใช้ลัวมอดูลที่เรียกว่ามอดูล:กล่องข้อความ เนมสเปซอื่น ๆ ของมีเดียวิกิเช่นหมวดหมู่และหน้าพูดคุยมีประกาศที่เจาะจงถึงเนมสเปซด้วยเช่นกัน ประกาศเหล่านี้มีมานานกว่าทศวรรษและมีระเบียบแบบแผนเกี่ยวกับการใช้เหล่านั้น ผู้มีส่วนร่วมให้บำรุงรักษาตามประกาศเหล่านี้ ชุมชนทุกภาษามีอิสระที่จะนำมาใช้หรือสร้างประกาศของตนเอง โดยเจาะจงกับความต้องการของโครงการเหล่านั้น ตัวอย่างเช่น คอมมอนส์มีประกาศเกี่ยวกับสัญญาอนุญาตจำนวนมากในขณะที่วิกิพจนานุกรมใช้ประกาศที่แตกต่างกันอย่างสิ้นเชิง

ช่วงกว้างและความหลากหลายของประกาศเหล่านี้ทำให้ยากที่จะสร้างมาตรฐาน หนึ่งในเกิดขึ้นในปี ค.ศ. 2007 ในวิกิพีเดียภาษาอังกฤษ

การรีเฟรชนี้เกิดขึ้นก่อนที่เว็บบนอุปกรณ์เคลื่อนที่สมัยใหม่จะมี แม้จะมีความพยายามในภายหลังโดยมูลนิธิวิกิมีเดียเพื่อนำประกาศเหล่านี้ไปสู่เว็บบนอุปกรณ์เคลื่อนที่ แต่ก็ยังไม่เป็นมิตรกับมือถือมากนัก ในฐานะจุดเริ่มต้น ข้อเสนอนี้จะมุ่งเน้นไปที่การปรับปรุงประกาศในเนมสเปซบทความซึ่งอิงตามแม่แบบ

การทำให้คืนสภาพด้วยมือถือในปัจจุบัน
ในไซต์วิกิมีเดียปัจจุบันเราไม่ได้แสดงผลแม่แบบ ทั้งหมด แต่เราจะแสดงลิงก์สีเทาเล็ก ๆ ที่มีข้อความว่า "ปัญหาหน้า" (page issues) ใต้ชื่อบทความ เมื่อคลิกแล้ว การวางซ้อนกับรายการปัญหาจะปรากฏขึ้น บางประกาศมีข้อความเวอร์ชัน "กะทัดรัด" ของแม่แบบ เมื่อพร้อมใช้งาน เฉพาะข้อความสำหรับเวอร์ชันกะทัดรัดจะปรากฏขึ้น

ข้อจำกัด
การดำเนินการในปัจจุบันขึ้นอยู่กับการปรับเปลี่ยนเอชทีเอ็มแอลที่สร้างโดยแม่แบบ การเปลี่ยนแปลงเล็กน้อยในแม่แบบเอชทีเอ็มแอลสามารถทำลายคุณลักษณะนี้บนอุปกรณ์เคลื่อนที่ได้ การใช้งานปัจจุบันไม่สามารถใช้ได้กับวิกิทั้งหมด แม่แบบมีความแตกต่างกันในแต่ละภาษา ตัวอย่างเช่น วิกิพีเดียภาษาฝรั่งเศสได้รับการรีเฟรชกล่องข้อความในปี ค.ศ. 2016 ตอนนี้พวกเขาใช้แม่แบบที่ต่างจากวิกิพีเดียภาษาอังกฤษ นี่คือรายการของมอดูลการบำรุงรักษาของพวกเขา เนื่องจากการเปลี่ยนแปลงนี้ การแจ้งเตือนภาษาฝรั่งเศสจะไม่ปรากฏในวิกิพีเดียบนอุปกรณ์เคลื่อนที่

ข้อเสนอศาลาชุมชนวิกิพีเดียภาษาอังกฤษ
มีข้อเสนอในวิกิพีเดียภาษาอังกฤษในปี ค.ศ. 2016 ข้อเสนอแย้งว่าลิงก์ "ปัญหาหน้า" ขนาดเล็กไม่ได้แสดงถึงความสำคัญของประกาศบางอย่าง

ในเดือนกันยายนปี ค.ศ. 2016 ชุมชนได้อนุมัติข้อเสนอนี้เพื่อเปิดเผยประเด็นเกี่ยวกับหน้าเว็บในเว็บไซต์บนมือถือ โดยมีความเห็นเป็นเอกฉันท์ว่าควรมองเห็นแม่แบบคำเตือนบางส่วนบนอุปกรณ์เคลื่อนที่

""หากเป็นบทความที่ได้รับการแจ้งลบและถูกตั้งค่าสถานะเป็นเรื่องหลอกลวงที่เป็นไปได้ด้วยการจัดแหล่งที่มาทางการแพทย์ไม่เพียงพอ ผู้อ่านใด ๆ ที่เข้าเยี่ยมชมบทความนั้นในคอมพิวเตอร์จะได้รับการทักโดยสามกล่องสีแดงและสีส้มขนาดใหญ่ที่ด้านบนสุดของหน้า หนึ่งในนั้นมีเครื่องหมายหยุดเป็นการเตือน... หากผู้อ่านเข้าชมบทความทางการแพทย์ที่หลอกลวงในโทรศัพท์ของตนเอง... พวกเขาจะได้เพียง "ปัญหาหน้า" สองคำเล็ก ๆ ภายใต้ชื่อบทความ...""

วัตถุประสงค์
เป้าหมายของโครงการนี้คือการปรับปรุงการรับรู้ถึงปัญหาต่าง ๆ ภายในบทความในเว็บบนมือถือ เราจะทำเช่นนี้โดยการจัดรูปแบบที่เห็นได้ของปัญหาหน้า

ทีมงานจะทำงานร่วมกับชุมชนเพื่อให้แนวทางในการจัดรูปแบบของแม่แบบ งานนี้จะส่งผลให้เกิดการจัดรูปแบบของปัญหาที่ดีที่สุดบนเว็บไซต์ในมือถือโดยไม่ต้องเปลี่ยนรูปแบบในเดสก์ท็อป

เป้าหมายนี้เป็นแผนที่สู่โปรแกรม 2, อ็อบเจกทีฟ 1 ของแผนประจำปีสำหรับผู้อ่าน "ช่วยให้ผู้อ่านสามารถวัดคุณภาพและความน่าเชื่อถือของบทความในประสบการณ์การอ่านของพวกเขา"

คำนิยามปัญหาหน้า
สำหรับขอบเขตของโครงการนี้ (เช่นเดียวกับในเอกสารด้านล่าง) เราจะนิยามหน้าว่ามีปัญหาหน้าหากมันอยู่ในเนมสเปซบทความหลัก (NS_MAIN, 0) และมันรวมแม่แบบต่อไปนี้ (ผ่านการรวมกลุ่มซ้อนกันเช่นกัน):


 * Ambox (กล่องข้อความบทความ)

อย่างแม่นยำมากขึ้น ผลลัพธ์ของแม่แบบจะได้รับผลกระทบจากการเปลี่ยนแปลงหากมีตารางเอชทีเอ็มแอลพร้อมซีเอสเอสคลาส  เป็นต้น เทียบเท่าอินเตอร์วิกิกับชื่อที่แปลแล้วจะยังไม่ได้รับผลกระทบ

แม่แบบต่อไปนี้ไม่จัดเป็น "ปัญหาหน้า" เนื่องจากได้รับการใช้ในเนมสเปซที่ไม่ใช่บทความเท่านั้น (NS_MAIN, 0) แต่เกี่ยวข้องกับโครงการนี้ เมื่อแม่แบบได้รับการซ่อนเพื่อให้สามารถอ่านได้บนมือถือ:


 * Tmbox (กล่องข้อความหน้าพูดคุย) เมื่ออยู่ในเนมสเปซ "อภิปราย"
 * Cmbox (กล่องข้อความหมวดหมู่) เมื่ออยู่ในเนมสเปซ "หมวดหมู่"
 * Fmbox (กล่องข้อความไฟล์) เมื่ออยู่ในเนมสเปซ "ไฟล์"

หมายเหตุ แม่แบบใด ๆ ที่ไม่ได้ระบุว่าตัวเองเป็น "ambox" ไม่ใช่ปัญหา ซึ่งรวมถึง:


 * w:Template:Asbox (กล่องโครงบทความ) - นี่คือคำแนะนำสำหรับการปรับปรุง (ไม่ใช่ปัญหา)

หมายเหตุเกี่ยวกับ "ประเภท" และ "ปัญหา" พารามิเตอร์
เราจะแสดงความเข้มงวดของปัญหาเหล่านั้น (และไอคอนที่เกี่ยวข้อง) สำหรับแม่แบบที่มีพารามิเตอร์ "ประเภท" ข้อมูลเพิ่มเติมเกี่ยวกับพารามิเตอร์ประเภทสามารถเห็นได้ในหน้าแม่แบบ ambox ในแต่ละโครงการและวิกิ (นี่คือหน้าสำหรับวิกิพีเดียภาษาอังกฤษ) ปัญหาที่ไม่มีพารามิเตอร์ประเภทภายในแม่แบบจะยังคงปรากฏบนหน้าเว็บโดยใช้การกำหนดสไตล์เริ่มต้น

ในทำนองเดียวกัน คำอธิบายสั้น ๆ จะใช้ได้เฉพาะในกรณีที่พารามิเตอร์ "ปัญหา" มีอยู่ในแม่แบบนั้น ภาพรวมของแม่แบบที่มีข้อความนี้สามารถพบได้ในภารกิจฟาบริเคเตอร์

ขั้นตอนการทำงาน

 * 1) ผู้ใช้เยี่ยมชมหน้าเว็บที่มีปัญหาหน้า
 * 2) ผู้ใช้โต้ตอบกับองค์ประกอบ "ปัญหาหน้า"
 * 3) ผู้ใช้จะได้รับการนำไปยังรายละเอียดเกี่ยวกับปัญหาหน้า

ทั่วไป
ปัญหาหน้ามือถือจะแสดงดังต่อไปนี้:
 * คำอธิบายปัญหา
 * คำอธิบายสั้น ๆ สำหรับปัญหาจะถูกใช้หากมี
 * หากไม่มีคำอธิบายสั้น ๆ เราจะแสดงจุดเริ่มต้นของคำอธิบายปัญหาแบบยาว
 * ความยาวของปัญหาสำหรับทั้งคำอธิบายแบบสั้นและยาวจะถูกจำกัดตามข้อจำกัดของพื้นที่
 * ความเข้มงวดของปัญหา
 * Severity will be set according to ambox type as follows (this means they will inherit the color of the template type):
 * 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.

ตัวอย่าง:







ประเด็นเดียว

 * 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).

หลายประเด็น

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

Example:



Multiple issues without Template:Multiple issues
We do not support the case where the multiple issues template is not used. If several issues are adjacent to one another but are not wrapped in the multiple issues template, then there are potential problems with the display - in particular with icon display. See phab:T202349 for further discussion.

Section issues
The initial implementation of this project will display issues within individual sections.

Potential future improvements
Once we put these styles in place, we would like to look at being able to provide them in a more centralized way by delivering mobile-friendly CSS using the TemplateStyles extension. This will allow us to cover a larger percentage of templates with specialized treatment and give more power to template editors to select the specialized treatment for each template.

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?'''
 * 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?

Additional research questions:
 * 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.

High level design goals:

 * 1) Compact: page issues come in a wide variety of lengths, but screen space on phones is limited and we want to respect the reader's desire to access the content, so we decided the banners needed to be compact (two lines of text, or roughly 62px tall max). We hope that in turn template editors will further refine page issue descriptions to (more) succinctly describe the issue.
 * 2) Easy to understand: there are over 300 unique page issues on English Wikipedia, many with beautiful, custom icons. While editors may be familiar with each individual issue we wanted a way to simplify them for readers. In a Vector-like manner we chose severity (i.e. type) as the main concept to communicate visually using 5 generic, globally understandable icons.
 * 3) Easy to engage with: we think that it's important for readers to have the opportunity to easily access additional information about a page issue, and perhaps even be intrigued enough to try fixing it. While many page issues have various links embedded in their descriptions, we wanted to focus the reader's attention on a single action: Learn more. The consistent placement of the blue Learn more link makes it easy for anyone to further engage with an issue they discover.

Here is an example of an ideal page issue banner:



Compatibility across Wikis:
Since page issues are not structured in any way across the hundreds of Wiki projects we knew there would be a large compatibility challenge. In other words, there was no simple way for us to render all page issues from all projects in a consistent manner on mobile devices that met our design goals listed above. Since we are most familiar English Wikipedia we decided to anchor the rendering code around how English page issues are formatted. Page issues on some other Wikis work quite well out of the box (e.g. Japanese, Chinese), however for other projects reformatting of page issue templates will be necessary in order to get them to play nicely with how we render them on mobile.

Here are a few examples from various Wikis that explain what kinds of fixes we recommend:

Making page issues (ambox templates) mobile friendly
See