Tăng trưởng/Cá nhân hóa ngày đầu tiên/Nhiệm vụ có cấu trúc/Thêm hình ảnh

This page is a translated version of the page Growth/Personalized first day/Structured tasks/Add an image and the translation is 36% complete.
Outdated translations are marked like this.

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.

"Add an image" feature on mobile

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: Nhóm Kỹ sư Nền tảng bắt đầu xây dựng API chứng minh-khái niệm cho việc gợi ý hình ảnh
  • 2021-01-21: Nhóm Android bắt đầu làm việc với một phiên bản khả thi tối thiểu với mục đích học hỏi
  • 2021-01-28: Kết quả thử nghiệm người dùng đã được đăng
  • 2021-02-04: tóm tắt cuộc thảo luận cộng đồng và số liệu bao trùm đã được đăng
  • 2021-05-07: Android MVP được phát hành tới người dùng
  • 2021-08-06: công bố kết quả từ Android và mockup cho Phiên bản thử 1
  • 2021-08-17: bắt đầu công việc backend trên Phiên bản thử 1
  • 2021-08-23: công bố các nguyên mẫu tương tác và bắt đầu thử nghiệm người dùng tại tiếng Anh và Tây Ban Nha
  • 2021-10-07: posted findings from user tests and final designs based on the findings
  • 2021-11-19: ambassador begin testing the feature in their production Wikipedias
  • 2021-11-22: image suggestion dataset is refreshed in advance of releasing Iteration 1 to users
  • 2021-11-29: Iteration 1 deployed to 40% of mobile accounts on Arabic, Czech, and Bengali Wikipedias.
  • 2021-12-22: posted leading indicators
  • 2022-01-28: desktop version deployed for 40% of new accounts on Arabic, Czech, and Bengali Wikipedias.
  • 2022-02-16: Spanish Wikipedia newcomers start getting "add an image"
  • 2022-03-22: Portuguese, Farsi, French and Turkish Wikipedia newcomers start getting "add an image"
  • 2023-02-07: Complete evaluation of section-level image suggestions (T316151)
  • 2023-10-16: Image Recommendations added to the Android Wikipedia app
  • Tiếp theo: expand to next set of wikis and analyze conversion funnel in detail


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". The Growth team believes that introducing these new kinds of editing workflows will allow more new people to begin participating on Wikipedia, some of whom will learn to do more substantial edits and get involved with their communities. After discussing the idea of structured tasks with communities, we decided to build the first structured task: "add a link".

Sau khi triển khai "thêm liên kết" vào tháng 5 năm 2021, chúng tôi đã thu thập các dữ liệu ban đầu cho thấy nhiệm vụ này cuốn hút với người mới đến và rằng họ đang tạo sửa đổi với tỷ lệ lùi sửa thấp -- chỉ ra rằng nhiệm vụ có cấu trúc có vẻ như có giá trị với trải nghiệm của người mới và với các wiki.

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.

Related projects

Nhóm Android đã làm việc với một phiên bản nhỏ của 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ở.

Ngoài ra, Nhóm Dữ liệu cấu trúc đang bước đầu khám phá thứ tương tự, nhắm tới những người dùng có kinh nghiệm hơn và được lợi từ Dữ liệu Cấu trúc trên Commons.


Sao lại là hình ảnh?

Mở rộng để đọc mục "Tại 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. Community members brought up ideas for how newcomers could make more substantial contributions. One idea is images. Wikimedia Commons contains 65 million images, but in many Wikipedias, over 50% of articles have no images. We believe that many images from Commons can make Wikipedia substantially more illustrated.

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"

 
Trong chiến dịch Bài viết Wikipedia Muốn Hình ảnh, 600 người dùng đã thêm hình ảnh vào 85.000 bài viết.

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.

Thông qua ý tưởng

Từ tháng 6 năm 2020 đến tháng 7 năm 2021, nhóm Tăng trưởng đã bắt tay vào thảo luận với cộng đồng, nghiên cứu nền tảng, đánh giá, và chứng minh-khái niệm xoay quanh nhiệm vụ "thêm hình ảnh". Điều này dẫn tới quyết định bắt đầu xây dựng bước lặp đầu tiên vào tháng 8 năm 2021 (xem Phiên bản thử 1). Mục này chứa toàn bộ các công việc nền dẫn tới Phiên bản thử 1.

Mở rộng để đọc mục "Thông qua ý tưởng"

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 nó 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.

Độ chính xác

Tính đến tháng 8 năm 2021, chúng tôi đã trải qua ba 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 và các Wikimedian chuyên gia khác, là những người bản ngữ ở các ngôn ngữ được thử nghiệm.

Hai vòng đánh giá đầu tiên

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:

Phân loại Diễn giải Ví dụ
2 Phù hợp với bài viết, mô tả thứ là tiêu đề của bài viết Bài viết là "Bướm" và nó là hình ảnh của một con bướm.
1 Phù hợp, nhưng khó để xác nhận cho bài viết trừ phi người dùng có chút bối cảnh, và sẽ cần một chú thích đầy đủ. Bài viết là "Bướm" và nó là hình ảnh của một nhà khoa học nghiên cứu về bướm nổi tiếng.
0 Không phù hợp với bài viết. Bài viết là "Bướm" và nó là hình ảnh của một chiếc ô tô.
-1 Hình ảnh đúng với chủ đề, nhưng không phù hợp với văn hóa địa phương. Bài viết là "Bướm" và hình ảnh là một loài bướm cụ thể chỉ sống ở một phần trên thế giới có những loài bướm khác so với loài bản địa.
-2 Hình ảnh dễ gây nhầm lẫn mà người dùng mới có thể tình cờ cho rằng nó là đúng. Bài viết là "Bướm" và hình ảnh là một con bướm đêm.
-3 Bài viết không nên có hình ảnh. Trang đổi hướng, danh sách, hoặc các bài viết về "họ", "tên".

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.

Vòng đánh giá thứ ba

Vào tháng 5 năm 2021, nhóm Dữ liệu có cấu trúc đã thực hiện một cuộc thử nghiệm ở phạm vi rộng hơn nhiều đối với thuật toán khớp hình ảnh (và thuật toán MediaSearch) ở Wikipedia tiếng Ả Rập, Cebuano, Anh, Việt, Bengali và Séc. Trong cuộc thử nghiệm này, khoảng 500 cặp bài viết-hình ảnh từ cả thuật toán khớp hình ảnh lẫn MediaSearch đều được đánh giá bởi các chuyên gia ở mỗi ngôn ngữ phân loại chúng thành các cặp "Tốt", "Được", hoặc "Tệ". Kết quả được liệt kê chi tiết bên dưới cho thấy:

  • Thuật toán khớp hình ảnh có độ chính xác từ 65-80% tùy thuộc vào việc tính là "Tốt" hay "Tốt+Được", và tùy vào wiki/người đánh giá. Một điều thú vị là, với kinh nghiệm đánh giá các cặp hình ảnh, các Wikimedian chuyên gia thường không nhất trí với nhau, bởi vì mỗi người có một tiêu chuẩn riêng về việc liệu một hình ảnh có phù hợp với một bài viết hay không.
  • Wikidata P18 ("Wikidata") là nguồn mạnh nhất cho các cặp, có độ chính xác từ 85%-95%. Hình ảnh từ các Wikipedia khác ("Liên wiki") và từ các thể loại Commons đính kèm với khoản mục Wikidata ("thể loại Commons") thì có độ chính xác thấp hơn ở một mức độ tương tự nhau.
  • Hình ảnh từ các Wikipedia khác ("Liên wiki") là nguồn phổ biến nhất cho các cặp. Nói cách khác, chúng có sẵn hơn cho thuật toán so với hai nguồn kia.
