Growth/Personalized first day/Structured tasks/ar

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

الوضع الحالي

 * 2020-05-01: التخطيط والتوثيق للملاحظات الأولية
 * 2020-05-17: البدء في النقاش داخل المجتمع
 * 2020-05-29: المجسّمات الأوّلية
 * 2020-08-24: أسبوع الاجتماعات التخطيطية
 * 2020-09-08: نداء إلى المجتمع حول مناقشة آخر التصاميم

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

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

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

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


 * 1) ابحثوا عن المقالة المنشودة.
 * 2) اكتشفوا ما إذا كانت المعلومات التي تريدون إضافتها موجودة بالفعل في المقالة.
 * 3) اختاروا القسم الذي تريدون إضافة الجملة فيه.
 * 4) اضغطوا للبدء في التعديل.
 * 5) اكتبوا الجملة في المكان الصحيح.
 * 6) اضغطوا على زر الاقتباس.
 * 7) ارجعوا إلى المصدر للحصول على الرابط أو معلومة الاقتباس.
 * 8) قوموا بملء ثم بحفظ نموذج الاقتباس.
 * 9) اضغطوا لنشر التعديل.
 * 10) قوموا بملء ثم تعديل الملخص.
 * 11) انشروا.

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

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


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

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

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

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

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

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

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

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



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



مع التفكير في المهام المهيكلة، يبدو أنّه سيطرح هذا السؤال الهام: هل على مسارات العمل أن تتّجه نحو تعليم الوافدين الجدد كيفية استخدام أساليب التحرير التقليدية، أم أن تتّجه أكثر نحو تسهيل تضخيم عدد تعديلات الوافدين الجدد؟

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


 * فقط حوالي 25% من الوافدين الجدد الذين يضغطون على مقالة مقترحة يقومون فعليا بتعديلها.
 * فقط حوالي 25% من الذين يقومون بتعديل مقترح يعاودون القيام بتعديلٍ مقترحٍ آخر.
 * هنالك قلّة من الوافدين الجدد الذين ينجحون فعليا في التعديلات المقترحة، يقومون بالعشرات منها يوميّا. يظهر هذا الطاقة الكامنة في الوافدين الجدد للقيام بالكثير من أعمال الويكي.
 * في اختبارات المستخدمين الحيّة، عندما يطلب من الوافدين الجدد من القيام بأعمال نسخ التحرير على مقالة ما أو إضافة وصلات إلى مقالة أخرى، يريدون في كثير من الأحيان معرفة دقيقة ماهي الجملة أو العبارة التي تتطلّب تدخّلهم. بعبارة أخرى، محاولة تعديل كامل المقالة/الصفحة أمر مفتوح جدّا.

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

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


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

مخاوف وسلبيات متعلقة بالمهام المهيكلة
عندما نضيف للمستخدمين طرق جديدة لتعديل ويكيبيديا، يمكن للعديد من الأمور أن تحيد:


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

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


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

Types of tasks
There are many different editing workflows that have the potential to become structured. We began to list workflows when we first designed the newcomer tasks workflow here, and we have since narrowed down to a shorter list of task types that seem best suited to being structured. The table below contains that short list, ranked in a potential priority order.

Prioritizing "add a link"
The Growth team currently (May 2020) wants to prioritize the "add a link" workflow over the other ones listed in the table above. Although other workflows, such as "copyedit", seem to be more valuable, there are a set of reasons we would want to start first with "add a link":


 * In the near term, the most important thing we would want to do first is to prove the concept that "structured tasks" can work. Therefore, we would want to build the simplest one, so that we can deploy to users and gain learnings, without having to invest too much in the first version. If the first version goes well, then we would have the confidence to invest in types of tasks that are more difficult to build.
 * "Add a link" seems to be the simplest for us to build because there already exists an algorithm built by the WMF Research team that seems to do a good job of suggesting wikilinks (see the Algorithm section).
 * Adding a wikilink doesn't usually require the newcomer to type anything of their own, which we think will make it particularly simple for us to design and build -- and for the newcomer to accomplish.
 * Adding a wikilink seems to be a low-risk edit. In other words, the content of an article can't be as compromised through adding links incorrectly as it could through adding references or images incorrectly.

Notes on "copyedit"
In conversations with community members on this project's discussion page, many people brought up the question of how to make a structured task around copyediting. Correcting spelling, grammar, punctuation, and tone seemed to everyone to be a clearly useful task that should be prioritized. The Growth team initially shied away from this workflow because of scaling concerns: even if we were able to find or develop an algorithm that could reliably find copyedits in one language, would we be able to do that in dozens of other languages?

