Growth/Personalizovaný první den/Strukturované editace/Přidávání obrázků

Growth

Funkce Growth

Nástroje k použití

Aktualizace

Growth tým

Řešeno přes Phabricator
Úkol T256081

Projekty Wikimedia Foundation Add an image Suggest images from Commons that newcomers could add to Wikipedia articles Skupina: Growth Začal: 2020-10-01 Členové týmu: Gergő Tisza (software engineer), Benoît Evellin (community relations specialist), Elena Tonkovidova (QA engineer), Kosta Harlan (software engineer), Morten Warncke-Wang (data analyst), Rita Ho (senior user experience designer), Max Binder (coach) Vedoucí: Roan Kattouw Vedení: Marcella Florence (engineering), Marshall Miller (product) Aktualizace: Most updates posted here .

Funkce "Přidat obrázek" na mobilu

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)
• 2023-10-16: Image Recommendations added to the Android Wikipedia app
• 2024-04-11: Publish "Add an image" Experiment Analysis
• Další: Release "Add an image" to more Wikipedias

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

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 Doporučení obrázků pro aplikaci Wikipedie pro Android pomocí stejných základních komponent. Kromě toho tým strukturovaných dat vydal oznámení o doporučeních obrázků cílená na zkušenější uživatele a těží ze strukturovaných dat na Commons.

Proč zrovna obrázky?

Rozbalit a přečíst si sekci "Proč 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. 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" V rámci kampaně Wikipedia Pages Wanting Photos přidalo 600 uživatelů ilustrace do celkem 85 tisíc stránek. 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 Wikipedii.

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.