Nguồn Độ chính xác (tốt) Độ chính xác (tốt+được) Phần trăm bao phủ
Wikidata 85% 93% 7%
Liên wiki 56% 76% 80%
Thể loại Commons 51% 76% 13%
All 63% 80% 100%

Xem bản kết quả bộ dữ liệu đầy đủ ở đây.

Độ bao phủ

Độ chính xác của thuật toán rõ ràng là một chi tiết hết sức quan trọng. Cũng quan trọng tương đương là "độ bao phủ" của nó -- tức là nó có thể đưa ra "bao nhiêu" cặp hình ảnh. Độ chính xác và độ bao phủ thường có mối quan hệ tỷ lệ nghịch: thuật toán càng chính xác thì nó đưa ra càng ít gợi ý (bởi vì nó sẽ chỉ đưa ra gợi ý khi nó chắc chắn). Chúng tôi cần phải trả lời những câu hỏi sau: thuật toán có thể cung cấp đủ các cặp xứng đáng để xây dựng một tính năng với nó không? Nó có thể tạo ra một ảnh hưởng đáng kể lên các wiki không? Chúng tôi đã xem xét 22 Wikipedia để nắm bắt được câu trả lời. Bảng dưới đây cho thấy các ý chính:

  • Số độ bao phủ phản ánh trong bảng có vẻ đủ cho một phiên bản đầu tiên của tính năng "thêm hình ảnh". Có đủ các cặp đề xuất ở mỗi wiki sao cho (a) người dùng sẽ không dùng hết, và (b) một tính năng có thể có tác động đáng kể tới việc một wiki giàu hình ảnh như thế nào.
  • Các wiki nằm trong tầm từ 20% không có hình ảnh (tiếng Séc-bi) tới 69% không có hình ảnh (tiếng Việt).
  • Chúng tôi có thể tìm thấy từ 7.000 (tiếng Bengali) tới 155.000 (tiếng Anh) bài viết không có hình ảnh với các gợi ý hình ảnh. Nhìn chung, khối lượng này đủ cho phiên bản đầu tiên của nhiệm vụ sao cho người dùng có đủ gợi ý để làm. Ở một số các wiki thưa thớt hơn, như tiếng Bengali, số lượng gợi ý có thể giảm sau khi người dùng giới hạn chủ đề họ quan tâm. Tuy vậy, tiếng Bengali chỉ có khoảng 100.000 bài viết, vậy nên chúng tôi sẽ đưa ra gợi ý cho 7% trong số chúng, tức là cũng đáng kể.
  • Về khoản chúng tôi có thể cải thiện về mặt minh họa nhiều thế nào cho các wiki với thuật toán này, mức trần dao động từ 1% (cebwiki) tới 9% (trwiki). Đó là số phần trăm tổng các bài viết bổ sung mà sau cùng sẽ có thêm hình ảnh minh họa nếu mỗi gợi ý đều phù hợp và được thêm vào wiki.
  • Các wiki có phần trăm bài viết không có hình minh hoạt thấp nhất mà chúng tôi có thể tìm gợi ý cho là arzwiki và cebwiki, cả hai đều có lượng lớn các bài viết do bot tạo. Điều này là hợp lý bởi vì nhiều trong số những bài viết đó là về một thị trấn hoặc sinh vật cụ thể không có hình ảnh trên Commons. Nhưng bởi vì những wiki này có quá nhiều bài viết nên vẫn có hàng chục ngàn bài để thuật toán có thể đưa ra gợi ý.
  • Trong tương lai xa hơn, chúng tôi hy vọng những cải thiện đối với thuật toán khớp hình ảnh, đối với MediaSearch, hoặc đối với luồng công việc tải/viết chú thích/tag hình ảnh sẽ sản sinh ra nhiều gợi ý hơn.
Wiki Tổng số bài viết Bài viết không có hình ảnh Phần trăm không có hình ảnh Có gợi ý hình ảnh Phần trăm không có hình ảnh có gợi ý
enwiki 6.199.587 2.932.613 47% 154.508 5%
trwiki 382.825 151.620 40% 35.561 23%
bnwiki 99.172 33.642 34% 6.921 21%
frwiki 2.273.610 952.994 42% 94.594 10%
ruwiki 1.680.385 584.290 35% 60.415 10%
fawiki 755.709 304.253 40% 55.382 18%
arwiki 1.080.564 581.710 54% 59.551 10%
dewiki 2.506.229 1.190.517 48% 110.771 9%
ptwiki 1.048.255 388.605 37% 79.483 20%
hewiki 282.232 73.261 26% 14.453 20%
cswiki 467.573 182.177 39% 37.300 20%
kowiki 526.990 274.338 52% 48.417 18%
plwiki 1.441.429 560.334 39% 71.456 13%
ukwiki 1.058.563 365.209 35% 51.154 14%
svwiki 3.514.965 1.686.664 48% 91.337 5%
huwiki 479.215 170.936 36% 26.559 16%
euwiki 364.458 105.412 29% 21.481 20%
hywiki 278.487 96.729 35% 13.531 14%
arzwiki 1.171.440 759.418 65% 32.956 4%
srwiki 640.678 126.102 20% 27.326 22%
viwiki 1.259.538 867.672 69% 83.785 10%
cebwiki 5.377.763 1.357.405 25% 61.839 5%

MediaSearch

Như đã đề cập ở trên, nhóm Dữ liệu có cấu trúc đang khám phá sử dụng thuật toán MediaSearch để làm tăng độ bao phủ và sản sinh ra nhiều gợi ý hơn.

MediaSearch hoạt động bằng cách kết hợp tìm kiếm dựa trên văn bản truyền thống và dữ liệu có cấu trúc để cung cấp các kết quả liên quan cho các tìm kiếm theo một cách không biết trước ngôn ngữ. Bằng cách sử dụng các tuyên bố Wikidata được thêm vào hình ảnh thứ là một phần của Dữ liệu có cấu trúc trên Commons làm đầu vào xếp hạng tìm kiếm, MediaSearch có thể tận dụng tên riêng, các khái niệm liên quan, và nhãn ở nhiều ngôn ngữ khác nhau để làm tăng độ liên quan của gợi ý hình ảnh. Bạn có thể tìm hiểu thêm thông tin về cách MediaSearch hoạt động tại đây.

