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

هذه الصفحة تصف العمل على المهمّة المهيكلة «إضافة صورة»، التي هي نوع من المهام المهيكلة التي سيُوفرها فريق النمو عبر لوحة المستخدم الخاصة بالوافدين الجدد. اشتغل فريق الأندرويد على نسخة مصغّرة لمهمّة مماثلة في تطبيق ويكيبيديا على الأندرويد باستخدام نفس المكوّنات الأساسية. النقاشات والتحديثات على هذه الصفحة ذات صلة لكلّ من الفريقين. بالإضافة إلى أنّ فريق البيانات الهيكليّة هو في المراحل الأولى من تجرِبة شيء مماثل، موجّه إلى مستخدمين أكثر خبرة مع استغلال البيانات المهيكلة في كومنز. النقاشات والتحديثات الموجودة على هذه الصفحة ذات صلة بعمل كافة الفرق.

تحتوي الصفحة على أهداف رئيسة وتصاميم وأسئلة مفتوحة وقرارات. To try out the experience, |please open up this interactive prototype on your mobile device.

سيتم نشر معظم الأخبار الخاصة بتدرّج العمل في الصفحة العامة لـأخبار فريق النمو، مع نشر بعض الأخبار الهامّة أو المفصّلة هنا.

الوضع الحالي

 * 2020-06-22: التفكير الأوّلي حول إنجاز خوارزمية بسيطة للصور الموصى باستخدامها
 * 2020-09-08: تقييم المحاولة الأولى باللغات الإنكليزية والفرنسية والعربية والكورية والتشيكية والفيتنامية
 * 2020-09-30: تقييم المحاولة الثانية عند خوارزمية تطابق بالإنكليزية والفرنسية والعربية والكورية والتشيكية والفيتنامية
 * 2020-10-26: نقاش داخلي بين المهندسين حول جدوى خدمة الصور الموصى بها
 * 2020-12-15: إجراء جولة أولى من اختبارات المستخدمين للبدء بفهم ما إذا كان الوافدون الجدد سنجحوا في هذه المهمة
 * 2021-01-20: يبدأ فريق هندسة النظام الأساسي في إنشاء واجهة برمجة تطبيقات لإثبات المفهوم لتوصيات الصور
 * 2021-01-21: يبدأ فريق الاندرويد العمل على الحد الأدنى من الإصدار القابل للتطبيق لأغراض التعلم
 * 2021-01-28: جرى نشر نتائج اختبار المستخدم
 * 2021-02-04: جرى نشر ملخّص نقاشات المجتمعات وإحصائيات التغطية
 * 2021-05-07: جرى إصدار أندرويد MVP للمستخدمين
 * 2021-08-06: النتائج المنشورة من الأندرويد والنماذج التقريبية للتكرار 1
 * 2021-08-17: بدأ العمل الخلفي على التكرار 1
 * 2021-08-23: نشر نماذج تقريبية تفاعلية وبدأ اختبارات المستخدم باللغتين الإنجليزية والإسبانية
 * 2021-10-07: النتائج المنشورة من اختبارات المستخدم والتصاميم النهائية بناءً على النتائج
 * 2021-11-19: يقوم المنسق باختبار هذه الميزة مع الويكيبيديين المشاركين
 * 2021-11-22: جرى تحديث مجموعة بيانات اقتراح الصور قبل إصدار التكرار 1 للمستخدمين
 * 2021-11-29: Iteration 1 deployed to 40% of mobile accounts on Arabic, Czech, and Bengali Wikipedias.
 * 2021-12-22: posted leading indicators
 * 2022-01-28: desktop version deployed for 40% of new accounts on Arabic, Czech, and Bengali Wikipedias.
 * 2022-02-16: Spanish Wikipedia newcomers start getting "add an image"
 * التالي: expand to next set of wikis and analyze conversion funnel in detail

ملخص
الهدف من المهام المهيكلة هو تقسيم مهام التحرير إلى مسارات عمل خطوة بخطوة من شأنها أن تناسب الوافدين الجدد وأن تناسب الأجهزة المحمولة. يعتقد فريق النمو أنّ تقديم هذه الشاكلة من مسارات العمل سيسمح لعدد أكبر من الأشخاص بالبَدْء بالمساهمة في ويكيبيديا، بعضهم سيتعلّم القيام بتعديلات جوهريّة والانخراط مع مجتمعاتهم. بعد النقاش حول المهام المهيكلة مع المجتمعات، قرّرنا إنشاء المهمّة المهيكلة الأولى: «إضافة رابط».

بعد نشر «إضافة رابط» في شهر مايو 2021، جمعنا بيانات أولية تظهر أنّ المهمّة كانت مشرّكة للوافدين الجدد، وأنهم قاموا بتعديلات ذات نسبة استرجاع متدنّية -- تظهر أنّ المهام المهيكلة هي ذات قيمة لتجربة الوافدين الجدد وللويكي.

