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

Ez az oldal a "kép hozzáadása" strukturált feladattal kapcsolatos munkát írja le, mely a strukturált feladatok egy típusa, amit a Növekedési csapat a kezdők kezdőlapján keresztül kínál fel.

Ez az oldal tartalmazza a főbb eszközöket, terveket, nyitott kérdéseket és döntéseket.

Az előrehaladásról szóló legtöbb apró frissítés az általános Növekedési csapat frissítések oldalára kerül, néhány nagyobb vagy részletes frissítés pedig ide.



Jelenlegi állapot

 * 2020-06-22: kezdeti elképzelések a képek ajánlására szolgáló egyszerű algoritmus létrehozására
 * 2020-09-08: első próbálkozás kiértékelése egy megfelelő algoritmusra angol, francia, arab, koreai, cseh és vietnámi nyelven
 * 2020-09-30: egy második kísérlet kiértékelése egy megfelelő algoritmusra angol, francia, arab, koreai, cseh és vietnámi nyelven
 * 2020-10-26: belső mérnöki megbeszélés a képajánló szolgáltatás lehetséges megvalósíthatóságáról
 * 2020-12-15: felhasználói tesztek első körének lefuttatása annak megértése érdekében, hogy a kezdők sikeresen megoldhatják-e ezt a feladatot
 * 2021-01-20: A platformmérnöki csapat megkezdi a képajánlásokhoz szükséges próba API létrehozását
 * 2021-01-21: Az Android-csapat megkezdi a minimálisan életképes verzió kidolgozását tanulási célokra
 * 2021-01-28: a felhasználói tesztek eredményeinek közzététele
 * 2021-02-04: a közösségi viták és a lefedettségi statisztikák összefoglalása
 * 2021-05-07: Az Android MVP kiadása a felhasználóknak
 * 2021-08-06: az Android eredményeinek és az 1. ismétlés mockupjainak közzététele
 * 2021-08-17: megkezdődik a backend munka az Iteration 1 kapcsán
 * 2021-08-23: interaktív prototípusok közzététele és felhasználói tesztek megkezdése angol és spanyol nyelven
 * 2021-10-07: a felhasználói tesztek eredményeinek és az eredményeken alapuló végleges terveknek a közzététele
 * 2021-11-19: a nagykövetek megkezdik az eszköz tesztelését a produktív Wikipédiáikban
 * 2021-11-22: a képjavaslatok adathalmazának frissítése az Iteration 1 felhasználók számára történő kiadása előtt
 * 2021-11-29: Az 1. verziót az arab, cseh és bengáli Wikipédiákon a mobilfelhasználók 40%-a használta.
 * 2021-12-22: közzétett vezető mutatók
 * 2022-01-28: az asztali változatot az új fiókok 40%-ára telepítették az arab, cseh és bengáli Wikipediákon.
 * 2022-02-16: A spanyol Wikipédia kezdő felhasználóinak "képet kell hozzáadniuk"
 * 2022-03-22: A portugál, perzsa, francia és török Wikipédia kezdő felhasználóinak megjelenik a "kép hozzáadása" felirat
 * 2023-02-07: Complete evaluation of section-level image suggestions (T316151)
 * 2023-10-16: Image Recommendations added to the Android Wikipedia app
 * Tovább: a következő wikikre való bővítés és a konverziós folyamat részletes elemzése

Összefoglaló
A strukturált feladatok célja, hogy a szerkesztési feladatokat lépésről lépésre olyan munkafolyamatokra bontsa, melyek értelmesek a kezdők számára és mobil eszközökön is jól használhatóak. A Növekedési csapat úgy véli, hogy az ilyen újfajta szerkesztési munkafolyamatok bevezetése lehetővé teszi, hogy több új szerkesztő vegyen részt a Wikipédia szerkesztésében, akik közül néhányan megtanulnak majd jelentősebb szerkesztéseket végezni, és bekapcsolódnak a közösségükbe. Miután megvitattuk a strukturált feladatok ötletét a közösségekkel, úgy döntöttünk, hogy létrehozzuk az első strukturált feladatot: "link hozzáadása". 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".

A "link hozzáadása" 2021 májusában történő bevezetése után kezdeti adatokat gyűjtöttünk, melyek azt mutatták, hogy a feladat vonzó volt a kezdő felhasználók számára, és hogy alacsony visszaállítási arány mellett végeztek szerkesztéseket -- ami azt jelzi, hogy a strukturált feladatok értékesnek tűnnek az új szerkesztők és a wikik számára.

Már az első feladat megalkotása közben is gondolkodtunk azon, hogy mi lehetne a következő strukturált feladat, és úgy gondoljuk, hogy a képek hozzáadása jó választás lehet a kezdők számára. Az ötlet az, hogy egy egyszerű algoritmus képeket ajánlana a Commonsból olyan szócikkekhez, melyekben nincsenek képek. Kezdetben csak a Wikidatában fellelhető, meglévő kapcsolatokat használná, és a kezdők saját belátásuk szerint döntenék el, hogy a képet a cikkre helyezik-e vagy sem.

Tudjuk, hogy sok nyitott kérdés van azzal kapcsolatban, hogy ez hogyan működne, és sok lehetséges oka van annak, hogy ez nem fog jól működni. Ezért reméljük, hogy sok közösségi tagtól halljuk majd a véleményeket, és folyamatos vitát folytatunk, miközben eldöntjük, hogyan tovább.



Kapcsolódó projektek
Az Android-csapat egy hasonló feladat minimális változatán dolgozott a Wikipédia Android-alkalmazásához, mely ugyanazokat az alapkomponenseket használja. Emellett a strukturált adatokkal foglalkozó csapat a kezdeti szakaszában van egy hasonló, tapasztaltabb felhasználóknak szánt, a Strukturált adatok a Commonson előnyét kihasználó fejlesztése.



Miért képek?
Jelentős szerkesztéseket keresünk

Amikor először beszéltünk a strukturált feladatokról a közösség tagjaival, sokan rámutattak, hogy a wikilinkek hozzáadása nem egy különösen nagy értékű szerkesztési típus. A közösség tagjai ötleteket vetettek fel arra vonatkozóan, hogy a kezdők hogyan tudnának érdemibb szerkesztést nyújtani. Az egyik ötlet a képek. A Wikimédia Commons 65 millió képet tartalmaz, de sok Wikipédiában a cikkek több mint 50%-a nem tartalmaz képet. Úgy gondoljuk, hogy a Commonsból származó sok kép lényegesen illusztráltabbá teheti a Wikipédiát. 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.