Tính đến tháng 2 năm 2021, nhóm hiện đang thử nghiệm cách để cung cấp một điểm số đáng tin cậy cho các gợi ý MediaSearch mà thuật toán gợi ý hình ảnh có thể sử dụng và quyết định liệu một gợi ý từ MediaSearch có đủ chất lượng để sử dụng trong nhiệm vụ gợi ý hình ảnh hay không. Chúng tôi muốn chắc chắn rằng người dùng thấy tự tin vào các gợi ý mà MediaSearch cung cấp trước khi cho chúng vào trong tính năng.

Nhóm Dữ liệu có cấu trúc cũng đang khám phá và lên nguyên mẫu một cách cho bot được tạo ra bởi người dùng để sử dụng các kết quả được tạo ra bởi cả thuật toán gợi ý hình ảnh và MediaSearch để tự động thêm hình ảnh vào bài viết. Đây sẽ là một thử nghiệm ở các wiki sử dụng bot nhiều, liên kết với các người viết bot cộng đồng. Bạn có thể tìm hiểu thêm về nỗ lực này hoặc bày tỏ hứng thú tham gia trong nhiệm vụ phabricator này.

Vào tháng 5 năm 2021, trong cùng một cuộc đánh giá được đề cập trong mục "Độ chính xác" ở trên, thuật toán MediaSearch được phát hiện có độ chính xác thấp hơn nhiều so với thuật toán khớp hình ảnh. Thuật toán khớp hình ảnh có độ chính xác khoảng 78%, trong khi đó MediaSearch là khoảng 38%. Do đó, nhóm Tăng trưởng không định sử dụng MediaSearch trong phiên bản thử đầu tiên của nhiệm vụ "thêm hình ảnh".

Câu hỏi và thảo luận

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?

Ghi chép từ cuộc thảo luận cộng đồng 2021-02-04

Bắt đầu từ Tháng 12 năm 2020, chúng tôi đã mời các thành viên cộng đồng nói chuyện về ý tưởng "thêm hình ảnh" trong năm ngôn ngữ (tiếng Anh, Bengali, Ả Rập, Việt, Séc). Cuộc thảo luận tiếng Anh chủ yếu diễn ra trên trang thảo luận ở đây, còn các cuộc nói chuyện bằng ngôn ngữ địa phương ở trên bốn trang Wikipedia khác. Chúng tôi đã lắng nghe từ 28 thành viên cộng đồng, và mục này tóm tắt một trong những suy nghĩ phổ biến và thú vị nhất. Những cuộc thảo luận này ảnh hưởng sâu sắc đến bộ thiết kế tiếp theo của chúng tôi.

  • Tổng thể: Thành viên cộng đồng nhìn chung tích cực một cách thận trọng về ý tưởng này. Nói cách khác, mọi người dường như đồng ý rằng việc sử dụng thuật toán để thêm hình ảnh vào Wikipedia là có giá trị, nhưng cũng có nhiều vấn đề tiềm năng với ý tưởng này, nhất là với người mới đến.
  • Thuật toán
    • Thành viên cộng đồng dường như thấy tự tin với thuật toán vì nó chỉ sử dụng đến các mối liên hệ được mã hóa vào Wikidata bởi những người dùng có kinh nghiệm, thay vì một dạng trí thông minh nhân tạo khó dự đoán nào đó.
    • Trong số ba nguồn cho thuật toán (Wikidata P18, liên kết liên wiki và thể loại Commons), mọi người đồng ý rằng thể loại Commons là cái yếu nhất (và Wikidata là cái mạnh nhất). Việc này đã được chứng minh ở trong cuộc thử nghiệm của chúng tôi, và có thể chúng tôi sẽ loại bỏ thể loại Commons trong các phiên bản thử tương lai.
    • Chúng tôi đã có lời khuyên hay ho về việc loại bỏ những trang cụ thể khỏi tính năng: trang đổi hướng, danh sách, năm, bài viết tốt và chọn lọc... Chúng tôi có thể cũng muốn loại bỏ trang tiểu sử người còn sống.
    • Chúng tôi cũng nên loại bỏ những hình ảnh có bản mẫu xóa trên Commons hoặc trước đó đã từng bị xóa khỏi trang Wikipedia.
  • Khả năng phán đoán của người mới đến
    • Thành viên cộng đồng nhìn chung lo ngại rằng người mới đến có thể đưa ra phán đoán tồi và quyết định tin tưởng vào thuật toán. Chúng tôi biết được từ các cuộc thử nghiệm người dùng rằng người mới đến có khả năng đưa ra phán đoán tốt, và chúng tôi tin rằng một thiết kế đúng đắn sẽ khuyến khích điều đó.
    • Trong việc thảo luận chiến dịch Trang Wikipedia Muốn Hình Ảnh, chúng tôi đã biết được rằng tuy nhiều người mới đến có khả năng đưa ra phán đoán tốt, một số người dùng quá tích cực có thể tạo ra nhiều sửa đổi gây hại trong một thời gian ngắn, khiến người tuần tra phải bận rộn. Chúng tôi có thể sẽ muốn thêm một dạng xác nhận nào đó để ngăn người dùng không thêm hình ảnh quá nhanh, hoặc tiếp tục thêm hình ảnh sau khi liên tục bị lùi sửa.
    • Hầu hết thành viên cộng đồng đồng ý rằng "độ liên quan" thì quan trọng hơn "chất lượng" khi xét liệu một hình ảnh có thuộc về bài viết hay không. Nói cách khác, nếu hình ảnh duy nhất của một người bị mờ thì thường vẫn tốt hơn là không có cái ảnh nào. Người mới đến cần phải được dạy về quy chuẩn này khi họ làm nhiệm vụ.
    • Giao diện của chúng tôi nên truyền tải được rằng người dùng nên tiến lên một cách chậm mà chắc, thay vì cố làm được càng nhiều gợi ý càng tốt.
    • Chúng tôi nên dạy người dùng rằng hình ảnh nên mang tính giáo dục, chứ không phải chỉ đơn thuần là để trang trí.
  • Giao diện người dùng
    • Một vài người đề xuất rằng chúng tôi nên cho người dùng thấy một số ứng cử viên hình ảnh để người dùng lựa chọn thay vì chỉ một hình ảnh. Việc này sẽ làm tăng khả năng hình ảnh phù hợp được gắn vào bài viết hơn.
    • Nhiều thành viên cộng đồng khuyến nghị rằng chúng tôi nên cho phép người mới đến chọn chủ đề họ quan tâm (đặc biệt là địa lý) với các bài viết họ đang làm nhiệm vụ. Nếu người mới đến chọn những lĩnh vực họ có kiến thức thì có thể họ sẽ đưa ra được những lựa chọn tốt hơn. May mắn là, việc này đã tự động là một phần của bất kỳ tính năng nào mà nhóm Tăng trưởng xây dựng, và chúng tôi vốn đã cho phép người dùng chọn giữa 64 lĩnh vực chủ đề khi chọn nhiệm vụ sửa đổi gợi ý.
    • Các thành viên cộng đồng gợi ý rằng người dùng mới nên nhìn thấy càng nhiều nội dung bài viết càng tốt, thay vì chỉ là một bản xe trước. Điều này sẽ giúp họ hiểu được tầm quan trọng của nhiệm vụ và có nhiều thông tin để sử dụng trong việc đưa ra đánh giá.
  • Vị trí đặt hình ảnh trong bài viết
    • Chúng tôi biết về các hộp thông tin Wikidata. Chúng tôi biết rằng với các wiki sử dụng chúng, cách được ưa thích hơn sẽ là thêm hình ảnh vào Wikidata thay vì vào bài viết để chúng có thể xuất hiện thông qua hộp thông tin Wikidata. Với nguồn cảm hứng này, chúng tôi sẽ nghiên cứu xem những hộp thông tin này phổ biến đến đâu trên những wiki khác nhau.
    • Nhìn chung, có vẻ như quy tắc "đặt hình ảnh dưới bản mẫu và trên nội dung" trong một bài viết sẽ có tác dụng trong hầu hết các trường hợp.
    • Một vài thành viên cộng đồng khuyên chúng tôi rằng kể cả nếu việc đặt hình ảnh trong bài viết không hoàn hảo thì những người dùng khác cũng sẽ vui vẻ sửa vị trí, vì công việc tìm kiếm hình ảnh phù hợp vất vả nhất đã được thực hiện rồi.
  • Người dùng không biết tiếng Anh
    • Các thành viên cộng đồng nhắc nhở chúng tôi rằng một số yếu tố metadata Commons có thể không thể biết ngôn ngữ, ví dụ như tuyên bố chú thích hình ảnh và miêu tả. Chúng tôi đã xem xét chính xác thì điều này phổ biến ra sao trong mục này.
    • 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.