خلال إنشائنا لتلك المهمة الأولى، كان تفكيرنا في المهمة الموالية التي يمكن أن تكون، ونحن نعتقد أن إضافة الصور يمكن أن تكون مناسبة جدا للوافدين الجدد. تكمن الفكرة في خوارزمية بسيطة تستطيع اقتراح وضع صور ورسومات من كومنز في مقالات لا تحمل أي صور. بادئا، ستقوم فقط باستخدام الروابط الموجودة التي يمكن العثور عليها في ويكي بيانات، وسيتمكّن الوافدون الجدد من استخدام تقديرهم الخاص لوضع الصورة في المقالة أو لا.

نعلم أنّه هنالك العديد من الأسئلة المفتوحة حول كيفية القيام بهذا، العديد من الأسباب الكامنة حول إمكانية سلوك طريق خاطئة. لذلك سنستمع إلى آراء أفراد المجتمع وسنجري محادثات مواكبة لكيفية تعاملنا مع طريقة العمل.

لماذا الصور؟
البحث عن المساهمات الثرية

عندما ناقشنا لأول مرة المهام المنظمة مع أعضاء المجتمع، أشار الكثيرون إلى أن إضافة روابط ويكي ليس نوعًا عالي القيمة من التحرير بشكل خاص. طرح أعضاء المجتمع أفكارًا حول كيفية قيام القادمين الجدد بتقديم المزيد من المساهمات الجوهرية. أحد الأفكار كان إضافة الصور. تحتوي ويكيميديا كومنز على 65 مليون صورة، ولكن في العديد من الويكيات، أكثر من 50% من المقالات لا تحتوي على صور. نعتقد أن العديد من الصور من كومنز يمكن أن تجعل ويكيبيديا أكثر وضوحًا بشكل كبير.

الاهتمام من الوافدين الجدد

نعلم أن العديد من الوافدين الجدد مهتمون بإضافة الصور إلى ويكيبيديا. «إضافة صورة» هو رد شائع يقدمه القادمون الجدد في استطلاع الترحيب عن سبب إنشائهم لحسابهم. نرى أيضًا أن أكثر أسئلة لوحة المساعدة شيوعًا يتعلق بكيفية إضافة الصور، وهذا صحيح عبر جميع مواقع الويكي التي نعمل معها. على الرغم من أن معظم هؤلاء الوافدين الجدد ربما يجلبون الصور الخاصة التي يريدون إضافتها، فإن هذا يلمح إلى كيف يمكن أن تكون الصور جذابة ومثيرة. وهذا أمر منطقي، بالنظر إلى العناصر الأخرى للصور للمنصات الأخرى التي يشارك فيها القادمون الجدد -- أشياء مثل انستجرام وفيسبوك.

صعوبة التعامل مع الصور

تعكس أسئلة طلبات المساعدة العديدة حول الصور أن عملية إضافتها إلى المقالات صعبة للغاية. يجب على الوافدين الجدد فهم الفرق بين ويكيبيديا وكومنز، والقواعد المتعلقة بحقوق النشر، والأجزاء الفنية لإدراج الصورة والتعليقات في المكان المناسب. يتطلب العثور على صورة في كومنز لمقال ما مزيدًا من المهارات، مثل المعرفة بويكي بيانات والتصنيفات.

نجاح حملة «صفحات ويكيبيديا بحاجة لصور»

كان لـحملة صفحات ويكيبيديا بحاجة لصور(WPWP) نجاح غير منتظر: أضاف 600 مستخدم صورة إلى 85,000 صفحة. قاموا بذلك بمساعدة بعض أدوات المجتمع التي قامت بتشخيص الصفحات التي ليس لها صور، والتي اقترحوا لها صورا محتملة عبر ويكي بيانات. في حين أن هناك دروسًا مهمة يجب تعلمها حول كيفية مساعدة الوافدين الجدد على النجاح في إضافة الصور، فإن هذا يمنحنا الثقة في أن المستخدمين يمكن أن يكونوا متحمسين لإضافة الصور وأنه يمكن مساعدتهم بالأدوات.

باعتبار كلّ ما سبق ذكره

بالتفكير في كل هذه المعلومات معا، نعتقد أنّه من الممكن بناء المهمّة المهيكلة «إضافة صورة» التي ستكون مُرََوِّحة للوافدين الجدد وفي الآن نفسه بنّاءة لويكيبيديا.

التحقق من صحة الفكرة
''منذ يناير 2020 حتى يوليو 2021، عمل فريق النموّ على نقاشات المجتمع والبحوث الخلفية، والتقييمات، وعلى إثبات المفاهيم حول مهمّة «إضافة صورة». أدى ذلك إلى قرار البَدْء في إنشاء أول محاولة لنا في أغسطس 2021 (طالع محاولة 1). يحتوي هذا القسم على كل الأعمال الخلفية المؤدية إلى المحاولة 1.''

الخوارزمية
تعتمد قابليتنا لإنشاء مهمّة مهيكلة تُعنى بإضافة الصور إلى ما إذا استطعنا إنشاء خوارزمية تولّد توصيات جيّدة بما فيه الكفاية. قطعا، لا نريد مطالبة الوافدين الجدد بإضافات سريعة لصور خاطئة للمقالات، التي يمكن أن تجبر المحرّرين أن يقوموا بالتنظيف وراءهم. وبالتالي، فإن محاولة إنشاء خوارزمية جيّدة، كان من أوّل الأمور التي عملنا عليها.

