Growth/Personalized first day/構造化タスク/画像の追加

グループ:	Growth
開始:	2020-10-01
チームのメンバー:	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)
リーダー:	Roan Kattouw
管理者:	Marcella Florence (engineering), Marshall Miller (product)
更新:	Most updates posted here.

This page is a translated version of the page Growth/Personalized first day/Structured tasks/Add an image and the translation is 92% complete.

Phabricator で追跡中
タスク T256081

このページでは「画像の追加」構造化タスクについての取り組みを解説します。「画像の追加」構造化タスクとは、Growth チームが新規参加者ホームページを通じて提供する予定の構造化タスクのひとつです。

このページでは主要なアセット、設計、未決の課題、意思決定について述べます。

進行中の増分更新のほとんどは全般的なGrowthチームの更新ページに投稿されます。このページにはいくつかの大規模または詳細な更新を掲載します。

現状

2020-06-22: 画像をお勧めするための単純なアルゴリズム作成のアイデアに関して最初の検討
2020-09-08: マッチングアルゴリズムの初回試作の評価、対象は英語版、フランス語版、アラビア語版、朝鮮語版、チェコ語版、ベトナム語版
2020-09-30: マッチングアルゴリズムの第2回試作の評価、対象は英語版、フランス語版、アラビア語版、朝鮮語版、チェコ語版、ベトナム語版
2020-10-26: 実行性のありそうな画像推薦サービスについて、技術面に関する内部の協議
2020-12-15: 利用者テストの初回を実施して、新規参加者がこのタスクをうまく習得するかどうか、把握を開始
2021-01-20: プラットフォーム技術班が画像推薦のための概念実証 API の構築を開始
2021-01-21: Android チームは調査用に使える最小限のバージョン開発に着手
2021-01-28: 利用者テストの結果を公表
2021-02-04: コミュニティの協議内容のまとめと、適用の統計を公表
2021-05-07: Android MVP を利用者に公開
2021-08-06: Android 版の公表結果と実用版模型（イテレーション1）
2021-08-17: イテレーション1でバックエンドの作業を開始
2021-08-23: 英語版とスペイン語版で、対話式の試作品を投入し、利用者テストを開始
2021-10-07: 利用者テストで発見したこと、それに立脚した設計の最終案を掲出
2021-11-19: 製品版のウィキペディアで大使がテストを開始
2021-11-22: イテレーション1を利用者に公開する前に画像おすすめデータセットをリフレッシュ
2021-11-29: イテレーション1をアラビア語版、チェコ語版、およびベンガル語版ウィキペディアでモバイルアカウントの40％に展開。
2021-12-22: 目を引く指標を提示
2022-01-28: デスクトップ版の展開はアラビア語版、チェコ語版、ベンガル語版の新規登録アカウントの40%に展開。
2022-02-16: スペイン語版ウィキペディアの新規参加者に「画像を追加」タスクの提供を開始
2022-03-22: ウィキペディアのポルトガル語版、ペルシャ語版、フランス語版、トルコ語版の新規参加者に「画像を追加」機能の提供を開始
2023-02-07: セクション・レベルの画像の提案の評価を完了 (T316151)
2023-10-16: Image Recommendations added to the Android Wikipedia app
2024-04-11: Publish "Add an image" Experiment Analysis
次: Release "Add an image" to more Wikipedias

概要

構造化タスクは編集タスクを段階ごとのワークフローに分割して、新規参加者に理解しやすく、そしてモバイル機器で理解しやすいようにすることを目的としています。 Growthチームは、これら新しい種類の編集ワークフローによって、より多くの新規参加者がウィキペディアへの関与を始めやすくなり、その中にはより実質的な編集を学んでコミュニティへ参加する人も出てくるだろうと信じています。構造化タスクのアイデアをコミュニティと議論した後、最初の構造化タスクの構築を決めました。「リンクの追加」です。

2021年5月に「リンクを追加」を展開後、初期データを採ったところ、新規参加者にとってタスクはやり甲斐があり、編集は差し戻される率は低いとわかり -- 構造化タスクは新規参加者の体験に、またウィキにとって価値があると示唆されました。

その最初のタスクを構築しながらも、次の構造化タスクは何がよいか、新規参加者に適したものとして画像の追加はどうかと考えていました。単純なアルゴリズムで画像のない記事に置くべき画像をコモンズからお勧めしてはどうだろうかという発案です。手始めに、ウィキデータで見つけることができる既存の接続のみを利用し、記事にその画像を使うかどうかは新規参加者が自分で判断するようにしてみます。

このタスクがどのように機能するのかについて多くの未解決の疑問、および上手くいかないかもしれない多くの潜在的な理由があることを把握しています。だからこそ、多くのコミュニティの皆さんからご意見を聞き、議論をしながらどのように進めていくのかを決定したいと考えます。

なぜ画像か？

「なぜ画像か？」節を展開して読む

実質的な貢献を求める

コミュニティのメンバーと最初に構造化タスクについて議論したとき、多くの人がウィキリンクの追加は特に価値の高い編集の種類ではないと指摘しました。コミュニティのメンバーは新規参加者がもっと実質的な貢献できる方法についてのアイデアも持ち出しました。ひとつのアイデアが画像です。ウィキメディア・コモンズには6500万の画像がありますが、多くのウィキペディアでは50%以上の記事に画像がありません。コモンズからの多くの画像がウィキペディアを実質的にもっと図解できるに違いないと考えています。

新規参加者の関心度

私たちは多くの新規参加者が画像の追加に興味を持っていることを知っています。「画像の追加」は歓迎アンケートでアカウントを作成した理由に対する新規参加者のよくある回答です。ヘルプパネルの質問でも画像の追加方法に関するものは最もよくある質問のひとつで、私たちが扱うすべてのウィキにわたってそうでした。これらの新規参加者のほとんどはおそらく追加したい独自の画像を持ってくるのでしょうが、これは画像がいかに魅力的でエキサイティングたりえるか示唆しています。新規参加者が参加している他のプラットフォーム（InstagramやFacebookのようなもの）が画像に重きを置いていることを考えれば理にかなっています。

画像を扱う難しさ

画像に関する多くのヘルプパネルの質問は、記事に画像を追加する工程が難しすぎることを反映しています。新規参加者はウィキペディアとコモンズの違い、著作権周辺のルール、および適正な場所に画像を挿入しキャプションを付けるための技術的な部分を理解する必要があります。図解されていない記事のためにコモンズで画像を見つけるには、ウィキデータやカテゴリの知識のような、さらなるスキルが要求されます。

「写真を募集中のウィキペディアのページ」キャンペーンの成功事例

写真を募集中のウィキペディアのページキャンペーン (WPWP)は予想外の成功を収めました。600人の利用者が8万5000ページに画像を追加したのです。これを達成するため利用した複数のコミュニティ・ツールは、画像がないページを抽出し、ウィキデータを介して適合しそうな画像を提案します。新規参加者がうまく画像を追加するのを助ける方法に関して学ぶべき重要な教訓がありますが、これは利用者に画像の追加に関するやる気を出させ、ツールで補助できるという自信を私たちに与えてくれます。

これを総合すると

この情報を総合して考えると、新規参加者にとって楽しく、なおかつウィキペディアにとって生産的である「画像の追加」構造化タスクを構築することが可能であると考えています。

アイデアの検証

2020年6月から2021年7月にかけて、Growthチームは「画像の追加」タスク周辺のコミュニティ議論、背景調査、評価、および概念実証に取り組みました。これにより2021年8月に最初のイテレーションを構築するという決定に至りました（イテレーション1参照）。この節にはイテレーション1に至るまでの背景作業のすべてが含まれています。

「アイデアの検証」節を展開して読む

アルゴリズム

画像の追加について構造化タスクを作ることができるかどうかは、十分に良好なお勧めを生成できるアルゴリズムを作成できるかどうかに依存します。間違った画像を追加するように新規参加者を駆り立てて、巡回者に後始末をさせる結果になることは断じて望んでいません。したがって、良好なアルゴリズムを作ることができるかどうか見てみることが私たちが最初に取り組んだことのひとつです。

ロジック

私たちはWikimedia Research teamと協力して、これまで正確さと人間の判断を優先するアルゴリズムをテストしてきました。いかなるコンピュータの視点も予期せぬ結果を生成してしまう可能性があるので、それよりもむしろ単純に経験を積んだ投稿者によって行われた接続に頼っているウィキデータにある既存の情報を統合します。以下は図解されていない記事に合致する提案をする3つの主要な方法です：

その記事に対するウィキデータの項目を見ます。もし画像(P18)があれば、その画像を選びます。
その記事に対するウィキデータの項目を見ます。もし関連付けられたコモンズのカテゴリ(P373)があれば、そのカテゴリから画像を選びます。
他言語版ウィキペディアで同じトピックに関する記事を見ます。それらの記事から導入の画像を選びます。

アルゴリズムには、アイコンやナビボックスの一部として記事に存在していそうな画像を除外するといったようなことをするロジックも含まれています。

正確さ

