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. The Android team is also thinking about a similar task for the Wikipedia Android app using the same underlying components. Additionally, the Structured Data team is in the early stages of exploring something similar, targeted at more experienced users and benefiting from Structured Data on Commons. Discussion and updates on this page are relevant to the work of all teams.

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
 * 2021-01-20: Platform Engineering team begins building proof-of-concept API for image recommendations
 * 2021-01-21: Android team begins work on minimum viable version for learning purposes
 * 2021-01-28: posted user test results
 * 2021-02-04: posted summary of community discussion and coverage statistics

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?
Tìm kiếm loại đóng góp có tính chất quan trọng

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.

Mối quan tâm của người mới đến

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

Kết luận

Suy nghĩ về tất cả những thông tin này, chúng tôi cho rằng có khả năng xây dựng một nhiệm vụ có cấu trúc "thêm hình ảnh" mà vừa vui cho người mới đến và vừa có ích cho Wikipedia.

Thuật toán
Khả năng tạo ra một nhiệm vụ có cấu trúc cho việc thêm hình ảnh thì phụ thuộc vào việc liệu chúng tôi có thể tạo ra một thuật toán sản sinh ra những gợi ý đủ tốt hay không. Chúng tôi chắc chắn là không muốn hướng người mới đến việc thêm hình ảnh sai vào bài, khiến cho những tuần tra viên phải dọn dẹp theo. Vì vậy, cố xem liệu chúng tôi có thể tạo nên một thuật toán tốt là một trong những việc đầu tiên chúng tôi tập trung vào.

Logic
Chúng tôi đã làm việc với Nhóm Nghiên cứu Wikimedia, và cho đến nay chúng tôi đã thử nghiệm một thuật toán ưu tiên độ chính xác và phán đoán của con người. Thay vì dùng bất cứ thị giác máy tính có thể sản sinh ra những kết quả không theo kỳ vọng nào thì nó chỉ đơn giản là tập hợp những thông tin đã có sẵn trên Wikidata, sử dụng những mối liên kết được tạo ra bởi những người dùng có kinh nghiệm. Dưới đây là ba cách chính để thuật toán đưa ra gợi ý phù hợp cho những bài viết chưa có hình ảnh:


 * Xem khoản mục Wikidata cho bài viết. Nếu nó có hình ảnh (P18) thì chọn hình ảnh đó.
 * Xem khoản mục Wikidata cho bài viết. Nếu có có một thể loại Commons liên kết (P373) thì chọn hình ảnh từ thể loại đó.
 * Xem bài viết cùng chủ đề ở các Wikipedia ngôn ngữ khác. Chọn một hình ảnh đầu bài từ những bài viết đó.

Thuật toán cũng có cả logic để làm những việc như là loại bỏ hình ảnh có khả năng là icon hoặc xuất hiện trong một bài viết như là một phần của một hộp điều hướng.

Accuracy
Tính đến tháng 12 năm 2020, chúng tôi đã trải qua hai vòng thử nghiệm thuật toán, mỗi lần đều xem xét các gợi ý cho bài viết tại sáu ngôn ngữ: tiếng Anh, tiếng Pháp, tiếng Ả Rập, tiếng Việt, tiếng Séc và tiếng Hàn. Việc đánh giá được thực hiện bởi các đại sứ của nhóm chúng tôi là những người bản ngữ ở mỗi ngôn ngữ. Khi xem xét 50 gợi ý ở mỗi ngôn ngữ, chúng tôi phân loại chúng thành những nhóm sau:

Một câu hỏi xuyên suốt việc tạo nên một thuật toán kiểu thế này là: nó phải chính xác đến mức nào? Liệu 75% gợi ý là đúng thì có đủ không? Nó có cần phải chính xác 90% không? Hay chỉ cần 50% là đủ rồi? Điều này phụ thuộc vào việc đánh giá của người dùng mới sử dụng nó là tốt đến đâu, và họ kiên nhẫn đến mức nào đối với những gợi ý không chính xác. Chúng tôi sẽ hiểu thêm về việc này khi chúng tôi thử nghiệm thuật toán với người dùng mới thật.