المنطق
اشتغلنا مع فريق البحث لويكيميديا، وإلى حدّ الآن، تمكنا من تجربة خوارزمية قد فاقت التطابق والحكم البشري. بالنأي عن استخدام أيّة رؤية حاسوبية، التي يمكن أن تولّد نتائج غير منتظرة، ببساطة هي تجمّع معلومات من ويكي بيانات، بالاعتماد على الاتصالات التي أجراها المساهمون المتمرسون. فيما يلي الطرق الرئيسة الثلاث التي تُقترح بها المطابقات مع المقالات التي لا تحتوي صورا:


 * النظر إلى عنصر ويكي بيانات للمقال. لو كانت لديه صورة (P18)، اختيار تلك الصورة.
 * النظر إلى عنصر ويكي بيانات للمقال. إذا كان له تصنيف في كومنز (P373)، اختيار صورة من التصنيف.
 * النظر إلى المقالات التي تتناول نفس الموضوع بلغة أخرى في ويكيبيديا. اختيار الصورة الرئيسية من تلك المقالات.

تتضمن الخوارزمية أيضًا منطقًا للقيام بأشياء مثل استبعاد الصور التي من المحتمل أن تكون رموزًا أو الموجودة في مقالة كجزء من صندوق التصفح.

المطابقة
اعتبارًا من أغسطس 2021، مررنا بـ 3 جولات من اختبار الخوارزمية، في كل مرة نبحث عن مطابقة المقالات في ست لغات: الإنجليزية والفرنسية والعربية والفيتنامية والتشيكية والكورية. تم إجراء التقييمات من قبل سفراء فريقنا، ومن قبل ويكيميديين خبيرين آخرين، وهم متحدّثون أصليون لهذه اللغات التي تم اختبارها.

التقييمان الأولان

لاحظنا في 50 تطابقا مقترحا في كل لغة، مررنا عليها كلها وصنّفناها ضمن هذه المجموعات:

السؤال الذي يدور حول العمل على خوارزمية مثل هذه هو: ما مدى الدقة التي يجب أن تكون؟ إذا كانت 75% من التطابقات جيدة، فهل هذا كافٍ؟ هل يجب أن تكون دقيقة بنسبة 90%؟ أو يمكن أن تكون دقيقة بنسبة 50%؟ هذا يعتمد على مدى جودة الحكم على الوافدين الجدد الذين يستخدمونها، ومقدار الصبر الذي لديهم للتطابقات الضعيفة. سنتعلم المزيد عن هذا عندما نختبر الخوارزمية مع مستخدمين جدد حقيقيين.

في التقييم الأول، كان الشيء الأكثر أهمية هو أننا وجدنا الكثير من التحسينات السهلة لإدخالها على الخوارزمية، بما في ذلك أنواع المقالات والصور التي يجب استبعادها. حتى بدون هذه التحسينات، كان حوالي 20-40% من التطابقات «2s»، مما يعني تطابقًا جيدا مع المقالة (حسب الويكي). يمكنكم مشاهدة النتائج الكاملة والملاحظات من التقييم الأول هنا.

في التقييم الثاني، تم إدخال العديد من التحسينات، وزادت الدقة. بين 50-70% من التطابقات كانت "2s" (حسب الويكي). لكن زيادة الدقة يمكن أن تقلل من التغطية، أي عدد المقالات التي يمكننا إجراء مطابقات لها. باستخدام معايير متحفظة، قد تكون الخوارزمية قادرة فقط على اقتراح عشرات الآلاف من التطابقات في ويكي معين، حتى لو كان هذا الويكي يحتوي على مئات الآلاف أو ملايين المقالات. نعتقد أن هذا الحجم سيكون كافيًا لإنشاء نسخة أولية من هذه الميزة. يمكنكم مشاهدة النتائج الكاملة والملاحظات من التقييم الثاني هنا.

التقييم الثالث

في مايو 2021، أجرى فريق البيانات اختبارا كبيرا على نطاق واسع لخوارزمية مطابقة الصورة (وخوارزمية MediaSearch) في الويكيبيديا باللغات العربية، Cebuano، الإنجليزية، الفيتنامية، البنغالية، ويكيبيديا التشيكية. وفي هذا الاختبار، جرى تقييم حوالي 500 مُطابقة من كل من خوارزمية مطابقة الصورة و MediaSearch من قبل الخبراء في كل لغة، الذين استخدموا وصفًا مثل: "جيد" أو "حسنا" أو "سيئ" لتقييم المُطابقة. النتائج المفصلة أدناه تتوضح ذلك:


 * كان تقييم خوارزمية مطابقة الصورة من 65-80٪ اعتمادا على ما قمنا بحساب "جيد" أو "جيد + حسنا"، وهذا يتوقف على الويكي / المقيم. ومن المثير للاهتمام، في تجربتنا لتقييم مطابقات الصور، كثيرا ما يختلف الويكيبيديون الخبراء في كثير من الأحيان مع بعضهم البعض، لأن كل شخص لديه معاييره الخاصة بما إذا كانت الصور تتعلق بالمقالات أم لا.
 * ويكي-بيانات P18 ("ويكي-بيانات") هو أقوى مصدر للمطابقات، تراوح التقييم من 85٪ -95٪. الصور من الويكيات الأخرى ("Cross-Wiki") ومن تصانيف كومنز المرتبطة بعناصر ويكي-بيانات ("تصانيف كومنز") أقل دقة بدرجة مماثلة.
 * الصور من الويكيات الأخرى ("Cross-Wiki") هي المصدر الأكثر شيوعا للمطابقات. وبعبارة أخرى، أكثر من تلك المتاحة للخوارزمية من المصدرين الآخرين.

