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

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ě
 * Další: analýza výsledků uživatelských testů a rozhodnutí o počátečních návrzích

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.

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.

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ýbornou shodu (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 shody. Pomocí konzervativních kritérií může být algoritmus schopen navrhnout pouze desítky tisíc shod v dané wiki. I když tato wiki obsahuje stovky tisíc nebo miliony článků. Věříme, že tento druh svazku 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 shody 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 shod. 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 shod. Jinými slovy, algoritmus je dává k dispozici více než ze zbývajicí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ídá 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ž je jistý). Musíme odpovědět na tyto otázky: je algoritmus schopen poskytnout dostatek shod, které stojí za to s ním vytvořit 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 shod, 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 (anglicky) neilustrovanými články jako vhodné kandidáty na doplnění. Obecně je to dostatečný objem pro první verzi úkolu, takže uživatelé mají spoustu shod. V některých menších wiki, jako je bengálská, se může dostat do malého počtu, jakmile se uživatelé zaměří na zájmová témata. To znamená, že bengálská wiki má pouze asi 100 000 článků, takže bychom navrhli shody pro 7% z nich, což je podstatné.
 * In terms of how big of an improvement in illustrations we could make to the wikis with this algorithm, the ceiling ranges from 1% (cebwiki) to 9% (trwiki). That is the overall percentage of additional articles that would wind up with illustrations if every match is good and is added to the wiki.
 * The wikis with the lowest percentage of unillustrated articles for which we can find matches are arzwiki and cebwiki, which both have a high volume of bot-created articles. This makes sense because many of those articles are of specific towns or species that wouldn't have images in Commons. But because those wikis have so many articles, there are still tens of thousands for which the algorithm has matches.
 * In the farther future, we hope that improvements to the image matching algorithm, or to MediaSearch, or to workflows for uploading/captioning/tagging images yield more candidate matches.

MediaSearch
As mentioned above, the Structured Data team is exploring using the MediaSearch algorithm to increase coverage and yield more candidate matches.

MediaSearch works by combining traditional text-based search and structured data to provide relevant results for searches in a language-agnostic way. By using the Wikidata statements added to images as part of Structured Data on Commons as a search ranking input, MediaSearch is able to take advantage of aliases, related concepts, and labels in multiple languages to increase the relevance of image matches. You can find more information about how MediaSearch works here.

As of February 2021, team is currently experimenting with how to provide a confidence score for MediaSearch matches that the image recommendations algorithm can consume and use to determine whether a match from MediaSearch is of sufficient quality to use in image matching tasks. We want to be sure that users are confident in the recommendations that MediaSearch provides before incorporating them into the feature.

The Structured Data team is also exploring and prototyping a way for user generated bots to use the results generated by both the image recommendations algorithm and MediaSearch to automatically add images to articles. This will be an experiment in bot-heavy wikis, in partnership with community bot writers. You can learn more about that effort or express interest in participating in the phabricator task.

In May 2021, in the same evaluation cited in the "Accuracy" section above, MediaSearch was found to be far less accurate than the image matching algorithm. Where the image matching algorithm was about 78% accurate, matches from MediaSearch were about 38% accurate. Therefore, the Growth team is not planning to use MediaSearch in its first iteration of the "add an image" task.

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. Zajímá nás také 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 nováčci mít 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í popisek k obrázkům, které do článku vkládají?
 * How much should newcomers judge images based on their "quality" as opposed to their "relevance"?
 * 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