We began to learn more about this by talking with User:Beland, who developed the "moss" script for English Wikipedia's Typo Team. We wanted to understand how the process works, and what it might look like to do something similar in other languages. In short, it sounds like the most promising avenue is through existing open-source spellcheckers and dictionaries. Two examples are the aspell and hunspell libraries. Below are our notes from learning about "moss" with User:Beland.


 * Prospects for doing something similar in other languages
 * A process like this should theoretically work in other languages, given that other languages also have Wiktionaries and open-source spellcheckers.
 * But it would not be possible to deploy in a new language without native speakers validating it. There would likely need to be customization for many languages.
 * Likely more challenges for languages without word segmentation (e.g. Japanese).
 * Likely more challenges for agglutinative languages.
 * Different projects have differing manuals of style, which may cause issues.
 * If an algorithm is performing poorly, it should always be possible to change its thresholds so that it identifies fewer potential errors, but with higher confidence.
 * How does moss work?
 * Download the dump files of all of English Wikipedia every two weeks.
 * In order to cut down on false positives, remove templates and everything inside quotation marks, etc.  Only want to work on the main text in the article: the things written “in Wikipedia’s voice”.
 * Check that every word is in English Wiktionary.
 * Uses Python NLTK (natural language toolkit) for word segmentation.
 * Looks at edit distance to classify misspellings.  e.g. “T1” is one edit distance (95% precision).  Also classifies “TS” whitespace errors.
 * Also includes an English open-source spellchecker to narrow the search space so that the algorithm can run faster.
 * He has also started trying to add grammar rules (e.g. identifying passive voice), but that’s more experimental, and much more difficult than spelling.
 * At the end of the process, it produces a list of articles and likely typos.  The user opens the article and searches for the likely typo.

Many copyedit requests are also editors whose native language is not English, asking for English polishing. See WikiProject Guild of Copy Editors.

Design
While the "structured task sketch" section above contains some quick initial sketches to demonstrate the idea behind structured tasks, this section contains our current design thinking. To look into the full set of thinking around designs for the "add a link" structured task, , which contains background, user stories, and initial design concepts.

Comparative review
When we design a feature, we look into similar features in other software platforms outside of the Wikimedia world. These are some highlights from comparative reviews done in preparation for Android’s suggested edits feature, which remain relevant for our project.


 * Task types – are divided into five main types: Creating, Rating, Translating,  Verifying content created by others (human or machine), and Fixing content created by others.
 * Visual design & layout – incentivizing features (stats, leaderboards, etc) and onboarding is often very visually rich, compared to pared back, simple forms to complete short edits. Gratifying animations often compensate for lack of actual reward.
 * Incentives – Most products offered intangible incentives grouped into: Awards and ranking (badges) for achieving set milestones, Personal pride and gratification (stats), or Unlocking features (access rights)
 * Users motivations – those with more altruistic motivations (e.g., help others learn) are more likely to be incentivized by intangible incentives than those with self-interested motivations (e.g., career/financial benefits)
 * Personalization/Customization – was used in some way on most apps reviewed. The most common customization was via surveys during account creation or before a task; and geolocalization used for system-based personalization.
 * Guidance – Almost all products reviewed had at least basic guidance prior to task completion, most commonly introductory ‘tours’. In-context help was also provided in the form of instructional copy, tooltips, step-by-step flows,  as well as offering feedback mechanisms (ask questions, submit feedback)

Initial wireframes
After organizing our thoughts and doing background research, the first visuals in the design process are "wireframes". These are simply meant to experiment and display some of the ideas we think could work well in a structured task workflow. For full context around these wireframes, see the.

نماذج التصميم لشهر أغسطس 2020
Translate this section

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

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


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

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



Static mockups

للاطلاع على هذه النماذج للتصورات، نوصي بعرض المجموعة الكاملة للشرائح أدناه.



Interactive prototypes

You can also try out the "interactive prototypes" that we're using for live user tests. These prototypes, for Concept A and for Concept B, show what it might feel like to use "add a link" on mobile. They work on desktop browsers and Android devices, but not iPhones. Note that not everything is clickable -- only the parts of the design that are important for the workflow.

أسئلة جوهرية