Klikněte pro přečtení sekce "Ověření nápadu"

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: Skupina Vysvětlení Příklad 2 Výborný obrázek pro daný článek, ilustrující věc uvedenou v názvu článku. Článek se jmenuje "Motýl" a na obrázku je vyobrazen motýl. 1 Dobrý obrázek, ale je obtížné to potvrdit, pokud uživatel nemá dostatečný kontext. Obrázek by vyžadoval informovaný popisek. Článek se jmenuje "Motýl" a obrázek zobrazuje významného vědce zabývajícího se motýly. 0 Obrázek se do článku nehodí. Článek se jmenuje "Motýl" a na obrázku je vyobrazen automobil. -1 Obrázek zobrazuje předmět v článku, ale není vhodný pro místní kulturu. Článek se jmenuje "Motýl" a na obrázku je zobrazen motýl, který se na daném místě nevyskytuje. -2 Zavádějící obrázek, o kterém by si nováček mohl omylem myslet, že je správný. Článek se jmenuje "Motýl", ale na obrázku je můra. -3 Na stránce by neměl být vůbec žádný obrázek. Rozcestníky, seznamy, či články "o křestních jménech". 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 wikimediáni často navzájem neshodují, protože každý má své vlastní standardy, zda obrázky do článků patří nebo ne. Wikidata P18 ("Wikidata") jsou největším zdrojem návrhů. Pohybují 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ů. Zdroj Přesnost (dobré) Přesnost (dobré+uspokojivé) Podíl na pokrytí Wikidata 85% 93% 7% Cross-wiki 56% 76% 80% kategorie Commons 51% 76% 13% Vše 63% 80% 100% 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 wikinách, 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 wikinách 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. Wikiny 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 wikiny 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ů. Wiki Celkem článků Neilustrovaných článků % neilustrovaných Mají návrh obrázku % neilustrovaných článků s návrhem enwiki 6 199 587 2 932 613 47% 154 508 5% trwiki 382 825 151 620 40% 35 561 23% bnwiki 99 172 33 642 34% 6 921 21% frwiki 2 273 610 952 994 42% 94 594 10% ruwiki 1 680 385 584 290 35% 60 415 10% fawiki 755 709 304 253 40% 55 382 18% arwiki 1 080 564 581 710 54% 59 551 10% dewiki 2 506 229 1 190 517 48% 110 771 9% ptwiki 1 048 255 388 605 37% 79 483 20% hewiki 282 232 73 261 26% 14 453 20% cswiki 467 573 182 177 39% 37 300 20% kowiki 526 990 274 338 52% 48 417 18% plwiki 1 441 429 560 334 39% 71 456 13% ukwiki 1 058 563 365 209 35% 51 154 14% svwiki 3 514 965 1 686 664 48% 91 337 5% huwiki 479 215 170 936 36% 26 559 16% euwiki 364 458 105 412 29% 21 481 20% hywiki 278 487 96 729 35% 13 531 14% arzwiki 1 171 440 759 418 65% 32 956 4% srwiki 640 678 126 102 20% 27 326 22% viwiki 1 259 538 867 672 69% 83 785 10% cebwiki 5 377 763 1 357 405 25% 61 839 5% MediaSearch 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. 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 wikiny 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 diskusní stránce Phabricatoru. 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 Obrá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 a 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 jednoho. 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í Snímek obrazovky z prototypu možné podoby nástroje, který byl použit v rámci uživatelského testování. Metadata o obrázku načtená z Commons jsou k dispozici po posunu dolů. 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: Jsou účastníci schopni s jistotou potvrdit návrh algoritmu na základě poskytnutých informací? S jakou přesností jsou účastníci schopni vyhodnotit návrhy? Nepřeceňují (či nepodceňují) své schopnosti? 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é? Jaké informace při vyhodnocování návrhů algoritmu považují účastníci za nejcennější? Jsou účastníci schopni napsat dobrý popisek k obrázku, který považují za vhodný k vložení do článku? Návrh 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. Jediný: V tomto návrhu uživatelům ukazujeme pouze jeden obrázek, ten uživatel může buď akceptovat nebo odmítnout. Více: Tento návrh ukazuje uživateli více potenciálních doporučení k porovnání a výběru toho nejlepšího nebo odmítnutí všech. Za sebou: Tento návrh nabízí více doporučených obrázků, ale uživatel je prohlíží postupně, zaznamenává úsudek a pak na konci vybere ten nejlepší, pokud zjistil, že se může použít více než jeden. 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: Jsou účastníci schopni s jistotou potvrdit návrh algoritmu na základě poskytnutých informací? 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ů? 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é? Jaká metadata považují účastníci za nejcennější při vyhodnocování navržených obrázků? 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. Prezentace obsahující kompletní výsledky uživatelského testování 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) . Potom hledal 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 wikin 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 wikin 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 wikin 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 wikiny pohybují mezi 3 % (srbské) a 10 % (švédské) popisy obrázků. Nízké pokrytí popisů a titulků v místním jazyce znamená, že ve většině wikin 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 wikin mají několik tisíc kandidátů s popisem v místním jazyce. Ale žádné neanglické wikiny 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. Wikiprojekt Popis v místním jazyce Popisek v místním jazyce Zobrazuje enwiki 51.71% 3.65% 6.20% trwiki 1.91% 1.32% 4.33% bnwiki 0.51% 1.08% 5.74% frwiki 5.95% 0.66% 8.52% ruwiki 4.05% 0.61% 6.73% fawiki 0.58% 0.59% 4.06% arwiki 0.97% 0.59% 7.00% dewiki 6.11% 0.49% 5.16% ptwiki 1.38% 0.34% 4.27% hewiki 1.20% 0.30% 6.18% cswiki 1.82% 0.23% 5.71% kowiki 0.97% 0.19% 4.80% plwiki 1.82% 0.17% 5.93% ukwiki 1.04% 0.12% 5.95% svwiki 0.90% 0.07% 10.10% huwiki 2.28% 0.03% 5.96% euwiki 0.27% 0.03% 6.20% hywiki 0.69% 0.03% 5.39% arzwiki 0.02% 0.01% 6.84% srwiki 0.36% 0.01% 3.46% viwiki 0.08% 0.00% 6.63% cebwiki 0.00% 0.00% 9.93% 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 hruškami a jablky. Dále si myslíme, že skutečnost, že úpravy z tohoto MVP který ve skutečnosti nemění wikiny, by vedla k nižšímu ukládání, protože uživatelé by byli méně motivováni vracet se a udě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.

Projekt

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.

• 
  Koncept A: Obsahuje rozmazanou verzi náhledu k navrženému obrázku, což úkol dělá více vizuálním.
• 
  Koncept B: Nemá žádný náhledový obrázek, aby si uživatel nezačal myslet, že tento obrázek "k článku patří".

Zahájení

Tyto návrhy popisují, co uživatelé uvidí po otevření prvního článku. Cílem této části procesu je vysvětlit, o co jde a jak dosáhnout úspěchu. Chceme, aby uživatelé porozuměli tomu, že přidávání obrázků je nutné brát seriózně. Poznámka: Konkrétní znění zatím nebylo přesně navrženo -- v tuto chvíli přemýšlíme o tom, jak bychom uživateli zprávu měli předat.

