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

এই পাতায় "একটি ছবি যুক্ত করুন" কাঠামোবদ্ধ কাজটির বিবরণ লিপিবদ্ধ রয়েছে। এটি এক ধরনের কাঠামোবদ্ধ কাজ যা নবাগতদের নীড়পাতার মাধ্যমে গ্রোথ দল প্রয়োগ করবে। অ্যান্ড্রয়েড দলও উইকিপিডিয়া অ্যান্ড্রয়েড অ্যাপের জন্য অনুরূপ কিছু করতে চাইছে, যার কার্যপদ্ধতি একইরকম হবে। দুই দলের ক্ষেত্রেই প্রাসঙ্গিক আলোচন ও হালনাগাদকৃত তথ্য এই পাতায় লিপিবদ্ধ রয়েছে। The Android team is also thinking about a similar task for the Wikipedia Android app using the same underlying components. Additionally, the Structured Data team is in the early stages of exploring something similar, targeted at more experienced users and benefiting from Structured Data on Commons. Discussion and updates on this page are relevant to the work of all teams.

এই পাতায় প্রধান প্রধান সামগ্রী, নকশা, উন্মুক্ত প্রশ্নাবলী এবং সিদ্ধান্তসমূহ লিপিবদ্ধ রয়েছে।

ধারাবাহিক উন্নতির হালনাগাদকৃত তথ্য সাধারণত গ্রোথ দলের হালনাগাদকৃত পাতায় দেয়া হবে। বৃহত্তর এবং বিস্তারিত তথ্য এখানে উল্লেখ করা হবে।

বর্তমান অবস্থা

 * 2020-06-22: ছবি সুপারিশ করার জন্য একটি সহজ অ্যালগোরিদম তৈরি করার পরিকল্পনাগুলো ভেবে দেখা
 * 2020-09-08: ইংরেজি, ফরাসি, আরবি, কোরিয়, চেক এবং ভিয়েতনামিয় ভাষায় একটি প্রাথমিক অবস্থার ম্যাচিং অ্যালগোরিদম পরীক্ষিত হয়েছে।
 * 2020-09-30: ইংরেজি, ফরাসি, আরবি, কোরিয়, চেক এবং ভিয়েতনামিয় ভাষায় দ্বিতীয় দফায় একটি ম্যাচিং অ্যালগোরিদম পরীক্ষিত হয়েছে।
 * 2020-10-26: ছবি সুপারিশকরণ সেবা চালুর সম্ভাব্যতা নিয়ে অভ্যন্তরীণ প্রকৌশলগত আলোচনা
 * 2020-12-15: ব্যবহারকারী পরীক্ষার প্রাথমিক ধাপগুলোর মাধ্যমে যাচাই করা হয় নবাগতরা এই কাজে সফল হবেন কীনা
 * 2021-01-20: Platform Engineering team begins building proof-of-concept API for image recommendations
 * 2021-01-21: Android team begins work on minimum viable version for learning purposes
 * 2021-01-28: posted user test results

সারাংশ
কাঠামোবদ্ধ কাজের উদ্দেশ্য হল সম্পাদনার কাজগুলোকে ভেঙে ছোটখাটো আকারের ধারাবাহিক কাজ তৈরি করা। এর মাধ্যমে নবাগতরা আরো সহজভাবে কাজটি বুঝতে পারবে, বিশেষ করে মোবাইল ব্যবহারকারীদের ক্ষেত্রে। গ্রোথ দল বিশ্বাস করে যে সম্পাদনার পরিবেশে নতুন ধরনের কাজের গতিপথ তৈরির ফলে আরো অনেক নতুন মানুষ উইকিপিডিয়ায় কাজ করতে শুরু করবেন। এদের অনেকে হয়তো উল্লেখযোগ্য পরিমাণে কাজ করবে এবং তাদের সম্প্রদায়ের সাথে প্রত্যক্ষভাবে যুক্ত হয়ে যাবেন। সম্প্রদায়ের সাথে কাঠামোবদ্ধ কাজের পরিকল্পনা নিয়ে আলোচনার পরে, আমরা সিদ্ধান্ত নিয়েছি প্রথম কাঠামোবদ্ধ কাজ তৈরি করব: "সংযোগ করুন"।