Trong cuộc đánh giá đầu tiên, điều quan trọng nhất là chúng tôi tìm ra có nhiều cải thiện có thể dễ dàng xây dựng với thuật toán, bao gồm loại bài viết và hình ảnh cần loại trừ. Dù không có những cải thiện đó thì khoảng 20-40% gợi ý là điểm "2", tức là phù hợp với bài viết (tùy thuộc vào từng wiki). Bạn có thể xem toàn bộ kết quả và ghi chú từ cuộc đánh giá đầu tiên ở đây.

Ở lần đánh giá thứ hai, nhiều cải thiện đã được áp dụng và độ chính xác đã tăng lên. Khoảng 50-70% gợi ý có điểm "2" (tùy thuộc vào wiki). Nhưng tăng độ chính xác có thể làm giảm độ bao phủ, tức là số lượng bài viết mà chúng tôi có thể tạo gợi ý. Sử dụng các tiêu chí vừa phải, thuật toán có lẽ chỉ có thể đưa ra hàng chục ngàn gợi ý trong một wiki nhất định, kể cả nếu như wiki đó có hàng trăm ngàn hoặc hàng triệu bài viết. Chúng tôi tin rằng khối lượng gợi ý như vậy sẽ là vừa đủ để xây dựng một phiên bản ban đầu của tính năng này. Bạn có thể xem toàn bộ kết quả và ghi chú từ cuộc đánh giá thứ hai ở đây.

Chúng tôi sẽ tiếp tục cải thiện thuật toán, và vào tháng 12 năm 2020, chúng tôi đang cố thực hiện một cuộc đánh giá thứ ba, bạn có thể theo dõi nó tại đây.

Coverage
The accuracy of the algorithm is clearly a very important component. Equally important is its "coverage" -- this refers to how many image matches it can make. Accuracy and coverage tend to be inversely related: the more accurate an algorithm, the fewer suggestions it will make (because it is only making suggestions when it is confident). We need to answer these questions: is the algorithm able to provide enough matches that it is worthwhile to build a feature with it? Would it be able to make a substantial impact on wikis? We looked at 22 Wikipedias to get a sense of the answers. The table is below these summary points:


 * The coverage numbers reflected in the table seem to be sufficient for a first version of an "add an image" feature. There are enough candidate matches in each wiki such that (a) users won't run out, and (b) a feature could make a substantial impact on how illustrated a wiki is.
 * Wikis range from 20% unillustrated (Serbian) to 69% unillustrated (Vietnamese).
 * We can find between 7,000 (Bengali) and 155,000 (English) unillustrated articles with match candidates. In general, this is a sufficient volume for a first version of the task, so that users have plenty of matches to do. In some of the sparser wikis, like Bengali, it might get into small numbers once users narrow to topics of interest. That said, Bengali only has about 100,000 total articles, so we would be proposing matches for 7% of them, which is substantial.
 * In terms of how big of an improvement in illustrations we could make to the wikis with this algorithm, the ceiling ranges from 1% (cebwiki) to 9% (trwiki). That is the overall percentage of additional articles that would wind up with illustrations if every match is good and is added to the wiki.
 * The wikis with the lowest percentage of unillustrated articles for which we can find matches are arzwiki and cebwiki, which both have a high volume of bot-created articles. This makes sense because many of those articles are of specific towns or species that wouldn't have images in Commons. But because those wikis have so many articles, there are still tens of thousands for which the algorithm has matches.
 * In the farther future, we hope that improvements to the image matching algorithm, or to MediaSearch, or to workflows for uploading/captioning/tagging images yield more candidate matches.

