Growth/Personalized first day/Structured tasks/Add an image/vi

Trang này nói về nhiệm vụ có cấu trúc "thêm hình ảnh", một loại nhiệm vụ có cấu trúc mà nhóm Tăng Trưởng mang lại thông qua trang nhà người mới. Nhóm Android cũng suy nghĩ về một nhiệm vụ tương tự cho ứng dụng Android Wikipedia sử dụng cùng những thành phần cơ sở. Những thảo luận và cập nhật trong trang này có liên quan tới công việc của cả hai nhóm.

Trang này chứa các sản phẩm, thiết kế, câu hỏi mở và các quyết định.

Hầu hết các cập nhật thêm vào sẽ được đăng trên trang cập nhật chung của Nhóm tăng trưởng, còn một số các cập nhật chi tiết hoặc lớn hơn sẽ được đăng ở đây.

Tình hình hiện tại

 * 2020-06-22: Những suy nghĩ ban đầu về các ý tưởng tạo nên một thuật toán đơn giản để gợi ý hình ảnh
 * 2020-09-08: đánh giá lần thử đầu tiên về một thuật toán gợi ý phù hợp tại tiếng Anh, tiếng Pháp, tiếng Ả Rập, tiếng Hàn Quốc, tiếng Séc và tiếng Việt
 * 2020-09-30: đánh giá lần thử thứ hai về một thuật toán gợi ý phù hợp tại tiếng Anh, tiếng Pháp, tiếng Ả Rập, tiếng Hàn Quốc, tiếng Séc và tiếng Việt
 * 2020-10-26: cuộc thảo luận kỹ thuật nội bộ về những tính năng tiềm năng cho dịch vụ gợi ý hình ảnh
 * 2020-12-15: chạy vòng kiểm tra người dùng đầu tiên để bắt đầu tìm hiểu xem liệu người mới đến có thể thành công với nhiệm vụ này không

Tóm tắt
Nhiệm vụ có cấu trúc chia nhỏ các nhiệm vụ sửa đổi thành một luồng công việc theo từng bước, trở nên dễ hiểu hơn cho người mới đến và cho các thiết bị di động. Nhóm Tăng Trưởng tin rằng giới thiệu những kiểu luồng công việc mới này sẽ cho phép nhiều người mới bắt đầu tham gia Wikipedia hơn, một vài trong số đó sẽ học được cách thực hiện những sửa đổi quan trọng hơn và tham gia vào cộng đồng. Sau khi $thảo luận ý tưởng về nhiệm vụ có cấu trúc với các cộng đồng thì chúng tôi đã quyết định xây dựng nhiệm vụ có cấu trúc đầu tiên: "thêm liên kết".

Kể cả khi chúng tôi xây dựng nhiệm vụ đầu tiên đó thì chúng tôi đã nghĩ đến việc nhiệm vụ có cấu trúc tiếp theo có thể là gì rồi, và chúng tôi cho rằng thêm hình ảnh có thể phù hợp với người mới đến. Ý tưởng sẽ là một thuật toán đơn giản gợi ý hình ảnh từ Commons để đặt vào các bài viết không có hình ảnh. Để bắt đầu thì nó sẽ chỉ sử dụng các mối liên hệ sẵn có trên Wikidata, và người mới đến sẽ đánh giá liệu có nên đặt hình ảnh đó vào bài viết hay không.

Chúng tôi biết là có nhiều câu hỏi mở xoay quanh phương thức hoạt động của nhiệm vụ này, nhiều lý do nó có thể không hoạt động chính xác. Đó là lý do tại sao chúng tôi hy vọng có thể lắng nghe và có một cuộc thảo luận với những thành viên cộng đồng trước khi quyết định sẽ tiếp tục ra sao.

Sao lại là hình ảnh?
 Looking for substantial contributions 

Khi chúng tôi lần đầu thảo luận về nhiệm vụ có cấu trúc với các thành viên của cộng đồng, nhiều người đã chỉ ra rằng thêm liên kết wiki không phải là một dạng sửa đổi có giá trị quá cao. Các thành viên cộng đồng đã đưa ra các ý tưởng về cách mà người mới đến có thể tạo những đóng góp quan trọng hơn. Một trong số đó là hình ảnh. Wikipedia Commons chứa 65 triệu hình ảnh, nhưng trong nhiều Wikipedia, hơn 50% bài viết không có hình ảnh. Chúng tôi tin rằng nhiều hình ảnh từ Commons có thể giúp Wikipedia được minh họa một cách đáng kể hơn.

 Interest from newcomers 