Kế hoạch thử nghiệm người dùng

 
Ảnh chụp màn hình từ nguyên mẫu của một luồng công việc gợi ý hình ảnh, được sử dụng trong thử nghiệm người dùng. Người dùng có thể cuộn xuống để xem thêm dữ liệu meta về hình ảnh từ Commons.

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?

Design

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.
 
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.
 
Multiple: this design shows the user multiple potential matches, and they could compare them and choose the best one, or reject all of them.
 
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.

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.

 
Slides showing the full user test findings
  • 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.
Wiki Local language descripton Local language caption Depicts
enwiki 51.71% 3.65% 6.20%
trwiki 1.91% 1.32% 4.33%
bnwiki 0.51% 1.08% 5.74%
frwiki 5.95% 0.66% 8.52%
ruwiki 4.05% 0.61% 6.73%
fawiki 0.58% 0.59% 4.06%
arwiki 0.97% 0.59% 7.00%
dewiki 6.11% 0.49% 5.16%
ptwiki 1.38% 0.34% 4.27%
hewiki 1.20% 0.30% 6.18%
cswiki 1.82% 0.23% 5.71%
kowiki 0.97% 0.19% 4.80%
plwiki 1.82% 0.17% 5.93%
ukwiki 1.04% 0.12% 5.95%
svwiki 0.90% 0.07% 10.10%
huwiki 2.28% 0.03% 5.96%
euwiki 0.27% 0.03% 6.20%
hywiki 0.69% 0.03% 5.39%
arzwiki 0.02% 0.01% 6.84%
srwiki 0.36% 0.01% 3.46%
viwiki 0.08% 0.00% 6.63%
cebwiki 0.00% 0.00% 9.93%

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.

Background

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.

Results

The Android team released the app in May 2021, and over several weeks, thousands of users evaluated tens of thousands of image matches from the image matching algorithm. The resulting data allowed the Growth team to decide to proceed with Iteration 1 of the "add an image" task. In looking at the data, we were trying to answer two important questions around "Engagement" and "Efficacy".

Engagement: do users of all languages like this task and want to do it?

  • On average, users in the Android MVP did about 11 annotations each. While this is less than image descriptions and description translations, it is greater than the other four kinds of Android tasks.
  • Image matching edits showed a substantially lower retention rate than other kinds of Android suggested edits, but there are concerns that it’s not possible to calculate an apples-to-apples comparison. Further, we think that the fact that the edits from this MVP do not actually change the wikis would lead to lower retention, because users would be less motivated to return and do more.
  • With respect to language, data was collected for users in English Wikipedia as well as from users who exclusively use non-English Wikipedia, including large numbers of evaluations from German, Turkish, French, Portuguese, and Spanish Wikipedias. We expected English and non-English users to have quite different experiences, because the majority of metadata on images in Commons is in English. But metrics were remarkably similar across the two groups, including number of tasks completed, time spent on task, retention, and judgment. This bodes well for this task being usable across wikis, although it's likely that many of the non-English Android users are actually bilingual.

Efficacy: will resulting edits be of sufficient quality?

  • 80% of the matches for which newcomers said "yes" are actually good matches according to experts. This is an improvement of about 5 percentage points over the algorithm alone.
  • This number goes up to 82-83% when we remove newcomers who have very low median time for evaluations.
  • Experts tend to agree with each other only about 85% of the time.
  • Because newcomer accuracy goes up when certain kinds of newcomers are removed (those who evaluate too quickly or who accept too many suggestions), we think that automated “quality gates” could boost newcomer performance to levels acceptable by communities.

See the full results are here.

Engineering

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

Phiên bản thử 1

Vào tháng 7 năm 2021, nhóm Tăng trưởng đã quyết định sẽ tiến hành xây dựng phiên bản thử đầu tiên của nhiệm vụ "thêm hình ảnh" cho web. Đây là một quyết định khó khăn vì vẫn còn nhiều câu hỏi mở và rủi ro xoay quanh việc khuyến khích người mới đến thêm hình ảnh vào các bài viết Wikipedia. Nhưng sau khi trải qua một năm thông qua ý tưởng, và từ đó xem xét các cuộc thảo luận cộng đồng, đánh giá, thử nghiệm, và chứng minh khái niệm xoay quanh ý tưởng này, chúng tôi đã quyết định xây dựng phiên bản thử đầu tiên để có thể tiếp tục học hỏi. Dưới đây là một số phát hiện chính từ giai đoạn thông qua ý tưởng đã dẫn chúng tôi bước tiếp:

  • Sự ủng hộ từ cộng đồng một cách đầy thận trọng: các thành viên cộng đồng cảm thấy tích cực một cách thận trọng về nhiệm vụ này, đồng tình rằng nó sẽ có giá trị, nhưng cũng chỉ ra nhiều rủi ro và khó khăn không ngờ tới mà chúng tôi nghĩ chúng tôi có thể giải quyết với một thiết kế tốt.
  • Thuật toán chính xác: thuật toán khớp hình ảnh đã cho thấy độ chính xác 65-80% qua nhiều bài thử nghiệm khác nhau, và chúng tôi đã có thể cải tiến nó thêm qua thời gian.
  • Thử nghiệm người dùng: nhiều người mới đến đã trải nghiệm nguyên mẫu và thấy nhiệm vụ này vui và hấp dẫn.
  • Android MVP: các kết quả từ Android MVP cho thấy người mới đến nhìn chung có sự phán đoán tốt với các gợi ý, nhưng quan trọng hơn là, nó đã cho chúng tôi manh mối về việc phải cải thiện kết quả của chúng như thế nào trong các thiết kế của mình. Kết quả cũng gợi ý rằng nhiệm vụ có thể hoạt động tốt ở các ngôn ngữ khác nhau.
  • Hiểu biết chung: vì đã vấp phải nhiều rào cản qua những bước thông qua ý tưởng khác nhau, chúng tôi có thể đề phòng chúng trong các thiết kế sắp tới của mình. Công việc nền này đã mang lại cho chúng tôi nhiều ý tưởng về việc phải dẫn dắt người mới đến đến đưa ra phán đoán tốt như thế nào, và phải làm sao để tránh các sửa đổi gây hại.