2021年8月現在、私たちはアルゴリズムのテストを既に3回行っており、各回で6言語（英語、フランス語、アラビア語、ベトナム語、チェコ語、および韓国語）の記事の合致を見ました。評価は私たちのチームの大使およびその言語を母国語として話すその他の熟練ウィキメディアンによって行われました。

最初の2回の評価

各言語で提案された50個の合致を見て、それらを以下のグループに分類しました：

区分	説明	例
2	記事にとても良く合致して、記事のタイトルを図解するものである。	記事が「チョウ（蝶）」であり、画像がチョウ（蝶）である。
1	良く合致するが、利用者が何らかの文脈を持っていない限り記事を補強することは難しく、良いキャプションが必要である。	記事が「チョウ（蝶）」であり、画像がチョウ（蝶）を研究した重要な科学者である。
0	記事に全く適合しない。	記事が「チョウ（蝶）」であり、画像が自動車である。
-1	画像が主題にとって正しいが、ローカルな文化に合致しない。	記事が「チョウ（蝶）」であり、画像が世界の一部からきたローカルな種類とは異なる特定のチョウ（蝶）である。
-2	新規参加者がうっかり正しいと考えてしまう可能性のある誤解を招く画像である。	記事が「チョウ（蝶）」であり、画像がガ（蛾）である。
-3	ページが画像を持つべきではない。	曖昧さ回避ページ、一覧、あるいは「人の名前」の記事。

アルゴリズムについての作業を通じてこのような疑問が浮かんできます：どのくらいの正確さが必要か？75%の合致が良好ならば十分か？90%の正確さが必要か？あるいは正確さが50%まで低下してもいいのか？これはそれを利用する新規参加者の判断がどのくらい良好か、およびどのくらい弱い合致を耐えることができるのかに依存します。これに関してはアルゴリズムを実際の新規参加者で利用者テストするときにもっと知ることができるでしょう。

最初の評価で、最も重要なことは、除外すべき記事や画像の種類を含む、簡単にできるアルゴリズムの改善点がたくさん見つかったことです。それらの改善なしでも、約20-40%の合致が「2」、つまり記事にとても良く合致しました（ウィキによって異なります）。最初の評価からの全結果と注記はこちらをご覧ください。

2回目の評価には、多くの改善が組み込まれ、正確さが向上しました。50-70%の間の合致が「2」でした（ウィキによって異なります）。しかし正確さの向上は網羅率、つまり合致させることができる記事の数を減少させる可能性があります。保守的な基準を使うと、何十万あるいは何百万という記事があるウィキでさえ、アルゴリズムは数万の合致しか提案できないかもしれません。そのような量は、この機能の初期バージョンを構築するには十分であると確信しています。2回目の評価からの全結果と注記はこちらをご覧ください。

3回目の評価

2021年5月、構造化データチームは画像マッチングアルゴリズム（およびメディア検索アルゴリズム）のさらに大規模なテストをアラビア語版、セブアノ語版、英語版、ベトナム語版、ベンガル語版、およびチェコ語版ウィキペディアで実施しました。このテストでは、画像マッチングアルゴリズムとメディア検索アルゴリズムの両方からの約500個の合致が各言語の熟練者によって評価され、合致を「良」、「可」、あるいは「不可」として分類できるようにしました。以下で詳述する結果によって、これらのことが示されました：

画像マッチングアルゴリズムの正確さは「良」を集計するか「良+可」を集計するかによって、そしてウィキ/評価者によって65-80%の範囲にあります。興味深いことに、画像の合致を評価する経験では、画像が記事に相応しいかどうか皆が独自の基準を持っているので、しばしば熟練ウィキメディアンの意見が互いに異なることがあります。
ウィキデータのP18（「ウィキデータ」）は合致の最も強力なソースで、85%-95%の範囲の正確さです。他のウィキペディアからの画像（「ウィキ横断」）とウィキデータの項目に付されたコモンズのカテゴリからの画像（「コモンズのカテゴリ」）は同程度のより低い正確さです。
他のウィキペディアからの画像（「ウィキ横断」）は最もありふれた合致のソースです。言い換えれば、他の2つのソースよりも多くのものをアルゴリズムが利用可能です。

ソース	正確さ（良）	正確さ（良+可）	網羅率のシェア
ウィキデータ	85%	93%	7%
ウィキ横断	56%	76%	80%
コモンズのカテゴリ	51%	76%	13%
すべて	63%	80%	100%

結果の全データセットはこちらで見てください.

網羅率

アルゴリズムの正確さは明らかに非常に重要な要素です。同様に重要なのはその「網羅率」です -- これはどれだけ多くの画像を合致させることができるかということです。正確さと網羅率は相反する傾向にあります：アルゴリズムが正確であればあるほど、提案の数は少なくなります（確信があるときだけ提案するからです）。私たちはこれらの疑問に答える必要があります：そのアルゴリズムは機能を構築する価値があるくらい十分な合致を提供できますか？ウィキに実質的な影響を及ぼすことができますか？その答えを感じ取るために22のウィキペディアを見ました。表がこれらの要点の下にあります：

表に反映されている網羅率の数字は、「画像の追加」機能の最初のバージョンとしては十分そうです。十分な合致の候補が各ウィキにあり、(a)利用者が使い果たすことなく、(b)機能がウィキの図解のあり方に実質的な影響を及ぼすことができます。
ウィキは20%が図解されていないもの（セルビア語版）から69%が図解されていないもの（ベトナム語版）まで範囲があります。
7,000個（ベンガル語版）から155,000個（英語版）の合致する候補がある図解されていない記事を見つけることができます。一般的には、これはタスクの最初のバージョンとしては十分な量であり、利用者が豊富な合致に取り組むことができます。ベンガル語版のような、一部のまばらなウィキでは、利用者が興味のあるトピックを絞ると少数になるかもしれません。とはいえ、ベンガル語版は全部で約100,000記事しかなく、その7%について合致を提案していますので、実質的と言えます。
このアルゴリズムでウィキにどれだけ大きな図解の改善できるかという観点では、上限は1% (cebwiki)から9% (trwiki)までの範囲です。これはすべての合致が良好でウィキに追加されるとした場合に図解されることになる追加の記事の全体的な割合です。
合致を見つけることができる図解されていない記事の割合が最も低いウィキはarzwikiとcebwikiで、両方ともボットによって作成された記事が大量にあります。そのような記事の多くはコモンズに画像がないであろう特定の町や種についてのものなので、これは理にかなっています。しかしそれらのウィキにはとても多くの記事があるので、なおもアルゴリズムが合致したものが何万もあります。
さらに将来的には、画像マッチングアルゴリズム、あるいはメディア検索、あるいは画像のアップロード/キャプション付け/タグ付けのワークフローをより多くの候補が合致するように改善したいと考えています。

ウィキ	全記事	図解のない記事	図解のない割合	画像の合致	合致した図解のない記事の割合
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%

メディア検索

上述のように、構造化データチームは網羅率を向上させ、より多くの候補を合致させるためにメディア検索アルゴリズムを利用して探索しています。

メディア検索は言語に依存しない方法で関連性のある検索結果を提供するために旧来のテキストベースの検索と構造化データを組み合わせて機能します。コモンズの構造化データの一部として画像に追加されたウィキデータの文を検索ランキングの入力として利用することによって、メディア検索は別名、関連のある概念、および多言語のラベルを画像マッチの関連性を向上させるために活用できます。メディア検索が機能する方法に関してさらなる情報はこちらをご覧ください。

2021年2月現在、チームはメディア検索からの合致が画像マッチングタスクに利用するのに十分な品質であるか決定するために画像推奨アルゴリズムが消費して利用できるメディア検索の合致に対する信頼度スコアを提供する方法を実験しています。メディア検索を機能に組み込む前に、メディア検索が提供する推奨を利用者が信頼していることを確かめたいです。

構造化データチームは、利用者が作成したボットが画像推奨アルゴリズムとメディア検索の両方によって生成された結果を自動的に記事に画像を追加するために利用する方法についても探索および試作しています。これはボットに重きを置くウィキで、コミュニティのボット作成者と協力しての実験となる予定です。phabricatorタスクに参加して、この取り組みに関してもっと知ったり、関心があることを表明してください。

2021年5月、上述の「正確さ」節で引用したのと同じ評価で、メディア検索は画像マッチングアルゴリズムよりもはるかに正確さが低いことがわかりました。画像マッチングアルゴリズムが約78%の正確さだったのに対して、メディア検索からの合致は約38%の正確さでした。したがって、Growthチームは「画像の追加」タスクの最初のイテレーションではメディア検索を利用しない計画です。

疑問と議論

未解決の疑問

画像はウィキペディアのとても重要で目に見える部分です。機能が画像の追加を簡単にすることがどのように作用するのか、落とし穴になるかもしれないものは何か、そしてコミュニティのメンバーにどのような関わりがあるのかについて、しっかりと考えることが重要です。それに向けて、多くの未解決の疑問がありますし、コミュニティのメンバーからさらに持ち上がってくる可能性のある疑問に耳を傾けたいと考えています。