• 
  Koncept A: Uvítací obrazovka je zobrazená přes celou obrazovku a vysvětluje, jakým způsobem je možné úkol dokončit.
• 
  Koncept B: Několik popup (vyskakovacích) oken vysvětlující různé součásti procesu přidávání obrázků

Přidávání obrázků

Tyto návrhy se týkají té části procesu, kde uživatel vidí navržený obrázek spolu s jeho metadaty načtenými z Commons. Rozhodne se, zda by obrázek měl či neměl být do článku přidán. Z uživatelského testování víme, že pro uživatele je důležité znát název souboru, jeho popis i popisek. To jim umožní správné rozhodnutí. Dostat všechny tyto informace na malou obrazovku mobilního zařízení je tou největší výzvou.

• 
  Koncept A: Navržený obrázek je umístěn ve stejném místě, jako bude po uložení v článku, což uživateli dává najevo, že obrázek skutečně skončí v článku. Uživatelé mohou obrázek zobrazit přes celou obrazovku a přes ikonu "i" si mohou zobrazit více metadat.
• 
  Koncept B: Navrhovaný obrázek je zobrazen na kartě "inspektor obrazu" spolu s metadaty z Commons, které jsou součástí obrázku. Uživatel může obrázek rozbalit a zobrazit na celou obrazovku.

Popisek a zveřejnění

Tyto návrhy se týkají té části procesu, kdy se uživatel již rozhodl obrázek do článku přidat. Nyní k němu musí napsat popisek. Toto bude pravděpodobně pro nováčky tou nejsložitější částí celého procesu. Stále přemýšlíme o tom, jak nováčkům vysvětlit, jaké druhy popisků jsou vhodné.

• 
  Koncept A: Popisek obrázku je přidáván pomocí existujícího nástroje vizuálního editoru, zobrazeném na samostatné obrazovce.
• 
  Koncept B: Popisek je přidáván přímo v článku, což uživateli pomůže zachytit kontext vyplývající z umístění tvořeného popisku.

Odmítnutí

Když uživatel odmítne návrh, chceme vědět z jakého důvodu je přesvědčen, že je návrh nesprávný. To nám pomůže vylepšit algoritmus. Také jde o příležitost uživateli připomenout kritéria, podle kterých má návrhy vyhodnocovat.

• 
  Koncept A: Uživatel si může vybrat pouze jednu možnost.
• 
  Koncept B: Uživatel si může vybrat vícero možností.

Výsledky uživatelských testů září 2021

V srpnu 2021 jsme provedli 32 uživatelských testů mezi lidmi, kteří byli v editaci Wikipedie noví, pomocí respondentů z usertesting.com. Polovina respondentů prošla konceptem A a polovina konceptem B. Aby bylo možné reprezentovat rozmanitější perspektivy, bylo to poprvé, kdy tým Growth provedl uživatelské testy mimo angličtinu: Test ve španělštině absolvovalo 11 respondentů, z nichž všichni se nacházeli mimo Spojené státy. To nám pomůže zajistit, že vytváříme funkci, která je hodnotná a srozumitelná pro obyvatelstvo po celém světě.

Naším cílem testování bylo zjistit, které části konceptů návrhu fungovaly nejlépe, a odhalit další potenciální vylepšení. Toto jsou naše hlavní zjištění a změny v návrzích, které plánujeme provést.

