Growth/Personalized first day/Structured tasks/Add an image/Idea validation/hu

2020 júniusától 2021 júliusáig a Növekedési csapat közösségi megbeszéléseken, háttérkutatáson, értékeléseken és koncepcióbizonylatokon dolgozott a a "kép hozzáadása" feladat körül. Ez vezetett ahhoz a döntéshez, hogy 2021 augusztusában elkezdjük az első iterációnk építését (lásd Iteration 1). ''Ez a szakasz tartalmazza az 1. iterációhoz vezető háttérmunkát.''

Algoritmus
Az, hogy képesek vagyunk-e strukturált feladatot készíteni a képek hozzáadására, attól függ, hogy tudunk-e olyan algoritmust létrehozni, mely kellően jó ajánlásokat generál. Semmiképpen sem szeretnénk arra ösztönözni a kezdőket, hogy rossz képeket adjanak hozzá a szócikkekhez, ami munkát okozna a járőröknek, hogy utánuk takarítsanak. Ezért az egyik első dolog, amin dolgozunk, hogy megpróbáljuk kideríteni, tudunk-e jó algoritmust készíteni.

Logika
Együtt dolgoztunk a Wikimédia kutatócsoporttal, és eddig egy olyan algoritmust teszteltünk, ami a pontosságot és az emberi megítélést helyezi előtérbe. Ahelyett, hogy bármilyen számítógépes látásmódot használna, ami váratlan eredményeket hozhat, egyszerűen csak a Wikidata meglévő információit összesíti, a tapasztalt szerkesztők által létrehozott kapcsolatokra támaszkodva. Ez a három fő módja annak, hogy a nem illusztrált szócikkekhez találatokat javasol:


 * Nézd meg a szócikkhez tartozó Wikidata-elemet. Ha van kép (P18), válaszd ki azt a képet.
 * Nézd meg a szócikk Wikidata-elemét. Ha van hozzá Commons kategória (P373), válassz egy képet a kategóriából.
 * Nézd meg az ugyanerről a témáról szóló szócikkeket más nyelvű Wikipédiákon. Válassz egy vezető képet ezekből a szócikkekből.

Az algoritmus olyan logikát is tartalmaz, mely például kizárja azokat a képeket, amik valószínűleg ikonok, vagy a szócikkben egy navbox részeként vannak jelen.

Pontosság
2021 augusztusától kezdve az algoritmus három tesztelési körön ment keresztül, minden alkalommal hat nyelv szócikkeit vizsgáltuk: Angol, francia, arab, vietnámi, cseh és koreai nyelven. Az értékeléseket csapatunk nagykövetei és más szakértő wikimédiások végezték, akik anyanyelvi beszélők a tesztelt nyelveken.

Az első két értékelés

Az egyes nyelvek 50 javasolt találatát megvizsgálva átnéztük és az alábbi csoportokba soroltuk azokat:

Az ilyen algoritmusokkal kapcsolatos munka során mindig felmerül a kérdés: mennyire kell pontosnak lennie? Ha a találatok 75%-a jó, az elégséges? Kell-e 90%-os pontosságúnak lennie? Vagy lehet akár 50%-os pontosságú is? Ez attól függ, hogy az algoritmust használó kezdők mennyire jó ítélőképességűek, és mennyi türelemmel rendelkeznek a gyenge találatokhoz. Erről többet fogunk megtudni, amikor az algoritmust valódi kezdőkkel teszteljük.

Az első értékelés során a legfontosabb az, hogy sok olyan egyszerű javítást találtunk az algoritmuson, melyeket könnyen el lehet végezni, például a kizárandó szócikkek és képek típusait illetően. Még e fejlesztések nélkül is a találatok körülbelül 20-40%-a volt "2s", vagyis a szócikkhez nagyszerűen illeszkedett (a wikitől függően). Az első értékelés teljes eredményeit és jegyzeteit itt találod.

A második értékelésnél számos javítás beépítésre került, és a pontosság nőtt. A találatok 50-70%-a volt "2s" (a wikitől függően). A pontosság növelése azonban csökkentheti a lefedettséget, azaz azon szócikkek számát, amelyekre találatokat tudunk találni. Konzervatív kritériumokat használva az algoritmus csak tízezer találatot tud javasolni egy adott wikiben, még akkor is, ha az adott wikinek több százezer vagy millió szócikke létezik. Úgy gondoljuk, hogy ez a fajta mennyiség elegendő lenne a funkció kezdeti változatának elkészítéséhez. A második értékelés teljes eredményeit és jegyzeteit itt olvashatod.