مجموعة البيانات كاملة تجدها في النتائج هنا.

التغطية
إن دقة الخوارزمية هي عنصر مهم للغاية. وبنفس القدر من الأهمية تكون "تغطيتها" - هذا يشير إلى "كم مرة" تطابق للصورة يُمكنها القيام بها. قد تكون الدقة والتغطية على ارتباط عكسي: فكلما زادت دِقة الخوارزمية، فإن اقتراحاتها تقل (نظرا لأنها ستقترح فقط عندما تكون واثقة). نحتاج إلى الإجابة على هذه الأسئلة: هل الخوارزمية قادرة على توفير ما يكفي من المطابقات بدرجة تجعل من المُفيد بناء "ميزة" بها؟ هل ستكون قادرة على تحقيق تأثير كبير على الويكي؟ نظرنا إلى 22 ويكيبيديا للحصول على الإجابات. يوجد الجدول تحت نقاط الملخص هذه:


 * يبدو أن أرقام التغطية التي في الجدول كافية للإصدار الأول من ميزة "إضافة صورة". هناك ما يكفي من المطابقات المقترحة في كل ويكي مثل (أ) التيسير على المستخدمين، و (ب) يمكن أن تحدث هذه الميزة تأثيرًا كبيرًا على كيفية وُضوح الويكي.
 * تتراوح الويكيات من 20٪ غير موضحة (صربية) إلى 69٪ غير موضحة (الفيتنامية).
 * يمكن العثور على عدد بين 7,000 (البنغالية) و155,000 (الإنجليزية) مقالة لا توجد فيها صور. عموما، هذا قدر كاف من أجل نسخة أولى للمهمّة، كي يتمكّن المستخدمون من الحصول على الكثير من التطابقات للقيام بها. في ويكييات أخرى مثل البنغالية، سيكون العدد أقلّ بينما يضيّق المستخدمون من مواضيع اهتماماتهم. مع هذا، توجد في ويكيبيديا البنغالية حوالي 100,000 مقالة إجماليا، لذلك نريد اقتراح تطابقات لـ7% منها، وهذا أمر أساسي.
 * من حيث حجم التحسن في الرسوم التوضيحية التي يمكننا إجراؤها على مواقع الويكي باستخدام هذه الخوارزمية، يتراوح الحد الأقصى من 1٪ (cebwiki) إلى 9٪ (trwiki). هذه هي النسبة المئوية الإجمالية للمقالات الإضافية التي قد تنتهي بالرسوم التوضيحية إذا كانت كل مطابقة جيدة وتمت إضافتها إلى الويكي.
 * إن مواقع الويكي التي تحتوي على أقل نسبة من المقالات بلا صور والتي يمكن أن نجد مطابقات لها هي arzwiki و cebwiki ، وكلاهما يحتوي على عدد كبير من المقالات التي جرى إنشاؤها بواسطة بوت. هذا منطقي لأن العديد من هذه المقالات تخص مدنًا أو أنواعًا معينة لا تحتوي على صور في كومنز. ولكن نظرًا لأن هذه الويكي تحتوي على العديد من المقالات ، فلا يزال هناك عشرات الآلاف من المقالات التي تتطابق معها الخوارزمية.
 * في المستقبل البعيد، نأمل أن تؤدي التحسينات التي تم إجراؤها على خوارزمية مطابقة الصور، أو على MediaSearch، أو عمليات سير العمل لتحميل الصور / إضافة تعليقات توضيحية / علامات عليها إلى المزيد من التطابقات المرشحة.

البحث في الوسائط MediaSearch
كما ذكرنا سابقًا، يستكشف فريق البيانات المهيكلة استخدام خوارزمية MediaSearch لزيادة التغطية وتحقيق المزيد من المطابقات المرشحة.

يعمل MediaSearch من خلال الجمع بين البحث التقليدي المستند إلى النص والبيانات المنظمة لتقديم نتائج ذات صلة لعمليات البحث بطريقة لا تعرف اللغة. باستخدام عبارات ويكي-بيانات المضافة إلى الصور كجزء من البيانات المهيكلة على العموم كمدخل لترتيب البحث، تستطيع MediaSearch الاستفادة من الأسماء المستعارة والمفاهيم ذات الصلة والتسميات بلغات متعددة لزيادة صلة مطابقة الصورة. يمكنك العثور على مزيد من المعلومات حول كيفية عمل MediaSearch هنا.

