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

Tato stránka popisuje práci týmu Growth na jedné ze strukturovaných editaci: "přidání obrázku", která bude nováčkům nabízena přes jejich Domovskou stránku.

Tato stránka obsahuje nejdůležitější informace, otevřené otázky a rozhodnutí.

Více novinek týkající se práce týmu Growth najdete na všeobecné stránce s aktualizacemi. Závažné a větší aktuality budou pak vloženy i sem.



Současný stav

 * 2020-06-22: úvahy o nápadech, jak by mohl fungovat algoritmus pro doporučování obrázků
 * 2020-09-08: vyhodnocení první verze algoritmu na anglické, francouzské, arabské, korejské, české a vietnamské Wikipedii
 * 2020-09-30: vyhodnocení druhé verze algoritmu na anglické, francouzské, arabské, korejské, české a vietnamské Wikipedii
 * 2020-10-26: interní diskuse mezi vývojáři softwaru o možné realizaci služby pro doporučování obrázků
 * 2020-12-15: první série uživatelského testování, pro pochopení, zda by nováčci tento typ úkolu ocenili
 * 2021-01-20: tým Platform Engineering začíná budovat API pro koncepci návrhů pro doporučení obrázků
 * 2021-01-21: tým Androidu začíná pracovat na minimalizované životaschopné verzi pro účely učení
 * 2021-01-28: zveřejněny výsledky uživatelského testování
 * 2021-02-04: zveřejněno shrnutí komunitních konzultací a statistiky pokrytí
 * 2021-05-07: minimalizovaný životaschopný produkt (MVP) v aplikaci pro Android nasazen uživatelům
 * 2021-08-06: zveřejněny výsledky z Androidu a maket pro Iteration 1
 * 2021-08-17: začínají závěrečné práce na Iteraci 1
 * 2021-08-23: zveřejnění interaktivních prototypů a zahájení uživatelských testů v angličtině a ve španělštině
 * 2021-10-07: zveřejněné výsledky uživatelských testů a konečné návrhy založené na těchto výsledcích
 * 2021-11-19: ambassador zahajuje testování funkce ve své produkční Wikipedii
 * 2021-11-22: datová sada návrhů obrázků se aktualizuje před vydáním Iterace 1 uživatelům
 * 2021-11-29: Iterace 1 byla nasazena na 40 % mobilních účtů na arabské, české a bengálské Wikipedii.
 * 2021-12-22: zveřejnění hlavních ukazatelů
 * 2022-01-28: desktopová verze nasazená pro 40 % nových účtů na arabské, české a bengálské Wikipedii.
 * 2022-02-16: Nováčci španělské Wikipedie začínají dostávat "přidej obrázek"
 * 2022-03-22: Nováčci na Wikipedii v portugalštině, perštině, francouzštině a turečtině začínají dostávat "přidej obrázek"
 * 2023-02-07: Kompletní hodnocení návrhů obrázků na úrovni sekce (T316151)
 * Další: rozšíření na další sadu wiki a podrobně analyzovat konverzní trychtýř

Shrnutí
Strukturované úkoly mají rozdělit existující editační činnosti do jednoduchého vícekrokového pracovního postupu, který by nováčkům dával smysl a bylo možné použít ho na mobilních zařízeních. Tým Growth věří, že zavedení těchto nových editačních pracovních postupů umožní většímu množství lidí zapojit se do tvorby Wikipedie. Někteří z těchto lidí se postupně naučí jak na složitější editace a více se zapojí do komunitního života. Poté, co jsme prodiskutovali strukturované editace s komunitou, rozhodli jsme se vytvořit první strukturovanou editaci: přidání odkazu. 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".

Poté, co jsme v květnu 2021 nasadili „add a link“ (přidat odkaz), shromáždili jsme počáteční data, která ukázala, že úkol byl pro nováčky zajímavý a že prováděli úpravy s nízkou mírou návratnosti - což naznačuje, že strukturované úkoly přinesou nováčkům i wiki cenné zkušenosti.

Už když jsme stavěli první úkol, přemýšleli jsme o tom, jaký by mohl být další strukturovaný úkol. Myslíme si, že přidávání obrázků by pro nováčky mohlo být vhodné. Myšlenka je taková, že jednoduchý algoritmus by doporučoval umístit obrázky od Commons do článků, které nemají žádné obrázky. Použilo by se pouze existující spojení, které lze nalézt ve Wikidatech a nováčci by použili svůj úsudek zda umístit obrázek do článku nebo ne.

Víme, že kolem této funkcionality existuje mnoho otevřených otázek a mnoho možných příčin, proč by její zavedení nemuselo dopadnout dobře. Proto doufáme, že se do diskuse zapojí hodně členů komunity a poradí nám, jak tuto funkci nejlépe implementovat.



Související projekty
Android tým pracoval na podobném úkolu, který implementoval do aplikace Wikipedie pro Android, založené na stejných komponentech. Navíc, tým pro strukturovaná data začal s prozkoumáváním podobného nápadu, zacíleného na zkušenější uživatele. Jejich projekt by měl využívat strukturovaná data dostupná na Commons. Diskuse a aktualizace na této stránce jsou důležité pro práci všech týmů.



Proč zrovna obrázky?
Hledáme podstatné příspěvky

Když jsme poprvé diskutovali o strukturovaných editacích s komunitou, mnoho členů komunity zmínilo, že přidání wikiodkazů není zrovna ceněná činnost. Členové komunity zmínili několik možností, jak by nováčci mohli ukládat editace s větším dopadem, než přidávání odkazů. Jedním z těchto nápadů bylo přidávání obrázků. Wikimedia Commons obsahuje přes 65 milionů obrázků, ale v mnoha jazykových verzích Wikipedie nemá polovina článků vůbec žádný obrázek. Věříme, že mnoho obrázků z Commons by mohlo pomoci článkům na Wikipedii k větší proilustrovanosti. 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.

Zájem ze strany nováčků

Víme, že mnoho nováčků chce obrázky do Wikipedie přidat. Odpověď „abych přidal obrázky“ je jednou z častých odpovědí na otázku „Proč si vytváříte účet“ v uvítacím dotazníku. Je to také jedna z častých otázek v panelu Potřebuji pomoc a to na všech projektech. Ačkoli většina nováčků pravděpodobně chce přidat vlastní obrázky, tato fakta ukazují na to, že obrázky nováčky zajímají. Dává nám to smysl, jelikož na obrázcích jsou založené i další internetové projekty, které nováčci mohou znát – například Instagram či Facebook.

Práce s obrázky je obtížná

Mnoho otázek na stránce Potřebuji pomoc se týká právě přidávání obrázků a obtížnosti tohoto procesu. Pro nováčky je obtížné pochopit rozdíl mezi Wikipedií a Commons. Pochopit pravidla ohledně autorských práv a zvládnout poměrně složitý postup, který je nutné provést, aby mohli obrázek do článku vložit. Nalezení vhodného obrázku na Commons navíc vyžaduje ještě více dovedností, například znalosti ohledně Wikidat či kategorií.

Úspěch kampaně "Wikipedia Pages Wanting Photos"