A kezdők érdeklődése

Tudjuk, hogy sok kezdő érdeklődik a Wikipédia képekkel való bővítése iránt. Az új belépők az üdvözlési kérdőívben gyakran válaszolták, hogy "képet szeretnék hozzáadni", amikor azt kérdezték, hogy miért hozták létre a fiókjukat. Azt is látjuk, hogy az egyik leggyakoribb kérdés a súgópanelen a képek hozzáadására vonatkozik, és ez az összes wikire igaz, amivel dolgozunk. Bár a legtöbb új felhasználó valószínűleg a saját képét hozza, amit hozzá szeretne adni, ez arra utal, hogy a képek hogyan lehetnek vonzóak és izgalmasak. Ennek van értelme, tekintve, hogy a többi platform, ahol a kezdők részt vesznek - mint például az Instagram és a Facebook -- kép-hangsúlyos elemeket tartalmaz.

A képekkel való munka nehézségei

A képekkel kapcsolatos számos súgópanel-kérdés azt tükrözi, hogy a képek szócikkekhez való hozzáadásának folyamata túl bonyolult. A kezdőknek meg kell érteniük a Wikipédia és a Commons közötti különbséget, a szerzői jogokra vonatkozó szabályokat, valamint a kép megfelelő helyre történő beillesztésének és feliratozásának technikai részét. Egy kép megtalálása a Commonsban egy illusztrálatlan cikkhez még több készséget igényel, például a Wikidata és a kategóriák ismeretét.

A "Wikipedia Pages Wanting Photos" kampány sikere

A Wikipedia Pages Wanting Photos (WPWP) kampány meglepő sikert aratott: 600 felhasználó 85 000 oldalhoz adott hozzá képeket. Tették ezt néhány közösségi eszköz segítségével, melyek azonosították a kép nélküli oldalakat, és a Wikidata segítségével javasolták a lehetséges képeket. Bár még fontos tanulságokat lehet levonni arról, hogyan kell segíteni a kezdőknek a képek hozzáadásában, ez bizalmat ad nekünk abban, hogy a felhasználók lelkesedhetnek a képek hozzáadásáért, és hogy az eszközök segíthetnek nekik.

Mindezt együttvéve

Mindezeket az információkat együttesen végiggondolva úgy gondoljuk, hogy lehetséges lehet egy olyan strukturált "kép hozzáadása" feladatot létrehozni, amely egyszerre szórakoztató a kezdők számára és produktív a Wikipédia számára.

Az ötlet jóváhagyása
''2020 júniusától 2021 júliusáig a Növekedési csapat a "kép hozzáadása" feladat körüli közösségi megbeszéléseken, háttérkutatásokon, értékeléseken és koncepcióvizsgálatokon dolgozott. 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 mindazt a háttérmunkát, amely az Iteration 1-ig vezetett.''

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 dolgoztunk, 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, mely a pontosságot és az emberi ítélőképességet 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 a Wikidata meglévő információit összesíti, a tapasztalt közreműködők által létrehozott kapcsolatokra támaszkodva. Ez a három fő módja annak, ahogyan a nem illusztrált cikkekhez találatokat javasol:


 * Nézd meg a szócikkhez tartozó Wikidata-elemet. Ha van benne kép (1$), válaszd ki azt a képet.
 * Nézd meg a szócikk Wikidata-elemét. Ha van hozzá Commons kategória (P373), akkor 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 vezérképet ezekből a 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áig az algoritmus három tesztelési fordulón ment keresztül, minden alkalommal hat nyelv szócikkeit vizsgáltuk: Angol, francia, arab, vietnámi, cseh és koreai. 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:

Egy ilyen algoritmuson végzett munka során az a kérdés, hogy mennyire kell pontosnak lennie? Ha az egyezések 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, hogy sok olyan egyszerű javítást találtunk az algoritmuson, amit könnyen el lehet végezni, beleértve a kizárandó szócikkek és képek típusait. Még ezen fejlesztések nélkül is a találatok körülbelül 20-40%-a "2-es" volt, ami azt jelenti, hogy a cikkhez nagyszerű találatok tartoznak (a wikitől függően). Az első értékelés teljes eredményeit és jegyzeteit itt találod.

A második értékeléshez számos javítást építettünk be, és a találati pontosság nőtt. A találatok 50-70%-a "2-es" volt (a wikitől függően). A pontosság növelése azonban csökkentheti a lefedettséget, azaz azon cikkek számát, melyekre egyezést tudunk találni. Konzervatív kritériumokat alkalmazva 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ó cikke van. Ú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 tekintheted meg.

Harmadik értékelés

2021 májusában a strukturált adatokkal foglalkozó csapat egy sokkal nagyobb léptékű tesztet végzett a képillesztési algoritmus (és a MediaSearch algoritmus) tesztelésére arab, cebuanói, angol, vietnámi, bengáli és cseh Wikipédiákon. Ebben a tesztben a képillesztési algoritmus és a MediaSearch mintegy 500 találatát értékelték az egyes nyelvek szakértői, akik jó esetben "Jó", "Rendben" vagy "Rossz" találatoknak minősíthették azokat. Az alább 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 a "Jó" vagy a "Jó+Rendben" kategóriába esik, é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, mivel 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özi") és a Wikidata-cikkekhez 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ások. 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 egybevetni. 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 javaslatokat, 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 eszközt létrehozni? Képes lenne-e érdemi hatást 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 tükröződő lefedettségi számok elegendőnek tűnnek egy "kép hozzáadása" funkció első verziójához. Minden wikiben van annyi jelölt találat, hogy (a) a szerkesztők nem fognak kifogyni belőle, és (b) egy funkció jelentős hatást gyakorolhatna 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 szócikkeket, ahol találunk megfelelő jelölteket. Általánosságban elmondható, hogy ez a feladat első verziójához elegendő mennyiség, így a szerkesztőknek bőven akad találatuk. Néhány ritkább wikiben, mint például a bengáli, ez a szám kis számokba is belekerülhet, amint a felhasználók leszűkítik az őket érdeklő témákat. Ennek ellenére a bengáliban csak körülbelül 100 000 szócikk van összesen, így a szócikkek 7%-ára javasolnánk találatokat, ami jelentős.
 * Ami azt illeti, hogy mekkora javulást érhetnénk el a wikik illusztrálásában ezzel az algoritmussal, a felső határ 1% (cebwiki) és 9% (trwiki) között mozog. Ez a további cikkek teljes százalékos aránya, ami illusztrációkkal egészülne ki, ha minden találat jó lenne és bekerülne a wikibe.
 * Az arzwiki és a cebwiki az a wiki, ahol a legalacsonyabb az illusztrálatlan cikkek aránya, melyekhez találunk találatokat, mivel mindkettőben nagy a botok által létrehozott cikkek száma. Ennek 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 nem lenne kép. De mivel ezekben a wikikben nagyon sok szócikk található, még mindig több tízezer olyan szócikk van, amire az algoritmus talál találatokat.
 * 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 Commonson található strukturált adatok 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ó itt található.