যখন আমরা প্রথম কাজটি তৈরি করছি, তখনই আমরা ভাবছিলাম পরের কাঠামোবদ্ধ কাজটি কী হতে পারে। আমরা চিন্তা করেছি যে ছবি যুক্ত করা নতুনদের জন্য একটা উপযুক্ত কাজ হবে। এর উদ্দেশ্য হল একটি সহজ অ্যালগোরিদমের মাধ্যমে কমন্স থেকে ছবি সুপারিশ করা হবে সেইসব নিবন্ধের জন্য, যেখানে কোনো ছবি নেই। প্রাথমিকভাবে এটা কেবল উইকিউপাত্তে বিদ্যমান সংযোগগুলো নিয়েই কাজ করবে, এবং নবাগতরা ঠিক করবেন যে ছবিটি ঐ নিবন্ধে যুক্ত করা প্রয়োজন আছে নাকি নেই।

আমরা জানি যে এটি কীভাবে কাজ করবে তা নিয়ে বিভিন্ন উন্মুক্ত প্রশ্ন রয়েছে। অনেক কারণ থাকতে পারে যার কারণে এটা সঠিকভাবে কাজ করবে না। এ জন্য আমরা বিভিন্ন সম্প্রদায়ের কাছ থেকে আলোচনার মাধ্যমে জানতে চাইছি আমরা কীভাবে এগোতে পারি।

ছবিই কেন?
উল্লেখযোগ্য অবদান অনুসন্ধানের জন্য

আমরা যখন সম্প্রদায়ে সদস্যদের সাথে প্রথম কাঠামোবদ্ধ কাজ নিয়ে আলোচনা করছিলাম, তখন অনেকেই জানিয়েছিলেন যে উইকিসংযোগ করাটা উঁচু ধরনের সম্পাদনা নয়। তারা জানিয়েছিলেন কীভাবে নবাগতরা উল্লেখযোগ্য অবদান করতে পারেন। একটি প্রস্তাবনা ছিল ছবিবিষয়ক। উইকিমিডিয়া কমন্সে প্রায় সাড়ে ছয় কোটিরও অধিক সংখ্যক ছবি আছে। কিন্তু বিভিন্ন ভাষার উইকিপিডিয়ার ৫০% নিবন্ধে কোনো ছবি নেই। আমরা বিশ্বাস করি কমন্স থেকে নেয়া অনেক ছবির মাধ্যমে উইকিপিডিয়ায় নিবন্ধগুলো আরো তাৎপর্যপূর্ণ হয়ে উঠবে।

নবাগতদের আগ্রহ

আমরা জানি যে উইকিপিডিয়ায় ছবি যুক্ত করার ব্যাপারে অনেক নবাগতই আগ্রহী। নবাগতরা যখন স্বাগত জরিপে অংশ নেন, তখন কেন অ্যাকাউন্ট তৈরি করছেন প্রশ্নের জবাবে উল্লেখযোগ্য সংখ্যক উত্তর দেন "ছবি যুক্ত করার জন্য"। আমরা সাহায্য প্যানেলের প্রশ্নের ক্ষেত্রেও দেখেছি কীভাবে ছবি যুক্ত করা যায় একটা নিয়মিত প্রশ্ন, যা আমরা যে সকল উইকির সাথে কাজ করেছি তার প্রত্যেক ক্ষেত্রেই লক্ষ্য করা গেছে। তবে অনেক নবাগতই প্রকৃতপক্ষে তাদের নিজেদের তোলা ছবি যুক্ত করতে চান, তবে এ থেকে এটা সুস্পষ্ট যে ছবি যোগ করার ব্যাপারটা আগ্রহোদ্দীপক এবং আকাঙ্ক্ষিত। এটা স্বাভাবিক, ছবি যোগ করার ব্যাপারটা নবাগতদের অংশ নেয়া ফেসবুক, ইনস্টাগ্রামের মত অন্যান্য প্ল্যাটফর্মের অনুরূপ।