アルゴリズムは良好な合致を豊富に提供できるくらい十分な正確さでしょうか？
新規参加者は画像を追加するかどうか決定するために、コモンズと図解されていない記事からどのようなメタデータを必要としますか？
お勧めを見るときに新規参加者は十分に良好な判断力を持っているでしょうか？
多くのコモンズのメタデータが英語だとすると、英語を読まない新規参加者が同様に良好な決定ができるでしょうか？
新規参加者は記事に置いた画像に並行して良好なキャプションを書くことができるでしょうか？
新規参加者はどれぐらい「関連性」と対照的に「品質」に基づいて判断すべきでしょうか？
新規参加者はこのタスクをどう思うでしょう？興味深い？楽しい？難しい？簡単？退屈？
どの記事に画像がないのかをどのくらい厳密に決定すべきでしょうか？
図解されていない記事のどこに画像を置くべきでしょうか？記事の冒頭に置けば十分でしょうか？
お勧めにおける潜在的なバイアス、つまりアルゴリズムがヨーロッパと北米のトピックについてより多く合致するかもしれないことにどのようにして気を配ることができるでしょうか。
このようなワークフローは荒らしの媒介となるでしょうか？これをどのようにして防ぐことができるでしょうか？

2021年02月04日のコミュニティ議論からのメモ

2020年12月から、「画像の追加」のアイデアに関して5つの言語（英語、ベンガル語、アラビア語、ベトナム語、チェコ語）でコミュニティのメンバーを招待して話し合いました。英語の議論は主にこちらの議論ページで実施され、ローカル言語の対話はその他4つのウィキペディアで実施されました。28人のコミュニティのメンバーから聞き取りを行っており、この節で最も一般的で興味深い考えの一部を要約します。これらの議論は次の一連の設計に大きな影響を与えています。

全体的には: コミュニティのメンバーはこのアイデアに関して、一般的には慎重ながらも楽観しています。言い換えれば、ウィキペディアに画像を追加するためにアルゴリズムを使うことには価値があるだろうけれど、特に新規参加者には、潜在的な落とし穴や間違った方向に進む可能性がある、というのが人々の合意のようです。
アルゴリズム
- 何らかの予測不可能な人工知能ではなく、経験を積んだ利用者によってウィキデータに書き込まれた関連付けに頼っているだけなので、コミュニティのメンバーはアルゴリズムを信頼しているようでした。
- アルゴリズムに対する3つのソース（ウィキデータP18、ウィキ間リンク、およびコモンズのカテゴリ）のうち、コモンズのカテゴリが最も貧弱（そしてウィキデータが最も強力）であるというのが人々の合意でした。これはテストによって裏付けられており、将来のイテレーションからコモンズのカテゴリを除外するかもしれません。
- 特定の種類のページ（曖昧さ回避、一覧、年、良質な記事、および秀逸な記事など）を機能から除外するという良い助言を得ました。存命人物の伝記も除外した方がいいかもしれません。
- コモンズで削除テンプレートが貼られている画像および以前そのウィキペディアのページから除去されたことがある画像も除外すべきです。
新規参加者の判断
- コミュニティのメンバーは一般的には新規参加者が貧弱な判断を適用してアルゴリズムの利益に疑いの目を向けることを懸念していました。利用者テストから新規参加者は良好な判断ができるとわかっており、適正な設計によってそれが促進されると信じています。
- 写真を募集中のウィキペディアのページキャンペーン (WPWP) について議論したところ、新規参加者の多くは良い判断を示すことができたものの、あまりに熱中した利用者は短時間に多くの不良な合致を行い、巡回者の作業を増やしてしまう可能性があることがわかりました。画像をあまりにも速く追加したり、何度も差し戻されているのに画像の追加を続けないよう、何らかの検証を追加した方がいいと思っています。
- 画像が相応しいかということになると、たいていのコミュニティのメンバーは「品質」よりも「関連性」が重要であることを肯定しました。言い換えれば、ある人物の写真が不鮮明なものしかなくても、たいていは画像が全くないよりはましであるということです。新規参加者がタスクをするときに、この規範を教える必要があります。
- 利用者はできるだけ多くの合致をこなそうとするのではなく、気を付けてゆっくり行動すべきであると、インターフェースが伝えるべきです。
- 画像は単なる装飾ではなく、教育的であるべきだと利用者に教えるべきです。
ユーザーインターフェイス
- 何人かの人々から、ひとつではなくいくつかの画像の候補を利用者に表示して、そこから選ぶようにしてはどうかという提案がありました。これによって良い画像が記事に添付される可能性が高まるでしょう。
- 多くのコミュニティのメンバーは、新規参加者が取り組む記事として興味のあるトピックの領域（特に地理）を選べるようにすることを推奨しました。新規参加者が何らかの知識を持っている領域を選べば、より強力な選択をすることが可能になるかもしれません。幸いなことに、これはGrowthチームが構築したあらゆる機能に自動的に組み込まれていて、既に利用者がお勧めの編集タスクを選ぶときに、64個のトピック領域から選ぶことができるようになっています。
- コミュニティのメンバーは、新規参加者は単にプレビューするだけではなく、記事の文脈をできるだけたくさん見るべきであると推奨しました。これはタスクの重大さを理解し、判断をするために使う豊富な情報を得るための助けになるでしょう。
記事における配置
- 私たちはウィキデータinfoboxに関して学びました。ウィキデータinfoboxを使っているウィキでは、画像を記事ではなくウィキデータに追加して、ウィキデータinfoboxを介して表示されるようにするのが望ましいことがわかりました。このようなわけで、これらのinfoboxが様々なウィキでどれくらい普及しているのか再調査することになるでしょう。
- 一般的には、記事で「画像をテンプレートの下かつコンテンツの上に置く」というルールがほとんどのときにうまくいきそうです。
- コミュニティのメンバーの一部は、たとえ記事における配置が完璧でなくても、適正な画像を探すという大変な作業は既に終わっているのだから、他の利用者が喜んで配置を訂正するだろうと私たちに助言しました。
非英語利用者
- コミュニティのメンバーは、キャプションや題材文のようないくつかのコモンズのメタデータの要素は言語に依存しない可能性があることに気づかせてくれました。この節で正確にはそれがどのくらい普及しているのか見ました。
- たとえ利用者が英語が流暢でなくとも、ラテン文字を読めるならばメタデータを利用できるかもしれないという提言を聞きました。これは多くの合致をするには、利用者は本質的には画像メタデータのどこかにある記事のタイトルを探すだけだからです。
- ある人はこの機能のためのメタデータを機械翻訳（例えば Google翻訳）を利用してローカルな言語に翻訳するというアイデアも提案しました。
キャプション
- コミュニティのメンバー（そしてGrowthチームのメンバー）は、新規参加者の適切なキャプションを書く能力に関して懐疑的です。
- キャプションの例、そしてキャプションを付けようとしている記事の種類に合わせたガイドラインを利用者に示すという助言を受けました。

利用者テストの計画

上記の未解決の疑問に関して考えると、コミュニティから提供されたものに加えて、「画像の追加」機能を構築する実行可能性を評価する助けとするためにいくつかの定量的および定性的な情報を生成したいです。スタッフとウィキメディアンの間で既にアルゴリズムを評価しましたが、新規参加者がどのような反応をするのか、そして画像が記事に相応しいか決定するときにどのように判断をするのかを見ることは重要です。

それに向けて、usertesting.comでテストを実施しています。そこではウィキペディアを初めて編集する人々が試作品で潜在的な画像の合致に目を通して、「はい」、「いいえ」、あるいは「わからない」と答えます。テストのために現状のアルゴリズムからの実際の合致に裏打ちされた、簡単な試作品を構築しました。試作品は供給されたすべての合致を次々と表示するだけです。画像は以下のようなコモンズからのすべての関連性のあるメタデータと共に表示されます：

ファイル名
サイズ
日付
利用者
解説
キャプション
カテゴリ
タグ

これは将来の実際の利用者のためのワークフローのようなものではないかもしれませんが、試作品は多くの情報を生成して、テスターができるだけ多くの潜在的な合致に素早く目を通すことができるように作られました。

対話式の試作品を試すには、こちらのリンクをご利用ください。この試作品は主にアルゴリズムからの合致を見るためのものであることに注意してください -- 実際の利用者体験はまだ具体的に検討していません。実際の編集には使えません。アルゴリズムによって提案された実際の合致60件が含まれます。

こちらがテストの主眼です：

提案と提供されたデータに基づいて、参加者は自信をもって合致を確認できるでしょうか？
参加者は提案を評価することについて、どのくらい正確でしょうか？自分がやったことについて、実際にやったことよりも良いと思っているのでしょうか悪いと思っているのでしょうか？
この方法で記事に画像を追加するタスクを、参加者はどう感じるでしょうか？難しい/簡単、面白い/退屈、やりがいがある/的外れ？
画像と記事の合致を評価するとき、参加者が最も役に立つと感じるのはどんな情報でしょうか？
参加者は提供されたデータを利用して、合致すると見なした画像に良いキャプションを書くことができるでしょうか？

設計

コンセプト A 対 B