Các giả thuyết

Chúng tôi không chắc chắn nhiệm vụ này sẽ hoạt động tốt -- đó là lý do tại sao chúng tôi lên kế hoạch xây dựng nó theo các phiên bản thử nhỏ để học hỏi dần dần. Chúng tôi "có" nghĩ rằng chúng tôi có thể sử dụng những hiểu biết cho đến thời điểm hiện tại để cố gắng xây dựng một phiên bản thử hạng nhẹ. Một cách để nghĩ về thứ chúng tôi đang làm với phiên bản thử của mình là thử nghiệm giả thuyết. Dưới đây là năm giả thuyết tích cực mà chúng tôi có về nhiệm vụ "thêm hình ảnh". Mục tiêu của chúng tôi với Phiên bản thử 1 sẽ là xem xem liệu những giả thuyết này có chính xác không.

  1. Chú thích hình ảnh: người dùng có thể viết chú thích hình ảnh thỏa đáng. Đây là câu hỏi mở lớn nhất của chúng tôi, vì hình ảnh được đặt vào các bài viết Wikipedia thường yêu cầu phải có chú thích, nhưng Android MVP không thử nghiệm khả năng viết chú thích của người mới đến.
  2. Tính hiệu quả: người mới đến có phán đoán đủ tốt để sửa đổi của họ được chấp nhận bởi cộng đồng.
  3. Mức độ thu hút: người dùng thích thực hiện nhiệm vụ này trên thiết bị di động, làm nhiều và quay lại để làm thêm nhiều hơn.
  4. Ngôn ngữ: người dùng không biết tiếng Anh sẽ có thể thực hiện nhiệm vụ này. Đây là một câu hỏi quan trọng, vì phần lớn metadata trên Commons là bằng tiếng Anh và điều quan trọng là người dùng phải đọc tên tệp, mô tả và chú thích từ Commons để tự tin xác nhận kết quả trùng khớp.
  5. Mô hình: mô hình thiết kế mà chúng tôi đã xây dựng cho "nhiệm vụ có cấu trúc thêm liên kết" sẽ mở rộng sang hình ảnh.

Phạm vi

Vì mục tiêu chính của chúng tôi với Phiên bản thử 1 là học hỏi, nên chúng tôi muốn có được trải nghiệm trước người dùng càng sớm càng tốt. Điều này có nghĩa là chúng tôi muốn giới hạn phạm vi của những gì mình xây dựng để có thể phát hành nó nhanh chóng. Dưới đây là những giới hạn phạm vi quan trọng nhất mà chúng tôi nghĩ rằng nên áp dụng cho Phiên bản thử 1.

  • Chỉ dành cho thiết bị di động: trong khi nhiều Wikimedian có kinh nghiệm hầu hết đều làm wiki từ máy tính để bàn/máy tính xách tay của họ thì những người mới đến đang gặp khó khăn trong việc đóng góp cho Wikipedia phần lớn lại sử dụng thiết bị di động và họ là đối tượng quan trọng hơn đối với nhóm Tăng trưởng. Nếu chúng tôi xây dựng Phiên bản thử 1 chỉ dành cho thiết bị di động, chúng tôi sẽ tập trung vào đối tượng đó đồng thời tiết kiệm được thời gian thiết kế và xây dựng cùng một luồng công việc cho máy tính để bàn/máy tính xách tay.
  • Đề xuất tĩnh: thay vì xây dựng một dịch vụ backend để liên tục chạy và cập nhật các gợi ý hình ảnh có sẵn bằng cách sử dụng thuật toán khớp hình ảnh, chúng tôi sẽ chạy thuật toán một lần và sử dụng tập hợp đề xuất tĩnh cho Phiên bản thử 1. Tuy điều này sẽ không cung cấp những hình ảnh mới nhất và dữ liệu mới nhất nhưng chúng tôi nghĩ rằng thế sẽ đủ cho việc học hỏi của chúng tôi.
  • Mô hình thêm liên kết: thiết kế của chúng tôi nói chung sẽ tuân theo các mô hình tương tự như thiết kế cho nhiệm vụ có cấu trúc trước đây của chúng tôi, "thêm liên kết".
  • Bài viết không có hình ảnh: chúng tôi sẽ giới hạn đề xuất của mình chỉ đối với các bài viết không có hình minh họa thay vì các bài viết đã có một số hình ảnh nhưng cần thêm. Điều này có nghĩa là luồng công việc của chúng tôi sẽ không cần phải bao gồm các bước để người mới chọn vị trí trong bài viết để đặt hình ảnh. Vì nó sẽ là hình ảnh duy nhất, nó có thể được giả sử là hình ảnh dẫn đầu ở đầu bài viết.
  • Không có hộp thông tin: chúng tôi sẽ giới hạn các gợi ý của mình chỉ cho các bài viết không có hộp thông tin. Đó là bởi vì nếu một bài viết không có hình ảnh hộp thông tin thì hình ảnh đầu tiên của nó thường phải được đặt trong hộp thông tin. Nhưng đó là một thách thức lớn về mặt kỹ thuật để đảm bảo rằng chúng tôi có thể xác định đúng hình ảnh và trường chú thích hình ảnh trong tất cả các hộp thông tin bằng nhiều ngôn ngữ. Điều này cũng tránh các bài viết có hộp thông tin Wikidata.
  • Một hình ảnh: mặc dù thuật toán khớp hình ảnh có thể đề xuất nhiều ứng cử viên hình ảnh cho một bài viết không có hình ảnh nhưng chúng tôi sẽ giới hạn Phiên bản thử 1 để chỉ đề xuất ứng viên có độ tin cậy cao nhất. Điều này sẽ mang lại trải nghiệm đơn giản hơn cho người mới đến cũng như nỗ lực thiết kế và kỹ thuật đơn giản hơn cho nhóm.
  • Cổng chất lượng: chúng tôi nghĩ rằng chúng tôi nên thêm một số loại cơ chế tự động để ngăn người dùng thực hiện một số lượng lớn các sửa đổi gây hại trong một thời gian ngắn. Các ý tưởng xung quanh vấn đề này bao gồm (a) giới hạn người dùng ở một số lần chỉnh sửa "thêm hình ảnh" nhất định mỗi ngày, (b) cung cấp cho người dùng hướng dẫn bổ sung nếu họ dành quá ít thời gian cho mỗi đề xuất, (c) cung cấp cho người dùng hướng dẫn bổ sung nếu họ có vẻ đang chấp nhận quá nhiều hình ảnh. Ý tưởng này được lấy cảm hứng từ trải nghiệm năm 2021 của Wikipedia tiếng Anh với chiến dịch Bài Viết Wikipedia Muốn Có Ảnh.
  • Wiki thử nghiệm: như với tất cả các phát triển mới của nhóm Tăng trưởng, trước tiên chúng tôi sẽ triển khai chỉ cho bốn wiki thử nghiệm của chúng tôi là Wikipedia tiếng Ả Rập, tiếng Việt, tiếng Bengali và tiếng Séc. Đây là những cộng đồng theo sát các dự án Tăng trưởng và nhận thức được rằng họ là một phần của các thử nghiệm. Nhóm Tăng trưởng sử dụng các đại sứ cộng đồng để giúp trao đổi nhanh chóng với các cộng đồng đó. Chúng tôi có thể thêm Wikipedia tiếng Tây Ban Nha và Bồ Đào Nha vào danh sách trong năm tới.