Starting in December 2020, we invited community members to talk about the "add an image" idea in five languages (English, Bengali, Arabic, Vietnamese, Czech). The English discussion mostly took place on the discussion page here, with local language conversations on the other four Wikipedias. We heard from 28 community members, and this section summarizes some of the most common and interesting thoughts. These discussions are heavily influencing our next set of designs.


 * Celkově: č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 mohli zhatit. Některé z těchto nástrah jsou zvláště důležité při práci s nováčky.
 * Algoritmus
 * Community members seemed to have confidence in the algorithm because it is only drawing on associations coded into Wikidata by experienced users, rather than some sort of unpredictable artificial intelligence.
 * Of the three sources for the algorithm (Wikidata P18, interwiki links, and Commons categories), people agreed that Commons categories are the weakest (and that Wikidata is the strongest). This has borne out in our testing, and we may exclude Commons categories from future iterations.
 * We got good advice on excluding certain kinds of pages from the feature: disambiguations, lists, years, good, and featured articles.. We may also want to exclude biographies of living persons.
 * We should also exclude images that have a deletion template on Commons and that have been previously removed from the Wikipedia page.
 * Úsudek nováčků
 * Community members were generally concerned that newcomers would apply poor judgment and give the algorithm the benefit of the doubt. We know from our user tests that newcomers are capable of using good judgment, and we believe that the right design will encourage it.
 * In discussing the Wikipedia Pages Wanting Photos campaign (WPWP), we learned that while many newcomers were able to exhibit good judgment, some overzealous users can make many bad matches quickly, causing lots of work for patrollers. We may want to add some sort of validation to prevent users from adding images too fast, or from continuing to add images after being repeatedly reverted.
 * Většina členů komunity souhlasila s tím, že "relevance" je důležitá než "kvalita". Jinými slovy, pokud jediná existující fotka osoby je rozmazaná, je to stále lepší, než vůbec žádný obrázek. Nováčci se toto musí při přidávání obrázků naučit.
 * Our interface should convey that users should move slowly and take care, as opposed to trying to get as many matches done as they can.
 * We should teach users that images should be educational, not merely decorative.
 * Uživatelské rozhraní
 * Several people proposed that we show users several image candidates to choose from, instead of just one. This would make it more likely that good images are attached to articles.
 * Many community members recommended that we allow newcomers to choose topic areas of interest (especially geographies) for articles to work with. If newcomers choose areas where they have some knowledge, they may be able to make stronger choices.  Fortunately, this would automatically be part of any feature the Growth team builds, as we already allow users to choose between 64 topic areas when choosing suggested edit tasks.
 * Community members recommend that newcomers should see as much of the article context as possible, instead of just a preview. This will help them understand the gravity of the task and have plenty of information to use in making their judgments.
 * 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 preferováno vložit obrázek 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é.
 * In general, it sounds like a rule of "place an image under the templates and above the content" in an article will work most of the time.
 * Some community members advised us that even if placement in an article isn't perfect, other users will happily correct the placement, since the hard work of finding the right image will already be done.
 * Neanglicky mluvící uživatelé
 * Community members reminded us that some Commons metadata elements can be language agnostic, like captions and depicts statements. We looked at exactly how common that was in this section.
 * We heard the suggestion that even if users aren't fluent with English, they may still be able to use the metadata if they can read Latin characters. This is because to make many of the matches, the user is essentially just looking for the title of the article somewhere in the image metadata.
 * Someone also proposed the idea of using machine translation (e.g. Google Translate) to translate metadata to the local language for the purposes of this feature.
 * Popisky
 * Členové komunity (spolu s členy týmu Growth) jsou skeptičtí ke schopnosti nováčků psát dobré popisky.
 * Bylo nám porazeno uživatelům ukazovat 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í


Thinking about the open questions above, in addition to community input, we want to generate some quantitative and qualitative information to help us evaluate the feasibility of building an "add an image" feature. Though we have been evaluating the algorithm amongst staff and Wikimedians, it is important to see how newcomers react to it, and to see how they use their judgment when deciding on whether an image belongs in an article.

To that end, we are going to run tests with usertesting.com, in which people new to Wikipedia editing can go through potential image matches in a prototype and respond "Yes", "No", or "Unsure". We built a quick prototype for the test, backed with real matches from the current algorithm. The prototype just shows one match after another, all in a feed. The images are shown along with all the relevant metadata from Commons:


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

Though this may not be what the workflow would be like for real users in the future, the prototype was made so that testers could go through lots of potential matches quickly, generating lots of information.

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 nepřemýšleli moc pečlivě. Prototyp zatím neukládá žádné editace, a obsahuje šedesát návrhů vygenerovaných naším algoritmem.

Níže jsou 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ůj výkon?
 * 3) How do participants feel about the task of adding images to articles this way? Do they find it easy/hard, interesting/boring, rewarding/irrelevant?
 * 4) Jaké informace považují účastníci za nejcenější při vyhodnocování návrhů algoritmu?
 * 5) Jsou účastníci schopni napsat dobrý popisek k obrázku, který považují za vhodný k vložení do článku?