2021 februárjától a csapat jelenleg azzal kísérletezik, 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 ami alapján eldöntheti, hogy a MediaSearchből származó találat megfelelő minőségű-e a képilleszté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ó csoport azt is vizsgálja és prototípusokat 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 "Pontosság" szakaszban idézett értékelés során a MediaSearch jóval kevésbé pontosnak bizonyult, mint a képillesztési algoritmus. Míg a képillesztési algoritmus körülbelül 78%-os pontosságú volt, addig a MediaSearch találatai körülbelül 38%-os pontosságúak voltak. Ezért a növekedési csapat nem tervezi a MediaSearch használatát a "kép hozzáadása" feladat első ismétlésében.

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ó, ami 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 tagjaira nézve. Ebből a célból számos nyitott kérdésünk van, és szeretnénk, ha a közösség tagjai továbbiakat is felvetnének.


 * 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?

A közösségi megbeszélések jegyzetei 2021-02-04
2020 decemberétől kezdve öt nyelven (angol, bengáli, arab, vietnámi, cseh) hívtuk meg a közösség tagjait, hogy beszélgessenek a "kép hozzáadása" ötletérő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 hallottunk véleményt, és ez a rész összefoglalja a leggyakoribb és legérdekesebb gondolatokat. 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 óvatosan optimisták ezzel az ötlettel kapcsolatban. Más szóval, úgy tűnik, a szerkesztők egyetértenek abban, hogy értékes lenne algoritmusokat használni a képek Wikipédiához való hozzáadásához, de hogy sok a lehetséges buktató, és hogy ez sokféleképpen 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 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: disambiguációk, listák, évszámok, jó és kiemelt cikkek... Lehet, hogy az élő személyek életrajzát 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 rosszul ítélik meg a helyzetet, és az algoritmusnak nem adnak igazat. Szerkesztői tesztjeinkből tudjuk, hogy a kezdők képesek józan ítélőképességre, és úgy véljük, 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 új felhasználó képes volt jó ítélőképességre, néhány túlbuzgó szerkesztő gyorsan sok rossz találatot hozhat létre, ami sok munkát okoz a járőröknek. Lehet, hogy valamiféle érvényesítést szeretnénk hozzáadni, hogy megakadályozzuk, hogy a felhasználó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 hozzátartozik-e. Más szóval, ha egy személyről az egyetlen kép 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 felhasználóknak ne csak egy, hanem több kép közül választhassanak. Ezáltal valószínűbbé válna, hogy a szócikkekhez jó képeket csatolnak.
 * A közösség számos tagja javasolta, hogy a kezdők választhassák ki az őket érdeklő tématerületeket (különösen a földrajzi területeket), ahol a szócikkekkel dolgozni szeretnének. Ha a kezdők olyan területeket választanak, ahol már van némi tudásuk, akkor talán erősebb döntéseket tudnak hozni. Szerencsére ez automatikusan része lenne minden olyan funkciónak, melyet a Növekedési csapat készít, mivel már most is lehetővé tesszük a szerkesztők számára, hogy 64 tématerület közül válasszanak 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 cikkkörnyezetet lássák, ne csak egy előnézetet. Ez segít nekik megérteni a feladat súlyát, és rengeteg információ áll rendelkezésükre a döntésük meghozatalához.
 * Elhelyezés a szócikken belül
 * Tanultunk a Wikidata infoboxokról. Megtanultuk, hogy az ezeket használó wikik esetében a képek lehetőleg a Wikidata infoboxon keresztül jelenjenek meg, és ne a szócikkben. Ennek szellemében azt fogjuk kutatni, 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, mint például a feliratok és az ábrázoló nyilatkozatok, nyelvfüggetlenek lehetnek. Ebben a szakaszban megnéztük, hogy ez pontosan mennyire gyakori.
 * Hallottuk azt a javaslatot, hogy még ha a szerkesztők nem is beszélnek folyékonyan angolul, akkor is használhatják a metaadatokat, ha képesek latin betűket olvasni. Ennek az az oka, hogy sok egyezéshez a felhasználó lényegében csak a 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.



Szerkesztői tesztelés tervezése


A fenti nyitott kérdésekre gondolva, a közösség véleménye mellett szeretnénk néhány kvantitatív és kvalitatív információt is generálni, melyek segítségével értékelni tudjuk a "kép hozzáadása" funkció létrehozásának megvalósíthatóságát. 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 az usertesting.com segítségével teszteket fogunk futtatni, melyekben a Wikipédia-szerkesztésben járatlan szerkesztők egy prototípusban végigmehetnek a lehetséges képtalálatokon, és "Igen", "Nem" vagy "Bizonytalan" választ adhatnak. A teszthez készítettünk egy gyors prototípust, melyet a jelenlegi algoritmussal készült valódi találatokkal támasztunk alá. A prototípus csak az egyik találatot mutatja egymás 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 algoritmus találatainak megtekintésére szolgál -- a tényleges felhasználó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?