このタスクのための設計について考えるにあたり、コンセプトAとコンセプトBに関して「リンクの追加」で直面したのと同じような疑問があります。コンセプトAでは、利用者は記事で編集を完遂し、一方コンセプトBでは、供給されたすべてを立て続けに編集して多くの編集を行います。コンセプトAは記事についての文脈を利用者により多く与え、一方でコンセプトBは効率を優先します。

上記の対話式の試作品では、コンセプトBを使用し、そこでは利用者は提案の供給に目を通して進んでいきました。利用者テストで利用者が提案とふれあう多くの例を見たかったのでそうしました。ウィキペディアAndroidアプリのようなプラットフォームには最適の設計かもしれません。Growthチームの文脈では、利用者が記事で編集するコンセプトAの線についてもっと考えています。これは「リンクの追加」で私たちが選択した方向であり、同じ理由で「画像の追加」にとって適切なものとなりうると考えます。

単一対複数

もうひとつの重要な設計について疑問は、単一の画像の合致を利用者に提案して表示するのか、複数の画像を与えてそこから選択するようにするのかということです。複数の合致を与えると、合致の中のひとつが良いものである可能性がより高くなります。しかしどれも良くない場合でさえ、その中のひとつを選ぶべきだと利用者に考えさせてしまう可能性もあります。また、特にモバイル機器にとって、設計および構築するのがより複雑になるでしょう。以下のような3つの見込みのあるワークフローの模型を作りました：

単一: この設計では、利用者は記事に対してひとつの提案された画像のみを与えられ、必要なのはそれを受け入れるか却下するかだけです。利用者にとって単純です。
複数: この設計は複数の潜在的な合致を利用者に表示し、利用者はそれらを比較して最善のものを選ぶか、そのすべてを却下できます。懸念は本当は相応しくない場合でさえ、記事に最善のものを追加すべきであるかのように利用者が感じてしまうかということでしょう。
連続: この設計は複数の画像の合致を提供しますが、利用者は一度にひとつずつを見て、判断を記録し、それから複数のものが合致するかもしれないと指摘していた場合には最後に最善のものを選択します。これは利用者が一度にひとつの画像に焦点を当てる役に立つかもしれませんが、最後に余分な段階が追加されます。

2020年12月の利用者テスト

背景

2020年12月の間、usertesting.comを使ってモバイルの対話式試作品の15のテストを実施しました。試作品には初歩的な設計、わずかな文脈や手ほどきしか含まれておらず、英語でウィキペディアの編集をそれまでに少しだけあるいは全くしたことがない利用者をテストしました。より多くの学びを得られるように、意図的に試作品のより早期に初歩的な設計をテストしました。このテストで対処したかった主な疑問は全体としての機能の実行可能性に関してであり、設計のより細かな点に関してではありません：

提案と提供されたデータに基づいて、参加者は自信をもって合致を確認できるでしょうか？
参加者は提案を評価することについて、どのくらい正確でしょうか？そして実際の素質は提案の評価で自らが認識した能力と比較してどうでしょう？
この方法で記事に画像を追加するタスクを、参加者はどう感じるでしょうか？難しい/簡単、面白い/退屈、やりがいがある/的外れ？
画像と記事の合致を評価するとき、参加者が最も価値があると思うのはどんなメタデータでしょうか？
参加者は提供されたデータを利用して、合致すると見なした画像に良いキャプションを書くことができるでしょうか？

テストでは、参加者に声を出しつつ少なくとも20個の記事と画像の合致に注釈を付けるよう依頼しました。はいをタップしたとき、試作品は記事内の画像に付随するキャプションを書くように依頼しました。全体としては、399個の注釈が集まりました。

要約

このような利用者テストによって「画像の追加」機能を首尾よく構築できることが確認できたと考えていますが、うまくいくのは適正に設計した場合だけです。テスターの多くはタスクを良く理解し、真面目に取り組み、良い決定をしました。 -- これによってこれが遂行する価値があるアイデアであるという確信を得ました。他方、多くの他の利用者はタスクの要点に関して困惑し、批判的に評価せず、貧弱な決定をしました -- しかしそのような困惑した利用者に対して、適切な文脈を与えタスクの重大さを伝えるように設計を改善する方法を見つけるのは簡単でした。

観察

すべての所見を見るには、スライドをご自由に閲覧ください。最も重要な点は以下のスライドに書かれています。

最小限の文脈がツールに提供され、コモンズとウィキペディアを編集する知識が限られていたことを考えれば、画像をウィキペディアの記事に合致させるタスクの一般的な理解は合理的に良好でした。ウィキペディアのUX（ユーザーエクスペリエンス）でツールが再設計されれば、理解を高める機会はあります。
以下のような一般的なパターンに気付きました：利用者は記事のタイトルと最初の数文を見て、それからもっともらしく合致しそうか確認するために画像を見ます（例えば、これは教会に関する記事で、これは教会の画像であるといった風に）。それから利用者はファイル名、解説、キャプション、あるいはカテゴリといった画像のメタデータのどこかに記事のタイトルがあるか探します。もし見つけたら、合致を確証します。
各画像マッチングタスクは編集に不慣れな人によって素早く行われる可能性があります。平均的には、画像のレビューには34秒かかりました。
全員がこのようなタスクをするのは興味深いだろうといい、大多数が簡単または非常に簡単と評価しました。
感じとられた画像と提案の品質は様々でした。多くの参加者は画像の構図やその他の美的要素に焦点を当て、それが提案の正確さの認知に影響を与えました。
コモンズからの画像メタデータのうちいくつかだけが画像マッチングにとって重要でした：ファイル名、解説、キャプション、カテゴリ。
多くの参加者は、時々、間違って画像を記事ではなく、画像自身のデータに合致させようとしました（例えば、「このファイル名は画像にとって正しそうか？」といった風に）。提案された画像の記事における文脈により焦点を当てるようなレイアウトと視覚的な階層の変更を探求すべきです。
良い合致の「連続」によって一部の参加者はより多くの画像を受け入れることに自己満足してしまいました -- 多くのものが立て続けに「はい」であると、批判的に評価するのをやめてしまいました。
利用者はキャプションの追加をうまくできませんでした。例えば「これは記事の人物の高品質な写真です。」というような、画像が合致する理由を書くことがしばしばありました。これは設計や利用者に対する説明によって改善できるものであると信じています。

評価指標

私たちのチームのメンバーはテストで利用者に表示されたすべての画像の合致に注釈を付け、利用者の回答を記録しました。このようにして、利用者の作業がどのくらい良好かについていくつかの統計を展開しました。
利用者に表示された399件の提案のうち、利用者が「はい」をタップしたのは192回（48%）でした。
そのうち、33件は不良な合致で、実際に記事に追加しても差し戻されるかもしれません。割合としては17%相当であり、これを「推定差し戻し率」と呼ぶことにします。

得た学び

17%の「推定差し戻し率」というのは本当に重要な数字で、これを可能な限り低減したいと考えます。一方では、この数字はウィキペディアにおける新規参加者の編集に対する平均的な差し戻し率（英語版36%、アラビア語版26%、フランス語版22%、ベトナム語版11%）に近いかもしくはそれよりも「低い」です。他方では、画像は記事内の小さな変更や単語よりも影響が大きく目立ちやすいです。テストした（品質ではなく、量に最適化されていた）ワークフローに行おうとしている様々な種類の変更を考慮に入れると、この差し戻し率は目に見えて低減すると考えています。
このタスクは次々と素早く供給を表示するのではなく、利用者を記事全体に連れていくワークフローの方がはるかにうまくいくと考えています。記事全体に連れていくことによって、利用者はより多くの文脈を見て画像が合致するか決定したり記事のどこに画像が行くのかを見ることができます。ウィキペディアの記事に実際に画像を追加しようとしているのだという、タスクの重要性を飲み込んでもらえると考えています。利用者が画像を追加するときに速度を追求するよりも、より注意深くなってくれると考えています。「リンクの追加」で「コンセプトA」のワークフローを構築すると決定したときと同じ決定に至りました。
手ほどき、説明、および例示によって結果が改善するだろうと考えています。これは特にキャプションについてはそうです。何らかの良いキャプションの例を見せれば、利用者は適切にキャプションを書く方法を理解するだろうと考えています。コモンズの説明やキャプションを出発点として利用することも促すことができます。
私たちのチームは最近、ひとりだけではなく、ふたりの利用者が確認するまで画像を記事に追加しない「共同決定」の枠組みを採用した方がいいか議論しています。これによって正確さが増すでしょうが、このような枠組みはウィキペディアの価値観と整合するのか、そしてその編集はどの利用者のクレジットになるのか、という疑問が湧きます。

メタデータ

利用者テストによってコモンズからの画像メタデータ（例えば、ファイル名、解説、キャプション、など）は、利用者が自信を持って合致をするために重要であることが示されました。例として、利用者は記事が教会に関するものであり、写真が教会のものであるということはわかりますが、記事で議論されている正にその教会であるかどうかということはメタデータによって判別できるようになります。利用者テストでは、これらのメタデータの項目が最も重要であるということがわかりました：ファイル名、解説、キャプション、カテゴリ。有用でなかった項目には、サイズ、アップロード日、およびアップロードした利用者名が含まれました。