Koncept A vs. B
In thinking about design for this task, we have a similar question as we faced for "add a link" with respect to Concept A and Concept B. In Concept A, users would complete the edit at the article, while in Concept B, they would do many edits in a row all from a feed. Concept A gives the user more context for the article and editing, while Concept B prioritizes efficiency.

In the interactive prototype above, we used Concept B, in which the users proceed through a feed of suggestions. We did that because in our user tests we wanted to see many examples of users interacting with suggestions. That's the sort of design that might work best for a platform like the Wikipedia Android app. For the Growth team's context, we're thinking more along the lines of Concept A, in which the user does the edit at the article. That's the direction we chose for "add a link", and we think that it could be appropriate for "add an image" for the same reasons.

Jeden vs. 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. Zároveň je tato možnost složitější na navržení, zejména s ohledem na mobilní zařízení. 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ítnou). Zde hrozí, že uživatelé do článku přidají nejlepší ze špatných obrázků, a to i přes to, že správným rozhodnutím by bylo nepřidat obrázek žádný.
 *  Serial : this design offers multiple image matches, but the user looks at them one at a time, records a judgment, and then chooses a best one at the end if they indicated that more than one might match. This might help the user focus on one image at a time, but adds an extra step at the end.



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

During December 2020, we used usertesting.com to conduct 15 tests of the mobile interactive prototype. The prototype contained only a rudimentary design, little context or onboarding, and was tested only in English with users who had little or no previous Wikipedia editing experience. We deliberately tested a rudimentary design earlier in the process so that we could gather lots of learnings. The primary questions we wanted to address with this test were around feasibility of the feature as a whole, not around the finer points of design:


 * 1) Are participants able to confidently confirm matches based on the suggestions and data provided?
 * 2) How accurate are participants at evaluating suggestions? And how does the actual aptitude compare to their perceived ability in evaluating suggestions?
 * 3) How do participants feel about the task of adding images to articles this way? Do they find it easy/hard, interesting/boring, rewarding/irrelevant?
 * 4) 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?

In the test, we asked participants to annotate at least 20 article-image matches while talking out loud. When they tapped yes, the prototype asked them to write a caption to go along with the image in the article. Overall, we gathered 399 annotations.

Shrnutí

We think that these user tests confirm that we could successfully build an "add an image" feature, but it will only work if we design it right. Many of the testers understood the task well, took it seriously, and made good decisions -- this gives us confidence that this is an idea worth pursuing. On the other hand, many other users were confused about the point of the task, did not evaluate as critically, and made weak decisions -- but for those confused users, it was easy for us to see ways to improve the design to give them the appropriate context and convey the seriousness of the task.

Pozorování

'' To see the full set of findings, feel free to browse the slides. The most important points are written below the slides. ''




 * General understanding of the task matching images to Wikipedia articles was reasonably good, given the minimal context provided for the tool and limited knowledge of Commons and Wikipedia editing. There are opportunities to boost understanding once the tool is redesigned in a Wikipedia UX.
 * The general pattern we noticed was: a user would look at an article's title and first couple sentences, then look at the image to see if it could plausibly match (e.g. this is an article about a church and this is an image of a church). Then they would look for the article's title somewhere in the image metadata, either in the filename, description, caption, or categories.  If they found it, they would confirm the match.
 * Each image matching task could be done quickly by someone unfamiliar with editing. On average, it took 34 seconds to review an image.
 * All said they would be interested in doing such a task, with a majority rating it as easy or very easy.
 * Perceived quality of the images and suggestions was mixed. Many participants focused on the image composition and other aesthetic factors, which affected their perception of the suggestion accuracy.
 * Only a few pieces of image metadata from Commons were critical for image matching: filename, description, caption, categories.
 * Many participants would, at times, incorrectly try to match an images to its own data, rather than to the article (e.g. "Does this filename seem right for the image?"). Layout and visual hierarchy changes to better focus on the article context for the image suggested should be explored.
 * “Streaks” of good matches made some participants more complacent with accepting more images -- if many in a row were "Yes", they stopped evaluating as critically.
 * Users did a poor job of adding captions. They frequently would write their explanation for why they matched the image, e.g. "This is a high quality photo of the guy in the article." This is something we believe can be improved with design and explanation for the user.