Câu hỏi mở
Hình ảnh là một phần quan trọng và dễ thấy của trải nghiệm Wikipedia. Chúng tôi cần phải suy nghĩ kỹ về việc một tính năng cho phép việc thêm hình ảnh dễ dàng thì sẽ hoạt động như thế nào, có thể phát sinh những vấn đề gì, và sẽ liên quan ra sao tới các thành viên cộng đồng. Vì thế, chúng tôi có nhiều câu hỏi mở, và chúng tôi muốn nghe thêm nữa những điều mà các thành viên cộng đồng có thể đưa tới.


 * Thuật toán của chúng tôi có chính xác đủ để cung cấp nhiều gợi ý đúng?
 * Người mới đến cần những dữ liệu meta từ Commons và bài viết không có hình ảnh nào để có thể đưa ra quyết định về việc có thêm hình ảnh hay không?
 * Người mới đến có thể đưa ra đánh giá đủ chính xác khi nhìn vào các gợi ý hay không?
 * Người mới đến không biết tiếng Anh có thể đưa ra quyết định chính xác tương tự không khi mà hầu như dữ liệu meta trên Commons là bằng tiếng Anh?
 * Người mới đến có thể viết chú thích hình ảnh đủ tốt cho hình ảnh họ đặt vào bài viết không?
 * Người mới đến nên đánh giá hình ảnh dựa trên "chất lượng" thay vì "độ liên quan" nhiều như thế nào?
 * Người mới đến liệu sẽ nghĩ nhiệm vụ này là thú vị? Vui? Khó? Dễ? Hay chán?
 * Chính xác thì chúng tôi nên xác định bài viết nào là bài viết không có hình ảnh?
 * Hình ảnh nên được đặt ở vị trí nào trong bài viết không có hình ảnh? Có nên đặt ở trên cùng bài viết không?
 * Chúng tôi nên lưu ý ra sao về hiện tượng thiên kiến trong gợi ý, nghĩa là có thể thuật toán sẽ đưa ra nhiều gợi ý về các chủ đề ở châu Âu và Bắc Mỹ hơn.
 * Một luồng công việc như thế liệu có thúc đẩy phá hoại không? Việc này có thể được ngăn chặn như thế nào?

Notes from community discussions 2021-02-04
Starting in December 2020, we invited community members to talk about the "add an image" idea in five languages (English, Bengali, Arabic, Vietnamese, Czech). The English discussion mostly took place on the discussion page here, with local language conversations on the other four Wikipedias. We heard from 28 community members, and this section summarizes some of the most common and interesting thoughts. These discussions are heavily influencing our next set of designs.


 * Overall: community members are generally cautiously optimistic about this idea. In other words, people seem to agree that it would be valuable to use algorithms to add images to Wikipedia, but that there are many potential pitfalls and ways this can go wrong, especially with newcomers.
 * Algorithm
 * Community members seemed to have confidence in the algorithm because it is only drawing on associations coded into Wikidata by experienced users, rather than some sort of unpredictable artificial intelligence.
 * Of the three sources for the algorithm (Wikidata P18, interwiki links, and Commons categories), people agreed that Commons categories are the weakest (and that Wikidata is the strongest). This has borne out in our testing, and we may exclude Commons categories from future iterations.
 * We got good advice on excluding certain kinds of pages from the feature: disambiguations, lists, years, good, and featured articles.. We may also want to exclude biographies of living persons.
 * We should also exclude images that have a deletion template on Commons and that have been previously removed from the Wikipedia page.
 * Newcomer judgment
 * Community members were generally concerned that newcomers would apply poor judgment and give the algorithm the benefit of the doubt. We know from our user tests that newcomers are capable of using good judgment, and we believe that the right design will encourage it.
 * In discussing the Wikipedia Pages Wanting Photos campaign (WPWP), we learned that while many newcomers were able to exhibit good judgment, some overzealous users can make many bad matches quickly, causing lots of work for patrollers. We may want to add some sort of validation to prevent users from adding images too fast, or from continuing to add images after being repeatedly reverted.
 * Most community members affirmed that "relevance" is more important than "quality" when it comes to whether an image belongs. In other words, if the only photo of a person is blurry, that is usually still better than having no image at all.  Newcomers need to be taught this norm as they do the task.
 * Our interface should convey that users should move slowly and take care, as opposed to trying to get as many matches done as they can.
 * We should teach users that images should be educational, not merely decorative.
 * User interface
 * Several people proposed that we show users several image candidates to choose from, instead of just one. This would make it more likely that good images are attached to articles.
 * Many community members recommended that we allow newcomers to choose topic areas of interest (especially geographies) for articles to work with. If newcomers choose areas where they have some knowledge, they may be able to make stronger choices.  Fortunately, this would automatically be part of any feature the Growth team builds, as we already allow users to choose between 64 topic areas when choosing suggested edit tasks.
 * Community members recommend that newcomers should see as much of the article context as possible, instead of just a preview. This will help them understand the gravity of the task and have plenty of information to use in making their judgments.
 * Placement in the article
 * We learned about Wikidata infoboxes. We learned that for wikis that use them, the preference is for images to be added to Wikidata, instead of to the article, so that they can show up via the Wikidata infobox.  In this vein, we will be researching how common these infoboxes are on various wikis.
 * In general, it sounds like a rule of "place an image under the templates and above the content" in an article will work most of the time.
 * Some community members advised us that even if placement in an article isn't perfect, other users will happily correct the placement, since the hard work of finding the right image will already be done.
 * Non-English users
 * Community members reminded us that some Commons metadata elements can be language agnostic, like captions and depicts statements. We looked at exactly how common that was in this section.
 * We heard the suggestion that even if users aren't fluent with English, they may still be able to use the metadata if they can read Latin characters. This is because to make many of the matches, the user is essentially just looking for the title of the article somewhere in the image metadata.
 * Someone also proposed the idea of using machine translation (e.g. Google Translate) to translate metadata to the local language for the purposes of this feature.
 * Captions
 * Community members (and Growth team members) are skeptical about the ability of newcomers to write appropriate captions.
 * We received advice to show users example captions, and guidelines tailored to the type of article being captioned.