メタデータが強力な決定を行うための重要な部分であるとすれば、特にコモンズのメタデータの大部分が英語であるという事実を踏まえて、このタスクをするために利用者は自身の言語でメタデータを必要としているのではないかということに関して考えているところです。22のウィキに対して、ローカル言語でメタデータの要素を持っているアルゴリズムからの画像の合致の割合を見ました。言い換えれば、アラビア語版ウィキペディアの図解されていない記事に合致させることができる画像に対して、どれだけの数のアラビア語の解説、キャプション、および題材（描写されているもの）があるのかということです。これらの要点の下に表があります：

一般的には、ローカル言語のメタデータの網羅率は非常に低いです。英語は例外です。
英語を除くすべてのウィキに対して、ローカル言語の解説がある画像の合致は7%よりも少ないです（英語は52%）。
英語を除くすべてのウィキに対して、ローカル言語のキャプションがある画像の合致は0.5%よりも少ないです（英語は3.6%）。
題材文に対して、画像の合致に対する網羅率はウィキによって3%（セルビア語）から10% （スウェーデン語）までの範囲にあります。
ほとんどのウィキにおけるローカル言語の解説およびキャプションの網羅率の低さは、ローカル言語のメタデータと共に提案できる画像が非常に少ないことを意味します。一部の大きなウィキではローカル言語の解説を伴う数千の候補があります。しかし英語以外のウィキでローカル言語のキャプションを伴う候補が千を超えるものはありません。
題材の網羅率はより高いものの、題材文はたいてい確実に合致させるのに十分な詳細が含まれていないと予想されます。例として、シカゴ・セント・ポール教会の写真に適用される題材文は「シカゴ・セント・ポール教会」よりも「教会」である可能性がはるかに高いです。
ユーザーインターフェースでローカル言語のメタデータを伴う画像の提案を優先させた方がいいと思いますが、網羅率を向上させる他の機能が構築されるまでは、英語以外のウィキではこれらの機能にとって実行可能な選択肢ではありません。

ウィキ	ローカル言語の解説	ローカル言語のキャプション	題材
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%

ローカル言語のメタデータは網羅率が低いとすると、私たちの現状のアイデアは英語を読むことができる利用者だけに画像マッチングタスクを提供することです。そうすれば、タスクを開始する前の簡単な質問として利用者に尋ねることができます。これによって残念ながら参加できる利用者の数は制限されます。コンテンツ翻訳ツールでも似たような状況で、これでコンテンツをあるウィキから他のウィキに移行するためには、利用者は翻訳元ウィキと翻訳先ウィキの言語がわかる必要があります。新規参加者にどの言語がわかるか尋ねるGrowthチームの歓迎アンケートからの結果に基づき、十分な数のこのような利用者がいると信じています。ウィキによって、20%から50%の新規参加者が英語を選択しています。

Android MVP

Android MVPの詳細は、こちらのページをご参照ください。

背景

たくさんのコミュニティ議論、多くの内部議論、そして上記の利用者テストの結果を受けて、この「画像の追加」のアイデアは追求し続けるに値する十分な将来性があると信じています。コミュニティのメンバーは概ね肯定的でしたが、警戒もしていました -- 私たちもまだ多くの懸念とアイデアがうまくいかないかもしれない理由があることは承知しています。もっと学ぶためにやりたい次の段階は、ウィキペディアAndroidアプリの「実用最小限の製品」(MVP)を構築することです。このMVPに関して最も重要なことは、編集をウィキペディアに保存しないということです。むしろ、データを収集し、アルゴリズムを改善し、設計を改善するためだけに利用する予定です。

Androidアプリは「提案編集」（お勧め編集）の起源であり、そのチームは簡単に新しいタスクの種類を構築する枠組みを持っています。これらがその主な部分です：

アプリは私たちがアルゴリズムと設計の改善に役立てるためだけに利用者が知る新しいタスクの種類を持つ予定です。
画像の合致が表示され、利用者は「はい」、「いいえ」、または「スキップ」を選択することになります。
アルゴリズムを改善し、インターフェースを改善する方法を決定し、そしてGrowthチームが後にウェブプラットフォーム向けに構築するのに適しているか考えるために、選択についてのデータを記録する予定です。
ウィキペディアは全く編集されず、非常にリスクの低いプロジェクトとなります。

結果

Androidチームはアプリを2021年5月に公開し、数週間の間に、数千の利用者が画像マッチングアルゴリズムからの数万の画像の合致を評価しました。結果データによってGrowthチームは「画像の追加」タスクのイテレーション1を進めることを決定できました。データを見るにあたり、私たちは「エンゲージメント」と「有効性」に関する2つの重要な疑問に答えようとしていました。

エンゲージメント：すべての言語の利用者がこのタスクを気に入り、やりたいと思うでしょうか？

平均的には、利用者はAndroid MVPでそれぞれ約11個の注釈を付けました。これは画像の解説と解説の翻訳より少ないものの、他の4つのAndroidタスクよりも多いです。
画像を合致させる編集は他の種類のAndroid提案編集よりもかなり低い定着率を示しましたが、単純に比較できないのではないかという懸念があります。さらに、このMVPからの編集はウィキを実際に変更しないという事実が利用者が戻ってきてもっと取り組むモチベーションを下げているので、より低い定着率につながっていると考えられます。
言語の点では、データは英語版ウィキペディアの利用者だけでなく、もっぱら非英語版ウィキペディアを利用する利用者からも収集されていて、ドイツ語版、トルコ語版、フランス語版、ポルトガル語版、およびスペイン語版ウィキペディアからの多数の評価も含まれます。コモンズにある画像のメタデータの大多数は英語なので、英語利用者と非英語利用者は全く異なる体験をするだろうと予測していました。しかし完遂したタスクの数、タスクに費やした時間、定着、および判断を含む評価指標は、2つの群で意外なことに似通っていました。非英語Android利用者の多くが実はバイリンガルということはありそうですが、これはこのタスクがウィキにまたがって使用できることをよく体現しています。

有効性：編集結果は十分な品質になるでしょうか？

新規参加者が「はい」と言った合致の80%は、熟練者によれば正確に良好な合致です。アルゴリズム単体よりも約5パーセントポイントの改善です。
評価時間の中央値が非常に低い新規参加者を除くと、この数字は82-83%に向上します。
熟練者の意見が互いに一致する傾向にあるのは約85%のときだけです。
特定の種類の新規参加者（あまりにも素早く評価している人やあまりにも多くの提案を受け入れている人）を除くと新規参加者の正確さは向上するので、自動化した「品質ゲート」によってコミュニティに受け入れられるレベルに新規参加者のパフォーマンスを押し上げることができると考えています。

全結果はこちらをご参照ください

技術面

この節にはこのプロジェクトの技術的側面を理解する方法についてのリンクが含まれます：

イテレーション1

2021年7月、Growthチームはウェブ用の「画像の追加」タスクの最初のイテレーションの構築を前進させることを決めました。新規参加者にウィキペディアの記事に画像を追加するよう奨励することに関する多くの未解決の疑問およびリスクのために、これは難しい決定でした。しかしアイデア検証の年を経て、このアイデアに関するコミュニティ議論、評価、テスト、および概念実証に目を通した後、私たちは学び続けることができるように最初のイテレーションを構築することを決めました。これらは私たちを前進へと導いたアイデア検証フェーズからの主な所見です：

慎重なコミュニティの支持：コミュニティのメンバーはこのタスクに関して慎重かつ楽観的であり、価値があるだろうことに同意していますが、私たちが良い設計で対処できると考えている多くのリスクと落とし穴を指摘しています。
正確なアルゴリズム：画像マッチングアルゴリズムは65-80%の正確さであると複数の異なるテストで示され、時間と共に洗練させていくことができました。
利用者テスト：試作品を体験した多くの新規参加者は、タスクが楽しく魅力的であると感じました。
Android MVP:Android MVPからの結果は新規参加者が提案に概ね良好な判断を適用していることを示しましたが、もっと重要なことは、設計で結果を改善する方法に関する手がかりを与えてくれたことです。結果はタスクが言語をまたいでうまく可能性も示唆しました。
全体的な学び：様々な検証段階を通して多くの落とし穴に出くわしてきましたが、これからの設計でそれらを防ぐことができるようになる予定です。この背景作業によって新規参加者を良い判断に導く方法、および有害な編集を避ける方法についてたくさんのアイデアがもたらされました。

仮説

このタスクがうまくいくだろうという確信はありません -- それが途中で学びながら、小さなイテレーションで構築することを計画する理由です。これまでの学びを利用して軽量な最初のイテレーションを構築する良い試みができると考えていることは間違いありません。私たちのイテレーションでやろうと考えているひとつの方法は仮説のテストです。以下は「画像の追加」タスクに関する5つの楽観的な仮説です。イテレーション1での目的は、これらの仮説が正しいか見ることになる予定です。

