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 

Chúng tôi biết rằng nhiều người mới đến cảm thấy hứng thú với việc thêm hình ảnh vào Wikipedia. "Để thêm hình ảnh" là một câu trả lời phổ biến mà người mới đến đưa ra trên bài khảo sát chào mừng về lý do họ tạo tài khoản. Chúng tôi cũng nhận thấy rằng một trong những câu hỏi bảng trợ giúp thường xuyên nhất là về cách để thêm hình ảnh, điều đó đúng trên mọi wiki mà chúng tôi làm việc cùng. Mặc dù hầu hết những người dùng mới này hẳn là có sẵn hình ảnh của chính họ mà họ muốn thêm vào nhưng điều này cũng cho thấy hình ảnh có thể gây hứng thú đến mức nào. Việc này cũng có lý thôi khi xét đến các yếu tố mang nặng tính hình ảnh trên các nền tảng khác mà người dùng mới sử dụng -- ví dụ như Instagram hay Facebook.

Khó khăn khi làm việc với hình ảnh

Việc có nhiều câu hỏi bảng trợ giúp về hình ảnh phản ánh rằng quá trình thêm chúng vào bài viết là quá khó khăn. Người mới đến phải hiểu sự khác biệt giữa Wikipedia và Commons, quy định về bản quyền, và các yếu tố kỹ thuật về việc thêm hình ảnh và ghi chú thích vào đúng vị trí. Tìm một hình ảnh trên Commons cho một bài viết chưa có hình ảnh thì thậm chí còn cần nhiều kỹ năng hơn, ví dụ như kiến thức về Wikidata và thể loại.

Thành công của chiến dịch "Bài viết Wikipedia Muốn Hình ảnh"

Chiến dịch Bài viết Wikipedia Muốn Hình ảnh (BVWMHA) là một thành công đầy bất ngờ: 600 người dùng đã thêm hình ảnh vào 85.000 bài viết. Họ thực hiện việc này với sự trợ giúp của một bài công cụ cộng đồng xác định các bài viết chưa có hình ảnh và gợi ý các hình ảnh tiềm năng qua Wikidata. Trong khi có nhiều bài học cần phải được rút ra về việc làm thế nào để giúp người dùng mới thành công trong việc thêm hình ảnh thì việc này mang đến cho chúng tôi lòng tin rằng người dùng có thể trở nên đam mê với việc thêm hình ảnh và rằng họ có thể được hỗ trợ bởi các công cụ.

 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.