A koncepció vs. B
A feladat tervezésén gondolkodva hasonló kérdés merült fel, mint a "link hozzáadása" esetében az A és a B koncepció tekintetében. Az A koncepcióban a szerkesztők a szócikk szerkesztését a cikknél végeznék el, míg a B koncepcióban több 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ó csatornán 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 felhasználók hogyan lépnek interakcióba a javaslatokkal. Ez az a fajta kialakítás, mely 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 szócikk szerkesztését a szócikknél végzi. Ezt az irányt választottuk a "link hozzáadása" esetében, és úgy gondoljuk, hogy ugyanezen okokból a "kép hozzáadása" esetében is megfelelő lehet.

Egyetlen vs. többszörös
Egy másik fontos tervezési kérdés, hogy egyetlen javasolt képillesztést mutassunk-e meg a felhasználónak, vagy több képillesztés közül választhat. Amennyiben 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épillesztést kap a szócikkhez, és csak azt kell elfogadnia vagy elutasítania. Ez egyszerű a szerkesztő számára.
 * Többszörös: ez a terv több lehetséges egyezést mutat a szerkesztőnek, aki ezeket összehasonlíthatja, és kiválaszthatja a legjobbat, vagy elutasíthatja az összeset. Aggodalomra adhat okot, ha a szerkesztő úgy érzi, hogy a legjobbat kell hozzáadnia a szócikkhez, még akkor is, ha az valójában nem tartozik oda.
 * Sorozatos: ez a kialakítás több képi egyezést kínál, de a szerkesztő egyenként nézi meg őket, rögzíti az ítéletét, majd a végén kiválasztja a legjobbat, ha jelezte, hogy egynél több egyezés lehetséges. Ez segíthet a szerkesztőnek, hogy egyszerre egy képre koncentráljon, de a végén egy plusz lépést tesz hozzá.



Szerkesztői tesztek 2020. december
Háttér

2020 decemberében a usertesting.com segítségével 15 tesztet végeztünk a mobil interaktív prototípussal. A prototípus csak kezdetleges dizájnt, kevés kontextust vagy onboardingot tartalmazott, és csak angol nyelven teszteltük olyan szerkesztőkkel, akiknek kevés vagy semmilyen korábbi Wikipédia-szerkesztési tapasztalatuk sem volt. Szándékosan egy kezdetleges kialakítást teszteltünk a folyamat elején, hogy sok tanulságot gyűjthessünk. A teszteléssel elsősorban a funkció egészének megvalósíthatóságát akartuk megvizsgálni, nem pedig a tervezés finomabb részleteit:


 * 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? És hogyan viszonyul a tényleges alkalmasság a javaslatok értékelésében tapasztalt képességeikhez?
 * 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 metaadatokat tartanak a résztvevők a legértékesebbnek a képek és szócikkek egyezésének é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?

A teszt során arra kértük a résztvevőket, hogy legalább 20 szócikk-kép egyezést kommentáljanak, miközben hangosan beszélnek. Amikor igennel koppintottak, a robot arra kérte őket, hogy írjanak egy képaláírást a szócikkben szereplő képhez. Összesen 399 megjegyzést gyűjtöttünk össze.

Összefoglaló

Úgy gondoljuk, hogy ezek a szerkesztői tesztek megerősítik, hogy sikeresen létrehozhatunk egy "kép hozzáadása" funkciót, de ez csak akkor fog működni, ha jól tervezzük meg. A tesztelők közül sokan jól megértették a feladatot, komolyan vették, és jó döntéseket hoztak -- ez bizalmat ad nekünk, hogy ez olyan ötlet, melyet érdemes megvalósítani. Másrészről viszont sok más szerkesztő nem értette a feladat lényegét, nem értékelte olyan kritikusan, és gyenge döntéseket hozott -- de ezeknek a zavarodott felhasználókat illetően könnyű volt meglátnunk, hogyan javíthatnánk a tervezésen, hogy megfelelő kontextust adjunk nekik és közvetítsük a feladat komolyságát.

Megfigyelések

''A teljes megállapítássorozat megtekintéséhez bátran böngészd a diákat. A legfontosabb pontok a diák alatt vannak leírva.''




 * A képek és a Wikipédia-szócikkek megfeleltetése feladatának általános megértése meglehetősen jó volt, figyelembe véve az eszköz számára biztosított minimális kontextust és a Commons illetve a Wikipédia-szerkesztés korlátozott ismereteit. Lehetőség van a megértés fokozására, amint az eszközt a Wikipédia UX alapján újratervezés alá kerül.
 * Az általunk észlelt általános minta a következő volt: a szerkesztő megnézi a szócikk címét és az első pár mondatot, majd megnézi a képet, hogy kiderítse, vajon hihető-e a megfelelés (pl. ez egy cikk egy templomról, ez pedig egy templom képe). Ezután megkeresné a szócikk címét valahol a kép metaadataiban, akár a fájlnévben, a leírásban, a képaláírásban vagy a kategóriákban.  Ha megtalálja, megerősíti az egyezést.
 * Minden képillesztési feladatot gyorsan elvégezhet egy, a szerkesztésben járatlan személy is. Átlagosan 34 másodpercig tartott egy kép átnézése.
 * Mindenki azt mondta, hogy szívesen elvégezne egy ilyen feladatot, és a többség könnyűnek vagy nagyon könnyűnek minősítette azt.
 * A képek és javaslatok minőségének megítélése vegyes volt. Sok résztvevő a képkompozícióra és más esztétikai tényezőkre összpontosított, ami befolyásolta a javaslatok pontosságának megítélését.
 * A Commonsból származó képi metaadatoknak csak néhány darabja volt kritikus a képillesztés szempontjából: fájlnév, leírás, felirat, kategóriák.
 * Sok résztvevő időnként helytelenül próbált egy képet a saját adataihoz, nem pedig a szócikkhez illeszteni (pl. "Ez a fájlnév megfelelőnek tűnik a képhez?"). Meg kell vizsgálni az elrendezés és a vizuális hierarchia megváltoztatását, hogy a javasolt kép jobban a szócikk kontextusára fókuszáljon.
 * A jó találatok "sorozata" néhány résztvevőt önelégültebbé tett a további képek elfogadásával kapcsolatban -- ha egymás után sok "igen" volt, már nem értékelték olyan kritikusan a képeket.
 * A szerkesztők rosszul végezték a képaláírások hozzáadását. Gyakran írtak magyarázatot arra, hogy miért egyezik a kép, pl. "Ez egy jó minőségű fotó a szócikkben szereplő fickóról". Ez olyasvalami, amin úgy véljük, hogy tervezéssel és a szerkesztő számára adott magyarázattal javítani lehet.