キャプション：利用者は満足のいくキャプションを書くことができます。ウィキペディアの記事に置かれた画像は一般的にはキャプションを必要とするので、これは私たちの最も大きな未解決の疑問ですが、Android MVPは新規参加者がキャプションをうまく書く能力をテストしていません。
有効性：新規参加者はコミュニティに受け入れられるくらい十分強力な判断力を持っているでしょう。
エンゲージメント：利用者はこのタスクをモバイルで行い、たくさん行い、そしてもっと行いに戻ってきそうです。
言語：英語がわからない利用者がこのタスクをできるでしょう。コモンズのメタデータの大多数は英語であり、コモンズ由来のファイル名、解説、およびキャプションを利用者が読むことは自信を持って合致を確かめるために不可欠なので、これは重要な疑問です。
パラダイム：「リンクの追加構造化タスク」を構築するための設計パラダイムは画像に拡張できるでしょう。

範囲

イテレーション1の主な目的は学ぶことなので、できるだけ早く利用者が体験できるようにしたいと考えています。つまりすぐに公開できるように構築するものの範囲を制限したいということです。以下はイテレーション1に課すべきと考えている最も重要な範囲制限です。

モバイルのみ：多くの経験を積んだウィキメディアンはほとんどのウィキ作業をデスクトップ/ノートパソコンから行っているものの、ウィキペディアに貢献しようと奮闘している新規参加者は広くモバイル機器を使用しており、Growth チームの取り組みにとってより重要な利用者層です。イテレーション1をモバイル向けにのみ構築すれば、デスクトップ/ノートパソコン向けに追加で設計して同じワークフローを構築する時間を節約しつつ、その利用者層に集中できるでしょう。
静的な提案：連続的に実行して利用可能な画像の合致を画像マッチングアルゴリズムを利用して更新するバックエンドサービスを構築するのではなく、アルゴリズムを1度実行して静的なセットをイテレーション1に利用する予定です。より新しい画像とより新鮮なデータが利用可能にならないものの、学びのためには十分だろうと考えています。
リンクの追加のパラダイム：設計は概ね前の構造化タスク、「リンクの追加」に対する設計と同じパターンに従う予定です。
図解されていない記事：いくつか図解があるけれどもっと図解できる記事を含めるのではなく、提案を図解が全くない記事のみに制限する予定です。つまり、ワークフローに新規参加者が記事のどこに画像を置くのか選択する段階を含める必要はないでしょう。唯一の画像となるので、記事冒頭の導入画像と仮定できます。
infoboxがない：提案をinfoboxがない記事のみに制限する予定です。図解されていない記事にinfoboxがある場合は、通常は最初の画像をinfoboxに置くべきだからです。しかし、多くの言語のすべてのinfoboxで画像および画像キャプションの欄を正しく識別できるようにすることは技術的に大変困難です。これによってウィキデータinfoboxがある記事も避けます。
単一の画像：画像マッチングアルゴリズムは単一の図解されていない記事に対して複数の画像候補を提案できるものの、イテレーション1を最も信頼度の高い候補のみを提案するように制限する予定です。新規参加者にとってより単純な体験、そしてチームにとってより単純な設計と開発の取り組みとなるでしょう。
品質ゲート：短時間に多数の不良な編集をするのを止める何らかの自動的な仕組みを含めるべきだと考えています。これに関するアイデアには(a)利用者の1日当たりの「画像の追加」編集を特定の数に制限する、(b)各提案にあまりにも短い時間しか費やしていない場合に追加の案内をする、(c) あまりにも多くの画像を受け入れているような場合に追加の案内をする、などが含まれます。このアイデアは英語版ウィキペディアの写真を募集中のウィキペディアのページキャンペーンでの2021年の経験によってひらめきを得ています。
早期導入ウィキ：すべての新しいGrowth開発と同じように、最初は4つの早期導入ウィキ（アラビア語、ベトナム語、ベンガル語、およびチェコ語版ウィキペディア）にのみ展開する予定です。これらはGrowthの取り組みを密接に追い、それらが実験の一部であるとわかっているコミュニティです。Growthチームはこれらのコミュニティに素早く対応するのを手助けするコミュニティ大使を採用しています。来る年にはスペイン語版およびポルトガル語版ウィキペディアを一覧に加えるかもしれません。

これらの範囲の選択が良さそうか、イテレーション1での学びを大きく制限しそうなものがないか、コミュニティのメンバーの意見を聞きたいです。

設計

模型と試作品

これまでの利用者テストおよびAndroid MVPの設計に基づいて、イテレーション1について複数の設計コンセプトを検討しています。利用者フローを5段階に分け、それぞれ2案を考えています。両方を利用者テストにかけて、新規参加者から情報を集める予定です。利用者テストは英語とスペイン語が対象の予定で -- 英語以外でのテストとして、チーム初の取り組みです。コミュニティの皆さんにも設計を考えてもらいたいですし、ご意見ご感想の投稿をトークページでお待ちしています。

利用者テスト向け試作品

私たちが構築しようと考えているものを体験するには、対話式の試作品を使ってもらうのが最も簡単な方法です。「コンセプトA」と「コンセプトB」の両方の設計について試作品を構築して、英語とスペイン語の両方で利用可能になっています。これらは実際のウィキのソフトウェアではなく、そのシミュレーション版です。つまり編集は実際には保存されず、すべてのボタンや操作が機能するわけではありません -- それでも「画像の追加」プロジェクトで最も重要なものは確かに機能します。

利用者テスト向け模型

以下は2021年8月に行った利用者テストで使った模型の静止画像です。コミュニティの皆さんがGrowthチームの設計者のFigmaファイルを探索することを歓迎します。これにはキャンバスの右下にある下記の模型だけでなく、そこに至る様々なひらめきやメモが含まれます。

フィード

これらの設計は、利用者がおすすめ編集の供給から作業をする記事を選ぶ、ワークフローのごく最初の部分を示しています。カードは魅力的である方が良いのですが、利用者を混乱させてはいけないとも考えています。

コンセプトA：おすすめ画像を縮小したサムネイルが含まれ、利用者に次に来るタスクに関する視覚情報が与えられる。
コンセプトB：画像のサムネイルはなし。そうすると、利用者はその記事にすでに「ある」画像だと誤解しない。

手ほどき

これらの設計は、タスクが何であるのかおよび良い成果を出す方法を説明することを目的として、利用者が最初のタスクを開始した後に見ることになるものを示しています。画像の追加は重大な編集であり、真剣に検討する必要があると利用者に理解してもらいたいです。以下のテキストはまだ注意深く設計されていない点にご注意ください -- どちらかというと、今はこのコンテンツをどんな経験として提供するかを考えています。

コンセプトA：画像の追加のコンセプトと手順を説明する全画面表示オーバーレイ。
コンセプトB：ワークフローの異なる部分に対して、ポップアップが次々に現れ要素を指摘する。

画像を追加

これら設計は、利用者がおすすめ画像を見て、コモンズ由来のメタデータを閲覧し、そして記事にその画像を追加するかどうか判断するワークフローの部分を示しています。利用者テストの結果、利用者が正しい判断をするには、画像のタイトル、コモンズの解説文、およびコモンズのキャプションを読むことが重要だとわかりました。すべての情報をモバイルの画面で利用可能にすること、これが設計の難しい部分です。

コンセプトA：提案された画像を記事内で配置される予定の場所に表示し、利用者が実際に画像を記事に置いて追加する感覚を味わえるようにする。利用者は画像を拡大して全画面表示したり、「i」をタップしてメタデータの詳細を閲覧できる。
コンセプトB：おすすめの画像を「画像検査」カード（image inspector）に、画像に付随するコモンズのメタデータと共に表示。画像をクリックして、全画面表示できる。

キャプションと公開

これらの設計は、利用者が記事に追加する画像を決めた後に、キャプションを書こうとしているワークフローの部分を示しています。これは新規参加者にとって最も難しい部分かもしれず、どんなキャプションが適しているか理解できるように補助する方法に関していまだに考えているところです。

コンセプトA：既存のビジュアルエディタのキャプションダイアログを介して、独自の画面でキャプションを追加する。
コンセプトB：記事上の位置にキャプションを追加し、キャプションがどこに表示されるのかという文脈を利用者が理解するのを助ける。

却下

利用者が提案を却下した場合、なぜマッチングが間違っていたのかデータを収集し、アルゴリズムの改善に結びつけたいと考えます。これはまた、利用者に画像を評価するときに使うべき評価基準を継続的に思い起こさせる機会でもあります。

コンセプトA：利用者はオプションを1件しか選べない。
コンセプトB：利用者は複数のオプションを選んでよい。

2021年9月の利用者テストの結果

2021年8月に実施したユーザテストを受けた32人はほぼ全員、ウィキペディアの翻訳初学者で、回答集めに使用したサイトはusertesting.com でした。テスト被験者を2つにわけて、半分はコンセプトA、残りの半分はコンセプトBを受けました。もっと多様な視点を取り入れようとして、Growth チームが英語版以外でテストを実施した初めての例になりました。スペイン語のテスト被験者は11名で、全員アメリカ国外にいた人です。私たちが構築している機能が世界中の人々にとって本当にわかりやすくて役に立つのか、確かめる役に立ちます。