Chúng tôi rất mong lắng nghe ý kiến của các thành viên cộng đồng về việc liệu những lựa chọn phạm vi như trên đã tốt chưa, và liệu có cái nào nghe giống như sẽ giới hạn việc học hỏi của chúng tôi trong Phiên bản thử 1 hay không.

Thiết kế

Mockup và nguyên mẫu

Xây dựng trên nền các thiết kế từ các cuộc thử nghiệm người dùng trước đây và trên Android MVP, chúng tôi đang cân nhắc nhiều khái niệm thiết kế khác nhau cho Phiên bản thử 1. Với mỗi phần trong số năm phần của luồng công việc người dùng, chúng tôi có hai lựa chọn. Chúng tôi muốn thử nghiệm người dùng cả hai để thu thập thông tin từ người mới đến. Chúng tôi cũng hy vọng các thành viên cộng đồng có thể cân nhắc chúng và cho chúng tôi ý kiến tại trang thảo luận. For each of five parts of the user flow, we have two alternatives. We'll user test both to gain information from newcomers. Our user tests will take place in English and Spanish -- our team's first time testing in a non-English language. We also hope community members can consider the designs and provide their thoughts on the talk page.

Prototypes for user testing

The easiest way to experience what we're considering to build is through the interactive prototypes. We've built prototypes for both the "Concept A" and "Concept B" designs, and they are available in both English and Spanish. These are not actual wiki software, but rather a simulation of it. That means that no edits are actually saved, and not all the buttons and interactions work -- but the most important ones relevant to the "add an image" project do work.

Mô hình

Bên dưới là các hình ảnh tĩnh của mô hình, nhưng các thành viên cộng đồng có thể khám phá tập tin Figma của nhà thiết nhóm Tăng trưởng, thứ chứa đựng các mô hình bên dưới ở phía dưới bên phải khung, cũng như những thông điệp truyền tải cảm hứng và ghi chú khác dẫn tới các mô hình này.

Nguồn cấp dữ liệu

Những thiết kế này liên kết tới phần đầu tiên của luồng công việc, tại đó người dùng sẽ chọn một bài viết để làm việc từ nguồn cấp dữ liệu sửa đổi gợi ý. Chúng tôi muốn các thẻ phải hấp dẫn nhưng cũng không gây bối rối cho người dùng.

Onboarding

Những thiết kế này liên quan tới những gì mà người dùng nhìn thấy sau khi mở lên nhiệm vụ đầu tiên, dùng để giải thích nhiệm vụ này là gì và như thế nào để làm tốt. Chúng tôi muốn người dùng hiểu được rằng việc thêm hình ảnh là một sửa đổi có kết quả và cần được cân nhắc nghiêm túc. Lưu ý là câu chữ vẫn chưa được thiết kế cẩn thận -- thay vào đó, hiện tại chúng tôi đang suy nghĩ về trải nghiệm khi chúng tôi truyền tải nội dung này.

Thêm hình ảnh

Những thiết kế này liên quan tới phần luồng công việc mà tại đó người dùng nhìn thấy hình ảnh gợi ý, dữ liệu meta của nó từ Commons, và quyết định xem có thêm nó vào bài viết hay không. Từ các cuộc thử nghiệm người dùng, chúng tôi biết được rằng việc người dùng đọc tiêu đề hình ảnh, mô tả trên Commons, và chú thích hình ảnh trên Commons để có thể đưa ra quyết định này một cách chính xác là hết sức quan trọng. Đây là phần thử thách của thiết kế: khiến tất cả thông tin đều có mặt trên màn hình điện thoại. We know from user tests that it is important for the user to read the image title, Commons description, and Commons caption in order to make this decision correctly. This is a challenging part of the design: making all that information available on the mobile screen.

Chú thích và xuất bản

Những thiết kế này liên quan tới phần luồng công việc sau khi người dùng đã quyết định thêm hình ảnh vào bài, và giờ họ sẽ viết một chú thích cho hình ảnh đó. Đây có thể là phần thách thức nhất đối với người mới đến, và chúng tôi vẫn đang suy nghĩ cách làm thế nào để giúp họ hiểu kiểu chú thích nào thì thích hợp.

Từ chối

Khi người dùng từ chối một gợi ý, chúng tôi muốn thu thập dữ liệu về lý do tại sao gợi ý lại sai để có thể cải thiện thuật toán. Đây cũng là một cơ hội để tiếp tục nhắc nhở người dùng về các tiêu chí đánh giá mà họ nên sử dụng khi đánh giá hình ảnh.

User test results September 2021

In August 2021, we ran 32 user tests amongst people who were new to Wikipedia editing, using respondents from usertesting.com. Half the respondents walked through Concept A and half through Concept B. In order to represent more diverse perspectives, this was the first time that the Growth team ran user tests outside of English: 11 respondents took the test in Spanish, all of whom were located outside the United States. This will help us make sure we're building a feature that is valuable and understandable for populations around the world.