We know that many newcomers are interested in adding images to Wikipedia. "To add an image" is a common response newcomers give on the welcome survey for why they are creating their account. We also see that one of the most frequent help panel questions is about how to add images, true across all the wikis we work with. Though most of these newcomers are probably bringing their own image that they want to add, this hints at how images can be engaging and exciting. That makes sense, given the image-heavy elements of the other platforms that newcomers participate in -- things like Instagram and Facebook.

 Difficulty of working with images 

The many help panel questions about images reflects that the process to add them to articles is too difficult. Newcomers have to understand the difference between Wikipedia and Commons, rules around copyright, and the technical parts of inserting and captioning the image in the right place. Finding an image in Commons for an unillustrated article requires even more skills, such as knowledge of Wikidata and categories.

 Success of "Wikipedia Pages Wanting Photos" campaign 

The Wikipedia Pages Wanting Photos campaign (WPWP) was a surprising success: 600 users added images to 85,000 pages. They did this with the assistance of a couple of community tools that identified pages that have no images, and which suggest possible images through Wikidata. While there are important lessons to be learned about how to help newcomers succeed with adding images, this gives us confidence that users can be enthusiastic about adding images and that they can be assisted by tools.

 Taking this all together 

Thinking about all this information together, we think that it could be possible to build an "add an image" structured task that is both fun for newcomers and productive for Wikipedias.

Algorithm
Our ability to make a structured task for adding images depends on whether we can create an algorithm that generates sufficiently good recommendations. We definitely do not want to urge newcomers to add the wrong images to articles, which would cause work for patrollers to clean up after them. Therefore, trying to see if we could make a good algorithm is one of the first things we've worked on.

Logic
We have been working with the Wikimedia Research team, and so far we have been testing an algorithm that prioritizes accuracy and human judgment. Rather than using any computer vision, which can generate unexpected results, it simply aggregates existing information in Wikidata, drawing on connections made by experienced contributors. These are the three main ways that it suggests matches to unillustrated articles:


 * Look at the Wikidata item for the article. If it has an image (P18), choose that image.
 * Look at the Wikidata item for the article. If it has a Commons category associated (P373), choose an image from the category.
 * Look at the articles about the same topic in other language Wikipedias. Choose a lead image from those articles.

The algorithm also includes logic to do things like exclude images that are likely icons or that are present on an article as part of a navbox.

Performance
As of December 2020, we've gone through two rounds of testing the algorithm, each time looking at matches to articles in six languages: English, French, Arabic, Vietnamese, Czech, and Korean. The evaluations were done by our team's ambassadors, who are native speakers in each languages. Looking at 50 matches in each language, we went through and classified them into these groups:

A question that runs throughout the work on an algorithm like this is: how accurate does it need to be? If 75% of matches are good is that enough? Does it need to be 90% accurate? Or could it be as low as 50% accurate? This depends on how good the judgment is of the newcomers using it, and how much patience they have for weak matches. We'll learn more about this when we user test the algorithm with real newcomers.

In the first evaluation, the most important thing is that we found a lot of easy improvements to make to the algorithm, including types of articles and images to exclude. Even without those improvements, about 20-40% of matches were "2s", meaning great matches for the article (depending on the wiki). You can see the full results and notes from the first evaluation here.

For the second evaluation, many improvements were incorporated, and the accuracy increased. Between 50-70% of matches were "2s" (depending on the wiki). But increasing the accuracy can decrease the coverage, i.e. the number of articles for which we can make matches. Using conservative criteria, the algorithm may only be able to suggest tens of thousands of matches in a given wiki, even if that wikis has hundreds of thousands or millions of articles. We believe that that kind of volume would be sufficient to build an initial version of this feature. You can see the full results and notes from the second evaluation here.

We are continuing to make improvements to the algorithm, and in December 2020, we are trying a third evaluation, which you can follow along with here.