Kampaň Wikipedia Pages Wanting Photos (WPWP) byla překvapivým úspěchem: 600 uživatelů přidalo obrázky na 85 000 stran. Udělali to za pomoci několika komunitních nástrojů, které identifikovaly stránky bez obrázků a které navrhovaly možné obrázky prostřednictvím Wikidat. I když je potřebné naučit se důležité lekce o tom, jak pomoci nováčkům uspět s přidáváním obrázků, dává nám to jistotu, že uživatelé mohou být s přidáváním obrázků nadšeni a že jim mohou pomoci uvedené nástroje.

Když vše dohromady uvážíme...

Když přemýšlíme o všech těchto informacích celkově, myslíme si, že by bylo možné vytvořit strukturovaný úkol „přidat obrázek“, který by byl nejen zábavný pro nováčky, ale i produktivní pro Wikipedie.

Ověření myšlenky
''Mezi červnem roku 2020 a červencem roku 2021 pracoval tým Growth na komunitních konzultacích, výzkumech, vyhodnocení algoritmů a ověření proveditelnosti nového konceptu, aby zjistil, zda strukturované přidávání obrázků dává smysl. Tato práce vedla k rozhodnutí týmu ze srpna 2021 vytvořit první verzi této strukturované editace (viz první verze). Tato sekce shrnuje veškerou práci, která k tomuto rozhodnutí vedla.''

Algoritmus
Naše schopnost vytvořit strukturovaný úkol pro přidávání obrázků závisí na tom, zda dokážeme vytvořit algoritmus, který generuje dostatečně dobrá doporučení. Rozhodně nechceme naléhat na nováčky, aby do článků přidávali špatné obrázky. Což by způsobilo, že by po nich kontrolující museli opravovat jejich práci. Pokus o zjištění, zda bychom mohli vytvořit dobrý algoritmus, byl proto jednou z prvních věcí, na které jsme pracovali.

Logika
Na algoritmu jsme pracovali ve spolupráci s výzkumným týmem Wikimedie. Náš algoritmus by měl být co nejpřesnější a upřednostňovat předchozí rozhodnutí člověka. Namísto využívání technologie počítačového vidění, což může vyústit v nečekané výsledky, by algoritmus měl vytvářet existující informace, například z Wikidat, a využívat data uložená zkušenými wikipedisty. Algoritmus využívá tři způsoby, jak navrhnout obrázky k doposud neilustrovaným článkům:


 * Podívej se do Wikidat na položku k danému článku. Pokud je v ní nějaký obrázek (P18), použij jej.
 * Podívej se do Wikidat na položku pro daný článek. Pokud je k ní přiřazená kategorie na Commons (P373), vyber některý z obrázků v této kategorii.
 * Podívej se na ten samý článek v jiných jazykových verzích Wikipedie. Vyber obrázek z některého z těchto článků.

Algoritmus také obsahuje logiku pro vynechání obrázků, které jsou pravděpodobně použity jako ikonka nebo jako součást navigačního boxu (navbox).

Přesnost
K srpnu 2021 máme za sebou tři kola vyhodnocování algoritmu, pokaždé jsme jeho funkčnost vyhodnocovali v šesti jazycích: angličtině, francouzštině, arabštině, vietnamštině, češtině a korejštině. Vyhodnocení algoritmu provedli ambasadoři našeho týmu spolu s dalšími zkušenými wikipedisty, kteří jsou rodilými mluvčími některého z testovaných jazyků.

První dvě vyhodnocení

Prošli jsme 50 náhodně navržených obrázků v každém z jazyků a návrhy jsme umístili do jedné z následujících skupin:

Během práce na algoritmu jsme se sami sebe ptali: jak přesný algoritmus musí být? Stačí přesnost 75 %? Nebo musí být přesnost 90 %? Anebo může být přesnost dokonce jen 50 %? Správná odpověď závisí na úsudku nováčků a jejich trpělivosti s nekvalitními tipy. Více informací se dozvíme při uživatelském testování, kde pracujeme s reálnými nováčky.

Při prvním vyhodnocení algoritmu jsme přišli na spoustu jednoduchých vylepšení. Včetně typů na články a obrázky, které by bylo vhodné ignorovat. I bez implementace těchto vylepšení bylo 20-40 % všech návrhů zařazeno do skupiny "2", což znamená výborné doporučení (přesné číslo záleží na konkrétním projektu). Kompletní výsledky prvního vyhodnocení jsou k dispozici.

Do druhého hodnocení bylo zapracováno mnoho vylepšení a zvýšila se přesnost. Mezi 50–70 % byla řešení druhé třídy (v závislosti na wiki). Ale zvýšení přesnosti může snížit pokrytí, tj. počet článků, pro které můžeme vytvářet návrhyy. Pomocí konzervativních kritérií může být algoritmus schopen navrhnout pouze desítky tisíc návrhů v dané wiki. I když tato wiki obsahuje stovky tisíc nebo miliony článků. Věříme, že tento druh provázání by byl dostatečný k vytvoření počáteční verze této funkce. Zde si můžete prohlédnout úplné výsledky a poznámky z druhého hodnocení.

Třetí vyhodnocení

V květnu 2021 uskutečnil tým strukturovaných dat mnohem rozsáhlejší test algoritmu (včetně algoritmu MediaSearch), a to v arabštině, cebuánu, angličtině, vietnamštině, bengálštině a češtině. V rámci tohoto testu prošli zkušení wikipedisté 500 obrázků pro oba dva algoritmy. Návrhy poté ohodnotili buď jako "dobré", "postačující" nebo "špatné". Výsledky ukázaly následující:


 * Algoritmus návrhu obrázků se pohybuje od 65 do 80 % s přesností v závislosti na tom, zda počítáte "dobrý" nebo "dobrý + dobře", a v závislosti na wiki - hodnotiteli. Je zajímavé, že podle našich zkušeností s hodnocením použití obrázků se odborníci Wikimediani často navzájem neshodují, protože každý má své vlastní standardy, zda obrázky do článků patří nebo ne.
 * Wikidata P18 ("Wikidata") je největším zdrojem návrhů. Pohybuje se s přesností od 85 % do 95 %. Obrázky z jiných Wikipedií ("Cross-wiki") a z kategorií Commons připojených k položkám Wikidat ("kategorie Commons") jsou v podobném rozsahu méně přesné.
 * Obrázky z jiných Wikipedií ("Cross-wiki") jsou nejčastějším zdrojem návrhů. Jinými slovy, algoritmus je dává k dispozici více než ze zbývajících dvou zdrojů.

Kompletní výsledky je možné nalézt zde..