• Zjištění
  • Koncept B jasně fungoval lépe pro účastníky testů z angličtiny i španělštiny, zejména:
    • Lepší pochopení úkolu. V konceptu A si uživatelé někdy mysleli, že obrázek je již v článku, kvůli jeho náhledu na navrhované kartě úprav a náhledu v článku.
    • Pečlivější zapojení a zvážení obsahu článku a metadat obrázků při hodnocení vhodnosti obrázku pro článek. Domníváme se, že je to proto, že oblasti článku a metadat byly jasně odděleny.
    • Větší využití detailů obrázku a obsahu článku při tvorbě titulků. Zkušenosti s titulky Concept B zobrazují celý text článku.
  • Další poznámky
    • Většina lidí tento úkol zpočátku špatně chápala jako nahrávání obrázků, když otevřeli modul Navrhované úpravy, bez ohledu na vývoj. Očekávání ohledně samoobslužných obrázků však bylo téměř u všech účastníků okamžitě opraveno, jakmile úkol otevřeli, a celkově Design B vyvolal lepší pochopení úkolu a úspěšné vyhodnocení obrázku než Design A.
    • Nováčci by těžili z větší informovanosti uživatelů o Commons a používání obrázků v článcích na Wikipedii, aby pochopili širší editační ekosystém Wikipedie a jejích sesterských projektů.
    • Uživatelé pochopili účel titulku a pochopili, že se zobrazí s obrázkem v článku na Wikipedii.
    • Španělští účastníci byli mnohem více naladěni na interwiki než angličtí účastníci. Potenciálně prozkoumejte způsoby, jak lépe vyhovět vícejazyčným/cross-wiki uživatelům.
    • Španělští účastníci potřebovali přeložit metadata Commons pro sebe, aby mohli psát dobré titulky ve španělštině.
    • Současný úkol vyžaduje několik různých dovedností, jako je vyhodnocování obrázků, psaní titulků a překlad (pro čtení metadat Commons z neanglické Wikipedie). V budoucnu mohou existovat výhody a příležitosti pro rozdělení tohoto úkolu na více úkolů, takže uživatelé nebudou muset mít všechny dovednosti, aby úkol dokončili.
• Změny
  • Nezobrazovat náhled navrhovaného obrázku na kartě ve zdroji navrhovaných úprav.
  • Nápovědy pro registraci fungovaly dobře, aby pomohly uživatelům porozumět úloze. U menších obrazovek však mohou být ohromující nebo nepřehledné. I když dáváme přednost implementaci popisků, rozhodli jsme se implementovat celoobrazovkové překryvy pro integraci do Iterace 1, protože dobré sestrojení popisků bude trvat podstatně déle. V budoucí iteraci můžeme implementovat popisky.
  • Obrázek a metadata obrázku musí být vedle sebe – když jsou v oddělených částech obrazovky, uživatelé jsou zmatení.
  • Protože je velmi důležité, aby uživatelé při rozhodování a psaní popisku zohledňovali metadata obrázku, musíme zvýšit viditelnost metadat pomocí jasnějších volání k jejich čtení.
  • Zahrneme do popisku s volným textem jednoduché ověření, jako je vynucení minimální délky titulků nebo zakázání, aby název souboru byl součástí titulku.
  • Uvedeme ukázky dobrých a špatných titulků ve vysvětlení kroku titulků.
  • Když uživatelé odmítnou návrh a uvedou důvod odmítnutí, některé z důvodů by neměly návrh odstranit z fronty, např. "Tohle téma neznám." Možná jiný uživatel bude schopen s jistotou provést porovnání.
• Příklad titulků: Níže jsou tři páry obrázků/článků použité v testu a skutečné titulky napsané uživatelskými testery. To nám dává představu o typech titulků, které můžeme od nováčků očekávat. Zdá se, že všechny jsou obecně na správné cestě, i když se pohybují od spíše "všeobecného textu" po spíše titulky. Najde se i pár, který se míjí účinkem.

• 
  Článek: Edward Edwards (Důstojník královského námořnictva)
  "Kresba HMS Pandora od Roberta Battyho"
  "HMS Pandora, jehož kapitánem byl admirál Edward Edwards, aby chytil vzbouřence."
  "Zobrazení potopení HMS Pandora z roku 1831"
  "Royal Navy"
  "Ilustrace potopení HMS Pandora"
• 
  Článek: Fiesque
  "Edouard Lalo, skladatel hudby opery Fiesque"
  "Foto Edouarda Lalo, skladatel Fiesque"
  "Edouard Lalo - 1865"
  "Eduard Lalo, kolem roku 1865"
  Tyto titulky byly přeloženy ze španělštiny.
• 
  Článek: Bahaettin Rahmi Bediz
  "Fotografie Bahaettina Rahmiho Bedize pořízená 1. ledna 1924, na snímku s jeho kolem"
  "Bahaettin Radmi Bediz dne 1. ledna 1924"
  "Rahmizadephoto1869"
  "Rahnizade Bahaeddin Bediz. V uniformě, stojící vedle kola"

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

Na základě výše uvedených zjištění uživatelských testů jsme vytvořili sadu návrhů, které implementujeme pro Iteraci 1. Nejlepší způsob, jak prozkoumat tyto návrhy, je zde v souboru Figma, který vždy obsahuje nejnovější verzi.