ছবি নিয়ে কাজ করার ক্ষেত্রে সমস্যা

ছবির ব্যাপারে সাহায্য প্যানেলের বিভিন্ন প্রশ্নের মাধ্যমে বুঝতে পারা যায় যে নিবন্ধে ছবি যোগের পদ্ধতিটা বেশ কঠিন। নবাগতদের উইকিপিডিয়া ও কমন্সের পার্থক্য বুঝতে হয়, কপিরাইট সম্পর্কে জানতে হয়, এবং সঠিকভাবে ছবি বসানো ও শিরোনাম দেয়ার ব্যাপারগুলো বুঝতে হয়। ছবি নেই এমন কোনো নিবন্ধে কমন্স থেকে বেছে ছবি যোগ করার জন্য কিছুটা দক্ষতার প্রয়োজন হয়, এবং এক্ষেত্রে উইকিউপাত্ত ও বিষয়শ্রেণী সংক্রান্ত জ্ঞান কাজে লাগে।

"উইকিপিডিয়ার নিবন্ধে ছবি চাই" ক্যাম্পেইনের সাফল্য

উইকিপিডিয়ার নিবন্ধে ছবি যোগ করুন (WPWP) ক্যাম্পেইন অসাধারণভাবে সাফল্যমণ্ডিত হয়। ৬০০ জন ব্যবহারকারী ৮৫,০০০ পাতায় ছবি যোগ করে। তারা কিছু সম্প্রদায় সরঞ্জাম ব্যবহার করে কাজটি করতেন। এই সরঞ্জাম ছবিহীন নিবন্ধগুলো তুলে ধরতো এবং উইকিউপাত্তের মাধ্যমে ছবি সুপারিশ করতো। কীভাবে নবাগতদের সহায়তা করা যায়, সে ব্যাপারে গুরুত্বপূর্ণ অনেক কিছু শেখা বাকি থাকলেও এর মাধ্যমে আমরা আত্মবিশ্বাসী হয়েছি যে ব্যবহারকারীরা ছবি যোগ করার ক্ষেত্রে আগ্রহী এবং এক্ষেত্রে তারা সরঞ্জামের সহায়তা নিতে পারেন।

সবকিছুকে একত্রীত করে

সব তথ্যাবলীকে একত্রীত করে আমরা ভেবে দেখেছি যে যদি কাঠামোবদ্ধ কাজ হিসেবে "একটি ছবি যুক্ত করুন" যুক্ত করা হয়, তাহলে এটা উইকিপিডিয়ার জন্য যেমন সৃজনশীল হবে তেমনি নবাগতদের জন্যও চিত্তাকর্ষক হবে।

অ্যালগোরিদম
কাঠামোবদ্ধ কাজ হিসেবে ছবি যোগ করার বৈশিষ্ট্যটি চালুর ক্ষেত্রে আমাদের সক্ষমতা নির্ভর করে অ্যালগোরিদমের উপরে, যা যথেষ্ট পরিমাণে ভালো সুপারিশ তৈরি করবে। আমরা চাই না নবাগতরা নিবন্ধে ভুল ছবি যোগ করার পথে হাঁটুক, কারণ তাহলে পরীক্ষকদের পরিষ্কারকরণে বেশ সময় ব্যয় হয়। এ জন্য প্রথমেই আমাদের কাজ করতে হবে যথেষ্ট পরিমাণে ভালো অ্যালগোরিদম তৈরি করতে।