Pokrytí
Přesnost algoritmu je zjevně velmi důležitou součástí. Neméně důležité je jeho "pokrytí" - to znamená "kolik" napoví shodných obrázků. Přesnost a pokrytí bývají nepřímo úměrné: čím přesnější je algoritmus, tím méně návrhů bude dávat (protože návrhy navrhuje pouze tehdy, když si je jistý). Musíme odpovědět na tyto otázky: je algoritmus schopen poskytnout dostatek návrhů, které stojí za to vytvořit s ním funkci? Mohlo by to mít podstatný dopad na wiki? Podívali jsme se na 22 Wikipedií, abychom získali představu o odpovědích. Tabulka je pod těmito souhrnnými body:


 * Čísla pokrytí uvedená v tabulce se zdají být dostačující pro první verzi funkce "přidat obrázek". V každé wiki je dostatek kandidátských návrhů, takže za (a) uživatelům obrázky "nedojdou" a za (b) funkce by mohla mít podstatný dopad na to, jak je wiki ilustrovaná.
 * Na jednotlivých projektech je mezi 20 % (srbská Wikipedie) a 69 % (vietnamská Wikipedie) neilustrovaných článků.
 * Můžeme najít mezi 7 000 (bengálskými) až 155 000 (anglickými) neilustrovaných článků jako vhodné kandidáty na doplnění obrázků. Obecně je to dostatečný objem pro první verzi úkolu, takže uživatelé mají dostatek návrhů. U některých menších wiki, jako je třeba bengálská, se můžeme dostat k malým počtům, zejména když se uživatelé zaměří na zájmová témata. To znamená, že pro bengálskou wiki (má pouze asi 100 000 článků) bychom navrhli obrázky pro 7 % z nich, což je podstatné.
 * Pokud jde o to, jak velké vylepšení ilustracemi bychom mohli na wiki s tímto algoritmem udělat, pohybuje se strop od 1 % (cebwiki) do 9 % (trwiki). To je celkové procento dalších článků, které by skončily s ilustracemi, pokud je každý návrh dobrý a přidá se na wiki.
 * Wiki s nejnižším procentem neilustrovaných článků, pro které můžeme najít návrhy, jsou arzwiki a cebwiki, které mají velký objem článků vytvořených robotem. To dává smysl, protože mnoho z těchto článků pochází z konkrétních měst nebo z oblastí, které by neměly v Commons obrázky. Ale protože tyto wiki mají tolik článků, stále jich existují desítky tisíc, pro které má algoritmus návrhy.
 * Ve vzdálenější budoucnosti doufáme, že vylepšení algoritmu návrhu obrázků, MediaSearch nebo pracovních postupů pro nahrávání/titulkování/označování obrázků přinese více kandidátských návrhů.

MediaSearch
Jak již bylo uvedeno výše, tým Structured Data zkoumá pomocí algoritmu MediaSearch pro zvýšení pokrytí a získání více kandidátských návrhů.

MediaSearch funguje tak, že kombinuje tradiční textové vyhledávání a strukturovaná data a poskytuje relevantní výsledky pro vyhledávání jazykově nerozlišujícím způsobem. Při použití příkazů Wikidat přidaných jako součásti strukturovaných dat na Commons k obrázkům jako vstupu do hodnocení vyhledávání, může MediaSearch využívat výhody aliasů, souvisejících konceptů a štítků ve více jazycích ke zvýšení významu obrázku. Další informace o tom, jak funguje MediaSearch, jsou zde.

V únoru 2021 tým experimentoval s tím, jak poskytnout skóre spolehlivosti pro návrhy MediaSearch, které může algoritmus doporučení obrázků použít k určení, zda je návrh od MediaSearch dostatečně kvalitní pro použití v zadáních doporučených obrázků. Chceme mít jistotu, než je začleníme do této funkce, že si uživatelé budou jistí doporučeními, která MediaSearch poskytuje.

Tým pro strukturovaná data také zkoumá a vyvíjí způsob, jakým by mohli uživateli generovaní roboti využívat výsledky generované algoritmem pro doporučení obrázků a MediaSearch k automatickému přidávání obrázků do článků. Půjde o experiment ve wiki pro náročné roboty ve spolupráci s komunitními autory robotů. Více se o tomto úsilí můžete dozvědět nebo můžete vyjádřit zájem o účast na phabricator task.

V květnu 2021 bylo ve stejném hodnocení uvedeném výše v odstavci "Přesnost" zjištěno, že MediaSearch je mnohem méně přesný než algoritmus návrhů obrázků. Tam, kde byl algoritmus shody obrázků přibližně 78 % přesný, byly návrhy z MediaSearch přesné přibližně jen na 38 %. Tým Growth proto neplánuje použít MediaSearch ve svém prvním uvedení úkolu "přidat obrázek".

Otázky a diskuse


Otevřené otázky
Obázky jsou důležitou a viditelnou součástí Wikipedie. Je důležité, abychom funkci umožňující snadné přidávání obrázků do detailu promysleli, včetně možného dopadu na členy komunity. K tomu potřebujeme znát odpovědi na následující otevřené otázky. Také nás zajímá cokoli dalšího, co na toto téma napadne členy komunity.


 * Bude náš algoritmus dostatečně přesný, aby poskytl dostatek dobrých návrhů?
 * Jaká metadata o obrázku (případně o ilustrovaném článku) nováček potřebuje znát, aby mohl rozhodnout o tom, zda je obrázek pro daný článek vhodný?
 * Budou mít nováčci dostatečně dobrý úsudek při práci s návrhy algoritmu?
 * Budou s algoritmem umět pracovat i nováčci, kteří neumí anglicky (většina metadat na Commons je totiž v angličtině)?
 * Dovedou nováčci napsat dostatečně kvalitní popisky k obrázkům, které do článku vkládají?
 * Jak moc by měli nováčci posuzovat obrázky na základě jejich "kvality" a nikoli na základě jejich "významu"?
 * Bude tento úkol pro nováčky zajímavý? Bude je bavit? Bude složitý nebo naopak jednoduchý?
 * Jak bychom měli definovat "neilustrované články"?
 * Kam do neilustrovaného článku bychom měli obrázek vložit? Stačí ho vložit na začátek článku?
 * Jak můžeme snížit riziko systematického zkreslení návrhů (algoritmus by například mohl mít mnohem více návrhů pro témata týkající se Evropy či severní Ameriky)?
 * Zvýší tato funkcionalita riziko vandalismu? Jak můžeme toto riziko snížit?