Harmadik értékelés

2021 májusában a Struktúrált Data csapata egy sokkal nagyobb léptékű tesztet végzett a képillesztési algoritmus (és a MediaSearch algoritmus) arab, cebuanói, angol, vietnámi, bengáli és cseh Wikipédiákon. E teszt során a képillesztési algoritmus és a MediaSearch mintegy 500 találatát értékelték az egyes nyelvek szakértői, akik "Jó", "Oké" vagy "Rossz" találatoknak minősítették azokat. Az alábbiakban részletezett eredmények ezeket mutatják:


 * A képillesztési algoritmus pontossága 65-80% között mozog attól függően, hogy "Jó"-nak vagy "Jó+Oké"-nak számít-e, és a wikitől/értékelőtől függően. Érdekes módon a képillesztések kiértékelésével kapcsolatos tapasztalataink szerint a szakértő wikimédiások gyakran nem értenek egyet egymással, mert mindenkinek saját mércéje van arról, hogy a képeknek helye van-e a szócikkekben.
 * A Wikidata P18 ("Wikidata") a legerősebb egyezésforrás, 85%-95%-os pontossággal. A más Wikipédiákból ("Wikiközii") és a Wikidata-elemekhez csatolt Commons-kategóriákból ("Commons-kategória") származó képek hasonló mértékben kevésbé pontosak.
 * A más Wikipédiákból származó képek ("wikiközi") a leggyakoribb találati forrás. Más szóval, ezekből több áll az algoritmus rendelkezésére, mint a másik két forrásból.

Az eredmények teljes adatkészlete itt található.

Lefedettség
Az algoritmus pontossága egyértelműen nagyon fontos összetevő. Ugyanilyen fontos a "lefedettség" is -- ez arra utal, hogy hány képet tud egyeztetni. A pontosság és a lefedettség általában fordítottan arányos: minél pontosabb egy algoritmus, annál kevesebb javaslatot tesz (mivel csak akkor tesz javaslatot, ha biztos a dolgában). Ezekre a kérdésekre kell válaszolnunk: képes-e az algoritmus annyi találatot adni, hogy érdemes legyen vele egy funkciót építeni? Lényeges hatást tudna-e gyakorolni a wikire? Megnéztünk 22 Wikipédiát, hogy képet kapjunk a válaszokról. Az összefoglaló pontok alatt található a táblázat:


 * A táblázatban szereplő lefedettségi számok elegendőnek tűnnek egy "kép hozzáadása" funkció első verziójához. Minden egyes wikiben elég jelölt találat van ahhoz, hogy (a) a szerkesztők ne fogyjanak ki, és (b) egy funkció jelentős hatást gyakorolhasson egy wiki illusztráltságára.
 * A wikik a 20%-os illusztrálatlanság (szerb) és a 69%-os illusztrálatlanság (vietnámi) között mozognak.
 * 7000 (bengáli) és 155000 (angol) között találunk illusztrálatlan cikkeket megfelelő jelöltekkel. Általánosságban elmondható, hogy ez a feladat első verziójához elegendő mennyiség, így a szerkesztőknek bőven van mit keresniük a találatok között. Néhány ritkább wikinél, mint például a bengáli, ez a szám kis számokba kerülhet, amint a szerkesztők leszűkítik az őket érdeklő témákat. Ennek ellenére a bengáliban csak körülbelül 100 000 cikk van összesen, tehát ezek 7%-ára javasolnánk találatokat, ami jelentős.
 * Ami azt illeti, hogy mekkora javulást érhetünk el a wikik illusztrációiban ezzel az algoritmussal, a plafon 1% (cebwiki) és 9% (trwiki) között mozog. Ez a további szócikkek teljes százalékos aránya, amely illusztrációkkal egészülne ki, ha minden egyezés jó lenne, és hozzáadnánk a wikihez.
 * Az arzwiki és a cebwiki a wikik, ahol a legalacsonyabb az illusztrálatlan cikkek aránya, melyekhez találunk találatokat, mivel mindkettőnek nagy a botok által létrehozott szócikkek száma. Ennek azért van értelme, mert ezek közül a szócikkek közül sok olyan konkrét városokról vagy fajokról szól, melyekhez a Commonsban nincs kép. De mivel ezekben a wikikben nagyon sok szócikk található, még mindig több tízezer olyan szócikk van, melyre az algoritmusnak van találata.
 * A távolabbi jövőben reméljük, hogy a képillesztési algoritmus, a MediaSearch vagy a képek feltöltésére/feliratozására/megjelölésére vonatkozó munkafolyamatok fejlesztése több találatot eredményez.