Metriky


 * Members of our team annotated all the image matches that were shown to users in the test, and we recorded the answers the users gave. In this way, we developed some statistics on how good of a job the users did.
 * Of the 399 suggestions users encountered, they tapped "Yes" 192 times (48%).
 * Of those, 33 were not good matches, and might be reverted were they to be added to articles in reality. This is 17%, and we call this the "likely revert rate".

 Takeaways 


 * The "likely revert rate" of 17% is a really important number, and we want this to be as low as possible. On the one hand, this number is close to or lower than the average revert rate for newcomer edits in Wikipedia (English is 36%, Arabic is 26%, French is 22%, Vietnamese is 11%).  On the other hand, images are higher impact and higher visibility than small changes or words in an article.  Taking into account the kinds of changes we would make to the workflow we tested (which was optimized for volume, not quality), we think that this revert rate would come down significantly.
 * We think that this task would work much better in a workflow that takes the user to the full article, as opposed to quickly shows them one suggestion after another in the feed. By taking them to the full article, the user would see much more context to decide if the image matches and see where it would go in the article.  We think they would absorb the importance of the task: that they will actually be adding an image to a Wikipedia article.  Rather than going for speed, we think the user would be more careful when adding images.  This is the same decision we came to for "add a link" when we decided to build the "Concept A" workflow.
 * We also think outcomes will be improved with onboarding, explanation, and examples. This is especially true for captions.  We think if we show users some examples of good captions, they'll realize how to write them appropriately.  We could also prompt them to use the Commons description or caption as a starting point.
 * Our team has lately been discussing whether it would be better to adopt a "collaborative decision" framework, in which an image would not be added to an article until two users confirm it, rather than just one. This would increase the accuracy, but raises questions around whether such a workflow aligns with Wikipedia values, and which user gets credit for the edit.

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

Given that metadata is a critical part of making a strong decision, we have been thinking about whether users will need to be have metadata in their own language in order to do this task, especially in light of the fact that the majority of Commons metadata is in English. For 22 wikis, we looked at the percentage of the image matches from the algorithm that have metadata elements in the local language. In other words, for the images that can be matched to unillustrated articles in Arabic Wikipedia, how many of them have Arabic descriptions, captions, and depicts? The table is below these summary points:


 * Všeobecně řečeno, metadata nebývají přeložena do místních jazyků. Výjimkou je angličtina.
 * For all wikis except English, fewer than 7% of image matches have local language descriptions (English is at 52%).
 * For all wikis except English, fewer than 0.5% of image matches have local language captions (English is at 3.6%).
 * For depicts statements, the wikis range between 3% (Serbian) and 10% (Swedish) coverage for their image matches.
 * The low coverage of local language descriptions and captions means that in most wikis, there are very few images we could suggest to users with local language metadata. Some of the larger wikis have a few thousand candidates with local language descriptions.  But no non-English wikis have over 1,000 candidates with local language captions.
 * Though depicts coverage is higher, we expect that depicts statements don’t usually contain sufficient detail to positively make a match. For instance, a depicts statement applied to a photo of St. Paul’s Church in Chicago is much more likely to be “church”, than “St. Paul’s Church in Chicago”.
 * Možná budeme muset prioritizovat 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.

Given that local-language metadata has low coverage, our current idea is to offer the image matching task to just those users who can read English, which we could ask the user as a quick question before beginning the task. This unfortunately limits how many users could participate. It's a similar situation to the Content Translation tool, in that users need to know the language of the source wiki and the destination wiki in order to move content from one wiki to another. We also believe there will be sufficient numbers of these users based on results from the Growth team's welcome survey, which asks newcomers which languages they know. Depending on the wiki, between 20% and 50% of newcomers select English.

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

Pozadí
After lots of community discussion, many internal discussions, and the user test results from above, we believe that this "add an image" idea has enough potential to continue to pursue. Community members have been generally positive, but also cautionary -- we also know that there are still many concerns and reasons the idea might not work as expected. The next step we want to in order to learn more is to build a "minimum viable product" (MVP) for the Wikipedia Android app. The most important thing about this MVP is that it will not save any edits to Wikipedia. Rather, it will only be used to gather data, improve our algorithm, and improve our design.

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


 * The app will have a new task type that users know is only for helping us improve our algorithms and designs.
 * 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, a 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