Poznámky z komunitní konzultace z února 2021
Od prosince 2020 jsme pozvali členy komunity, aby diskutovali o nápadu "přidat obrázek" v pěti jazycích (angličtina, bengálština, arabština, vietnamština, čeština). Anglická diskuse se většinou odehrávala na této diskusní stránce, konverzace v místním jazyce na dalších čtyřech Wikipediích. Ozvalo se nám 28 členů komunity a tato část shrnuje některé z nejběžnějších a nejzajímavějších myšlenek. Tyto diskuse výrazně ovlivňují naši další sadu návrhů.


 * Souhrnně: Členové komunity jsou obecně opatrně optimističtí. Jinými slovy, souhlasí s tím, že využití algoritmu pro navrhování obrázků do Wikipedie by bylo užitečné, ale zároveň upozorňují na mnoho nástrah, které by projekt mohly zhatit. Některé z těchto nástrah jsou zvláště důležité při práci s nováčky.
 * Algoritmus
 * Zdá se, že členové komunity mají v algoritmus důvěru, protože čerpá pouze z představ zakódovaných do Wikidat zkušenými uživateli, spíše než z jakési nepředvídatelné umělé inteligence.
 * Ze tří zdrojů pro algoritmus (Wikidata P18, interwiki odkazy a kategorie Commons) se lidé shodli, že kategorie Commons je nejslabší (a že Wikidata jsou nejsilnější). To se při našem testování potvrdilo a kategorie Commons můžeme v budoucí cestě za výsledkem vyloučit.
 * Dostali jsme dobrou radu ohledně vyloučení určitých druhů stránek z této funkce: disambiguations, listes, years, good, and feature articles .. Můžeme také chtít vyloučit biografie živých osob.
 * Měli bychom také vyloučit obrázky, které mají na Commons šablonu pro mazání a které byly již dříve odstraněny ze stránek Wikipedie.
 * Úsudek nováčků
 * Členové komunity byli obecně znepokojeni tím, že nováčci budou uplatňovat špatný úsudek a dají algoritmu přednost i když budou pochybovat. Z našich uživatelských testů víme, že nováčci jsou schopni používat dobrý úsudek a věříme, že tímto podpoříme správný vývoj.
 * Při diskusi o kampani Wikipedia Pages Wanting Photos (WPWP) jsme se dozvěděli, že i když mnoho nováčků dokázalo prokázat dobrý úsudek, někteří příliš horliví uživatelé mohou provést rychle mnoho špatných zásahů, což způsobí spoustu práce kontrolujícím. Možná budeme chtít přidat nějaký druh ověření, abychom uživatelům zabránili příliš rychlém přidávání obrázků nebo v přidávání obrázků po opakovaném vrácení kontrolujícím.
 * Většina členů komunity souhlasila s tím, že "význam" je důležitější než "kvalita". Jinými slovy, pokud jediná existující fotka je rozmazaná, je to stále lepší, než vůbec žádný obrázek. Nováčci se při přidávání obrázků musí toto naučit.
 * Naše nápověda by měla říkat, že uživatelé by vše měli řešit zvolna a být opatrní a ne se snažit udělat za každou cenu co nejvíce zásahů.
 * Měli bychom uživatele naučit, že obrázky by měly být poučné a nejen dekorativní.
 * Uživatelské rozhraní
 * Několik lidí navrhlo, abychom uživatelům ukázali pouze několik kandidátů na obrázky, ne jenom jeden. To by zvýšilo pravděpodobnost, že k článkům budou připojeny pouze dobré obrázky.
 * Mnoho členů komunity doporučilo, abychom nováčkům umožnili vybrat si tematické oblasti zájmu (zejména zeměpisné oblasti), se kterými chtějí pracovat. Pokud si nováčci vyberou oblasti, ve kterých mají nějaké znalosti, mohou být schopni učinit přesnější rozhodnutí. Naštěstí by to byla automaticky součást funkce, kterou tým Growth staví, protože již nyní uživatelům umožňujeme při výběru navrhovaných úprav si vybrat mezi 64 tematickými oblastmi.
 * Členové komunity doporučují, aby nováčci místo náhledu viděli co nejvíce z kontextu článku. To jim pomůže pochopit závažnost úkolu a získat více informací, které mohou použít při rozhodování.
 * Vložení obrázku do článku
 * Dozvěděli jsme se o Wikidata infoboxech. Zjistili jsme, že u projektů, které používají Wikidata infoboxy, je upřednostňováno vložení obrázku do Wikidat namísto přímo do článku. Z tohoto důvodu budeme zkoumat, jak jsou tyto infoboxy na různých projektech časté.
 * Obecně to vypadá, že nejčastěji bude fungovat pravidlo "umístit obrázek pod šablony a nad obsah" v článku.
 * Někteří členové komunity nám poradili, že i když umístění v článku nebude dokonalé, ostatní uživatelé umístění rádi opraví, protože ta nejhorší práce při hledání správného obrázku bude již hotová.
 * Neanglicky mluvící uživatelé
 * Členové komunity nám připomněli, že některé prvky metadat Commons mohou být neurčitelné pro jazyk, například titulky a vyobrazení výroků. Podívali jsme se přesně na to, jak běžné to bylo v tomto odstavci.
 * Slyšeli jsme návrh, že i když uživatelé neovládají angličtinu, mohou metadata používat. Stačí když umí číst latinské znaky. Aby uživatel vytvořil hodně návrhů, v podstatě jen hledá název článku někde v metadatech obrázku.
 * Někdo také navrhl myšlenku použít, pro účely této funkce, strojový překlad (např. Google Translate) k přeložení metadat do místního jazyka.
 * Popisky
 * Členové komunity (spolu s členy týmu Growth) jsou skeptičtí ke schopnosti nováčků psát dobré popisky.
 * Bylo nám doporučeno ukazovat uživatelům příklad správných popisků spolu s vodítky přizpůsobenými konkrétnímu typu článku, ve kterém by popisek měl být.



Plánování uživatelského testování


Uvažujeme-li o otázkách otevřených výše, chceme kromě příspěvků komunity vygenerovat také kvantitativní a kvalitativní informace, které nám pomohou vyhodnotit proveditelnost vytvoření funkce "přidat obrázek". Ačkoli jsme hodnotili algoritmus mezi zaměstnanci a Wikimediány, je také důležité vidět, jak na ně reagují nováčci. Vidět, jak používají svůj úsudek při rozhodování o tom, zda obrázek do článku patří.

Za tímto účelem spustíme testy s usertesting.com, ve kterých mohou nováčci projít při úpravách Wikipedie potenciálními návrhy obrázků v prototypu a odpovědět "ano", "ne" nebo "nejistý". Pro test jsme vytvořili rychlý prototyp podložený skutečnými návrhy ze současného algoritmu. Prototyp ukazuje pouze jeden zásah za druhým, vše v souvislosti. Obrázky jsou zobrazeny společně se všemi příslušnými metadaty z Commons:


 * Název souboru
 * Velikost souboru
 * Datum nahrání
 * Uživatel
 * Popis
 * Popisek
 * Kategorie
 * Štítky

Ačkoli to nemusí být pracovní postup pro skutečné uživatele do budoucna, prototyp byl vytvořen tak, aby testeři mohli rychle projít množstvím potenciálních návrhů a generovat mnoho informací.

Abyste si vyzkoušeli interaktivní prototyp, využijte tento odkaz. Prosím, vezměte na vědomí, že v tomto prototypu byste se měli zaměřit na algoritmus samotný – zatím jsme o rozhraní pro uživatele moc důkladně nepřemýšleli. Prototyp zatím neukládá žádné editace a obsahuje šedesát návrhů vygenerovaných naším algoritmem.

Otázky, na které budeme během testování hledat odpovědi:


 * 1) Jsou účastníci schopni s jistotou potvrdit návrh algoritmu na základě poskytnutých informací?
 * 2) S jakou přesností jsou účastníci schopni vyhodnotit návrhy? Nepřeceňují (či nepodceňují) své schopnosti?
 * 3) Jak vnímají účastníci úkol přidávat obrázky do článků tímto způsobem? Považují to za snadné nebo těžké, zajímavé či nudné, obohacující nebo nevýznamné?
 * 4) Jaké informace při vyhodnocování návrhů algoritmu považují účastníci za nejcennější?
 * 5) Jsou účastníci schopni napsat dobrý popisek k obrázku, který považují za vhodný k vložení do článku?

Koncept A nebo koncept B
Pokud přemýšlíme o návrhu tohoto problému, máme podobnou otázku, jaké jsme čelili pro "přidání odkazu" s ohledem na koncept A nebo koncept B. V konceptu A by uživatelé dokončili úpravu celého článku, zatímco v konceptu B by provedli mnoho úprav za sebou, vše z doporučení. Koncept A dává uživateli více kontextu pro článek a jeho úpravy, zatímco koncept B upřednostňuje efektivitu.