Metrikák


 * Csapatunk tagjai megjegyzésekkel látták el az összes képegyezést, melyet a teszt során a szerkesztőknek mutattunk, és feljegyeztük a felhasználók által adott válaszokat. Ily módon statisztikákat készítettünk arról, hogy a felhasználók milyen jó munkát végeztek.
 * A 399 javaslatból, mellyel a szerkesztők találkoztak, 192 alkalommal (48%) koppintottak az "Igen"-re.
 * Ezek közül 33 nem volt jó találat, és vissza lehetne vonni őket, ha a valóságban is hozzáadnák a szócikkekhez. Ez 17%, és ezt nevezzük " várható visszaállítási aránynak".

Tanulságok


 * A 17%-os "várható visszaállítási arány" egy nagyon fontos szám, és azt szeretnénk, ha ez a szám a lehető legalacsonyabb lenne. Egyrészt ez a szám közel van a Wikipédiában az új szerkesztők átlagos visszaállítási arányához, vagy alacsonyabb annál (az angol 36%, az arab 26%, a francia 22%, a vietnámi 11%).  Másrészt a képek nagyobb hatásúak és jobban láthatóak, mint a szócikken belüli apró változtatások vagy szavak. Figyelembe véve, hogy milyen változtatásokat hajtanánk végre az általunk tesztelt munkafolyamatban (mely a mennyiségre, nem pedig a minőségre volt optimalizálva), úgy gondoljuk, hogy ez a visszaállítási arány jelentősen csökkenne.
 * Úgy véljük, hogy ez a feladat sokkal jobban működne egy olyan munkafolyamatban, ami a szerkesztőt a teljes szócikkhez vezeti, szemben azzal, hogy gyorsan megmutatja neki az egyik javaslatot a másik után a feedben. A teljes szócikkhez való eljutás révén a szerkesztő sokkal több összefüggést láthatna, hogy eldönthesse, hogy a kép megfelel-e, és láthassa, hogy a kép hova illeszkedik a cikkben.  Úgy gondoljuk, hogy a szerkesztők átéreznék a feladat fontosságát: azt, hogy valóban képet fognak hozzáadni egy Wikipédia-szócikkhez.  Ahelyett, hogy a sebességre törekedne, úgy gondoljuk, hogy a felhasználó sokkal óvatosabb lenne a képek hozzáadásakor. Ugyanerre a döntésre jutottunk a "link hozzáadása" esetében is, amikor az "A koncepció" munkafolyamat megalkotása mellett döntöttünk.
 * Azt is hisszük, hogy az eredmények javulni fognak a bevezetéssel, a magyarázattal és a példákkal. Ez különösen igaz a feliratokra. Úgy gondoljuk, ha mutatunk a szerkesztőknek néhány példát a jó feliratokra, rájönnek, hogyan kell azokat megfelelően megírni.  Arra is ösztönözhetjük őket, hogy a Commons leírását vagy feliratát használják kiindulópontként.
 * Csapatunk az utóbbi időben arról vitatkozik, hogy nem lenne-e jobb egy "közös döntési" keretrendszert elfogadni, melyben egy kép csak akkor kerülne egy szócikkhez, ha azt nem csak egy, hanem két szerkesztő is megerősíti. Ez növelné a pontosságot, de kérdéseket vet fel azzal kapcsolatban, hogy egy ilyen munkafolyamat összhangban van-e a Wikipédia értékeivel, és hogy melyik felhasználó kapja meg a szerkesztésért járó elismerést.

Metaadatok
A szerkesztői tesztek azt mutatták, hogy a Commonsból származó képi metaadatok (pl. fájlnév, leírás, képaláírás stb.) kritikus fontosságúak ahhoz, hogy a felhasználó magabiztosan elvégezze a keresést. Például, bár a szerkesztő látja, hogy a szócikk egy templomról szól, és hogy a fénykép egy templomot ábrázol, a metaadatok alapján meg tudja állapítani, hogy a cikkben tárgyalt templomról van-e szó. A szerkesztői tesztek során azt láttuk, hogy a metaadatoknak a következő elemei voltak a legfontosabbak: fájlnév, leírás, képaláírás, kategóriák. A nem hasznos elemek közé tartozott a méret, a feltöltés dátuma és a feltöltő felhasználóneve.

Tekintettel arra, hogy a metaadatok fontos szerepet játszanak a határozott döntés meghozatalában, elgondolkodtunk azon, hogy a felhasználóknak szükségük lesz-e a metaadatokra a saját nyelvükön ahhoz, hogy ezt a feladatot elvégezhessék, különösen annak fényében, hogy a Commons metaadatok többsége angol nyelvű. 22 wiki esetében megnéztük, hogy az algoritmus által kapott képegyezések hány százaléka rendelkezik helyi nyelvű metaadatelemekkel. Más szóval, az arab Wikipédia illusztrálatlan szócikkeihez illeszthető képek közül hánynak van arab nyelvű leírása, felirata és ábrája? A táblázat ezen összefoglaló pontok alatt található:


 * Általánosságban elmondható, hogy a helyi nyelvű metaadatok lefedettsége nagyon alacsony. Az angol a kivétel.
 * Az angol kivételével az összes wiki esetében a képmegfelelések kevesebb mint 7%-a rendelkezik helyi nyelvű leírással (az angol 52%).
 * Az angol kivételével az összes wiki esetében a képek kevesebb mint 0,5%-a rendelkezik helyi nyelvű felirattal (az angol 3,6%).
 * Az ábrázoló állítások esetében a wikik 3% (szerb) és 10% (svéd) között mozognak a képmegfeleltetések.
 * A helyi nyelvű leírások és feliratok alacsony lefedettsége azt jelenti, hogy a legtöbb wikiben nagyon kevés olyan kép van, melyet helyi nyelvű metaadatokkal tudnánk ajánlani a szerkesztőknek. A nagyobb wikik némelyikében néhány ezer jelölt van helyi nyelvű leírással.  De egyetlen nem angol nyelvű wikinek sincs több mint 1000 jelöltje helyi nyelvű felirattal.
 * Bár az ábrák lefedettsége nagyobb, arra számítunk, hogy az ábrázoló leírások általában nem tartalmaznak elegendő részletet ahhoz, hogy biztosan találjunk egyezést. Például a chicagói Szent Pál-templomról készült fotóra alkalmazott depicts kijelentés sokkal valószínűbb, hogy "templom", mint hogy "chicagói Szent Pál-templom".
 * Lehet, hogy a szerkesztői felületeken a helyi nyelvi metaadatokkal ellátott képjavaslatokat szeretnénk előnyben részesíteni, de amíg más funkciókat nem építünk a lefedettség növelésére, a helyi nyelvekre való hagyatkozás nem életképes lehetőség a nem angol nyelvű wikikben.