Měření

Hlavní ukazatele

Kdykoli nasadíme nové funkce, definujeme sadu "hlavních ukazatelů", které budeme sledovat během raných fází experimentu. Ty nám pomáhají rychle zjistit, zda se funkce obecně chová podle očekávání, a umožňují nám zjistit, zda nezpůsobuje nějaké škody na wikinách. Každý hlavní indikátor přichází s plánem činnosti v případě, že je dosaženo definované prahové hodnoty, aby tým věděl, co má dělat.

Indikátor	Plán akce
Návratová rychlost	To naznačuje, že komunita považuje úpravy "přidat obrázek" za nekonstruktivní. Pokud je míra vracení pro "přidat obrázek" podstatně vyšší než u nestrukturovaných úloh, provedeme analýzu vrácených změn, abychom pochopili, co toto zvýšení způsobuje, a poté úlohu upravíme, abychom snížili pravděpodobnost, že úpravy budou vráceny.
Míra odmítnutí uživatele	To může znamenat, že navrhujeme mnoho obrázků, které se nehodí. Pokud je míra odmítnutí vyšší než 40 %, provedeme kontrolu algoritmu návrhu obrázku a upravíme prahové hodnoty nebo provedeme změny, abychom zlepšili kvalitu doporučení.
Míra nadměrného přijetí	To by mohlo naznačovat, že někteří uživatelé ve skutečnosti neaplikují úsudek na své úkoly, což znamená, že možná budeme chtít implementovat různé brány kvality. (Jaké procento uživatelů, kteří dokončili relaci, nikdy neodmítli nebo nepřeskočili obrázek? Jaké procento uživatelů, kteří mají pět nebo více dokončených relací, nikdy neodmítlo nebo nepřeskočilo obrázek? Kolik relací u všech uživatelů obsahovalo pouze přijetí?)
Míra dokončení úkolu	To může znamenat, že došlo k problému s pracovním postupem úprav. Pokud je podíl uživatelů, kteří začnou úlohu "přidat obrázek" a dokončí ji, nižší než 55 % (míra dokončení pro "přidat odkaz"), prozkoumáme, kde v pracovním postupu uživatelé odejdou, a nasadíme změny návrhu, aby mohli pokračovat.

Shromáždili jsme údaje o využití funkce "přidat obrázek" od nasazení od 29. listopadu 2021 do 14. prosince 2021. "Přidat obrázek" bylo zpřístupněno pouze na mobilním webu a je přiděleno náhodným 50 % registrací na této platformě (vyjma naší 20 % celkové kontrolní skupiny). Zaměřujeme se proto na mobilní uživatele registrované po nasazení. Tato datová sada vylučovala známé testovací účty a neobsahuje data od uživatelů, kteří blokují protokolování událostí (např. prostřednictvím svého blokovače reklam).

Souhrn: Nejpozoruhodnější věcí na datech hlavního ukazatele je, jak málo úprav bylo dosud dokončeno: Pouze 89 úprav během prvních dvou týdnů. Během prvních dvou týdnů "přidávání odkazu" bylo provedeno téměř 300 úprav. Tato funkce byla nasazena jak uživatelům stolních počítačů, tak i uživatelům mobilních zařízení, ale to samo o sobě k vyrovnání rozdílu nestačí. Některá vodítka napovídají následující předčasné ukazatele. Například míra dokončení úkolů je pozoruhodně nízká. Všimli jsme si také, že lidé nedělají mnoho z těchto úkolů za sebou, zatímco s "přidat odkaz" uživatelé dělají desítky za sebou. Toto je hlavní oblast pro budoucí vyšetřování.

Rychlost vrácení: K identifikaci úprav a vrácení používáme značky úprav a vrácení musí být provedeno do 48 hodin od úpravy. To je v souladu s běžnými postupy pro návraty.

Typ úkolu	Počet úprav	Počet vrácení	Návratová rychlost
Přidání obrázku	69	13	18,8%
Přidání odkazu	209	4	1,9%
Zkopírování	93	19	20,4%