MediaSearch
Amint arról már szó volt, a strukturált adatokkal foglalkozó csoport vizsgálja a MediaSearch algoritmus használatát a lefedettség növelése és több találati lehetőség biztosítása érdekében.

A MediaSearch a hagyományos szövegalapú keresés és a strukturált adatok kombinálásával működik, hogy nyelvfüggetlen módon releváns találatokat adjon a keresésekhez. A Strukturált Data a Commonson részeként a képekhez hozzáadott Wikidata állítások keresési rangsorolási bemenetként való felhasználásával a MediaSearch képes kihasználni az aliasokat, a kapcsolódó fogalmakat és a többnyelvű címkéket, hogy növelje a képek találatainak relevanciáját. A MediaSearch működéséről további információkat itt találhatsz.

2021 februárjától a csapat jelenleg kísérletezik azzal, hogyan lehet a MediaSearch találatokhoz egy olyan megbízhatósági pontszámot biztosítani, melyet a képajánló algoritmus felhasználhat, és amely alapján eldönthető, hogy a MediaSearch általi találat megfelelő minőségű-e a képmegfeleltetési feladatokban való felhasználáshoz. Biztosak akarunk lenni abban, hogy a szerkesztők bíznak a MediaSearch által adott ajánlásokban, mielőtt beépítenénk azokat a funkcióba.

A strukturált adatokkal foglalkozó csapat azt is vizsgálja és prototípust készít, hogy a szerkesztők által generált botok hogyan használhatják a képajánló algoritmus és a MediaSearch által generált eredményeket arra, hogy automatikusan képeket adjanak hozzá a szócikkekhez. Ez egy kísérlet lesz a botoktól hemzsegő wikikben, a közösségi bot-írókkal együttműködve. Többet megtudhatsz erről az igyekezetről, vagy kifejezheted érdeklődésedet a phabricator feladatban való részvétel iránt.

2021 májusában a fenti a "Pontosság" szakaszban idézett értékelésben a MediaSearch jóval kevésbé pontosnak bizonyult, mint a képegyeztető algoritmus Míg a képegyeztető algoritmus kb. 78%-os pontosságú volt, addig a MediaSearch találatai kb. 38%-os pontosságúak lettek. Ezért a növekedési csapat nem tervezi a MediaSearch használatát a "kép hozzáadása" feladat első iterációjában.



Kérdések és megbeszélés


Nyitott kérdések
A képek fontos és látható részét képezik a Wikipédia-élménynek. Nagyon fontos, hogy alaposan átgondoljuk, hogyan működne egy olyan funkció, amely lehetővé tenné a képek egyszerű hozzáadását, mik lennének a lehetséges buktatók, és milyen következményekkel járna a közösség tagjai számára. E célból sok nyitott kérdésünk van, és szeretnénk hallani a közösség tagjainak további felvetéseiről.


 * Elég pontos lesz-e az algoritmusunk ahhoz, hogy sok jó találatot adjunk?
 * Milyen metaadatokra van szükségük a kezdőknek a Commonsból és a kép nélküli szócikkből ahhoz, hogy dönteni tudjanak a kép hozzáadásáról?
 * A kezdők kellően jó ítélőképességgel rendelkeznek-e majd az ajánlások áttekintésekor?
 * Azok a kezdők, akik nem olvasnak angolul, ugyanolyan jól tudnak majd dönteni, mivel a Commons metaadatainak nagy része angolul van?
 * Képesek lesznek-e az új felhasználók jó képaláírásokat írni a szócikkekbe helyezett képek mellé?
 * Mennyire kell a kezdőknek a képeket a "minőségük" alapján megítélniük, szemben a "relevanciájukkal"?
 * Érdekesnek fogják-e tartani ezt a feladatot a kezdők? Szórakoztatónak? Nehéznek? Könnyűnek? Unalmasnak?
 * Pontosan hogyan határozzuk meg, hogy mely szócikkekben nincsenek képek?
 * A kép nélküli szócikkben hol kell elhelyezni a képet? Elég, ha a cikk elejére kerül?
 * Hogyan tudunk figyelni az ajánlások esetleges torzítására, azaz lehet, hogy az algoritmus sokkal több találatot ad az európai és észak-amerikai témákhoz.
 * Vajon egy ilyen munkafolyamat vektora lesz a vandalizmusnak? Hogyan lehet ezt megakadályozni?