Tekintettel arra, hogy a helyi nyelvű metaadatok lefedettsége alacsony, jelenlegi elképzelésünk az, hogy a képillesztési feladatot csak azoknak a szerkesztőknek ajánljuk fel, akik tudnak angolul olvasni, amit a feladat megkezdése előtt gyors kérdésként feltehetünk a felhasználónak. Ez sajnos korlátozza azt, hogy hány szerkesztő vehetne részt. Hasonló a helyzet, mint a tartalomfordító eszköz esetében, hogy a felhasználóknak ismerniük kell a forrás-wiki és a cél-wiki nyelvét ahhoz, hogy tartalmat tudjanak átvinni egyik wikiből a másikba. A Növekedési csapat üdvözlő felmérésének eredményei alapján is úgy gondoljuk, hogy elegendő számú ilyen szerkesztő lesz, akik megkérdezik a kezdőket, hogy milyen nyelveket ismernek. A wikitől függően a kezdők 20-50%-a választja az angol nyelvet.

Android MVP
Az Android MVP-vel kapcsolatos részleteket lásd ezen az oldalon.

Háttér
Sok közösségi vita, számos belső megbeszélés és a fenti szerkesztői tesztek eredményei után úgy véljük, hogy ebben a "kép hozzáadása" ötletben van elég potenciál ahhoz, hogy tovább folytassuk. A közösségi tagok általában pozitívak, de egyben óvatosak is voltak -- azt is tudjuk, hogy még mindig sok aggály és ok van arra, hogy az ötlet esetleg nem működik a várt módon. A következő lépés, amit szeretnénk megtenni, hogy többet tudjunk meg, az egy "minimálisan életképes termék" (MVP) létrehozása a Wikipédia Android alkalmazáshoz. A legfontosabb dolog ezzel az MVP-vel kapcsolatban az, hogy nem fog elmenteni semmilyen szerkesztést a Wikipédián. Inkább csak arra fogjuk használni, hogy adatokat gyűjtsünk, javítsuk az algoritmusunkat, és javítsuk a tervezésünket.

Az Android alkalmazás az, ahonnan a "javasolt szerkesztések" származnak, és az a csapat rendelkezik egy olyan keretrendszerrel, amely segítségével új feladattípusokat lehet könnyen létrehozni. Ezek a fő darabok:


 * Az alkalmazásnak lesz egy új feladattípusa, melyről a szerkesztők tudják, hogy csak arra szolgál, hogy segítsen nekünk az algoritmusaink és a formatervezésünk javításában.
 * A szerkesztőknek képi egyezéseket fog mutatni, ők pedig az "Igen", "Nem", vagy "Hagyd ki" opciót választhatják ki.
 * Feljegyezzük a választásaik adatait, hogy javíthassuk az algoritmust, meghatározzuk, hogyan javítsuk a kezelőfelületet, és átgondoljuk, hogy a növekedési csapat később mit építhetne a webes platformra.
 * A Wikipédián nem lesz szerkesztés, így ez egy nagyon alacsony kockázatú projekt.

Eredmények
Az Android-csapat 2021 májusában adta ki az alkalmazást, és több hét alatt több ezer szerkesztő értékelte a képillesztési algoritmus több tízezer képillesztését. Az így kapott adatok alapján a növekedési csapat úgy döntött, hogy folytatja a "kép hozzáadása" feladat 1. iterációját. Az adatok vizsgálata során két fontos kérdésre próbáltunk választ adni az "elkötelezettség" és a "hatékonyság" körül.

Elkötelezettség: minden nyelvi szerkesztőjének tetszik ez a feladat, és meg szeretné is csinálni?
 * Az Android MVP felhasználói átlagosan körülbelül 11 megjegyzést tettek egyenként. Ez ugyan kevesebb, mint a képleírások és a leírások fordítása, de nagyobb, mint a másik négyféle Android-feladat.
 * A képillesztési szerkesztések lényegesen alacsonyabb megtartási arányt mutattak, mint a más típusú Android javasolt szerkesztések, de aggodalomra ad okot, hogy nem lehet almás összehasonlításra számítani. Továbbá úgy gondoljuk, hogy az a tény, hogy az ezen MVP szerkesztései valójában nem változtatják meg a wikit, alacsonyabb megtartáshoz vezetne, mivel a szerkesztők kevésbé lennének motiváltak arra, hogy visszatérjenek és többet szerkesszenek.
 * A nyelv tekintetében adatokat gyűjtöttünk az angol nyelvű Wikipédia szerkesztőiről, valamint olyan felhasználóktól, akik kizárólag nem angol nyelvű Wikipédiát használnak, beleértve a német, török, francia, portugál és spanyol Wikipédiák nagyszámú értékelését. Arra számítottunk, hogy az angol és a nem angol nyelvű felhasználóknak meglehetősen eltérő tapasztalatai lesznek, mivel a Commonsban található képek metaadatainak többsége angol nyelvű. A mérőszámok azonban figyelemre méltóan hasonlóak voltak a két csoportban, beleértve a teljesített feladatok számát, a feladattal töltött időt, a megtartást és az értékelést. Ez jó előjel arra nézve, hogy ez a feladat a wikik között is használható, bár valószínű, hogy a nem angol Android-felhasználók közül sokan valóban kétnyelvűek.

