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

このページでは「画像の追加」構造化タスクについての取り組みを解説します. 「画像の追加」構造化タスクとは、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: ウィキペディアのポルトガル語版、ペルシャ語版、フランス語版、トルコ語版の新規参加者に「画像を追加」機能の提供を開始
 * 次: 次のグループのウィキ群に展開し、コンバージョンファネルを詳細に分析する（ファネル分析）

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

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

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

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



関連するプロジェクト群
Android チームでも同じ構成要素を応用し、Android 版ウィキペディア アプリへの導入を類似のタスクを最小限のバージョンで検討しています. これに加え、構造化データチームは、より経験を積んだ利用者を対象とした、似たようなものでコモンズの構造化データを活用する初期検討段階にあります. このページに示す協議と進捗状況は、すべてのチームに関連します.



なぜ画像か？
実質的な貢献を求める

コミュニティのメンバーと最初に構造化タスクについて議論したとき、多くの人がウィキリンクの追加は特に価値の高い編集の種類ではないと指摘しました. コミュニティのメンバーは新規参加者がもっと実質的な貢献をすることができる方法についてのアイデアも持ち出しました. ひとつのアイデアが画像です. ウィキメディア・コモンズには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個の合致を見て、それらを以下のグループに分類しました：

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

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

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

3回目の評価

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


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

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

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


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

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

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

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件が含まれます.

テストの主眼は以下の通りです.


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

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

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

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


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



2020年12月のユーザーテスト
背景

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


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

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

要約

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

観察

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




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

評価指標


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

得た学び


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

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

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


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

ローカル言語のメタデータは網羅率が低いとすると、我々の現状のアイデアは英語を読むことができる利用者だけに画像マッチングタスクを提供することです. そうすれば、タスクを開始する前の簡単な質問として利用者に尋ねることができます. これによって残念ながら参加できる利用者の数は制限されます. コンテンツ翻訳ツールでも似たような状況で、これでコンテンツをあるウィキから他のウィキに移行するためには、利用者は翻訳元ウィキと翻訳先ウィキの言語がわかる必要があります. 新規参加者にどの言語がわかるか尋ねる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%のときだけです.
 * 特定の種類の新規参加者（あまりにも素早く評価している人やあまりにも多くの提案を受け入れている人）を除くと新規参加者の正確さは向上するので、自動化した「品質ゲート」によってコミュニティに受け入れられるレベルに新規参加者のパフォーマンスを押し上げることができると考えています.

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

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


 * プラットフォーム・エンジニアリング・チームによって、Android MVPを後押しするために構築された「概念実証」APIについての取り組み
 * AndroidチームのMVPに関するPhabricatorタスク
 * 画像マッチングアルゴリズムのPhabricatorタスクおよび評価

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


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

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


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

範囲
イテレーション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」の両方の設計について試作品を構築して、英語とスペイン語の両方で利用可能になっています. これらは実際のウィキのソフトウェアではなく、そのシミュレーション版です. つまり編集は実際には保存されず、すべてのボタンや操作が機能するわけではありません -- それでも「画像の追加」プロジェクトで最も重要なものは確かに機能します.


 * コンセプトA（英語）
 * コンセプトB（英語）
 * コンセプトA（スペイン語）
 * コンセプトB（スペイン語）

利用者テスト向け模型

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

フィード

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

イテレーション1の最終設計

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

Leading indicators
Whenever we deploy new features, we define a set of "leading indicators" that we will keep track of during the early stages of the experiment. These help us quickly identify if the feature is generally behaving as expected and allow us to notice if it is causing any damage to the wikis. Each leading indicator comes with a plan of action in case the defined threshold is reached, so that the team knows what to do.

We collected data on usage of "add an image" from deployment on November 29, 2021 until December 14, 2021. "Add an image" has only been made available on the mobile website, and is given to a random 50% of registrations on that platform (excluding our 20% overall control group). We therefore focus on mobile users registered after deployment. This dataset excluded known test accounts, and does not contain data from users who block event logging (e.g. through their ad blocker).

Overall: The most notable thing about the leading indicator data is how few edits have been completed so far: only 89 edits over the first two weeks. Over the first two weeks of "add a link", almost 300 edits were made. That feature was deployed to both desktop and mobile users, but that alone is not enough to make up the difference. The leading indicators below give some clues. For instance, task completion rate is notably low. We also notice that people do not do many of these tasks in a row, whereas with "add a link", users do dozens in a row. This is a prime area for future investigation.

Revert rate: We use edit tags to identify edits and reverts, and reverts have to be done within 48 hours of the edit. The latter is in line with common practices for reverts.

The "add an image" revert rate is comparable to the copyedit revert rate, and it’s significantly higher than "add a link" (using a test of proportions). Because "add an image" has a comparable revert rate to unstructured tasks, the threshold described in the leading indicator table is not met, and we do not have cause for alarm. That said, we are still looking into why reverts are occurring in order to make improvements. One issue we've noticed so far is a large number of users saving edits from outside the "add an image" workflow. They can do this by toggling to the visual editor, but it is happening so much more often than for "add a link" that we think there s something confusing about the "caption" step that is causing users to wander outside of it.

Rejection rate: We define an edit “session” as reaching the edit summary dialogue or the skip dialogue, at which point we count whether the recommended image was accepted, rejected, or skipped. Users can reach this dialogue multiple times, because we think that choosing to go back and review an image or edit the caption is a reasonable choice.

The threshold in the leading indicator table was a rejection rate of 40%, and this threshold has not been met. This means that users are rejecting suggestions at about the same rate as we expected, and we don't have reason to believe the algorithm is underperforming.

Over-acceptance rate: We reuse the concept of an "edit session" from the rejection rate analysis, and count the number of users who only have sessions where they accepted the image. In order to understand whether these users make many edits, we measure this for all users as well as for those with multiple edit sessionsfive or more edit sessions. In the table below, the "N total" column shows the total number of users with that number of edit sessions, and "N accepted all" the number of users who only have edit sessions where they accepted all suggested links.

It is clear that over-acceptance is not an issue in this dataset, because there are no users who have 5 or more completed image edits, and for those who have more than one, 38% of the users accepted all their suggestions. This is in the expected range, given that the algorithm is expected usually to make good suggestions.

Task completion rate: We define "starting a task" as having an impression of "machine suggestions mode". In other words, the user is loading the editor with an "add an image" task. Completing a task is defined as clicking to save the edit, or confirming that you skipped the suggested image.

The threshold defined in the leading indicator table is "lower than 55%", and this threshold has been met. This means we are concerned about why users do not make their way through the whole workflow, and we want to understand where they get stuck or drop out.