যুক্তি
আমরা উইকিমিডিয়া গবেষণা দলের সাথে কাজ করছি এবং এযাবৎ আমরা যে অ্যালগোরিদমটি পরীক্ষা করছি সেটি সঠিকতা এবং মানুষের সিদ্ধান্তকে গুরুত্ব দেয়। কম্পিউটার ভিশন পদ্ধতি ব্যবহার করা হয়নি, যা কিছুটা অস্বাভাবিক ফলাফল প্রদান করে। বর্তমানে এটি সহজভাবে অভিজ্ঞ অবদানকারীদের অবদানের সংযোগ ঘটিয়ে উইকিউপাত্ত থেকে বিদ্যমান তথ্য গ্রহণ করে। মূলত তিন উপায়ে এটি ছবিবিহীন নিবন্ধে ছবির সুপারিশ করে:


 * নিবন্ধের উইকিউপাত্ত ভুক্তির দিকে লক্ষ্য করা হয়। যদি এটির কোনো ছবি (P18) থাকে, তবে সেই ছবিটি নির্বাচন করা হয়।
 * নিবন্ধের উইকিউপাত্ত ভুক্তির দিকে লক্ষ্য করা হয়। যদি এটির সাথে কোনো কমন্স বিষয়শ্রেণী (P373) থাকে, তবে বিষয়শ্রেণী থেকে সেই ছবিটি নির্বাচন করা হয়।
 * একই বিষয়ে অন্য ভাষার নিবন্ধে কোনো ছবি আছে কীনা দেখা হয়, থাকলে ঐ নিবন্ধের মূল ছবিটি নির্বাচন করা হয়।

অ্যালগোরিদম আরো কিছু যুক্তিকে ব্যবহার করে, যেমন আইকন বা কোনো নিবন্ধের পরিভ্রমণ বক্সে থাকা ছবি।

কর্মক্ষমতা
ডিসেম্বর ২০২০ পর্যন্ত আমরা দুই দফায় অ্যালগোরিদম পরীক্ষা করেছি, প্রত্যেকবার মোট ছয় ভাষায় এটি পরিচালিত হয়েছে: ইংরেজি, ফরাসি, আরবি, ভিয়েতনামিয়, চেক এবং কোরিয়। আমাদের দলের অ্যাম্বাসেডররা এটি পরীক্ষা করেছে, যারা স্থানীয়ভাবে ঐ ভাষা ব্যবহার করেন। প্রতিটি ভাষার মোট ৫০টি প্রস্তাবনা দেয়া হয়েছে, তা যাচাই করে এবং শ্রেণিবিন্যাস করে আমরা নিম্নোক্ত বিভাগে ভাগ করেছি:

এ ধরনের অ্যালগোরিদমের কাজের ক্ষেত্রে একটি প্রশ্ন থাকে, যে এটাকে কতটা সঠিক হতে হবে? ৭৫% মিলে গেলে সেটা কি যথেষ্ট হবে? নাকি এটাকে ৯০% সঠিক হতে হবে? এটা ৫০% এর মত সঠিক হলে কি চলবে? এই সব নির্ভর করে নবাগত যারা এটা ব্যবহার করবে, তাদের দৃষ্টিভঙ্গির উপর, এবং কম মিলে যাওয়া ক্ষেত্রগুলোতে তারা কতটা ধৈর্যশীল হবেন। আমরা এ সম্পর্কে আরো জানতে পারব যখন সত্যিকারের নবাগতদের উপর অ্যালগোরিদমটা পরীক্ষা করতে সক্ষম হব।

প্রথম দফার মূল্যায়নে আমরা সবচেয়ে গুরুত্বপূর্ণ যে ব্যাপারটা দেখতে পেয়েছি সেটা হল অ্যালগরিদমের কিছু সহজ উন্নতির ক্ষেত্র, এবং কোন নিবন্ধ আর ছবি বাদ দিতে হবে সেটিও। এই উন্নতিগুলো বাদেও প্রায় ২০-৪০% মিল ছিল "২-এর", অর্থাৎ নিবন্ধের জন্য (বিভিন্ন উইকির উপর নির্ভরশীল) এগুলো দারুণভাবে মিলে গেছে। মূল্যায়নের সম্পূর্ণ ফলাফল এবং টিকা আপনি এখানে দেখতে পাবেন।