Our goals for the testing were to identify which parts of the design concepts worked best, and to surface any other potential improvements. These are our main findings and changes to the designs we plan to make.

  • Findings
    • Concept B clearly performed better for participants in both English and Spanish tests, particularly:
      • Better understanding of the task. In Concept A, users sometimes thought the image was already in the article, because of its preview on the suggested edit card and the preview in the article.
      • More careful engagement and consideration of article contents and image metadata when evaluating image suitability to an article. We suspect this is because the article and metadata areas were clearly separated.
      • Greater use of image details and article contents during caption composition. The Concept B caption experience shows the full article text.
    • Other notes
      • Most people misunderstood the task initially as uploading images when they opened the Suggested edits module, regardless of design. But expectation about self-sourcing images was immediately corrected for almost all participants as soon as they opened the task, and overall, Design B evoked better task comprehension and successful image evaluation than Design A.
      • Newcomers would benefit from more user education around Commons and use of images on Wikipedia articles in their understanding of the broader editing ecosystem of Wikipedia and its sister projects.
      • Users understood the purpose of the caption, and understood that it would be displayed with the image in the Wikipedia article.
      • Spanish participants were far more interwiki-attuned than English participants. Potentially explore ways to better cater to multilingual/cross-wiki users.
      • Spanish participants needed to translate Commons metadata to themselves in order to write good captions in Spanish.
      • The current task requires several different skills, such as image evaluation, caption writing, and translation (for reading Commons metadata from a non-English Wikipedia). There may be benefits and opportunities for separating out this task into multiple tasks in future so that users don't have to have all the skills in order to complete the task.
  • Changes
    • Do not show a preview of the suggested image on the card in the suggested edits feed.
    • The onboarding tooltips worked well to help users understand the task. But they could be overwhelming or cluttering for smaller screens. Though we prefer to implement tooltips, we have decided to implement fullscreen overlays for onboarding in Iteration 1, because tooltips will take a substantially longer time to engineer well. We may implement tooltips in a future iteration.
    • Image and image metadata need to be next to each other -- when they are in separate parts of the screen, users become confused.
    • Because it is very important that users consider image metadata when making their decision and writing the caption, we need to increase the visibility of the metadata with clearer calls to read it.
    • Include simple validation on the free-text caption, such as enforcing a minimum length for captions, or not allowing the filename to be part of the caption.
    • Provide samples of good and bad captions in the explanation for the caption step.
    • When users reject a suggestion and give the reason for the rejection, some of the reasons should not remove the suggestion from the queue, e.g. "I do not know this topic". Perhaps another user will be able to confidently make the match.
  • Example captions: below are three image/article pairings used in the test and the actual captions written by user testers. This gives us a sense of the sorts of captions we can expect from newcomers. They all seem to be generally on the right track, though they range from more like "alt text" to more like captions. There are also a couple that miss the mark.

Final designs for Iteration 1

Based on the user test findings above, we created the set of designs that we are implementing for Iteration 1. The best way to explore those designs is here in the Figma file, which always contains the latest version.

Measurement

Leading indicators

Whenever we deploy new features, we define a set of "leading indicators" that we will keep track of during the early stages of the experiment. These help us quickly identify if the feature is generally behaving as expected and allow us to notice if it is causing any damage to the wikis. Each leading indicator comes with a plan of action in case the defined threshold is reached, so that the team knows what to do.

Indicator Plan of Action
Revert rate This suggests that the community finds the "add an image" edits to be unconstructive. If the revert rate for "add an image" is substantially higher than that of unstructured tasks, we will analyze the reverts in order to understand what causes this increase, then adjust the task in order to reduce the likelihood of edits being reverted.
User rejection rate This can indicate that we are suggesting a lot of images that are not good matches. If the rejection rate is above 40%, we will QA the image suggestion algorithm and adjust thresholds or make changes to improve the quality of the recommendations.
Over-acceptance rate This might indicate that some users aren't actually applying judgment to their tasks, meaning we might want to implement different quality gates. (What percentage of users who have a complete session have never rejected or skipped an image? What percentage of users who have five or more complete sessions have never rejected or skipped an image? How many sessions across all users contained only acceptances?)
Task completion rate This might indicate that there’s an issue with the editing workflow. If the proportion of users who start the "add an image" task and complete it is lower than 55% (completion rate for "add a link"), we investigate where in the workflow users leave and deploy design changes to enable them to continue.

We collected data on usage of "add an image" from deployment on November 29, 2021 until December 14, 2021. "Add an image" has only been made available on the mobile website, and is given to a random 50% of registrations on that platform (excluding our 20% overall control group). We therefore focus on mobile users registered after deployment. This dataset excluded known test accounts, and does not contain data from users who block event logging (e.g. through their ad blocker).

Overall: The most notable thing about the leading indicator data is how few edits have been completed so far: only 89 edits over the first two weeks. Over the first two weeks of "add a link", almost 300 edits were made. That feature was deployed to both desktop and mobile users, but that alone is not enough to make up the difference. The leading indicators below give some clues. For instance, task completion rate is notably low. We also notice that people do not do many of these tasks in a row, whereas with "add a link", users do dozens in a row. This is a prime area for future investigation.

Revert rate: We use edit tags to identify edits and reverts, and reverts have to be done within 48 hours of the edit. The latter is in line with common practices for reverts.

Task type N edits N reverts Revert rate
Add an image 69 13 18,8%
Add a link 209 4 1,9%
Copyedit 93 19 20,4%

The "add an image" revert rate is comparable to the copyedit revert rate, and it’s significantly higher than "add a link" (using a test of proportions). Because "add an image" has a comparable revert rate to unstructured tasks, the threshold described in the leading indicator table is not met, and we do not have cause for alarm. That said, we are still looking into why reverts are occurring in order to make improvements. One issue we've noticed so far is a large number of users saving edits from outside the "add an image" workflow. They can do this by toggling to the visual editor, but it is happening so much more often than for "add a link" that we think there is something confusing about the "caption" step that is causing users to wander outside of it.

Rejection rate: We define an edit “session” as reaching the edit summary dialogue or the skip dialogue, at which point we count whether the recommended image was accepted, rejected, or skipped. Users can reach this dialogue multiple times, because we think that choosing to go back and review an image or edit the caption is a reasonable choice.

N accepted % N rejected % N skipped % N total
53 41,7 38 29,9 36 28,3 127

The threshold in the leading indicator table was a rejection rate of 40%, and this threshold has not been met. This means that users are rejecting suggestions at about the same rate as we expected, and we don't have reason to believe the algorithm is underperforming.

Over-acceptance rate: We reuse the concept of an "edit session" from the rejection rate analysis, and count the number of users who only have sessions where they accepted the image. In order to understand whether these users make many edits, we measure this for all users as well as for those with multiple edit sessions and five or more edit sessions. In the table below, the "N total" column shows the total number of users with that number of edit sessions, and "N accepted all" the number of users who only have edit sessions where they accepted all suggested images.

Edits N total N accepted all %
≥1 edit 97 34 35,1
≥2 edits 21 8 38,1
≥5 edits 0 0 0,0