Míra návratu "přidat obrázek" je srovnatelná s mírou návratu zkopírovaných úprav a je výrazně vyšší než "přidat odkaz" (pomocí testu proporcí). Protože "přidat obrázek" má srovnatelnou míru návratu k nestrukturovaným úkolům, práh popsaný v tabulce hlavních indikátorů je nedodržen a nemáme důvod k obavám. To znamená, že stále zkoumáme, proč dochází k návratům, abychom mohli provést zlepšení. Jeden problém, kterého jsme si zatím všimli, je velký počet uživatelů, kteří ukládají úpravy mimo pracovní postup "přidat obrázek". Mohou to udělat přepnutím do vizuálního editoru, ale děje se to mnohem častěji než u "přidání odkazu", že si myslíme, že na kroku "titulek" je něco matoucího, což způsobuje, že se uživatelé pohybují mimo něj.

Míra odmítnutí: "Relace" úprav definujeme jako dosažení dialogu souhrnu úprav nebo dialogu přeskočení, kdy počítáme, zda byl doporučený obrázek přijat, odmítnut nebo přeskočen. Uživatelé se k tomuto dialogu mohou dostat vícekrát, protože si myslíme, že volba vrátit se zpět a zkontrolovat obrázek nebo upravit popisek je rozumnou volbou.

Počet schválení	%	Počet zamítnutí	%	Počet přeskočení	%	Celkem
53	41,7	38	29,9	36	28,3	127

Prahová hodnota v tabulce hlavních ukazatelů byla míra odmítnutí 40 % a tato prahová hodnota nebyla splněna. To znamená, že uživatelé odmítají návrhy přibližně stejnou rychlostí, jakou jsme očekávali, a nemáme důvod se domnívat, že algoritmus nefunguje dostatečně.

Míra nadměrného přijetí: Znovu používáme koncept "relace úprav" z analýzy míry odmítnutí a počítáme počet uživatelů, kteří mají pouze návštěvy, kde přijali obrázek. Abychom pochopili, zda tito uživatelé provádějí mnoho úprav, měříme to u všech uživatelů a také u uživatelů s vícenásobnými úpravami pěti nebo více relací úprav. V tabulce níže sloupec "Celkem" zobrazuje celkový počet uživatelů s daným počtem relací úprav a "Počet přijalo vše" počet uživatelů, kteří mají pouze relace úprav, kde přijali všechny navrhované odkazy.

Úpravy	Počet celkem	Počet přijalo vše	%
≥1 úprava	97	34	35,1
≥2 úpravy	21	8	38,1
≥5 úprav	0	0	0,0

Je jasné, že nadměrné přijímání není v tomto souboru dat problémem, protože neexistují žádní uživatelé, kteří mají 5 nebo více dokončených úprav obrázků, a u těch, kteří mají více než jednu, 38 % uživatelů přijalo všechny jejich návrhy. To je v očekávaném rozsahu, vzhledem k tomu, že se očekává, že algoritmus obvykle poskytne dobré návrhy.

Míra dokončení úkolu: "Zahájení úlohy" definujeme jako pojem "režimu strojových návrhů". Jinými slovy, uživatel načítá editor s úkolem "přidat obrázek". Dokončení úkolu je definováno jako kliknutí pro uložení úprav nebo potvrzení, že jste přeskočili navrhovaný obrázek.

Počet zahájení úlohy	Počet dokončení 1+ úkolů	%
313	96	30,7

Práh definovaný v tabulce hlavních ukazatelů je "nižší než 55 %" a tento práh byl splněn. To znamená, že nás znepokojuje, proč si uživatelé neprojdou celým pracovním postupem, a chceme pochopit, kde uvíznou nebo odpadnou.

Add an Image Experiment Analysis

Review the full report: "Add an Image" Experiment Analysis, March 2024.

"Přidat obrázek" do sekce

Návrh "přidat obrázek" na úrovni sekce

Na wikinách, kde je nasazen, mají nováčci přístup ke strukturované úloze "přidat obrázek" ze své domovské stránky pro nováčky. Stávající úkol "přidat obrázek" navrhuje návrhy obrázků na úrovni článku pro zcela neilustrované články. Obrázek je poté přidán do hlavní části článku, aby pomohl ilustrovat koncept článku jako celku.

Přihlášení titulků pro úlohu "přidat obrázek" na úrovni sekce

Proběhne přihlášení k úkolu, po kterém bude následovat konkrétní návrh (včetně důvodu, proč je obrázek navržen). Pokud se nováček rozhodne, že se obrázek hodí do sekce článku, dostane pokyny k psaní titulků. Strukturovaný úkol poskytuje podrobnosti o obrázku, v případě potřeby další nápovědu k psaní titulků a poté vyzve nováčka, aby zkontroloval a publikoval úpravu.