Plan for user testing


Suy nghĩ về những câu hỏi mở phía trên, cộng thêm những cung cấp từ cộng đồng, chúng tôi muốn tạo ra một số thông tin vừa có chất vừa có lượng để giúp chúng tôi đánh giá tính khả thi của việc xây một tính năng "thêm hình ảnh". Mặc dù thành viên trong nhóm chúng tôi và các Wikimedian đã đánh giá về thuật toán nhưng việc xem người mới đến phản ứng như thế nào về nó và xem cách họ đưa ra phán đoán khi quyết định liệu một bức ảnh có thuộc về bài viết hay không mới là điều quan trọng.

Chúng tôi sẽ chạy thử nghiệm bằng usertesting.com, tại đó những người mới với việc sửa đổi Wikipedia có thể lướt qua các gợi ý hình ảnh trong một nguyên mẫu và trả lời "Có", "Không" hoặc "Không chắc". Chúng tôi đã xây dựng một nguyên mẫu nhanh cho cuộc thử nghiệm bằng những gợi ý thật từ thuật toán hiện tại. Nguyên mẫu chỉ đưa ra lần lượt từng gợi ý, tất cả đều trong một feed. Các hình ảnh được cung cấp cùng với mọi dữ liệu meta liên quan từ Commons:


 * Tên tập tin
 * Kích thước
 * Thời gian
 * Thành viên
 * Mô tả
 * Chú thích hình
 * Thể loại
 * Thẻ

Mặc dù luồng công việc cho người dùng thật sự trong tương lai có thể không giống như vậy nhưng chúng tôi tạo ra nguyên mẫu này để các tester có thể đi qua nhiều gợi ý một cách nhanh chóng và cho ra nhiều thông tin.

Để thử nguyên mẫu tương tác, hãy sử dụng liên kết này. Lưu ý rằng nguyên mẫu này chủ yếu là để xem các gợi ý từ thuật toán -- chúng tôi vẫn chưa nghĩ sâu về trải nghiệm người dùng thực sự. Nó không thực sự tạo ra bất kỳ sửa đổi nào. Nó chứa 60 gợi ý thật do thuật toán đề xuất.

Sau đây sẽ là những gì chúng tôi mong đợi từ cuộc thử nghiệm:


 * 1) Những người tham gia có thể xác nhận các gợi ý một cách tự tin dựa trên những dữ liệu cung cấp?
 * 2) Những người tham gia đánh giá các gợi ý chính xác đến mức nào? Họ thấy họ đang làm tốt hơn hay tệ hơn so với những gì họ thực sự làm?
 * 3) Những người tham gia cảm thấy thế nào về nhiệm vụ thêm hình ảnh vào bài viết bằng cách này? Họ thấy dễ/khó, thú vị/chán, đáng làm/không liên quan?
 * 4) Thông tin nào người tham gia cảm thấy có giá trị nhất trong việc giúp họ đánh giá xem liệu hình ảnh và bài viết có phù hợp với nhau không?
 * 5) Những người tham gia có thể dựa trên những dữ liệu được cung cấp mà viết được caption phù hợp cho hình ảnh mà họ cho là đúng với bài viết không?

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.