Ve výše uvedeném prototypu umožňujícím vzájemnou komunikaci jsme použili koncept B, ve kterém uživatelé postupují prostřednictvím doporučených návrhů. Udělali jsme to, protože v našich uživatelských testech jsme chtěli vidět hodně příkladů vzájemných vztahů uživatelů a návrhů. To je ten druh vývoje, který by mohl fungovat nejlépe pro prostředí, jako je aplikace Wikipedie pro Android. V kontextu týmu Growth uvažujeme spíše podle konceptu A, ve kterém uživatel provádí úpravy v článku. To je směr, který jsme zvolili pro "přidání odkazu". Myslíme si, že by mohl být ze stejných důvodů vhodný i pro "přidání obrázku".

Jeden nebo více
Další důležitou otázkou je, zda uživatelům ukázat jediný navržený obrázek nebo jim zobrazit několik vhodných obrázků, ze kterých si mohou vybrat. Ve druhém případě je zde vyšší šance, že alespoň jedna z možností se do článku bude hodit. Zároveň to ale může motivovat nováčky vždy nějaký obrázek vybrat, a to i v případě, kdy se do článku nehodí ani jeden. Také je tato možnost, zejména s ohledem na mobilní zařízení, složitější na navržení. Vytvořili jsme návrhy pro tři různé možnosti:


 * Jediný: V tomto návrhu ukazujeme uživatelům pouze jeden navržený obrázek ke konkrétnímu článku a uživatel pak má možnost jej buď přijmout nebo odmítnout. Tento návrh je pro uživatele jednoduchý na používání.
 * Více: V tomto návrhu uživatelům ukazujeme několik návrhů, které mohou porovnat a vybrat z nich nejlepší (anebo všechny odmítnout). Zde hrozí, že uživatelé do článku přidají nejlepší ze špatných obrázků. To i přes to, že správným rozhodnutím by bylo nepřidat obrázek vůbec žádný.
 * Za sebou: Tento návrh nabízí více doporučených obrázků, ale uživatel se dívá na jeden po druhém. Zaznamenává úsudek a pak na konci vybere ten nejlepší obrázek, pokud se rozhodne, že se může použít více než jeden. To může uživateli pomoci soustředit se pouze na jeden obrázek po druhém, ale na konci přidá další krok k výběru.



Uživatelské testování - prosinec 2020
Podklady

Během prosince 2020 jsme použili web usertesting.com k provedení 15 testů interaktivního prototypu mobilního telefonu. Prototyp obsahoval pouze základní návrh, malý kontext nebo zapojení a byl testován pouze v angličtině s uživateli, kteří měli předchozí nebo jen malé zkušenosti s úpravou Wikipedie. Záměrně jsme nejprve v tomto procesu testovali základní návrh, abychom mohli shromáždit více znalostí. Primární otázky, které jsme chtěli tímto testem řešit, se týkaly proveditelnosti této funkce jako celku, nikoli přesnějších bodů projektu:


 * 1) Jsou účastníci schopni s jistotou potvrdit návrh algoritmu na základě poskytnutých informací?
 * 2) Jak přesní jsou účastníci při hodnocení návrhů? A jak se skutečná schopnost srovnává s jimi vnímanou schopností při hodnocení návrhů?
 * 3) Jak vnímají účastníci úkol přidávat obrázky do článků tímto způsobem? Považují to za snadné nebo těžké, zajímavé či nudné, obohacující nebo nevýznamné?
 * 4) Jaká metadata považují účastníci za nejcennější při vyhodnocování navržených obrázků?
 * 5) Jsou účastníci schopni napsat dobré popisky pro obrázky, které považují za vhodné k vložení do daného článku?

V testu jsme účastníky požádali, aby opatřili poznámkami alespoň 20 zápisů v článku s obrázky. Když klepli na ano, prototyp je požádal, aby napsali popisek, který by odpovídal obrázku v článku. Celkově jsme shromáždili 399 anotací.

Shrnutí

Myslíme si, že tyto uživatelské testy potvrzují, že bychom mohli úspěšně vytvořit funkci "přidat obrázek". Bude ale fungovat, pouze pokud ji správně navrhneme. Mnoho testerů úkolu dobře porozumělo, vzalo ho vážně a udělalo dobrá rozhodnutí - to nám dává jistotu, že je to myšlenka, se kterou stojí zato pokračovat. Na druhou stranu mnoho dalších uživatelů bylo zmateno. Nehodnotilo úkol kriticky a rozhodovalo se špatně - ale pro tyto zmatené uživatele bylo pro nás snadné najít způsoby, jak vylepšit návrh, dát jim odpovídající souvislost a vysvětlit závažnost úkolu.

Sledování

''Chcete-li zobrazit celou sadu návrhů, můžete procházet snímky. Pod snímky jsou zapsány nejdůležitější body.''




 * Obecné porozumění obrázkům odpovídajícím zadání k článkům Wikipedie bylo přiměřeně dobré, vzhledem k minimálním souvislostem poskytovaných nástroji a omezeným znalostem úprav Commons a Wikipedie. Po přepracování nástroje v uživatelském prostředí Wikipedie existují příležitosti ke zlepšení porozumění.
 * Všimli jsme si obecného vzorce: uživatel se podíval na název článku a prvních pár vět, poté se podíval na obrázek a zjistil, zda by se mohl věrohodně shodovat (např. Toto je článek o kostele a toto je obrázek kostela) . Pakhledal název článku někde v metadatech obrázku, buď v názvu souboru, popisu, titulku nebo kategoriích. Pokud jej našel, zápis potvrdil.
 * Každý úkol přiřazování obrázků dokázal rychle provést každý, kdo nebyl obeznámen s úpravou. V průměru trvalo prohlížení obrázku 34 sekund.
 * Všichni uvedli, že by měli zájem takový úkol provést, přičemž většina jej hodnotí jako snadný nebo velmi snadný.
 * Vnímaná kvalita obrázků a návrhů byla smíšená. Mnoho účastníků se zaměřilo na kompozici obrazu a další estetické faktory, které ovlivnily jejich ovlivňování myšlení.
 * Pro párování obrázků bylo rozhodujících pouze několik metadat obrázku od Commons: název souboru, popis, titulek, kategorie.
 * Mnoho účastníků se občas nesprávně pokoušelo spojit obrázky s jejich vlastními daty, spíše než s článkem (např. "Vypadá tento název souboru pro obrázek správně?"). Měly by být prozkoumány změny rozvržení a vizuální posloupnosti, aby se dalo lépe soustředit na souvislosti článku pro navrhovaný obrázek.
 * "Řada" dobrých zápisů přiměla některé účastníky k většímu zájmu s přijetím dalších obrázků - pokud bylo hodně "Ano", přestali hodnotit zadání kriticky.
 * Uživatelé špatně přidávali titulky. Často psali svá vysvětlení, která odpovídala obrázku, např. "Toto je vysoce kvalitní fotografie muže z článku." To je něco, co věříme, že lze vylepšit vývojem a vysvětlením pro uživatele.