The Android team released the app in May 2021, and over several weeks, thousands of users evaluated tens of thousands of image matches from the image matching algorithm. The resulting data allowed the Growth team to decide to proceed with Iteration 1 of the "add an image" task. In looking at the data, we were trying to answer two important questions around "Engagement" and "Efficacy".

Engagement: do users of all languages like this task and want to do it?
 * 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ů aplikace pro Android.
 * Image matching edits showed a substantially lower retention rate than other kinds of Android suggested edits, but there are concerns that it’s not possible to calculate an apples-to-apples comparison. Further, we think that the fact that the edits from this MVP do not actually change the wikis would lead to lower retention, because users would be less motivated to return and do more.
 * With respect to language, data was collected for users in English Wikipedia as well as from users who exclusively use non-English Wikipedia, including large numbers of evaluations from German, Turkish, French, Portuguese, and Spanish Wikipedias. We expected English and non-English users to have quite different experiences, because the majority of metadata on images in Commons is in English. But metrics were remarkably similar across the two groups, including number of tasks completed, time spent on task, retention, and judgment. This bodes well for this task being usable across wikis, although it's likely that many of the non-English Android users are actually bilingual.

Efficacy: will resulting edits be of sufficient quality?
 * 80% 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 účinnnosti.
 * Toto číslo se zvedne na 82-83%, když odebereme nováčky, kteří posouzením obrázku stráví minimum času.
 * Experti se spolu shodnou pouze v 85 % případech.
 * Because newcomer accuracy goes up when certain kinds of newcomers are removed (those who evaluate too quickly or who accept too many suggestions), we think that automated “quality gates” could boost newcomer performance to levels acceptable by communities.

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

Vývoj
Tato sekce obsahuje odkazy na stránky s podrobnými informacemi ohledně technického aspektu tohoto projektu:


 * Práce týmu Platform Engineering na "proof of concept" API vyvinutém pro aplikaci pro Android
 * Úkoly na Phabricatoru týkající se MVP vyvinutém týmem aplikace pro Android
 * Úkoly na Phabricatoru týkající se vyhodnocení algoritmu

Iterace 1
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ů 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žovali 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ů implementovat lépe. Výsledky také ukázaly, že tento úkol by mohl fungovat ve více jazycích.
 * Celkové poznatky: jelikož jsme na mnoho z 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 editacím.

Hypotézy
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) Paradigma: designové paradigma, které jsme vytvořili pro "přidávání odkazů" bude fungovat i pro obrázky.

Rozsah projektu
Jelikož 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ů, algoritmus pustíme pouze jednou, a pro první verzi použijeme statický 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é.
 * Add a link paradigm: our design will generally follow the same patterns as the design for our previous structured task, "add a link".
 * 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, abychom se nemuseli 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 pouze nabízet jeden obrázek, se kterým si je algoritmus nejjistější. To umožní vytvořit jednodušší rozhraní pro nováčky, které bude také 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žit velké množství špatných editací během krátké doby. To můžeme implementovat například takto: (a) umožnit uživatelům přidat pouze omezené množství obrázků za den, (b) zobrazení dalších instrukcí uživatelům, kteří návrhy posuzují příliš krátkou dobu, (c) zobrazení dalších instrukcí uživatelům, kteří schvalují příliš mnoho návrhů. Tato myšlenka byla inspirována zkušeností anglické Wikipedie s kampaní Wikipedia Pages Wanting Photos.
 * Pouze pilotní projekty: stejně jako se všemi novými produkty 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í na těchto projektech. 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ý, anebo 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.

Mockups and prototypes
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ě. To 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.

 Prototypes 

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


 * Concept A (English)
 * Concept B (English)
 * Concept A (Spanish)
 * Concept B (Spanish)

Grafický návrh

Níže jsou statické obrázky našich grafických návrhů. Členové komunit se mohou podívat i na Figma soubor vytvořený designérkou týmu Growth; návrhy z této stránky najdete v pravém dolním rohu plátna. Figma soubor také obsahuje různé poznámky a věci, které nás inspirovaly.

Seznam článků

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 aby zároveň uživatele nemátla.