عند مناقشة هذه التصميمات، يأمل الفريق في إثارة مجموعة من التساؤلات الجوهرية:


 * 1) هل يجب على التعديل أن يحدث داخل المقالة (المزيد من السياق)؟ أم ضمن تجربة منفردة مخصصة لهذا النوع من التعديل (مزيد من التركيز، لكن قفزة كبيرة للذهاب إلى استخدام المحرر)؟
 * 2) ماذا لو أراد شخص ما تعديل نص الرابط أو هدفه؟ هل يجب علينا منع ذلك أم تركهم ينتقلون إلى المحرر التقليدي؟ هل هذه الفرصة المناسبة لتلقينهم المحرّر المرئي؟
 * 3) نعلم أنّه من الجوهريّ لنا أن ندعم اكتشاف الوافدين الجدد لطرق التحرير التقليدية. لكن متى يجب علينا القيام بذلك؟ هل نقوم بذلك خلال تجربة المهام المهيكلة مع تذكير بأن الوافد الجديد له خيار الذهاب إلى المحرّر؟ أم بصفة دوريّة عند الانتهاء من المراحل، مثل عند اكتمال عدد معيّن من المهام المهيكلة؟
 * 4) هل لفظ "بوت" هو الأنسب هنا؟ ماهي العبارات الممكنة الأخرى؟ "خوارزمي"، "حاسوب"، "أوتو-"، "آلة" إلخ.؟ ما الذي قد يساعد بشكل أفضل في جعل اقتراحات الآلة غير قابلة للخطأ وأهمية التدخّل البشري؟

Mobile user testing September 2020
Background

During the week of September 7, 2020, we used usertesting.com to conduct 10 tests of the mobile interactive prototypes, 5 tests each of Concepts A and B, all in English. By comparing how users interact with the two different approaches at this early stage, we wanted to better understand whether one or the other is better at providing users with good understanding and ability to successfully complete structured tasks, and to set them up for other kinds of editing afterward. Specific questions we wanted to answer were:


 * Do users understand how they are improving an article by adding wikilinks?
 * Do users seem like they will want to cruise through a feed of link edits?
 * Do users understand that they're being given algorithmic suggestions?
 * Do users make better considerations on machine-suggested links when they have the full context of the article (like in Concept A)?
 * Do users complete tasks more confidently and quickly in a focused UI (like in Concept B)?
 * Do users feel like they can progress to other, non-structured tasks?

Key findings


 * The users generally were able to exhibit good judgment for adding links. They understood that AI is fallible and that they have to think critically about the suggestions.
 * While general understanding of what the task would be ("adding links") was low at first, they understood it well once they actually started doing the task. Understanding in Concept B was marginally lower.
 * Concept B was not better at providing focus. The isolation of excerpts in many cases was mistaken for the whole article. There were also many misunderstandings in Concept B about whether the user would be seeing more suggestions for the same term, for the same article, or for different articles.
 * Concept A better conveyed expectations on task length than Concept B. But the additional context of a whole article did not appear to be the primary factor of why.
 * As participants proceed through several tasks, they become more focused on the specific link text and destination, and less on the article context. This seemed like it could lead to users making weak decisions, and this is a design challenge. This was true for both Concepts A and B.
 * Almost every user intuitively knew they could exit from the suggestions and edit the article themselves by tapping the edit pencil.
 * All users liked the option to view their edits once they finished, either to verify or admire them.
 * “AI” was well understood as a concept and term. People knew the link suggestions came from AI, and generally preferred that term over other suggestions. This does not mean that the term will translate well to other languages.
 * Copy and onboarding needs to be succinct and accessible in multiple points. Reading our instructions is important, but users tended not to read closely. This is a design challenge.

Outcome


 * We want to build Concept A for mobile, but absorbing some of the best parts of Concept B's design. These are the reasons why:
 * User tests did not show advantages to Concept B.
 * Concept A gives more exposure to rest of editing experience.
 * Concept A will be more easily adapted to an “entry point in reading experience”: in addition to users being able to find tasks in a feed on their homepage, perhaps we could let them check to see if suggestions are available on articles as they read them.
 * Concept A was generally preferred by community members who commented on the designs, with the reason being that it seemed like it would help users understand how editing works in a broader sense.
 * We still need to design and test for desktop.

Ideas

The team had these ideas from watching the user tests:


 * Should we consider a “sandbox” version of the feature that lets users do a dry run through an article for which we know the “right” and “wrong” answers, and can then teach them along the way?
 * Where and when should we put the clear door toward other kinds of editing?  Should we have an explicit moment at the end of the flow that actively invites them copyedit or do another level task?
 * It’s hard to explain the rules of adding a link before they try the task, because they don't have context. How might we show them the task a little bit, before they read the rules?
 * Perhaps we could onboard the users in stages?  First they learn a few of the rules, then they do some links, then we teach them a few more pointers, then they do more links?
 * Should users have a cooling-off period after doing lots of suggestions really fast, where we wait for patrollers to catch up, so we can see if the user has been reverted?

Engineering
To follow along with engineering progress on the backend "add link" service, please see this page on Wikitech.