اعتبارًا من فبراير 2021، قام الفريق بتجربة كيفية توفير درجة ثقة لمطابقات MediaSearch التي يمكن أن تستهلكها خوارزمية توصيات الصور وتستخدمها لتحديد ما إذا كانت المطابقة من MediaSearch ذات جودة كافية لاستخدامها في مهام مطابقة الصور. نريد أن نتأكد من ثقة المستخدمين في التوصيات التي يقدمها MediaSearch قبل دمجها في الميزة.

يقوم فريق البيانات المهيكلة أيضًا باستكشاف وإنشاء نماذج أولية لطريقة تستخدم فيها برامج البوت -الخاصة بالمستخدمين- النتائج الصادرة عن كل من خوارزمية اقتراح الصور و MediaSearch لإضافة الصور تلقائيًا إلى المقالات. ستكون هذه تجربة في مواقع الويكي ذات البوتات الثقيلة، بالشراكة مع مؤلفي البوتات المجتمعية. يمكنك معرفة المزيد حول هذا الجهد أو التعبير عن الاهتمام بالمشاركة في مهمة phabricator.

في مايو 2021، في نفس التقييم المذكور في قسم "الدقة" أعلاه، وجد أن MediaSearch أقل دقة بكثير من خوارزمية مطابقة الصور. حيث كانت خوارزمية مطابقة الصور دقيقة بنسبة 78٪ ، وكانت المطابقات من MediaSearch دقيقة بنسبة 38٪. لذلك، لا يخطط فريق Growth لاستخدام MediaSearch في التكرار الأول لمهمة "إضافة صورة".

أسئلة مفتوحة
الصور جزء مهم ومرئي من تجربة ويكيبيديا. من الأهمية بمكان أن نفكر مليًا في كيفية عمل ميزة تتيح الإضافة السهلة للصور، وما هي المخاطر المحتملة، وما هي الآثار المترتبة على أعضاء المجتمع. لتحقيق هذه الغاية، لدينا العديد من الأسئلة المفتوحة، ونريد أن نسمع المزيد من الأسئلة التي يمكن لأعضاء المجتمع طرحها.


 * هل ستكون الخوارزمية الخاصة بنا دقيقة بما فيه الكفاية بحيث يتم توفير الكثير من التطابقات الجيدة؟
 * ما هي البيانات الوصفية من كومنز والمقال بلا صور التي يحتاجها الوافدون الجدد لاتخاذ قرار بشأن إضافة الصورة؟
 * هل يتمتع الوافدون الجدد بحكم جيد بما فيه الكفاية عند النظر في التوصيات؟
 * هل سيتمكن الوافدون الجدد الذين لا يقرؤون اللغة الإنجليزية من اتخاذ قرارات جيدة، بالنظر إلى أن الكثير من البيانات الوصفية العامة مكتوبة باللغة الإنجليزية؟
 * هل سيتمكن الوافدون الجدد من كتابة أوصاف جيدة لتتماشى مع الصور التي يضعونها في المقالات؟
 * إلى أي مدى يجب على الوافدين الجدد الحكم على الصور بناءً على «جودتها» مقابل «ملاءمتها»؟
 * هل سيعتقد الوافدون الجدد أن هذه المهمة ممتعة؟ مرحة؟ صعبة؟ سهلة؟ مملة؟
 * كيف نحدد بالضبط المقالات التي لا تحتوي على صور؟
 * أين يجب أن توضع الصورة في المقالة؟ هل يكفي وضعها في أعلى المقال؟
 * كيف يمكننا أن نضع في اعتبارنا التحيز المحتمل في التوصيات، أي ربما تقوم الخوارزمية بإجراء العديد من التطابقات لمواضيع في أوروبا وأمريكا الشمالية.
 * هل سيكون هذا النوع من سير العمل ناقلا للتخريب؟ كيف يمكننا تفادي ذلك؟