Partnerství s týmem strukturovaných dat (Structured Data)

Tým Growth spolupracuje s týmem strukturovaných dat při práci na variantě úkolu "přidat obrázek" na úrovni sekce.

Toto je jeden aspekt projektu Structured Data Across Wikipedia. Tento nový úkol poskytne návrhy obrázků, které jsou relevantní pro konkrétní sekci v článku. Tento úkol návrhu obrázku na úrovni oddílu bude považován za obtížnější úkol, který bude navrhován pouze nováčkům, kteří jsou úspěšní v aktuálním úkolu "přidat obrázek" na úrovni článku.

Přečtěte si více o práci týmu Structured Data Across Wikimedia zde: Návrhy obrázků na úrovni sekcí .

Hypotézy

• Strukturovaná editační zkušenost sníží překážku vstupu, a tím zapojí více nováčků a více druhů nováčků než nestrukturovaná zkušenost.  
• Nováčci s pracovním postupem dokončí více úprav ve své první relaci a je pravděpodobnější, že se vrátí a dokončí další.
• Přidáním nového typu úlohy "přidat obrázek" se zvýší počet návrhů obrázků dostupných pro každý jazyk.

Zaměření

Klíčový výstup: Dokončení Obrázky na úrovni sekcí (strukturovaný úkol pro nováčka) Epic (T321754).

Vývoj

Snímky obrazovek ze dvou mobilních designů jsou vidět vpravo. V tomto souboru Figma jsou viditelné návrhy "přidat obrázek" na úrovni sekce.

Testy použitelnosti

Počáteční uživatelské testování návrhů bylo dokončeno v dubnu 2023 v angličtině. Šest testerů dostalo instrukce, byli požádáni, aby experimentovali s tímto prototypem návrhu na úrovni sekce a vyhodnotili snadnost a zábavnost úkolu. Testeři byli ve věku od 18 do 55 let, byli z 5 různých zemí a většina z nich předtím Wikipedii neupravovala. Tři z testerů byli muži a tři ženy. Byli požádáni, aby přezkoumali dva návrhy obrázků, jeden byl "dobrý" návrh obrázku a jeden "špatný" návrh obrázku.

Některé klíčové poznatky z uživatelského testování:

• Všichni účastníci pochopili smysl: "Jasné, snadno pochopitelné, přímočaré."
• Zdálo se, že účastníci úkolu rozumí a že se při rozhodování potřebují zaměřit na daný úsek. Jeden účastník přijal "špatný" návrh obrázku:
  • 2/6 účastníků přijalo "dobrý" návrh obrázku (3 odmítli obrázek, 1 účastník jej přeskočil).
  • 5/6 účastníků odmítlo "špatný" návrh obrázku.
    • Poznámka: Algoritmus, který podporuje návrhy obrázků, by měl poskytovat více "dobrých" návrhů než "špatných", ale algoritmus není dokonalý, a proto tento úkol vyžaduje kontrolu člověkem a je vhodný pro nové editory.
• Někteří účastníci uvedli, že chtějí více než jeden obrázek ke kontrole v jedné sekci: “Jeden návrh nestačí, možná můžete prezentovat více obrázků, ze kterých si můžete vybrat, abych mohl vybrat ten nejvhodnější obrázek.”

Vyhodnocení algoritmu

Cílem týmu Growth je zajistit, aby strukturované úkoly pro nováčky poskytovaly nováčkům návrhy, které jsou přesné alespoň v 70 % případů. Provedli jsme několik kol hodnocení, abychom zkontrolovali přesnost algoritmu pro návrh obrázků.

V počátečním hodnocení byly návrhy stále poměrně nepřesné (T316151). Mnoho obrázků bylo navrženo v sekcích, které by neměly obsahovat obrázky, nebo obrázek související s jedním tématem v sekci, ale nereprezentoval sekci jako celek. Na základě zpětné vazby z tohoto hodnocení, aby návrhy byly přesnější, pokračoval tým pro strukturovaná data v práci na vylepšeních logiky a filtrování (T311814).