Megjegyzések a közösségi megbeszélésekből 2021-02-04
2020 decemberétől kezdve öt nyelven (angol, bengáli, arab, vietnámi, cseh) meghívtuk a közösség tagjait, hogy beszélgessenek a "kép hozzáadása" ötletről. Az angol nyelvű megbeszélések többnyire az itteni vitalapon zajlottak, a helyi nyelvű beszélgetések pedig a másik négy Wikipédián. A közösség 28 tagjától hallhattunk véleményt, és ez a rész a legnépszerűbb és legérdekesebb gondolatokat foglalja össze. Ezek a beszélgetések nagyban befolyásolják a következő tervezési sorozatunkat.


 * Általános - a közösség tagjai általában körültekintően optimisták ezzel az ötlettel kapcsolatban. Más szóval, úgy tűnik, az emberek egyetértenek abban, hogy értékes lenne algoritmusok segítségével képeket hozzáadni a Wikipédiához, de hogy sok lehetséges buktató és mód van arra, hogy ez rosszul sülhet el, különösen a kezdők esetében.
 * Algoritmus
 * Úgy tűnt, hogy a közösség tagjai bíznak az algoritmusban, mivel az csak a tapasztalt felhasználók által a Wikidatába kódolt asszociációkra támaszkodik, nem pedig valamiféle kiszámíthatatlan mesterséges intelligenciára.
 * Az algoritmus három forrása (Wikidata P18, interwiki linkek és Commons kategóriák) közül a szerkesztők egyetértettek abban, hogy a Commons kategóriák a leggyengébbek (és a Wikidata a legerősebb). Ez beigazolódott a tesztelésünk során, és lehet, hogy a Commons-kategóriákat kizárjuk a jövőbeli iterációkból.
 * Jó tanácsokat kaptunk bizonyos típusú oldalak kizárására a funkcióból: diszharmonizálás, listák, évszámok, jó és kiemelt szócikkek. Lehet, hogy az élő személyek életrajzait is ki akarjuk zárni.
 * Azokat a képeket is ki kell zárnunk, melyek törlési sablonnal rendelkeznek a Commonson, és melyek korábban már törlésre kerültek a Wikipédia oldaláról.
 * Kezdők értékelése
 * A közösség tagjai általában attól tartottak, hogy a kezdők rossz ítélőképességet használnak majd, és az algoritmusnak adják meg az előnyt. A szerkesztői tesztekből tudjuk, hogy a kezdők képesek jó ítélőképességet tanúsítani, és úgy gondoljuk, hogy a megfelelő tervezés ezt ösztönözni fogja.
 * A Wikipedia Pages Wanting Photos (WPWP) kampány megvitatása során kiderült, hogy bár sok kezdő képes volt jó ítélőképességet tanúsítani, néhány túlbuzgó szerkesztő gyorsan sok rossz találatot hozhat létre, sok munkát okozva a járőröknek. Lehet, hogy valamilyen érvényesítést szeretnénk hozzáadni, hogy megakadályozzuk, hogy a szerkesztők túl gyorsan adjanak hozzá képeket, vagy hogy többszöri visszaállítás után is folytassák a képek hozzáadását.
 * A legtöbb közösségi tag megerősítette, hogy a "relevancia" fontosabb, mint a "minőség", amikor arról van szó, hogy egy kép odatartozik-e. Más szóval, ha egy személyről az egyetlen fotó elmosódott, az általában még mindig jobb, mintha egyáltalán nem lenne kép. A kezdőknek meg kell tanítani ezt a normát, miközben a feladatot végzik.
 * A kezelőfelületünknek azt kell sugallnia, hogy a szerkesztőknek lassan és óvatosan kell haladniuk, nem pedig azt, hogy minél több találatot próbáljanak meg elvégezni.
 * Meg kell tanítanunk a szerkesztőknek, hogy a képeknek tanulságosnak kell lenniük, nem pedig pusztán dekoratívnak.
 * Felhasználói felület
 * Többen javasolták, hogy a szerkesztőknek ne csak egy, hanem több képjelöltet is mutassunk, melyek közül választhatnak. Ezáltal valószínűbbé válna, hogy a szócikkekhez jó képeket csatolnak.
 * Sok közösségi tag javasolta, hogy tegyük lehetővé, hogy a kezdők kiválaszthassák az őket érdeklő tématerületeket (különösen a földrajzi területeket) a szócikkekhez, melyekkel dolgozni szeretnének. Ha a kezdők olyan területeket választanak, ahol már van némi ismeretük, akkor talán határozottabb döntéseket tudnak hozni. Szerencsére ez automatikusan része lenne minden olyan funkciónak, melyet a Növekedési csapat épít, mivel már most is engedélyezzük, hogy a szerkesztők 64 témakör közül választhassanak a javasolt szerkesztési feladatok kiválasztásakor.
 * A közösség tagjai azt javasolják, hogy a kezdők a lehető legtöbb cikk-környezetet lássák, ne csak egy előnézetet. Ez segít nekik megérteni a feladat súlyosságát, és rengeteg információ áll rendelkezésükre a döntésük meghozatalához.
 * Elhelyezés a szócikken belül
 * Megismertük a Wikidata infoboxokat. Megtanultuk, hogy az ezeket használó wikik esetében a képek lehetőleg a Wikidata infoboxon keresztül jelenjenek meg a Wikidata infoboxon keresztül, nem pedig a szócikken keresztül. Ennek szellemében kutatni fogjuk, hogy mennyire gyakoriak ezek az infoboxok a különböző wikikben.
 * Általánosságban úgy tűnik, hogy a "helyezz egy képet a sablonok alá és a tartalom fölé" szabály egy szócikkben a legtöbbször működik.
 * Néhány közösségi tag azt tanácsolta nekünk, hogy még ha nem is tökéletes az elhelyezés egy szócikkben, más szerkesztők szívesen kijavítják az elhelyezést, mivel a megfelelő kép megtalálásának nehéz munkája már megtörtént.
 * Nem angol nyelvű szerkesztők
 * A közösség tagjai emlékeztettek bennünket arra, hogy a Commons egyes metaadat elemei, például a feliratok és az ábrázoló megjegyzések, nyelvfüggetlenek lehetnek. Megnéztük, hogy ez pontosan mennyire gyakori ebben a szakaszban.
 * Hallottuk azt a javaslatot, hogy még ha a szerkesztők nem is beszélnek folyékonyan angolul, akkor is képesek lehetnek használni a metaadatokat, ha el tudják olvasni a latin betűket. Ez azért van így, mert sok egyezéshez a szerkesztő lényegében csak a szócikk címét keresi valahol a kép metaadataiban.
 * Valaki azt az ötletet is felvetette, hogy a metaadatokat gépi fordítással (pl. Google fordító) fordítsák le a helyi nyelvre e funkció céljára.
 * Feliratok
 * A közösség tagjai (és a növekedési csapat tagjai) szkeptikusak azzal kapcsolatban, hogy a kezdők képesek-e megfelelő feliratokat írni.
 * Azt a tanácsot kaptuk, hogy mutassunk a szerkesztőknek példákat a feliratokra, és a feliratozandó szócikk típusára szabott iránymutatásokat.