Open questions
Images are such an important and visible part of the Wikipedia experience. It is critical that we think hard about how a feature enabling the easy adding of images would work, what the potential pitfalls might be, and what the implications would be for community members. To that end, we have many open questions, and we want to hear of more that community members can bring up.


 * Will our algorithm be sufficiently accurate such that plenty of good matches are provided?
 * What metadata from Commons and the unillustrated article do newcomers need in order to make a decision about whether to add the image?
 * Will newcomers have sufficiently good judgment when looking at recommendations?
 * Will newcomers who don't read English be equally able to make good decisions, given that much of Commons metadata is in English?
 * Will newcomers be able to write good captions to go along with images that they place in the articles?
 * How much should newcomers judge images based on their "quality" as opposed to their "relevance"?
 * Will newcomers think this task is interesting? Fun? Difficult? Easy? Boring?
 * How exactly should we determine which articles have no images?
 * Where in the unillustrated article should the image be placed? Is it sufficient to put it at the top of the article?
 * How can we be mindful of potential bias in the recommendations, i.e. perhaps the algorithm will make many more matches for topics in Europe and North America.
 * Will such a workflow be a vector for vandalism? How can this be prevented?

Validating the idea


Thinking about the open questions above, in addition to community input, we want to generate some quantitative and qualitative information to help us evaluate the feasibility of building an "add an image" feature. Though we have been evaluating the algorithm amongst staff and Wikimedians, it is important to see how newcomers react to it, and to see how they use their judgment when deciding on whether an image belongs in an article.

To that end, we are going to run tests with usertesting.com, in which people new to Wikipedia editing can go through potential image matches in a prototype and respond "Yes", "No", or "Unsure". We built a quick prototype for the test, backed with real matches from the current algorithm. The prototype just shows one match after another, all in a feed. The images are shown along with all the relevant metadata from Commons:


 * Filename
 * Size
 * Date
 * User
 * Description
 * Caption
 * Categories
 * Tags

Though this may not be what the workflow would be like for real users in the future, the prototype was made so that testers could go through lots of potential matches quickly, generating lots of information.

To try out the interactive prototype, use this link. Note that this prototype is primarily for viewing the matches from the algorithm -- we have not yet thought hard about the actual user experience. It does not actually create any edits. It contains 60 real matches proposed by the algorithm.

Here's what we'll be looking for in the test:


 * 1) Are participants able to confidently confirm matches based on the suggestions and data provided?
 * 2) How accurate are participants at evaluating suggestions? Do they think they are doing a better or worse job than they are actually doing?
 * 3) How do participants feel about the task of adding images to articles this way? Do they find it easy/hard, interesting/boring, rewarding/irrelevant?
 * 4) What information do participants find most valuable in helping them evaluate image and article matches?
 * 5) Are participants able to write good captions for images they deem a match using the data provided?

Concept A vs. B
In thinking about design for this task, we have a similar question as we faced for "add a link" with respect to Concept A and Concept B. In Concept A, users would complete the edit at the article, while in Concept B, they would do many edits in a row all from a feed. Concept A gives the user more context for the article and editing, while Concept B prioritizes efficiency.

In the interactive prototype above, we used Concept B, in which the users proceed through a feed of suggestions. We did that because in our user tests we wanted to see many examples of users interacting with suggestions. That's the sort of design that might work best for a platform like the Wikipedia Android app. For the Growth team's context, we're thinking more along the lines of Concept A, in which the user does the edit at the article. That's the direction we chose for "add a link", and we think that it could be appropriate for "add an image" for the same reasons.

Single vs. Multiple
Another important design question is whether to show the user a single proposed image match, or give them multiple images matches to choose from. When giving multiple matches, there's a greater chance that one of the matches is a good one. But it also may make users think they should choose one of them, even if none of them are good. It will also be a more complicated experience to design and build, especially for mobile devices. We have mocked up three potential workflows:


 * Single: in this design, the user is given only one proposed image match for the article, and they only have to accept or reject it. It is simple for the user.
 * Multiple: this design shows the user multiple potential matches, and they could compare them and choose the best one, or reject all of them. A concern would be if the user feels like they should add the best one to the article, even if it doesn't really belong.
 * Serial: this design offers multiple image matches, but the user looks at them one at a time, records a judgment, and then chooses a best one at the end if they indicated that more than one might match. This might help the user focus on one image at a time, but adds an extra step at the end.