Ve druhém hodnocení byly návrhy v průměru mnohem lepší (T330784). Výsledky se samozřejmě velmi lišily podle jazyka, ale průměrná přesnost byla u mnoha wikin poměrně vysoká. Existují však některé wikiny, na kterých návrhy stále nejsou dost dobré na to, aby je mohli prezentovat nováčkům, pokud jsme nevyužili pouze návrhy "dobré křižovatky". To by výrazně omezilo počet dostupných návrhů obrázků, takže se místo toho snažíme zvýšit skóre spolehlivosti námi poskytovaných návrhů.

wiki	% dobrého zarovnání	% dobrého propojení	% dobrého obrazu p18/p373/řízení	celkový počet hodnocených návrhů
arwiki	71	91	54	511
bnwiki	28	86	26	204
cswiki	41	77	23	128
enwiki	76	96	75	75
eswiki	60	67	48	549
frwiki	N.A.	N.A.	100	3
idwiki	66	81	37	315
ptwiki	92	100	84	85
ruwiki	73	89	69	250
overall	64	86	57	2,120

Je dobré poznamenat, že tuto úlohu bude možné konfigurovat komunitou pomocí Special:EditGrowthConfig. Doufáme, že úkol vylepšíme do té míry, aby mohl dobře fungovat na všech wikinách, ale komunity se nakonec rozhodnou, zda je tento úkol vhodný a měl by zůstat povolený.

Komunitní konzultace

Diskuse s Growth pilot wiki je plánována na květen 2023 (T332530). Návrhy, plány a otázky zveřejníme na arabské Wikipedii, bengálské Wikipedii, české Wikipedii, španělské Wikipedii a také zde na Mediawiki budeme sdílet další podrobnosti.

Měření

Rozhodli jsme se nenasadit tuto funkci v A/B testu a místo toho umožnit uživatelům přihlásit se k jejímu používání prostřednictvím dialogu pro výběr úkolu na domovské stránce pro nováčky nebo prostřednictvím dialogu po úpravách "Vyzkoušet nový úkol", který je součástí Funkce Leveling Up. To znamenalo, že jsme se zaměřili na měření sady hlavních indikátorů, abychom pochopili, zda úkol funguje dobře. Více podrobností o tom lze nalézt v T332344.

Pro návrhy na úrovni sekcí a na úrovni článku jsme stáhli data ze základu KPI Grafana společnosti Growth od 2023-07-31 do 2023-08-28 (k dispozici zde). Tento časový rámec byl zvolen, protože by neměl být tolik ovlivněn červnovým/červencovým poklesem aktivity, který často vidíme na wikinách. The end date is limited by the team shutting off image suggestions in late August (see T345188 for more information). Tento rozsah dat pokrývá celé čtyři týdny dat. I když nám tato datová sada neumožňuje oddělit ji podle platformy (desktop a mobilní web), ani nám neumožňuje jemnější uživatelské filtrování, byla snadno dostupná a poskytuje nám přiměřeně dobrý obrázek, který je pro tento druh analýzy dostačující. v tuto chvíli. Pomocí této datové sady získáme přehled o aktivitě úlohy zobrazený v tabulce 1.

Tabulka 1: Kliknutí na úkol, dokončení a vrácení podle typu úkolu.

Typ úkolu	Kliknutí na zadání	Uložené úpravy	Vrátí se	Míra dokončení úkolu	Návratová rychlost
Section-level	1 149	688	60	58,1%	9,0%
Article-level	6 800	2 414	105	35,5%	4,3%

We see from the table that the task completion rate for section-level image suggestions is high, on par with Add a Link (ref) when that was released. Je to pravděpodobně proto, že úkol na úrovni sekce je něco, co si uživatelé buď sami vyberou v dialogu pro výběr úkolu, nebo se rozhodnou vyzkoušet poté, co byli požádáni prostřednictvím dialogu "Try a new task" (vyzkoušet nový úkol), který je součástí Leveling Up. Tito uživatelé jsou tedy pravděpodobně již zkušenými editory a nemají s dokončením tohoto úkolu příliš mnoho problémů.

Rychlost vrácení pro úlohu na úrovni sekce je vyšší než pro úlohu na úrovni článku. Nemyslíme si, že tento rozdíl je důvodem k obavám ze dvou důvodů. Za prvé, může být obtížnější souhlasit s tím, že článek je jasně vylepšen přidáním obrázku na úrovni sekce ve srovnání s přidáním obrázku na úrovni článku. Za druhé, články navržené pro obrázky na úrovni sekcí již mají hlavní obrázek, což může znamenat, že jsou také delší a mají více přispěvatelů, kteří prověřují úpravy.