Hatékonyság: a kapott szerkesztések megfelelő minőségűek lesznek?
 * Azoknak a találatoknak a 80%-a, melyekre a kezdők igennel válaszoltak, a szakértők szerint valóban jó találatok. Ez körülbelül 5 százalékpontos javulást jelent az algoritmushoz képest.
 * Ez a szám 82-83%-ra emelkedik, ha eltávolítjuk azokat a kezdőket, akiknek az értékelésre fordított átlagos ideje nagyon alacsony.
 * A szakértők általában csak az esetek 85%-ában értenek egyet egymással.
 * Mivel a kezdők pontossága növekszik, ha bizonyos típusú kezdőket eltávolítunk (azokat, akik túl gyorsan értékelnek, vagy akik túl sok javaslatot fogadnak el), úgy gondoljuk, hogy az automatikus "minőségi kapuk" növelhetik a kezdők teljesítményét a közösségek által elfogadható szintre.

A teljes eredmény itt olvasható.

Tervezés
Ez a rész linkeket tartalmaz arra vonatkozóan, hogy hogyan követheted a projekt technikai aspektusait:


 * A Tervezés Platform csapat által a "proof of concept" API munkája, melyet az Android MVP támogatására lett megépítve
 * Az Android csapat MVP körül végzett Phabricator-feladatok
 * A Phabricator feladatai és a képegyeztető algoritmus értékelései

1. ismétlés
2021 júliusában a növekedési csapat úgy döntött, hogy továbblép a "kép hozzáadása" feladat első verziójának elkészítésében a webre. Ez nehéz döntés volt, mivel számos nyitott kérdés és kockázat merült fel azzal kapcsolatban, hogy a kezdőket arra ösztönözzük, hogy képeket adjanak hozzá a Wikipédia szócikkeihez. De miután egy éven át folytattuk az ötlet érvényesítését, és átnéztük az ezzel kapcsolatos közösségi vitákat, értékeléseket, teszteket és koncepcióbizonylatokat, úgy döntöttünk, hogy megépítjük az első iterációt, hogy tovább tanulhassunk. Ezek az ötlet validálási fázisának főbb megállapításai, melyek alapján továbblépünk:


 * Visszafogott közösségi támogatás: a közösség tagjai óvatosan optimisták ezzel a feladattal kapcsolatban, egyetértenek abban, hogy értékes lenne, de számos kockázatra és buktatóra mutattak rá, melyeket szerintünk jó tervezéssel kezelni tudunk.
 * Pontos algoritmus: a képillesztési algoritmus több különböző teszt során 65-80%-os pontosságot mutatott, és idővel sikerült finomítanunk.
 * Szerkesztői tesztek: a prototípusokat megtapasztaló sok új felhasználó szórakoztatónak és magával ragadónak találta a feladatot.
 * Android MVP: az Android MVP eredményei azt mutatták, hogy a kezdők általában jó ítélőképességet használtak a javaslatoknál, de ami még fontosabb, hogy támpontokat adtak arra vonatkozóan, hogyan javíthatnánk az eredményeiket a terveinkben. Az eredmények arra is utaltak, hogy a feladat nyelvek között is jól működhet.
 * Általános tanulságok: Miután a különböző validálási lépések során számos buktatóba ütköztünk, a következő tervezéseink során képesek leszünk ezek ellen védekezni. Ez a háttérmunka rengeteg ötletet adott ahhoz, hogyan vezessük a kezdőket a jó ítélőképességre, és hogyan kerüljük el a káros szerkesztéseket.

Hipotézisek
Nem vagyunk biztosak abban, hogy ez a feladat jól fog működni -- ezért tervezzük, hogy kis ismétlésekben építjük fel, menet közben tanulva. Úgy gondoljuk, hogy az eddigi tanulságaink felhasználásával jó kísérletet tehetünk egy könnyű első iteráció megalkotására. Az egyik módja annak, hogy elgondolkodjunk azon, amit az iterációinkkal csinálunk, a hipotézisvizsgálat. Az alábbiakban öt optimista hipotézist mutatunk be a "kép hozzáadása" feladattal kapcsolatban. Az 1. iterációban az lesz a célunk, hogy megnézzük, igazak-e ezek a feltevések.


 * 1) Képaláírások: A szerkesztők képesek kielégítő képaláírásokat írni. Ez a legnagyobb nyitott kérdésünk, mivel a Wikipédia-szócikkekbe kerülő képekhez általában szükség van feliratokra, de az Android MVP nem tesztelte, hogy a kezdők képesek-e jól megírni azokat.
 * 2) Hatékonyság: a kezdők elég erős megítéléssel rendelkeznek ahhoz, hogy szerkesztéseiket a közösségek elfogadják.
 * 3) Elkötelezettség: a szerkesztők szeretik ezt a feladatot mobilon elvégezni, sokszor megteszik, és visszatérnek, hogy még többet szerkesszenek.
 * 4) Nyelvek: az angolul nem tudó szerkesztők is el tudják majd végezni ezt a feladatot. Ez egy fontos kérdés, mivel a Commons metaadatainak többsége angol nyelvű, és a felhasználók számára kritikus fontosságú, hogy a Commonsból el tudják olvasni a fájlnevet, a leírást és a feliratot, hogy magabiztosan megerősíthessék az egyezést.
 * 5) Párhuzam: a "link hozzáadása strukturált feladathoz" felépített tervezési paradigma a képekre is kiterjed.