ملاحظات من مناقشات المجتمع 2021-02-04
بدءًا من ديسمبر 2020، قمنا بدعوة أعضاء المجتمع للتحدث عن فكرة "إضافة صورة" بخمس لغات (الإنجليزية ، البنغالية ، العربية ، الفيتنامية ، التشيكية). جرت مناقشة اللغة الإنجليزية في الغالب على صفحة المناقشة هنا ، مع محادثات باللغة المحلية في الويكيبيديات الأربع الأخرى. سمعنا من 28 من أعضاء المجتمع، وهذا القسم يلخص بعض الأفكار الأكثر شيوعًا وإثارة للاهتمام. تؤثر هذه المناقشات بشدة على مجموعتنا التالية من التصميمات.


 * بصورة شاملة: أعضاء المجتمع عموما متفائلون بحذر بشأن هذه الفكرة. بعبارة أخرى، يبدو أن الناس يتفقون على أنه سيكون من المفيد استخدام الخوارزميات لإضافة صور إلى ويكيبيديا، ولكن هناك العديد من المزالق المحتملة والطرق التي يمكن أن يحدث بها هذا الخطأ، خاصة مع الوافدين الجدد.
 * خوارزمية
 * يبدو أن أعضاء المجتمع يثقون في الخوارزمية لأنها تعتمد فقط على الارتباطات المشفرة في ويكي بيانات من قبل المستخدمين ذوي الخبرة، بدلاً من نوع من الذكاء الاصطناعي الذي لا يمكن التنبؤ به.
 * من بين المصادر الثلاثة للخوارزمية (ويكي-بيانات P18 ، وصلات الويكيات الأخرى ، وتصنيفات كومنز)، اتفق الناس على أن تصنيفات كومنز هي الأضعف (وأن ويكي بيانات هي الأقوى). وقد ثبت هذا في اختباراتنا، وقد نستبعد تصنيفات كومنز من التكرارات المستقبلية.
 * لقد حصلنا على نصائح جيدة بشأن استبعاد أنواع معينة من الصفحات من الميزة: توضيح ، والقوائم ، والسنوات ، والمقالات الجيدة، والمختارة .. وقد نرغب أيضًا في استبعاد السير الذاتية لأشخاص أحياء.
 * يجب علينا أيضًا استبعاد الصور التي تحتوي على قالب حذف في كومنز والتي تمت إزالتها مسبقًا من صفحة ويكيبيديا.
 * حكم الوافد الجديد
 * كان أعضاء المجتمع قلقين بشكل عام من أن الوافدين الجدد سيطبقون حكمًا سيئًا. نعلم من اختبارات المستخدم أن الوافدين الجدد قادرون على استخدام الحكم الجيد، ونعتقد أن التصميم الصحيح سيشجعهم.
 * عند مناقشة حملة صفحات ويكي تحتاج صور (WPWP)، تعلمنا أنه بينما كان العديد من الوافدين الجدد قادرين على إصدار أحكام جيدة، يمكن لبعض المستخدمين المتحمسين إجراء العديد من المطابقات السيئة بسرعة، مما يتسبب في الكثير من العمل للمراجعين. قد نرغب في إضافة نوع من التحقق لمنع المستخدمين من إضافة الصور بسرعة كبيرة، أو من الاستمرار في إضافة الصور بعد التراجع بشكل متكرر.
 * أكد معظم أعضاء المجتمع أن "الملاءمة" أكثر أهمية من "الجودة" عندما يتعلق الأمر بما إذا كانت الصورة تنتمي أم لا. بمعنى آخر، إذا كانت الصورة الوحيدة للشخص ضبابية، فهذا أفضل من عدم وجود صورة على الإطلاق. يجب تعليم الوافدين الجدد هذه القاعدة أثناء قيامهم بالمهمة.
 * يجب أن توضح واجهتنا أنه يجب على المستخدمين التحرك ببطء وعناية، بدلاً من محاولة إجراء أكبر عدد ممكن من المطابقات.
 * يجب أن نُعلِّم المستخدمين أن الصور يجب أن تكون تعليمية وليست زخرفية فحسب.
 * واجهة المستخدم
 * اقترح العديد من الأشخاص أن نعرض على المستخدمين العديد من الصور المرشحة للاختيار من بينها، بدلاً من واحدة فقط. سيؤدي هذا إلى زيادة احتمالية إرفاق الصور الجيدة بالمقالات.
 * 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.
 * الوضع في المقال
 * We learned about Wikidata infoboxes. We learned that for wikis that use them, the preference is for images to be added to Wikidata, instead of to the article, so that they can show up via the Wikidata infobox.  In this vein, we will be researching how common these infoboxes are on various wikis.
 * 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.
 * مستخدمون غير ناطقين باللغة الإنجليزية
 * 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.
 *  Captions 
 * Community members (and Growth team members) are skeptical about the ability of newcomers to write appropriate captions.
 * We received advice to show users example captions, and guidelines tailored to the type of article being captioned.

مخطّط لاختبار المستخدم


بالتفكير في الأسئلة المفتوحة أعلاه، بالإضافة إلى مدخلات المجتمع، نريد إنشاء بعض المعلومات الكمية والنوعية لمساعدتنا في تقييم جدوى بناء ميزة "إضافة صورة". على الرغم من أننا قمنا بتقييم الخوارزمية بين الموظفين ومستخدمي ويكيميديا، فمن المهم أن نرى كيف يتفاعل الوافدون الجدد معها، ونرى كيف يستخدمون حكمهم عند اتخاذ قرار بشأن ما إذا كانت الصورة تنتمي إلى مقال.

لحقيق لهذه الغاية، سنجري اختبارات مع usertesting.com، حيث يمكن للأشخاص الجدد في تحرير ويكيبيديا المرور عبر تطابقات الصور المحتملة في نموذج أولي والرد بـ «نعم» أو «لا» أو «غير متأكد». قمنا ببناء نموذج أولي سريع للاختبار، مدعومًا بتطابقات حقيقية من الخوارزمية الحالية. يعرض النموذج الأولي تطابقا واحدا فقط تلو الآخر، كل ذلك في مسار واحد. يتم عرض الصور مع جميع البيانات الوصفية ذات الصلة من كومنز:


 * اسم الملف
 * الحجم
 * التاريخ
 * المستخدم
 * الوصف
 * التعليق
 * التصنيفات
 * الوسوم