User tests December 2020
Background

During December 2020, we used usertesting.com to conduct 15 tests of the mobile interactive prototype. The prototype contained only a rudimentary design, little context or onboarding, and was tested only in English with users who had little or no previous Wikipedia editing experience. We deliberately tested a rudimentary design earlier in the process so that we could gather lots of learnings. The primary questions we wanted to address with this test were around feasibility of the feature as a whole, not around the finer points of design:


 * 1) Are participants able to confidently confirm matches based on the suggestions and data provided?
 * 2) How accurate are participants at evaluating suggestions? And how does the actual aptitude compare to their perceived ability in evaluating suggestions?
 * 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 metadata 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?

In the test, we asked participants to annotate at least 20 article-image matches while talking out loud. When they tapped yes, the prototype asked them to write a caption to go along with the image in the article. Overall, we gathered 399 annotations.

Summary

We think that these user tests confirm that we could successfully build an "add an image" feature, but it will only work if we design it right. Many of the testers understood the task well, took it seriously, and made good decisions -- this gives us confidence that this is an idea worth pursuing. On the other hand, many other users were confused about the point of the task, did not evaluate as critically, and made weak decisions -- but for those confused users, it was easy for us to see ways to improve the design to give them the appropriate context and convey the seriousness of the task.

Observations

''To see the full set of findings, feel free to browse the slides. The most important points are written below the slides.''
 * General understanding of the task matching images to Wikipedia articles was reasonably good, given the minimal context provided for the tool and limited knowledge of Commons and Wikipedia editing. There are opportunities to boost understanding once the tool is redesigned in a Wikipedia UX.
 * The general pattern we noticed was: a user would look at an article's title and first couple sentences, then look at the image to see if it could plausibly match (e.g. this is an article about a church and this is an image of a church). Then they would look for the article's title somewhere in the image metadata, either in the filename, description, caption, or categories.  If they found it, they would confirm the match.
 * Each image matching task could be done quickly by someone unfamiliar with editing. On average, it took 34 seconds to review an image.
 * All said they would be interested in doing such a task, with a majority rating it as easy or very easy.
 * Perceived quality of the images and suggestions was mixed. Many participants focused on the image composition and other aesthetic factors, which affected their perception of the suggestion accuracy.
 * Only a few pieces of image metadata from Commons were critical for image matching: filename, description, caption, categories.
 * Many participants would, at times, incorrectly try to match an images to its own data, rather than to the article (e.g. "Does this filename seem right for the image?"). Layout and visual hierarchy changes to better focus on the article context for the image suggested should be explored.
 * “Streaks” of good matches made some participants more complacent with accepting more images -- if many in a row were "Yes", they stopped evaluating as critically.
 * Users did a poor job of adding captions. They frequently would write their explanation for why they matched the image, e.g. "This is a high quality photo of the guy in the article." This is something we believe can be improved with design and explanation for the user.

Metrics


 * Members of our team annotated all the image matches that were shown to users in the test, and we recorded the answers the users gave. In this way, we developed some statistics on how good of a job the users did.
 * Of the 399 suggestions users encountered, they tapped "Yes" 192 times (48%).
 * Of those, 33 were not good matches, and might be reverted were they to be added to articles in reality. This is 17%, and we call this the "likely revert rate".

Takeaways


 * The "likely revert rate" of 17% is a really important number, and we want this to be as low as possible. On the one hand, this number is close to or lower than the average revert rate for newcomer edits in Wikipedia (English is 36%, Arabic is 26%, French is 22%, Vietnamese is 11%).  On the other hand, images are higher impact and higher visibility than small changes or words in an article.  Taking into account the kinds of changes we would make to the workflow we tested (which was optimized for volume, not quality), we think that this revert rate would come down significantly.
 * We think that this task would work much better in a workflow that takes the user to the full article, as opposed to quickly shows them one suggestion after another in the feed. By taking them to the full article, the user would see much more context to decide if the image matches and see where it would go in the article.  We think they would absorb the importance of the task: that they will actually be adding an image to a Wikipedia article.  Rather than going for speed, we think the user would be more careful when adding images.  This is the same decision we came to for "add a link" when we decided to build the "Concept A" workflow.
 * We also think outcomes will be improved with onboarding, explanation, and examples. This is especially true for captions.  We think if we show users some examples of good captions, they'll realize how to write them appropriately.  We could also prompt them to use the Commons description or caption as a starting point.
 * Our team has lately been discussing whether it would be better to adopt a "collaborative decision" framework, in which an image would not be added to an article until two users confirm it, rather than just one. This would increase the accuracy, but raises questions around whether such a workflow aligns with Wikipedia values, and which user gets credit for the edit.