Sledované oblasti


 * Členové našeho týmu komentovali všechny návrhy obrázků, které se uživatelům zobrazily v testu, a zaznamenali odpovědi, které uživatelé poskytli. Tímto způsobem jsme vytvořili několik statistik o tom, jak dobrou práci uživatelé odvedli.
 * Z 399 návrhů, se kterými se uživatelé setkali, klikli na "Ano" 192krát (48 %).
 * Z toho 33 nebylo správných zápisů a mohlo by být vráceno, kdyby byly přidány do článků ve skutečnosti. To je 17 % a říkáme tomu "pravděpodobné vrácení" (likely revert rate).

Nabídka


 * "Pravděpodobná míra návratnosti" 17 % je opravdu důležité číslo a chceme, aby toto číslo bylo co nejnižší. Na jedné straně se toto číslo blíží nebo je "nižší" než průměrná návratnost nových úprav ve Wikipedii (angličtina je 36 %, arabština je 26 %, francouzština je 22 %, vietnamština je 11 %). Na druhou stranu obrázky mají větší dopad a vyšší viditelnost než malé změny nebo slova v článku. Vezmeme-li v úvahu druhy změn, které bychom provedli v pracovním postupu, který jsme testovali (který byl optimalizován pro objem, nikoli pro kvalitu), myslíme si, že by se tato míra návratnosti výrazně snížila.
 * Myslíme si, že tento úkol by fungoval mnohem lépe v pracovním postupu, který uživatele zavede k celému článku. Na rozdíl od toho, že se mu rychle zobrazí jeden návrh za druhým v rychlém sledu. Tím, že uživatel vnímá celý článek, uvidí mnohem více souvislostí pro rozhodnutí, zda je obrázek vhodný a uvidí, kam se v článku uloží. Myslíme si, že uživatelé vnímají důležitost úkolu: že ve skutečnosti přidají obrázek k článku na Wikipedii. Myslíme si, že spíše než být rychlý bude uživatel při přidávání obrázků opatrnější. Je to stejné rozhodnutí, k jakému jsme přišli pro "přidání odkazu", když jsme se rozhodli vybudovat pracovní postup "Koncept A".
 * Myslíme si také, že výsledky se zlepší díky zapojení, vysvětlení a příkladům. To platí zejména pro popisky. Myslíme si, že pokud ukážeme uživatelům několik příkladů dobrých titulků, pochopí, jak je správně napsat. Mohli bychom je také vyzvat, aby jako výchozí bod použili popis nebo popisek z Commons.
 * Náš tým v poslední době diskutuje o tom, zda by bylo lepší přijmout rámec "spolupracujícího rozhodování", ve kterém by do článku nebyl přidán obrázek, dokud jej nepotvrdí dva uživatelé, místo jednoho. To by zvýšilo přesnost. Ale vyvolávají se tím otázky, zda je takový pracovní postup v souladu s hodnotami Wikipedie a který uživatel získá uznání za úpravu.

Metadata
Uživatelské testování ukázalo, že metadata k obrázku načtená z Commons (jméno souboru, jeho popis a popisek, apod.) jsou nezbytně nutná pro to, aby uživatel mohl s jistotou rozhodnout, zda obrázek do článku patří nebo ne. Například, ačkoliv uživatel může snadno vidět, že článek je o nějakém kostele, a že na obrázku je nějaký kostel, až metadata jim umožní určit, zda je v článku i na obrázku ten samý kostel. Uživatelské testování ukázalo, že nejdůležitější jsou následující metadata: jméno souboru, popis, popisek a kategorie. Mezi metadata, která užitečná nebyla, se řadí například velikost souboru, datum nahrání nebo uživatelské jméno nahrávajícího.