على الرغم من أن هذا قد لا يكون نفس ما سيكون عليه سير العمل بالنسبة للمستخدمين الحقيقيين في المستقبل، فقد تم إنشاء النموذج الأولي بحيث يمكن للمختبرين إجراء الكثير من التطابقات المحتملة بسرعة، مما ينتج عنه الكثير من المعلومات.

لتجربة النموذج الأولي التفاعلي، استخدموا هذا الرابط. لاحظوا أن هذا النموذج الأولي مخصص بشكل أساسي لعرض التطابقات من الخوارزمية -- لم نفكر بعد مليًا في تجربة المستخدم الفعلية. لا يقوم في الواقع بإنشاء أي تعديلات. يحتوي على 60 تطابقًا حقيقيًا اقترحته الخوارزمية.

إليكم ما سنبحث عنه في الاختبار:


 * 1) هل المشاركون قادرون على تأكيد التطابقات بثقة بناءً على الاقتراحات والبيانات المقدمة؟
 * 2) ما مدى دقة المشاركين في تقييم الاقتراحات؟ هل يعتقدون أنهم يقومون بعمل أفضل أم أسوأ مما كانوا يقومون به؟
 * 3) كيف يشعر المشاركون حيال مهمة إضافة الصور إلى المقالات بهذه الطريقة؟ هل يجدونها سهلة/صعبة، مثيرة للاهتمام/مملة، مجزية/غير ذات صلة؟
 * 4) ما هي المعلومات التي يجدها المشاركون أكثر قيمة في مساعدتهم على تقييم تطابق الصور والمقالات؟
 * 5) هل يمكن للمشاركين أن يكتبوا تعليقات جيّدة للصور التي يعتقدون أنّها تتطابق مع البيانات المقدّمة؟

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

Single vs. Multiple
Another important design question is whether to show the user a single proposed image match, or give them multiple images matches to choose from. When giving multiple matches, there's a greater chance that one of the matches is a good one. But it also may make users think they should choose one of them, even if none of them are good. It will also be a more complicated experience to design and build, especially for mobile devices. We have mocked up three potential workflows:


 * وحيد: in this design, the user is given only one proposed image match for the article, and they only have to accept or reject it. It is simple for the user.
 * متعدّد: this design shows the user multiple potential matches, and they could compare them and choose the best one, or reject all of them. A concern would be if the user feels like they should add the best one to the article, even if it doesn't really belong.
 * سلسلي: 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.



User tests December 2020
خلفية

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) What metadata do participants find most valuable in helping them evaluate image and article matches?
 * 5) Are participants able to write good captions for images they deem a match using the data provided?

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.

 Summary 

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.

 Observations 

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

القياسات


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

البيانات الوصفية
The user tests showed us that image metadata from Commons (e.g. filename, description, caption, etc.) is critical for a user to confidently make a match. For instance, though the user can see that the article is about a church, and that the photo is of a church, the metadata allowed them to tell if it is the church discussed in the article. In the user tests, we saw that these items of metadata were most important: filename, description, caption, categories. Items that were not useful included size, upload date, and uploading username.

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:


 * In general, local language metadata coverage is very low. English is the exception.
 * 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”.
 * We may want to prioritize image suggestions with local language metadata in our user interfaces, but until other features are built to increase the coverage, relying on local languages is not a viable option for these features in non-English wikis.

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
'' See this page for the details on the Android MVP. ''

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

The Android app is where "suggested edits" originated, and that team has a framework to build new task types easily. These are the main pieces:


 * The app will have a new task type that users know is only for helping us improve our algorithms and designs.
 * It will show users image matches, and they will select "Yes", "No", or "Skip".
 * We'll record the data on their selections to improve the algorithm, determine how to improve the interface, and think about what might be appropriate for the Growth team to build for the web platform later on.
 * No edits will happen to Wikipedia, making this a very low-risk project.

Results
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?
 * On average, users in the Android MVP did about 11 annotations each. While this is less than image descriptions and description translations, it is greater than the other four kinds of Android tasks.
 * 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% of the matches for which newcomers said "yes" are actually good matches according to experts. This is an improvement of about 5 percentage points over the algorithm alone.
 * This number goes up to 82-83% when we remove newcomers who have very low median time for evaluations.
 * Experts tend to agree with each other only about 85% of the time.
 * 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.

See the full results are here.

هندسيات
This section contains links on how to follow along with technical aspects of this project:


 * Work on the "proof of concept" API by the Platform Engineering team, built to back the Android MVP
 * Phabricator tasks around the Android team's MVP
 * Phabricator tasks and evaluations of the image matching algorithm

Iteration 1
In July 2021, the Growth team decided to move forward with building a first iteration of an "add an image" task for the web. This was a difficult decision, because of the many open questions and risks around encouraging newcomers to add images to Wikipedia articles. But after going through a year of idea validation, and looking through the resulting community discussions, evaluations, tests, and proofs-of-concepts around this idea, we decided to build a first iteration so that we could continue learning. These are the main findings from the idea validation phase that led us to move forward:


 * Cautious community support: community members are cautiously optimistic about this task, agreeing that it would be valuable, but pointing out many risks and pitfalls that we think we can address with good design.
 * Accurate algorithm: the image matching algorithm has shown to be 65-80% accurate through multiple different tests, and we have been able to refine it over time.
 * User tests: many newcomers who experienced prototypes found the task fun and engaging.
 * Android MVP: the results from the Android MVP showed that newcomers generally applied good judgment to the suggestions, but more importantly, gave us clues about how to improve their results in our designs. The results also hinted that the task could work well across languages.
 * Overall learnings: having bumped into many pitfalls through our various validation steps, we'll be able to guard against them in our upcoming designs. This background work has given us lots of ideas on how to lead newcomers to good judgment, and how to avoid damaging edits.