It is clear that over-acceptance is not an issue in this dataset, because there are no users who have 5 or more completed image edits, and for those who have more than one, 38% of the users accepted all their suggestions. This is in the expected range, given that the algorithm is expected usually to make good suggestions.

Task completion rate: We define "starting a task" as having an impression of "machine suggestions mode". In other words, the user is loading the editor with an "add an image" task. Completing a task is defined as clicking to save the edit, or confirming that you skipped the suggested image.

N Started a Task N Completed 1+ Tasks %
313 96 30,7

The threshold defined in the leading indicator table is "lower than 55%", and this threshold has been met. This means we are concerned about why users do not make their way through the whole workflow, and we want to understand where they get stuck or drop out.

"Add an image" to a Section

 
Section-level "add an image" suggestion

On wikis where it is deployed, newcomers have access to the “add an image” structured task from their Newcomer homepage. The existing "add an image" task suggests article-level image suggestions for entirely unillustrated articles. The image is then added to the article's lead section to help illustrate the article's concept as a whole.

 
Caption onboarding for the section-level "add an image" task

There will be onboarding for the task, followed by a specific suggestion (that includes the reason why the image is suggested). If the newcomer decides the image is a good fit for the article's section, then they receive guidance on caption writing. The structured task provides image details, further caption writing help if needed, and then prompts the newcomer to review and publish the edit.

A partnership with the Structured Data team

The Growth team is partnering with the Structured Data team to work on a section-level variation of the “add an image” task.

This is one aspect of the Structured Data Across Wikipedia project. This new task will provide image suggestions that are relevant to a particular section within an article. This section-level image suggestion task will be considered a more difficult task that will only be suggested to newcomers who are successful at the current article-level “add an image” task.

Read more about the Structured Data Across Wikimedia team’s work here: Section-level image suggestions .

Hypotheses

  • Structured editing experience will lower the barrier to entry and thereby engage more newcomers, and more kinds of newcomers than an unstructured experience.  
  • Newcomers with the workflow will complete more edits in their first session, and be more likely to return to complete more.
  • Adding a new type of “add an image” task will increase the number of image suggestions available for each language.

Scope

Key deliverable: completion of the Section-Level Images (newcomer structured task) Epic (T321754).

Design

Screenshots from two mobile designs can be seen on the right. Section-level "add an image" designs are visible in this Figma file.

User testing

Initial user testing of designs was completed in April 2023 in English. Six testers were given instructions, asked to experiment with this section-level design prototype, and evaluate the easiness and enjoyableness of the task. Testers ranged in age from 18 to 55, were from 5 different countries, and most had not previously edited Wikipedia. Three of the testers were male, and three were female. They were asked to review two image suggestions, one was a "good" image suggestion and one was a "bad" image suggestion.

Some key take-aways from the user testing:

  • The onboarding was understood by all participants: “Clear, easy to understand, straightforward.
  • Participants seemed to understand the task and that they needed to focus on the section when making their decision. One participant accepted a "bad" image suggestion:
    • 2/6 participants accepted the "good" image suggestion (3 rejected the image, 1 participant skipped it).
    • 5/6 participants rejected the "bad" image suggestion.
      • Note: the algorithm that powers image suggestions should provide more "good" suggestions than "bad" suggestions, but the algorithm isn't perfect, which is why this task needs human review and is suitable for new editors.
  • Some participants mentioned wanting more than one image to review per section:One suggestion is not enough, maybe you can present more images to choose from so I can select the most appropriate image.

Algorithm evaluation

The Growth team aims to ensure structured tasks for newcomers provide suggestions to newcomers that are accurate at least 70% of the time. We have conducted several rounds of evaluation to review the accuracy of the image suggestion algorithm.

In the initial evaluation, suggestions were still fairly inaccurate (T316151). Many images were suggested in sections that shouldn't have images, or the image related to one topic in the section but didn't represent the section as a whole. Based on feedback from this evaluation, the Structured Data team continued to work on logic and filtering improvements to ensure suggestions were more accurate (T311814).

In the second evaluation, on average, suggestions were much better (T330784). Of course results varied widely by language, but the average accuracy was fairly high for many wikis. However, there are some wikis in which the suggestions are still not good enough to present to newcomers, unless we only utilized the "good intersection" suggestions. That would severely limit the number of image suggestions available, so we are looking instead at increasing the confidence score of the suggestions we provide.

wiki % good alignment % good intersection % good p18/p373/lead image total rated suggestions
arwiki 71 91 54 511
bnwiki 28 86 26 204
cswiki 41 77 23 128
enwiki 76 96 75 75
eswiki 60 67 48 549
frwiki N.A. N.A. 100 3
idwiki 66 81 37 315
ptwiki 92 100 84 85
ruwiki 73 89 69 250
overall 64 86 57 2,120

It's good to note that this task will be Community configurable via Special:EditGrowthConfig. We hope to improve the task to the point that it can work well on all wikis, but communities will ultimately decide if this task is a good fit and should remain enabled.

Community consultation

A discussion with Growth pilot wikis is planned for May 2023 (T332530). We will post designs, plans, and questions at Arabic Wikipedia, Bengali Wikipedia, Czech Wikipedia, Spanish Wikipedia, as well as share further details here on MediaWiki.

Measurement

We decided to not deploy this feature in an A/B test and instead allow users to opt in to using it through the task selection dialogue on the Newcomer Homepage, or through the "Try a new task" post-edit dialogue that's part of the Levelling Up features. This meant that we focused on measuring a set of leading indicators to understand if the task was performing well. More details about this can be found in T332344.

We pulled data from Growth's KPI Grafana board from 2023-07-31 to 2023-08-28 (available here) for Section-Level and Article-Level suggestions. This timeframe was chosen because it should not be as much affected by the June/July slump in activity that we often see on the wikis. The end date is limited by the team shutting off image suggestions in late August (see T345188 for more information). This data range covers four whole weeks of data. While this dataset does not allow us to separate it by platform (desktop and mobile web), nor does it allow us more fine-grained user filtering, it was easily available and provides us with a reasonably good picture that's sufficient for this kind of analysis at this time. Using this dataset we get the overview of task activity shown in Table 1.

Table 1: Task clicks, completions, and reverts by task type.
Task type Task clicks Saved edits Reverts Task completion rate Revert rate
Section-level 1.149 688 60 58,1% 9,0%
Article-level 6.800 2.414 105 35,5% 4,3%

We see from the table that the task completion rate for section-level image suggestions is high, on par with Add a Link (ref) when that was released. This is likely because the section-level task is something users either choose themselves in the task selection dialogue, or choose to try out after being asked through the "Try a new task" dialogue that's part of Levelling Up. Those users are therefore likely already experienced editors and don't have too many issues with completing this task.

The revert rate for the section-level task is higher than the article-level task. We don't think this difference is cause for concern for two reasons. First, it might be harder to agree that an article is clearly improved by adding a section-level image compared to adding an article-level image. Secondly, articles suggested for section-level images already have a lead image, which might mean that they're also longer and have more contributors scrutinizing the edit.