Terv a szerkesztői teszteléshez


A fenti nyitott kérdésekre gondolva, a közösség visszajelzései mellett szeretnénk néhány olyan mennyiségi és minőségi információt is generálni, melyek segítenek egy "kép hozzáadása" funkció létrehozásának megvalósíthatóságát értékelni. Bár az algoritmust már értékeltük a munkatársak és a Wikimédiások körében, fontos látni, hogyan reagálnak rá a kezdők, és hogyan használják az ítélőképességüket, amikor arról döntenek, hogy egy kép beletartozik-e egy szócikkbe.

Ebből a célból a usertesting.com segítségével teszteket fogunk végezni, melyekben a Wikipédia-szerkesztésben járatlan emberek egy prototípusban végigmehetnek a lehetséges képtalálatokon, és "Igen", "Nem" vagy "Nem biztos" válaszokat adhatnak. A teszthez egy gyors prototípust készítettünk, melyet a jelenlegi algoritmussal készült valódi találatokkal támasztottunk alá. A prototípus csak az egyik találatot mutatja meg a másik után, mindezt egy feedben. A képek a Commons összes vonatkozó metaadatával együtt jelennek meg:


 * Fájlnév
 * Méret
 * Dátum
 * Szerkesztő
 * Leírás
 * Felirat
 * Kategóriák
 * Címkék

Bár lehet, hogy a jövőben nem ez lesz a munkafolyamat a valódi szerkesztők számára, a prototípus úgy készült, hogy a tesztelők sok potenciális találatot gyorsan át tudjanak nézni, sok információt generálva.