Vzhledem k tomu, že metadata jsou klíčovou součástí rozhodování, přemýšleli jsme o tom, zda budou muset mít uživatelé k tomuto úkolu metadata ve svém mateřském jazyce. Zejména s ohledem na skutečnost, že většina metadat Commons je v angličtině. U 22 wiki jsme se podívali na procento návrhů obrázků z algoritmu, který má prvky metadat v místním jazyce. Jinými slovy, kolik z nich má obrázky, které lze přiřadit k neilustrovaným článkům v arabské Wikipedii, arabské popisy, titulky a vyobrazení? Tabulka je pod těmito souhrnnými body:


 * Všeobecně řečeno, metadata nebývají přeložena do místních jazyků. Výjimkou je angličtina.
 * U všech wiki kromě angličtiny má popis místního jazyka méně než 7 % návrhů obrázků (angličtina je na 52 %).
 * U všech wiki kromě angličtiny má méně než 0,5 % návrhů obrázků místní popisy v angličtině (angličtina je 3,6 %).
 * U článků s obrázkem se wiki pohybují mezi 3 % (srbské) a 10 % (švédské) popisy obrázků.
 * Nízké pokrytí popisů a titulků v místním jazycev znamená, že ve většině wiki existuje jen velmi málo obrázků, které bychom mohli navrhnout uživatelům s metadaty místním jazykem. Některé z větších wiki mají několik tisíc kandidátů s popisem v místním jazyce. Ale žádné neanglické wiki nemají více než 1 000 kandidátů s titulky v místním jazyce.
 * Ačkoli je pokrytí vyšší, očekáváme, že příkazy vyobrazení obvykle neobsahují dostatečné detaily k pozitivnímu nalezení návrhu. Například pro vyobrazení kostela sv. Pavla v Chicagu na fotografii je mnohem pravděpodobnější při zadání "church" (kostel) než "St. Paul’s Church in Chicago" (sv. Paul's Church v Chicagu).
 * Možná budeme muset upřednostňovat takové návrhy, ke kterým existují místní metadata. Dokud ale nebudou existovat funkce, které zvýší pokrytí souborů metadaty v místních jazycích, spoléhání se na přeložená metadata není pro neanglické projekty vhodná cesta.

Vzhledem k tomu, že metadata místního jazyka mají nízké pokrytí, je naší současnou myšlenkou nabídnout úkol návrhu obrázků pouze těm uživatelům, kteří umí číst anglicky. Což bychom mohli uživateli položit jako rychlou otázku před zahájením úkolu. To bohužel omezuje počet uživatelů, kteří se mohou zúčastnit. Je to podobná situace jako u Nástroje pro překlad obsahu v tom, že uživatelé potřebují znát jazyk zdrojové wiki a cílové wiki, aby mohli přesouvat obsah z jedné wiki do druhé. Věříme také, že bude dostatečný počet těchto uživatelů na základě výsledků uvítacího průzkumu týmu Growth, který se nováčků ptá, jaké jazyky znají. V závislosti na wiki volí angličtinu 20 % až 50 % nově příchozích.

Android MVP
Detaily ohledně cs:MVP vyvinutém týmem aplikace pro Android můžete najít na této stránce.

Pozadí
Po mnoha komunitních diskusích, mnoha interních diskusích a výsledcích uživatelských testů se domníváme, že tento nápad "přidat obrázek" má dostatečný potenciál, aby se mohl dále rozvíjet. Členové komunity byli vesměs pozitivní, ale také opatrní - víme také, že stále existuje mnoho obav a důvodů, proč tato myšlenka nemusí fungovat podle očekávání. Dalším krokem, který chceme udělat, abychom se dozvěděli více, je vytvoření "minimálního životaschopného produktu" (MVP)(minimum viable product) pro aplikace Wikipedie pro Android. Nejdůležitější věcí na tomto MVP je, že neuloží žádné úpravy na Wikipedii. Spíše bude použit pouze ke sběru dat, vylepšení našeho algoritmu a vylepšení našeho projektu.

Aplikace pro Android je místem, kde editační tipy začaly a tým starající se o tuto aplikaci má strukturu, která jim umožňuje snadno přidávat další druhy editačních tipů. Toto jsou nejdůležitější informace:


 * Aplikace bude mít nový typ úkolu, o kterém uživatelé vědí, že nám pomůže pouze vylepšit naše algoritmy a návrhy.
 * Uživatelům ukáže návrhy a oni zvolí buď "Ano", "Ne" nebo "Přeskočit".
 * Zaznamenáme data o tom, jaká rozhodnutí uživatelé zvolili. Tato data použijeme k vylepšení algoritmu a uživatelského rozhraní. Budeme také přemýšlet o tom, jakým způsobem můžeme totéž vytvořit pro web.
 * Na Wikipedii se nebudou ukládat žádné editace, což znamená, že jde o projekt s velmi nízkou mírou rizika.

Výsledky
Tým Androidu vydal aplikaci v květnu 2021 a během několika týdnů tisíce uživatelů vyhodnotily desítky tisíc doporučení obrázků pomocí algoritmu návrhu obrázků. Výsledná data umožnila týmu Growth rozhodnout se pokračovat první revizí úkolu "přidat obrázek". Při zkoumání dat jsme se pokoušeli zodpovědět dvě důležité otázky týkající se "zapojení" a "účinnosti".

Angažovanost: líbí se tento úkol uživatelům všech jazyků a chtějí jej plnit?
 * V průměru uživatelé MVP aplikace pro Android vyřídili asi 11 návrhů. I když jde o menší číslo, než u popisků obrázků a překladu popisů, jde o větší číslo, než u zbylých čtyř editačních tipů pro aplikace Android.
 * Úpravy návrhu obrázků vykazovaly podstatně nižší míru uložení než jiné druhy úprav navržených systémem Android. Existují obavy, že není možné vypočítat srovnání mezi jablky a jablky. Dále si myslíme, že skutečnost, že úpravy z tohoto MVP který ve skutečnosti nemění wiki, by vedla k nižšímu ukládání, protože uživatelé by byli méně motivováni vracet se a dělat více.
 * Pokud jde o jazyk, data byla shromažďována pro uživatele v anglické Wikipedii a také od uživatelů, kteří používají výhradně neanglickou Wikipedii, včetně velkého počtu hodnocení z německé, turecké, francouzské, portugalské a španělské Wikipedie. Očekávali jsme, že uživatelé angličtiny a neangličtiny budou mít zcela odlišné zkušenosti, protože většina metadat u obrázků v Commons je v angličtině. Sledované oblasti však byly napříč oběma skupinami nápadně podobné, včetně počtu dokončených úkolů, času stráveného nad úkolem, udržení a úsudku. To svědčí o tom, že je tento úkol použitelný napříč wiki, i když je pravděpodobné, že mnoho neanglických uživatelů Androidu je ve skutečnosti dvojjazyčných.

Účinnost: Budou výsledné úpravy dostatečně kvalitní?
 * 80 % z návrhů, u kterých nováčci řekli "ano", jsou skutečně vhodnými obrázky (podle zkušených wikipedistů). To znamená, že úsudek nováčků vylepšil algoritmus o asi pět procent na účinnosti.
 * Toto číslo se zvedne na 82-83 %, když odebereme nováčky, kteří posuzováním obrázku stráví minimum času.
 * Experti se spolu shodnou pouze v 85 % případů.
 * Protože přesnost nováčků stoupá, když jsou odstraněny určité druhy nováčků (ti, kteří hodnotí příliš rychle nebo kteří přijímají příliš mnoho návrhů), domníváme se, že automatizované "brány kvality" by mohly zvýšit výkon nováčků na úroveň přijatelnou komunitami.

Kompletní výsledky můžete najít zde.

Vývoj
Tato sekce obsahuje odkazy na stránky s podrobnými informacemi ohledně technických aspektů tohoto projektu:


 * Práce týmu Platform Engineering na "proof of concept" (ověření konceptu) API vyvinutém pro aplikaci pro Android
 * Úkoly na Phabricatoru týkající se MVP vyvinutém týmem aplikací pro Android
 * Úkoly na Phabricatoru týkající se vyhodnocení algoritmu

Iterace 1 (cesta k dosažení výsledku)
V červenci 2021 se tým Growth rozhodl pracovat na tvorbě první verze nové strukturované editace: přidávání obrázků (této první verzi budeme nadále říkat Iterace 1). Šlo o obtížné rozhodnutí, protože existuje mnoho nezodpovězených otázek a přidávání obrázků do článků prováděné nováčky spolu nese určitá rizika. Jelikož jsme ale předtím nápad ověřovali a také si pečlivě prošli komunitní konzultace a výsledky testování algoritmu, rozhodli jsme se vytvořit Iteraci 1, a získávat další poznatky v průběhu. Toto jsou nejdůležitější dosavadní poznatky, které nám umožnily začít pracovat na Iteraci 1:


 * Opatrná komunitní podpora: Členové komunity jsou opatrně optimističtí; souhlasí s tím, že by šlo cenný projekt, ale zmínili mnoho rizik a nebezpečí; myslíme si, že tato rizika můžeme vyřešit pomocí dobrého grafického návrhu.
 * Přesný algoritmus: Algoritmus pro doporučování obrázků má přesnost 65-80 %, měřenou pomocí několika odlišných testů. Podařilo se nám algoritmus postupem času vylepšit.
 * Uživatelské testování: Mnoho nováčků, kteří si vyzkoušeli prototyp, považovalo tento úkol za zábavný.
 * Android MVP: Výsledky z MVP aplikace pro Android ukázaly, že nováčci mají vesměs dobrý úsudek. Aplikace pro Android nás také upozornila na to, jak můžeme přidávání obrázků uvádět lépe. Výsledky také ukázaly, že tento úkol by mohl fungovat ve více jazycích.
 * Celkové poznatky: Jelikož jsme na mnoho nástrah, které na nás čekají, již narazili během ověřování nápadu, budeme schopni na ně myslet při tvorbě grafického návrhu. Předcházející práce na přidávání obrázků nám dala dostatečné množství informací k tomu, abychom mohli odhadnout, jak dobrý úsudek budou nováčci mít a jak můžeme předejít škodlivým úpravám.

Předpoklady
Nejsme si jisti, zda přidávání obrázků bude dobře fungovat – z tohoto důvodu plánujeme strukturovanou editaci vybudovat po malých částech a z každé části se poučit. Jsme ale přesvědčeni, že s využitím poznatků z předchozích projektů týmu Growth jsme schopni vytvořit funkční odlehčenou první verzi. Jedním ze způsobů, jak můžeme o postupné tvorbě přemýšlet, je testování hypotéz. Níže vám představujeme pět optimistických hypotéz, které máme pro přidávání obrázků. Naším cílem v první verzi je potvrzení či vyvrácení těchto hypotéz.


 * 1) Popisky: Uživatelé umí psát dostatečně kvalitní popisky. Toto je naše největší otevřená otázka, jelikož obrázky vložené do článků na Wikipedii obecně mají mít vhodný popisek, ale Android MVP toto dostatečně neotestoval.
 * 2) Úsudek nováčků: Nováčci budou mít dostatečně správný úsudek, aby jejich editace byly komunitou přijaty
 * 3) Zájem: Uživatelé mají o strukturovanou editaci na mobilním zařízení zájem; uloží více než jednu editaci a k editování se vrací.
 * 4) Jazyky: Uživatelé nemluvící anglicky budou schopni úkol dokončit. Toto je důležité, protože většina metadat na Commons je v angličtině, přičemž je důležité umět přečíst název souboru, jeho popis a popisek z Commons, aby uživatel mohl s jistotou potvrdit návrh.
 * 5) Soubor pravidel: Navrhovaný vzor, který jsme vytvořili pro "přidávání odkazů" bude fungovat i pro obrázky.