দ্বিতীয় দফার মূল্যায়নের জন্য নানাভাবে একে উন্নত করা হয়, সঠিকতাও বৃদ্ধি পায়। ৫০-৭০% "2s" মিলসম্পন্ন হয় (বিভিন্ন উইকির উপর নির্ভরশীল)। তবে সঠিকতা বৃদ্ধি করার ফলে ব্যাপকতা কমে যেতে পারে, অর্থাৎ সম্ভাব্য মিল দেখানোর জন্য পাওয়া নিবন্ধের সংখ্যা। কিছুটা সংরক্ষিত উপায় অনুসরণ করে এই অ্যালগোরিদম নির্দিষ্ট উইকিতে মাত্র কয়েক হাজার প্রস্তাবনা দিতে পারবে, যদি সেই উইকিতে হাজার বা লাখো নিবন্ধ থাকে তা সত্ত্বেও। আওরা বিশ্বাস করি যে এই সংখ্যা নতুন বৈশিষ্ট্যের প্রাথমিক সংস্করণের জন্য যথেষ্ট হবে। দ্বিতীয় দফা মূল্যায়নের সম্পূর্ণ ফলাফল এবং টিকা এখানে দেখতে পাবেন।

আমরা অ্যালগোরিদমটি আরো উন্নত করার জন্য কাজ করছি। ২০২০ সালের ডিসেম্বরে আমরা তৃতীয় দফা মূল্যায়নের চেষ্টা করবি, যা সম্পর্কে আপনি এখানে দেখতে পাবেন।

উন্মুক্ত প্রশ্ন
উইকিপিডিয়া অভিজ্ঞতার একটি গুরুত্বপূর্ণ অংশে রয়েছে ছবি। আমরা তীক্ষ্ণভাবে বিচার করছি কীভাবে সহজে ছবি যুক্ত করার বৈশিষ্ট্যটি কাজ করবে, সম্ভাব্য সমস্যা কী হতে পারে, এবং সম্প্রদায়ের সদস্যদের জন্য প্রয়োগটা কেমন হবে। আমরা অনেক উন্মুক্ত প্রশ্ন পেয়েছি এবং আমরা সম্প্রদায়ের সদস্যদের থেকে আরো প্রশ্ন আহ্বান করছি।


 * আমাদের অ্যালগোরিদম কি যথেষ্ট পরিমাণে ভালো হবে, যেন পর্যাপ্ত সংখ্যক সম্ভাব্য মিলসম্পন্ন প্রস্তাবনা দেয়া সম্ভব হবে?
 * ছবি যোগ করা হবে কী না সংক্রান্ত সিদ্ধান্ত নেয়ার ক্ষেত্রে কমন্স এবং ছবিবিহীন নিবন্ধ সংশ্লিষ্ট কী কী মেটাডেটা নবাগতদের প্রয়োজন হবে?
 * পরামর্শগুলো দেখে কি নবাগতরা যথেষ্ট পরিমাণে সঠিক সিদ্ধান্ত নিতে পারবে?
 * কমন্সের মেটাডেটা যদি ইংরেজিতে থাকে, তাহলে কি নবাগত যারা ইংরেজি ভালো জানেন না, তারাও একইভাবে ভালো সিদ্ধান্ত নিতে পারবে?
 * নবাগতরা কি নিবন্ধে ছবি যোগ করার পাশাপাশি ভালো ক্যাপশন লিখতে পারবে?
 * ছবির "মান" দেখে বিচার করাটা নবাগতদের জন্য কতটা জরুরী, যদি এর মানের বিপরীতে "প্রাসঙ্গিকতা"র কথা চিন্তা করি?
 * নবাগতদের কাছে কি এই কাজটা আগ্রহোদ্দীপক হবে? মজাদার? কঠিন? সহজ? বিরক্তিকর?
 * আমরা ঠিক কীভাবে নির্ধারণ করব যে কোন কোন নিবন্ধে ছবি নেই?
 * ছবিবিহীন নিবন্ধের কোথায় ছবি বসানো হবে? নিবন্ধের শীর্ষভাবে ছবি বসানোই কি যথেষ্ট হবে?
 * পরামর্শের ক্ষেত্রে সম্ভাব্য পক্ষপাতের ব্যাপারে আমরা কীভাবে খেয়াল রাখতে পারি? যেমন, হয়তো পরামর্শের ক্ষেত্রে ইউরোপ ও উত্তর আমেরিকাকে অধিক সংখ্যক মিলের প্রস্তাবনা দেয়া হতে পারে।
 * এরকম একটি কার্যপদ্ধতি কি ধ্বংসপ্রবণতা তৈরি করবে? কীভাবে এর বিরুদ্ধে পদক্ষেপ নেয়া যেতে পারে?