Hypotheses
We're not certain that this task will work well -- that's why we plan to build it in small iterations, learning along the way. We do think that we can make a good attempt using our learnings so far to build a lightweight first iteration. One way to think about what we're doing with our iterations is hypothesis testing. Below are five optimistic hypotheses we have about the "add an image" task. Our aim in Iteration 1 will be to see if these hypotheses are correct.


 * 1) Captions: users can write satisfactory captions. This is our biggest open question, since images that get placed into Wikipedia articles generally require captions, but the Android MVP did not test the ability of newcomers to write them well.
 * 2) Efficacy: newcomers will have strong enough judgment that their edits will be accepted by the communities.
 * 3) Engagement: users like to do this task on mobile, do many, and return to do more.
 * 4) Languages: users who don’t know English will be able to do this task. This is an important question, since the majority of metadata on Commons is in English, and it is critical for users to read the filename, description, and caption from Commons in order to confidently confirm a match.
 * 5) Paradigm: the design paradigm we built for "the add a link structured task" will extend to images.

Scope
Because our main objective with Iteration 1 is learning, we want to get an experience in front of users as soon as we can. This means we want to limit the scope of what we build so that we can release it quickly. Below are the most important scope limitations we think we should impose on Iteration 1.


 * Mobile only: while many experienced Wikimedians do most of the wiki work from their desktop/laptop, the newcomers who are struggling to contribute to Wikipedia are largely using mobile devices, and they are the more important audience for the Growth team's work. If we build Iteration 1 only for mobile, we'll concentrate on that audience while saving the time it would take to additionally design and build the same workflow for desktop/laptop.
 * Static suggestions: rather than building a backend service to continuously run and update the available image matches using the image matching algorithm, we'll run the algorithm once and use the static set of suggestions for Iteration 1. While this won't make the newest images and freshest data available, we think it will be sufficient for our learning.
 * Add a link paradigm: our design will generally follow the same patterns as the design for our previous structured task, "add a link".
 * Unillustrated articles: we'll limit our suggestions only to articles that have no illustrations in them at all, as opposed to including articles that have some already, but could use more. This will mean that our workflow will not need to include steps for the newcomer to choose where in the article to place the image. Since it will be the only image, it can be assumed to be the lead image at the top of the article.
 * No infoboxes: we'll limit our suggestions only to articles that have no infoboxes. That's because if an unillustrated article has an infobox, its first image should usually be placed in the infobox. But it is a major technical challenge to make sure we can identify the correct image and image caption fields in all infoboxes in many languages. This also avoids articles that have Wikidata infoboxes.
 * Single image: although the image matching algorithm can propose multiple image candidates for a single unillustrated article, we'll limit Iteration 1 to only proposing the highest-confidence candidate. This will make for a simpler experience for the newcomer, and for a simpler design and engineering effort for the team.
 * Quality gates: we think we should include some sort of automatic mechanism to stop a user from making a large number of bad edits in a short time. Ideas around this include (a) limiting users to a certain number of "add an image" edits per day, (b) giving users additional instructions if they spend too little time on each suggestions, (c) giving users additional instructions if they seem are accepting too many images. This idea was inspired by English Wikipedia's 2021 experience with the Wikipedia Pages Wanting Photos campaign.
 * Pilot wikis: as with all new Growth developments, we will deploy first only to our four pilot wikis, which are Arabic, Vietnamese, Bengali, and Czech Wikipedias. These are communities who follow along with the Growth work closely and are aware that they are part of experiments. The Growth team employs community ambassadors to help us correspond quickly with those communities. We may add Spanish and Portuguese Wikipedias to the list in the coming year.

We're interested to hear community members' opinions on if these scoping choices sound good, or if any sound like they would greatly limit our learnings in Iteration 1.

Mockups and prototypes
Building on designs from our previous user tests and on the Android MVP, we are considering multiple design concepts for Iteration 1. For each of five parts of the user flow, we have two alternatives. We'll user test both to gain information from newcomers. Our user tests will take place in English and Spanish -- our team's first time testing in a non-English language. We also hope community members can consider the designs and provide their thoughts on the talk page.

 Prototypes for user testing 

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)

نماذج بالأحجام الطبيعية لاختبار المستخدم

Below are static images of the mockups that we're using for user testing in August 2021. Community members are welcome to explore the Growth team designer's Figma file, which contains the mockups below in the lower right of the canvas, as well as the various pieces of inspiration and notes that led to them.

Feed

These designs refer to the very first part of the workflow, in which the user chooses an article to work on from the suggested edits feed. We want the card to be attractive, but also not confuse the user.

 Final designs for Iteration 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.