Az interaktív prototípus kipróbálásához használd ezt a linket. Megjegyzendő, hogy ez a prototípus elsősorban az algoritmusból származó találatok megtekintésére szolgál -- a tényleges szerkesztői élményen még nem gondolkodtunk sokat. Valójában nem hoz létre semmilyen szerkesztést. Az algoritmus által javasolt 60 valódi találatot tartalmaz.

A következőkre fogunk figyelni a teszt során:


 * 1) A résztvevők képesek-e magabiztosan megerősíteni a találatokat a javaslatok és a megadott adatok alapján?
 * 2) Mennyire pontosak a résztvevők a javaslatok értékelésében? Úgy gondolják, hogy jobb vagy rosszabb munkát végeznek, mint amilyen valójában?
 * 3) Hogyan érzik magukat a résztvevők a képek ilyen módon történő hozzáadásának feladatával kapcsolatban a szócikkekhez? Könnyűnek/nehéznek, érdekesnek/unalmasnak, jutalmazónak/érdektelennek találják?
 * 4) Milyen információkat tartanak a résztvevők a legértékesebbnek a képek és a szócikkek egymáshoz való párosításának értékelésében?
 * 5) Képesek-e a résztvevők a megadott adatok alapján jó képaláírásokat írni az általuk megfelelőnek ítélt képekhez?

Tervezés


A vs. B koncepció
A feladat tervezésén gondolkodva hasonló kérdés, mint amivel a "hivatkozás hozzáadása" esetében szembesültünk az A és a B koncepció tekintetében. Az A koncepcióban a szerkesztők a szerkesztést a szócikknél fejeznék be, míg a B koncepcióban sok szerkesztést végeznének egymás után, mindegyiket egy feedből. Az A koncepció több kontextust ad a szerkesztőnek a szócikkhez és a szerkesztéshez, míg a B koncepció a hatékonyságot helyezi előtérbe.

A fenti interaktív prototípusban a B koncepciót alkalmaztuk, melyben a szerkesztők egy javaslatokból álló feeden keresztül haladnak. Ezt azért tettük, mert a szerkesztői tesztjeink során sok példát akartunk látni arra, hogy a szerkesztők hogyan lépnek kapcsolatba a javaslatokkal. Ez az a fajta kialakítás, ami a legjobban működhet egy olyan platformon, mint a Wikipédia Android-alkalmazása. A Növekedési csapat kontextusában inkább az A koncepcióban gondolkodunk, melyben a szerkesztő a szerkesztést a szócikknél végzi. Ezt az irányt választottuk a "hivatkozás hozzáadása" esetében, és úgy gondoljuk, hogy ugyanezen okokból a "kép hozzáadása" esetében is megfelelő lenne.



Egyetlen vs. többszörös
Egy másik fontos tervezési kérdés, hogy a szerkesztőnek egy egyetlen javasolt képet mutassunk-e meg, vagy több kép közül választhat. Ha több találatot adunk meg, nagyobb az esélye annak, hogy az egyik találat jó. De az is előfordulhat, hogy a szerkesztők azt gondolják, hogy az egyiket kell választaniuk, még akkor is, ha egyik sem jó. Emellett bonyolultabb lesz a tervezés és a kivitelezés, különösen a mobileszközök esetében. Három lehetséges munkafolyamatot modelleztünk:


 * Egyetlen: ebben a kialakításban a szerkesztő csak egy javasolt képet kap a szócikkhez, és csak azt kell elfogadnia vagy elutasítania. Ez egyszerű a szerkesztő számára.
 * Többszörös: ennél a kialakításnál a szerkesztőnek több potenciális egyezést mutatunk, melyeket összehasonlíthat, és kiválaszthatja a legjobbat, vagy elutasíthatja az összeset. Aggasztó lenne, ha a szerkesztő úgy érezné, hogy a legjobbat kell hozzáadnia a szócikkhez, még akkor is, ha valójában nem tartozik oda.
 * Sorozatos: ez a kialakítás több képi egyezést kínál, de a szerkesztő egyszerre csak egyet néz meg, rögzíti az ítéletét, majd a végén kiválasztja a legjobbat, ha jelezte, hogy több mint egy lehetséges egyezés van. Ez segíthet a szerkesztőnek abban, hogy egyszerre egy képre koncentráljon, de a végén egy plusz lépést tesz hozzá.



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

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:


 * 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