Metadata
The user tests showed us that image metadata from Commons (e.g. filename, description, caption, etc.) is critical for a user to confidently make a match. For instance, though the user can see that the article is about a church, and that the photo is of a church, the metadata allowed them to tell if it is the church discussed in the article. In the user tests, we saw that these items of metadata were most important: filename, description, caption, categories. Items that were not useful included size, upload date, and uploading username.

Given that metadata is a critical part of making a strong decision, we have been thinking about whether users will need to be have metadata in their own language in order to do this task, especially in light of the fact that the majority of Commons metadata is in English. For 22 wikis, we looked at the percentage of the image matches from the algorithm that have metadata elements in the local language. In other words, for the images that can be matched to unillustrated articles in Arabic Wikipedia, how many of them have Arabic descriptions, captions, and depicts? The table is below these summary points:


 * In general, local language metadata coverage is very low. English is the exception.
 * For all wikis except English, fewer than 7% of image matches have local language descriptions (English is at 52%).
 * For all wikis except English, fewer than 0.5% of image matches have local language captions (English is at 3.6%).
 * For depicts statements, the wikis range between 3% (Serbian) and 10% (Swedish) coverage for their image matches.
 * The low coverage of local language descriptions and captions means that in most wikis, there are very few images we could suggest to users with local language metadata. Some of the larger wikis have a few thousand candidates with local language descriptions.  But no non-English wikis have over 1,000 candidates with local language captions.
 * Though depicts coverage is higher, we expect that depicts statements don’t usually contain sufficient detail to positively make a match. For instance, a depicts statement applied to a photo of St. Paul’s Church in Chicago is much more likely to be “church”, than “St. Paul’s Church in Chicago”.
 * We may want to prioritize image suggestions with local language metadata in our user interfaces, but until other features are built to increase the coverage, relying on local languages is not a viable option for these features in non-English wikis.

Given that local-language metadata has low coverage, our current idea is to offer the image matching task to just those users who can read English, which we could ask the user as a quick question before beginning the task. This unfortunately limits how many users could participate. It's a similar situation to the Content Translation tool, in that users need to know the language of the source wiki and the destination wiki in order to move content from one wiki to another. We also believe there will be sufficient numbers of these users based on results from the Growth team's welcome survey, which asks newcomers which languages they know. Depending on the wiki, between 20% and 50% of newcomers select English.

Android MVP
See this page for the details on the Android MVP.

After lots of community discussion, many internal discussions, and the user test results from above, we believe that this "add an image" idea has enough potential to continue to pursue. Community members have been generally positive, but also cautionary -- we also know that there are still many concerns and reasons the idea might not work as expected. The next step we want to in order to learn more is to build a "minimum viable product" (MVP) for the Wikipedia Android app. The most important thing about this MVP is that it will not save any edits to Wikipedia. Rather, it will only be used to gather data, improve our algorithm, and improve our design.

The Android app is where "suggested edits" originated, and that team has a framework to build new task types easily. These are the main pieces:


 * The app will have a new task type that users know is only for helping us improve our algorithms and designs.
 * It will show users image matches, and they will select "Yes", "No", or "Skip".
 * We'll record the data on their selections to improve the algorithm, determine how to improve the interface, and think about what might be appropriate for the Growth team to build for the web platform later on.
 * No edits will happen to Wikipedia, making this a very low-risk project.

The Android team will be working on this in February and March 2021, hopefully allowing the Growth team to begin learning quickly.

Engineering
This section contains links on how to follow along with technical aspects of this project:


 * Work on the "proof of concept" API by the Platform Engineering team, built to back the Android MVP
 * Phabricator tasks around the Android team's MVP
 * Phabricator tasks and evaluations of the image matching algorithm