Rozsah projektu
Protože hlavním účelem práce na Iteraci 1 je získávání zkušeností, chceme produkt dostat co nejrychleji k reálným uživatelům. To znamená, že potřebujeme vytvořit co nejmenší produkt, který bude možné rychle vydat. Níže jsou nejdůležitější omezení rozsahu projektu, které bychom chtěli pro první verzi uplatnit.


 * Pouze mobilní zařízení: Ačkoli většina zkušených wikimediánů nejčastěji používá desktopové zařízení, velká část nováčků používá mobilní zařízení, což zvětšuje význam mobilních zařízení pro práci týmu Growth. Pokud vytvoříme první verzi pouze pro mobil, umožní nám to soustředit se na toto publikum, zatímco se nebudeme muset zabývat vytvořením obdobného návrhu pro desktop.
 * Statické návrhy: Abychom ušetřili čas strávený tvorbou služby pro navrhování obrázků, spustíme algoritmus pouze jednou a pro první verzi použijeme stálý set návrhů. I když návrhy nebudou používat nejnovější obrázky a ostatní údaje, myslíme si, že pro první verzi budou dostatečné.
 * Pravidla návrhu: Náš vývoj bude obecně postupovat podle stejných vzorů jako vývoj pro náš předchozí strukturovaný úkol "přidat odkaz".
 * Neilustrované články: Návrhy obrázků omezíme pouze na články, ve kterých se zatím nevyskytuje vůbec žádný obrázek. Nebudeme se zabývat články, ve kterých sice obrázek již je, ale mělo by jich tam být více. To znamená, že výsledný produkt nebude muset obsahovat kroky pro rozhodnutí, kam do článku obrázek vložit. Jelikož půjde o jediný obrázek v článku, dává smysl ho vložit jako hlavní obrázek na začátek článku.
 * Žádné infoboxy: Omezíme návrhy pouze na články, ve kterých se nevyskytují infoboxy. To je proto, že u neilustrovaných článků s infoboxem by zpravidla obrázek měl být vložen do infoboxu. Je ovšem velmi obtížné správně určit kam a jak do infoboxu obrázek a jeho popisek vložit. Toto nám zároveň umožní nezabývat se problematikou článků s infoboxy založenými na Wikidatech.
 * Jeden obrázek: Ačkoliv algoritmus umí navrhnout více obrázků pro jeden článek, první verze přidávání obrázků bude nabízet pouze jeden obrázek, se kterým si je algoritmus nejjistější. To umožní vytvořit jednodušší rozhraní pro nováčky, které bude zároveň jednodušší na tvorbu.
 * Kontrola kvality: Myslíme si, že bychom měli do produktu zahrnout nějaký automatický mechanismus, který by uživatelům zabránil uložení velkého množství špatných editací během krátké doby. To můžeme uskutečnit například takto: (a) umožnit uživatelům přidat pouze omezené množství obrázků za den, (b) zobrazit další instrukce uživatelům, kteří návrhy posuzují příliš krátkou dobu, (c) zobrazit další instrukce uživatelům, kteří schvalují příliš mnoho návrhů. Podnět k této myšlence byl dán zkušeností z anglické Wikipedie s kampaní Wikipedia Pages Wanting Photos.
 * Pouze pilotní projekty: Stejně jako u všech nových produktů týmu Growth, nejprve produkt nasadíme na našich čtyřech pilotních projektech (arabská, vietnamská, bengálská a česká Wikipedie). Na těchto projektech jsou komunity, které sledují práci týmu Growth zblízka a o všech experimentech vědí s předstihem. Tým Growth na těchto projektech zaměstnává komunitní ambassadory, kteří mu pomáhají s komunikací. V příštím roce do seznamu pilotních projektů možná zařadíme i španělskou a portugalskou Wikipedii.

Zajímá nás, zda tento přístup považují členové komunit za rozumný a nebo zda si myslí, že v průběhu práce na projektu narazíme na limity způsobené některým z výše popsaných omezení rozsahu projektu.

Makety a prototypy
Pro první verzi projektu zvažujeme několik možných návrhů, které jsme vytvořili na základě výsledků předchozího uživatelského testování a MVP v aplikaci pro Android. Pro každou z částí uživatelského rozhraní jsme připravili dvě alternativy. Nováčkům pravděpodobně uvolníme obě (v rámci A/B testování), abychom zjistili, která je úspěšnější. Naše uživatelské testy budou probíhat v angličtině a španělštině. Což je první testování našeho týmu v neanglickém jazyce. Doufáme také, že nám členové komunity pomohou v přemýšlení nad těmito dvěma variantami.

Prototypy pro uživatelské testování

Nejjednodušší způsob, jak vyzkoušet, o čem uvažujeme, je vytvořit interaktivní prototypy. Postavili jsme prototypy pro provedení "Konceptu A" i "Konceptu B". Jsou k dispozici v angličtině i ve španělštině. Nejedná se o skutečný wiki software, ale spíše o jeho simulaci. To znamená, že se ve skutečnosti neukládají žádné úpravy a nefungují všechna tlačítka a interakce - ale jen ta nejdůležitější nutná pro práci s projektem "add an image" (přidat obrázek) "'do" (udělej).


 * Koncept A (anglicky)
 * Koncept B (anglicky)
 * Koncept A (španělsky)
 * Koncept B (španělsky)

Grafické návrhy pro uživatelské testování

Níže jsou statické obrázky našich grafických návrhů. Členové komunit se mohou podívat i na soubor Figma vytvořený vývojáři týmu Growth. Návrhy z této stránky najdete v pravém dolním rohu. Soubor Figma také obsahuje různé poznámky a inspirace ke grafickým návrhům.

Výběr článku

Tyto návrhy se zabývají první částí procesu přidávání obrázků, kde si uživatel z nabízených článků vybere ten, na kterém by chtěl pracovat. Chceme, aby karta s článkem byla atraktivní, ale zároveň aby uživatele nemátla.

Konečné návrhy pro Opakování 1

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

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.

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

Read more about the Structured Data Across Wikimedia team’s work here: Section-level image suggestions. 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
A data scientist will measure the impact of this task, and closely look at Growth's key performance indicators like: activation, retention, productivity, and revert rate (T332344).