Hatáskör
Mivel az 1. ismétléssel a fő célunk a tanulás, a lehető leghamarabb szeretnénk a szerkesztők elé tárni egy tapasztalatot. Ez azt jelenti, hogy korlátozni akarjuk az általunk épített elemek hatókörét, hogy gyorsan kiadhassuk. Az alábbiakban bemutatjuk a legfontosabb terjedelmi korlátozásokat, melyeket véleményünk szerint az 1. ismétléssel kapcsolatban meg kell határoznunk.


 * Csak mobilra: míg sok tapasztalt wikimédiás a wikin végzett munka nagy részét asztali számítógépéről/laptopról végzi, a Wikipédiához való szerkesztéssel küszködő kezdők nagyrészt mobileszközöket használnak, és ők a fontosabb célközönség a Növekedés csapat munkája szempontjából. Ha az 1. verziót csak mobilra készítjük el, akkor erre a közönségre koncentrálunk, miközben megspóroljuk azt az időt, amit ugyanennek a munkafolyamatnak a megtervezése és felépítése az asztali számítógépre/laptopra is igénybe venne.
 * Statikus javaslatok: ahelyett, hogy egy háttérszolgáltatást építenénk, mely folyamatosan futtatja és frissíti az elérhető képegyezéseket a képillesztési algoritmus segítségével, egyszer futtatjuk le az algoritmust, és a javaslatok statikus készletét használjuk az 1. ismétléshez. Bár így nem a legújabb képek és a legfrissebb adatok lesznek elérhetőek, úgy gondoljuk, hogy ez elegendő lesz a tanuláshoz.
 * Link hozzáadásának paradigmája: A tervezésünk általában ugyanazokat a mintákat fogja követni, mint az előző strukturált feladatunk, a "link hozzáadása" tervezése.
 * Illusztrálatlan szócikkek: a javaslatainkat csak azokra a szócikkekre korlátozzuk, melyekben egyáltalán nincsenek illusztrációk, szemben azokkal a cikkekkel, melyekben már van illusztráció, de még többre lenne szükség. Ez azt jelenti, hogy a munkafolyamatunknak nem kell lépéseket tartalmaznia, hogy a kezdők kiválaszthassák, hogy a szócikkben hol helyezzék el a képet. Mivel ez lesz az egyetlen kép, feltételezhető, hogy ez lesz a vezető kép a szócikk tetején.
 * Nincsenek infoboxok: Javaslatainkat csak azokra a szócikkekre korlátozzuk, melyekben nincsenek infoboxok. Ez azért lehetséges, mert ha egy kép nélküli cikknek van infoboxa, akkor az első képet általában az infoboxban kell elhelyezni. De komoly technikai kihívást jelent annak biztosítása, hogy sok nyelven minden infoboxban azonosítani tudjuk a megfelelő képet és képfelirat-mezőt. Ezzel elkerülhetőek azok a cikkek is, melyeknek Wikidata infoboxuk van.
 * Egyetlen kép: bár a képillesztési algoritmus több képjelöltet is javasolhat egyetlen illusztrálatlan szócikkhez, az 1. iterációt arra szűkítjük, hogy csak a legnagyobb megbízhatóságú jelöltet javasoljuk. Ez egyszerűbb élményt nyújt a kezdőknek, és könnyebbé teszi a csapat tervezési és mérnöki munkáját.
 * Minőségi kapuk: úgy gondoljuk, hogy valamilyen automatikus mechanizmust kellene beépítenünk, amely megakadályozza, hogy egy szerkesztő rövid idő alatt nagyszámú rossz szerkesztést végezzen. Az erre vonatkozó ötletek közé tartozik (a) a felhasználók korlátozása egy bizonyos számú "kép hozzáadása" szerkesztésre naponta, (b) további utasítások adása a felhasználóknak, ha túl kevés időt töltenek az egyes javaslatokkal, (c) további utasítások adása a felhasználóknak, ha úgy tűnik, hogy túl sok képet fogadnak el. Ezt az ötletet az angol Wikipédia 2021-es, a Wikipedia Pages Wanting Photos kampányával kapcsolatos tapasztalatai ihlették.
 * Kísérleti wikik: mint minden új Növekedési fejlesztést, először csak a négy kísérleti wikinkre fogjuk telepíteni, melyek az arab, vietnámi, bengáli és cseh wikipédiák. Ezek olyan közösségek, akik szorosan követik a Növekedés munkáját, és tisztában vannak azzal, hogy kísérletek részesei. A növekedés csapata közösségi nagyköveteket alkalmaz, akik segítenek nekünk abban, hogy gyors levelezést folytassunk ezekkel a közösségekkel. A következő évben a spanyol és portugál Wikipédiákat is felvehetjük a listára.

Kíváncsiak vagyunk a közösség tagjainak véleményére, hogy ezek a választási lehetőségek jónak tűnnek-e, vagy bármelyik úgy hangzik, mintha nagymértékben korlátozná az 1. ismétlés során szerzett tapasztalatainkat.

Mockupok és prototípusok
A korábbi szerkesztői tesztekből és az Android MVP alapján többféle tervezési koncepciót is fontolóra veszünk az 1. ismétléshez. A felhasználói folyamat öt részének mindegyikére vonatkozóan két alternatívánk van. Mindkettőt szerkesztői tesztelésnek vetjük alá, hogy információkat szerezzünk a kezdő felhasználóktól. Szerkesztői tesztjeink angol és spanyol nyelven zajlanak majd -- csapatunk először tesztel nem angol nyelven. Reméljük, hogy a közösség tagjai is megvizsgálják a terveket, és elmondják véleményüket a vitalapon.

Prototípusok felhasználói teszteléshez

A legkönnyebben az interaktív prototípusokon keresztül lehet megtapasztalni, hogy mit tervezünk építeni. Mind az "A koncepció", mind a "B koncepció" tervekhez készítettünk prototípusokat, és ezek angol és spanyol nyelven is elérhetőek. Ez nem tényleges wiki szoftver, hanem inkább annak szimulációja. Ami azt jelenti, hogy a szerkesztések nem kerülnek elmentésre, és nem minden gomb és interakció működik -- de a "kép hozzáadása" projekt szempontjából legfontosabbak működnek.


 * A koncepció (angol nyelven)
 * B koncepció (angol nyelven)
 * A koncepció (spanyol nyelven)
 * B koncepció (spanyol nyelven)

Mockupok felhasználói teszteléshez

Az alábbiakban statikus képek láthatóak a mockupokról, melyeket 2021 augusztusában használunk a felhasználói teszteléshez. A közösség tagjai szívesen felfedezik a Growth team designer's Figma file fájlt, amely tartalmazza az alábbi mockupokat a canvas jobb alsó részén, valamint a különböző inspirációkat és jegyzeteket, amelyek ezekhez vezettek.

Feed

Ezek a minták a munkafolyamat legelső részére vonatkoznak, melyben a szerkesztő kiválaszt egy szócikket, amin dolgozni szeretne a javasolt szerkesztési feedből. Azt szeretnénk, hogy a kártya vonzó legyen, de ne is zavarja össze a szerkesztőt.

'''Az 1. iteráció végső tervei'''

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.

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.

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.

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

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 sessionsfive 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 links.

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.

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

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.

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

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.