今回のテストの目標として、設計コンセプトのうち最適な部分の見極めと、改善できそうな部分を見つけ出すことです。これらが主な発見と今後の設計変更の見込みです。

発見
- 英語版でもスペイン語版でも、参加者の成功率はコンセプトBの方が、次の点で明らかに高くなりました。
  - タスクがわかりやすいかどうか。コンセプトAの場合、利用者の中に画像はすでに 記事に配置してあると勘違いする人がいて、おすすめ編集のカードに表示してあるし、さらに記事のプレビュー画面にも画像があるせいでした。
  - 特定の記事に適した画像かどうか評価する時には、記事の内容や画像のメタデータをより慎重に検討。推論として、記事本体とメタデータが明確に区別してあるせいだろうと考えます。
  - キャプションの記述をすると、画像の細部や記事の内容を多用。コンセプトBのキャプション技術の場合、記事の全文を表示。
- その他のメモ
  - 当初、おすすめ編集モジュールを開いた人のほとんどは画像をアップロードするのかとタスクの内容を誤解しており、それは設計が違っても共通していました。それでも自己典拠の画像はほぼ全員がタスクを開いたとたんに修正を受け、最終的には設計AよりもBの方が、タスクの理解をうながし画像の適切な評価につながりました。
  - 編集初学者がウィキペディアや姉妹プロジェクトの編集のエコシステムをもっと広く理解するには、コモンズの使い方、ウィキペディアの記事で画像を使う方法に関して利用者教育を増やすと役に立つはずです。
  - 利用者はキャプションの目的を理解し、それが画像と共にウィキペディアの記事に表示されることを理解していました。
  - スペイン語の参加者は英語の参加者よりもはるかにウィキ横断に順応していました。多言語でウィキをまたいで活動する利用者の需要に応えるより良い方法を探索するかもしれません。
  - スペイン語の参加者はスペイン語で良いキャプションを書くために、コモンズのメタデータを自分で翻訳する必要がありました。
  - 現在のタスクは、画像の評価、キャプションを書くこと、および（非英語ウィキペディアからコモンズのメタデータを読むための）翻訳、といったいくつかの異なるスキルを必要とします。利用者がタスクを完遂するためにすべてのスキルを持っていなくてもよいように、このタスクを将来、複数のタスクに分離することには利益と機会があるかもしれません。
変更
- お勧めの画像のプレビューをお勧めの編集フィードのカード上で表示しません。
- 手ほどきツールチップは利用者がタスクを理解するのを上手く手助けします。しかしより小さいスクリーンでは圧倒されたり取り乱してしまうかもしれません。私たちはツールチップを実装した方がいいと思っていますが、ツールチップはうまく設計するにはかなり長い時間がかかってしまうので、イテレーション1では手ほどきについて全画面オーバーレイを実装することに決めました。将来のイテレーションではツールチップを実装するかもしれません。
- 画像と画像のメタデータは互いに隣り合っている必要があります -- 画面の別の部分にあると、利用者は困惑します。
- 利用者が決定をしてキャプションを書くときに画像のメタデータを考慮することは非常に重要なので、メタデータをより分かりやすく呼び出して読めるように視認性を向上させる必要があります。
- キャプションの最小長さを強制したり、ファイル名をキャプションの一部にすることを許容しないといったような、自由テキストのキャプションについての簡単な検証を含めます。
- キャプションの手順の説明でキャプションの良い例と悪い例を提示します。
- 利用者が提案を却下し、却下した理由を与えたとき、例えば「私はこのトピックを知りません」というような一部の理由では、その提案をキューから除去すべきではありません。ひょっとすると他の利用者は自信を持って合致させることができるでしょう。
キャプション例: 以下の3つの画像と記事の組み合わせはテストで使用され、利用者テスターによって書かれた実際のキャプションです。これは私たちが新規参加者から期待できるキャプションの種類の感覚を与えてくれます。すべて概ね正しい方向のようではありますが、「代替テキスト」のようなものからキャプションらしいものまで範囲があります。いくつか的外れなものもあります。

Article: Edward Edwards (Royal navy officer)
"Drawing of the HMS Pandora by Robert Batty"
"The HMS Pandora, of which Admiral Edward Edwards captained in order to catch mutineers."
"An 1831 depiction of the HMS Pandora sinking"
"Royal Navy"
"Illustration of HMS Pandora sinking"
Article: Fiesque
"Edouard Lalo, composer of the music of the Fiesque opera"
"Photo of Edouard Lalo, composer of Fiesque"
"Edouard Lalo - 1865"
"Eduard Lalo, around 1865"
These captions were translated from Spanish.
Article: Bahaettin Rahmi Bediz
"A photo of Bahaettin Rahmi Bediz taken on 1st January 1924, pictured with his bicycle"
"Bahaettin Radmi Bediz on 1 January 1924"
"Rahmizadephoto1869"
"Rahnizade Bahaeddin Bediz. in uniform, standing next to a bicycle"

繰り返し開発1の最終設計

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

測定

先導指標

私たちが新しい機能を展開するときはいつでも、実験の早期段階の間の進路を維持する一連の「先導指標」を定義します。これらはその機能が全般的に期待した通りの挙動をしているか素早く識別する手助けとなり、ウィキに何らかの損害を引き起こしていれば私たちに知らせてくれます。それぞれの先導指標には定義されたしきい値に達した場合の行動計画が付随するので、チームは何をすべきかがわかります。

指標	行動計画
差し戻し率	これはその「画像の追加」編集をコミュニティが非建設的とみなしていることを示唆します。「画像の追加」についての差し戻し率が非構造化タスクよりもかなり高い場合、この原因が何なのか理解するために差し戻しを分析し、編集が差し戻される傾向を減少させるためにタスクを調整します。
利用者却下率	これは良く合致しない画像をたくさん提案していることを示している可能性があります。却下率が40%を超える場合、私たちは画像提案アルゴリズムのQA（品質保証）をして、お勧めの品質を改善するためにしきい値を調整するか変更を行います。
過剰受け入れ率	これは一部の利用者が実はタスクについて判断をしていないことを示しているかもしれず、つまりは別の品質ゲートを実装した方がいいのかもしれません。 (画像を却下したりスキップしたりすることなく完了したセッションがある利用者の割合は？画像を却下したりスキップしたりすることなく完了したセッションが5つ以上ある利用者の割合は？全利用者で受け入れのみを含むセッションの数は？)
タスク完遂率	これは編集ワークフローに問題があることを示しているかもしれません。「画像の追加」タスクを開始して完遂する利用者の比率が55%（「リンクの追加」の完遂率）よりも低い場合、ワークフローのどこで利用者が去っているのか調査し、継続できるように設計の変更を展開します。

2021年11月29日の展開から2021年12月14日までの「画像の追加」の使用についてのデータを収集しました。「画像の追加」はモバイルウェブサイトでのみ利用可能になっており、そのプラットフォーム上での登録の無作為な50%に提供されました（20%の全体的な対照群を除く）。したがって開発後に登録したモバイル利用者に焦点を当てています。このデータセットは既知のテストアカウントを除外し、（例えば広告ブロッカーによって）イベントログをブロックしている利用者からのデータは含みません。

全体: 先導指標データに関して最も特筆すべきことは、これまでに完遂した編集者がいかに少ないかということです：最初の二週間で89編集のみです。「リンクの追加」の最初の二週間では、およそ300編集が行われました。その機能はデスクトップとモバイル両方の利用者に展開されていましたが、それだけではこの差が生まれることはありません。下記の先導指標はいくつかのヒントを与えてくれます。例えば、タスク完遂率は顕著に低いです。「リンクの追加」では、利用者が何十個も立て続けに行ったのに対して、こちらは人々が多くのタスクを立て続けに行わなかったこともわかりました。これは将来の調査における最重要領域です。

差し戻し率: 編集と差し戻しを識別するために編集タグを利用し、差し戻しは編集から48時間以内に行われるものとします。後者は差し戻しの一般的な慣習に則しています。

タスクの種類	編集数	差し戻し数	差し戻し率
画像の追加	69	13	18.8%
リンクの追加	209	4	1.9%
校正	93	19	20.4%

「画像の追加」の差し戻し率は校正の差し戻し率と同程度で、「リンクの追加」よりもかなり高いです（比率の検定を使用）。「画像の追加」は非構造化タスクと差し戻し率が同程度なので、先導指標の表で述べたしきい値に抵触せず、警戒する理由はありません。とは言え、なぜ差し戻しが発生しているのか調査を続けています。これまでにわかっているひとつの問題は、多数の利用者が「画像の追加」ワークフローの外側から編集を保存しているということです。ビジュアルエディターに切り替えることによってこれが可能ですが、「リンクの追加」よりもはるかに頻繁に起こっているので、「キャプション」の手順に関して紛らわしいものがあって、それによって利用者が外側に迷い出ていると考えています。