চিন্তা যাচাইকরণ


সম্প্রদায়ের মতামত আর উপরে বর্ণিত উন্মুক্ত প্রশ্নসমূহের পাশাপাশি আমরা চাই "একটি ছবি যুক্ত করুন" বৈশিষ্ট্যের জন্য কিছু গুণগত আর পরিমাণগত তথ্য তৈরি করতে চাই। আমরা কর্মকর্তা এবং উইকিমিডিয়ানগণ এই অ্যালগোরিদমের মূল্যায়ন করছেন, নবাগতরা এই বৈশিষ্ট্যটি কীভাবে দেখেন, তা জানাটা গুরুত্বপূর্ণ। তারা নিবন্ধে ছবি যোগ করার ক্ষেত্রে কীভাবে বিচক্ষণতার পরিচয় দেবেন সেটাও একটা গুরুত্বপূর্ণ ব্যাপার।

আমরা usertesting.com ব্যবহার করে কিছু পরীক্ষা করব, যেন উইকিপিডিয়ার সম্পাদনার ক্ষেত্রে যারা নতুন তারা ছবি শনাক্তকরণ প্রোটোটাইপের জন্য "হ্যাঁ", "না", বা "নিশ্চিত নই" নির্বাচন করতে পারেন। আমরা পরীক্ষার জন্য একটা দ্রুত প্রোটোটাইপ তৈরি করেছি, যা বর্তমান অ্যালগোরিদমের সত্যিকারের মিলগুলোকে নিয়ে নির্মিত। প্রোটোটাইপটি একটার পর একটা মিল দেখাবে। ছবি দেখানোর পাশাপাশি কমন্স থেকে প্রাসঙ্গিক মেটাডেটাও দেখানো হয়।


 * চিত্রের নাম
 * আকার
 * তারিখ
 * ব্যবহারকারী
 * বিবরণ
 * শিরোনাম
 * বিষয়শ্রেণীসমূহ
 * ট্যাগসমূহ

ভবিষ্যতে নবাগতদের জন্য যে কার্যপদ্ধতি তৈরি হবে, তার সাথে এটার অবিকল মিল না থাকলেও পরীক্ষকরা যেন সহজেই কিছু মিল নিয়ে কাজ করতে পারেন, তথ্য পেতে পারেন, তার জন্যই প্রোটোটাইপটি নির্মিত হয়েছে।

প্রোটোটাইপটি পরীক্ষা করার জন্য, এই লিঙ্ক ব্যবহার করুন।

পরীক্ষার জন্য আমরা যা দেখছি:


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


 * Single: 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.
 * Multiple: 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.
 * Serial: this design offers multiple image matches, but the user looks at them one at a time, records a judgment, and then chooses a best one at the end if they indicated that more than one might match. This might help the user focus on one image at a time, but adds an extra step at the end.



User tests December 2020
Background

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.

Metrics


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

Android MVP
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.

The Android team will be working on this in February and March 2021, hopefully allowing the Growth team to begin learning quickly.

Engineering
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