却下率: 編集の要約ダイアログまたはスキップダイアログに到達するまでを編集「セッション」と定義し、その時点で提案された画像が受け入れられたか、却下されたか、あるいはスキップされたかを集計します。戻って画像を見直したりキャプションを編集するのは合理的な選択だと考えますので、利用者がこのダイアログに複数回到達する可能性があります。

受け入れ数	%	却下数	%	スキップ数	%	合計数
53	41.7	38	29.9	36	28.3	127

先導指標の表で却下率しきい値は40%であり、このしきい値に抵触していません。つまり利用者は期待通りの比率で提案を却下しており、アルゴリズムが性能不足であると考える理由はないということです。

過剰受け入れ率: 却下率の分析から「編集セッション」の概念を再利用し、画像を受け入れているセッションのみである利用者の数を集計します。このような利用者が多数の編集を行っているかどうか理解するために、全利用者に対してだけでなく、編集セッションが複数および5以上の利用者に対してもこれを測定しました。下表で、「合計数」列は編集セッション数が該当する利用者の総数、「全受け入れ数」は提案されたすべての画像を受け入れた編集セッションのみである利用者の数を示します。

編集	合計数	全受け入れ数	%
≥1 編集	97	34	35.1
≥2 編集	21	8	38.1
≥5 編集	0	0	0.0

5つ以上の画像編集を完遂した利用者はおらず、複数の編集を完遂した利用者ではすべての提案を受け入れた利用者は38%なので、このデータセットでは過剰受け入れが問題になっていないことが明らかです。アルゴリズムがたいていは良好な提案を行うとすれば、これは想定の範囲内です。

タスク完遂率: 「タスクの開始」を「機械の提案モード」を表示することと定義します。言い換えれば、利用者が「画像の追加」タスクがあるエディターを読み込んでいるということです。タスクの完遂は、編集の保存をクリックまたは提案された画像をスキップしたことを確認することと定義します。

タスク開始数	1+ タスク完遂数	%
313	96	30.7

先導指標の表で定義したしきい値は「55%よりも低い」であり、このしきい値に抵触しています。つまり、私たちは利用者がなぜワークフロー全体を通過していないのか懸念しており、どこで行き詰ったり諦めたりしているのかを理解したいと考えているということです。

Add an Image Experiment Analysis

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

セクションへの「画像の追加」

「画像の追加」構造化タスクが展開されているウィキでは、新規参加者ホームページからアクセスできます。既存の「画像の追加」タスクは、全く図解されていない記事に対して記事レベルの画像を提案します。記事の概念を全体として図解する役に立つように、画像は記事の導入部に追加されます。

タスクについての手ほどきがあり、続いて具体的な提案（画像が提案された理由を含む）があります。画像が記事のセクションによく適していると新規参加者が決定した場合、その後キャプションを書くことについて案内を受けます。構造化タスクは画像の詳細、必要ならばさらにキャプションの書き方のヘルプを提供し、それから新規参加者に編集を見直して公開するよう促します。

構造化データチームとの協力

Growthチームは構造化データチームと協力して「画像の追加」タスクのセクションレベル版に取り組んでいます。

ウィキペディア横断構造化データプロジェクトの一環です。この新しいタスクは記事内の特定のセクションに関連する画像の提案を提供する予定です。このセクションレベルの画像提案タスクはより難しいタスクとみなされ、現状の記事レベルの「画像の追加」に成功した新規参加者にのみ提案される予定です。

ウィキメディア横断構造化データチームの取り組みの詳細はこちらをお読みください: Section-level image suggestions 。

仮説

構造化編集体験は参入障壁を下げ、それによってより多くの新規参加者、そして構造化されていない体験よりも多くの種類の新規参加者を引き込むでしょう。
ワークフローで新規参加者は最初のセッションでより多くの編集を完遂し、さらに完遂するために戻ってくる可能性が高まるでしょう。
新しい種類の「画像の追加」タスクを追加することによって、各言語で利用可能な画像提案の数が増加するでしょう。

範囲

Key deliverable: completion of the Section-Level Images (newcomer structured task) Epic (T321754).

設計

Screenshots from two mobile designs can be seen on the right. Section-level "add an image" designs are visible in this Figma file.

利用者テスト

設計の最初の利用者テストは2023年4月に英語で完了しました。 6人のテスターに指示をして、このセクションレベルの設計試作品で実験をし、タスクの簡単さと楽しさを評価するように依頼しました。テスターの年齢は18歳から55歳までの範囲で、異なる5か国出身で、ほとんどの人はそれまでにウィキペディアを編集したことはありませんでした。テスターのうち3人は男性、3人は女性でした。 2つの画像をレビューするよう依頼しました。ひとつは「良い」画像提案、ひとつは「悪い」画像提案でした。

利用者テストからわかった重要なことは：

すべての参加者が手ほどきを理解しました：「明確で、理解しやすく、単純です。」
参加者はタスクと決定をするときにセクションに焦点を当てる必要があることを理解しているようでした。 1人の参加者が「悪い」画像提案を受け入れました：
- 2/6の参加者が「良い」画像提案を受け入れました（3人が画像を却下、1人が画像をスキップしました）。
- 5/6の参加者が「悪い」画像提案を却下しました。
  - 注記：画像提案を供給するアルゴリズムは「悪い」画像提案よりも「良い」画像提案を多く提供するはずですが、アルゴリズムは完璧ではなく、それがこのタスクが人間のレビューを必要とし新しい編集者に適している理由です。
セクション当たりひとつよりも多くの画像がほしいと述べた参加者もいました： “ひとつの提案は十分ではなく、もっと多くの画像から選択できるように提示してくれれば、おそらくもっと適切な画像を選択することができます。”

アルゴリズム評価

Growthチームは新規参加者向け構造化タスクが少なくとも70%のときに正確な提案を新規参加者に提供できるようにすることを目指しています。画像提案アルゴリズムの正確さを検証するために数回の評価を実施しました。

最初の評価では、提案はまだかなり不正確でした (T316151)。画像を持つべきではないセクションで画像を提案したり、セクションのひとつのトピックに関連しているもののセクション全体を表さない画像を提案したりすることが多くありました。この評価からのフィードバックに基づき、構造化データチームは提案がより正確になるよう改善するロジックとフィルタリングに取り組み続けました (T311814)。

2回目の評価では、平均的には、提案ははるかに良くなりました (T330784)。もちろん結果は言語によって大きく異なりますが、平均的な正確さは多くのウィキでかなり高かったです。 However, there are some wikis in which the suggestions are still not good enough to present to newcomers, unless we only utilized the "good intersection" suggestions. That would severely limit the number of image suggestions available, so we are looking instead at increasing the confidence score of the suggestions we provide.

wiki	% good alignment	% good intersection	% good p18/p373/lead image	total rated suggestions
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

このタスクはSpecial:EditGrowthConfigでコミュニティが設定可能であることを覚えておくと良いです。私たちはすべてのウィキで上手く動作させることができるところまでタスクを改善したいと考えていますが、究極的にはコミュニティがこのタスクが良く適合していて有効なままにしておくべきかを決定することになります。

コミュニティとの話し合い

Growthパイロットウィキとの議論は2023年5月に計画されています (T332530)。設計、計画、および質問をアラビア語版ウィキペディア、ベンガル語版ウィキペディア、チェコ語版ウィキペディア、スペイン語版ウィキペディアに投稿し、さらに詳細をここMediaWikiで共有します。

測定

A/Bテストでこの機能を展開せず、代わりに利用者が新規参加者ホームページのタスク選択ダイアログ、あるいはレベルアップ機能の一部である編集後の「新しいタスクを試す」ダイアログでオプトインできるようにすることに決定しました。 This meant that we focused on measuring a set of leading indicators to understand if the task was performing well. More details about this can be found in T332344.

We pulled data from Growth's KPI Grafana board from 2023-07-31 to 2023-08-28 (available here) for Section-Level and Article-Level suggestions. This timeframe was chosen because it should not be as much affected by the June/July slump in activity that we often see on the wikis. The end date is limited by the team shutting off image suggestions in late August (see T345188 for more information). This data range covers four whole weeks of data. While this dataset does not allow us to separate it by platform (desktop and mobile web), nor does it allow us more fine-grained user filtering, it was easily available and provides us with a reasonably good picture that's sufficient for this kind of analysis at this time. Using this dataset we get the overview of task activity shown in Table 1.

表1: タスクの種類ごとのタスクのクリック、完遂、および差し戻し。
タスクの種類	タスクのクリック	保存された編集	差し戻し	タスク完遂率	差し戻し率
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. This is likely because the section-level task is something users either choose themselves in the task selection dialogue, or choose to try out after being asked through the "Try a new task" dialogue that's part of Levelling Up. Those users are therefore likely already experienced editors and don't have too many issues with completing this task.

The revert rate for the section-level task is higher than the article-level task. We don't think this difference is cause for concern for two reasons. First, it might be harder to agree that an article is clearly improved by adding a section-level image compared to adding an article-level image. Secondly, articles suggested for section-level images already have a lead image, which might mean that they're also longer and have more contributors scrutinizing the edit.

現状

概要

関連するプロジェクト群