Wikimedia Apps/Team/Android/Communication/UsertestingJuly2021/ar

This page is a translated version of the page Wikimedia Apps/Team/Android/Communication/UsertestingJuly2021 and the translation is 90% complete.

المعلومات الأساسية

يعمل فريق أندرويد على تحسين أنظمة الاتصال في تطبيق أندرويد. ونحن ندعم حالياً جميع الإشعارات والتنبيهات في تطبيق أندرويد.

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

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

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

نريد أن نفهم قبل إجراء المزيد من التعديلات على الإشعارات وخدمة الرسائل في التطبيق، المواضع البديهية والميزات وسير العمل لمستخدمي التطبيق. تجمع صفحة المشروع معلوماتٍ أولية من المُستخدمين. نطلب من المشاركين في بحثنا التعليق على صفحة حوار المناقشة هذه بردودهم على البروتوكول أدناه أو مراسلتنا عبر البريد الإلكتروني على android-support@wikimedia.org.

الأسئلة البحثية

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

البروتوكول

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

البديل أ👇

البديل أ = جرس الإشعارات في شريط التطبيق (هذه هي توصية التصميم الحالية)

الإيجابيات:

يمكن تطبيق هذا الوضع على للتطبيق بأكمله
التناسق مع المنصات الأخرى (سطح المكتب والجوال)

السلبيات:

تصبح خانة البحث أصغر
قد تصبح علامات التبويب والإشعارات مضلِّلة

البديل ب 👇

البديل ب = إضافة عنصر قائمة الإشعارات إلى قائمة التجاوز

الإيجابيات:

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

السلبيات:

تكون الإشعارات مخفاة خلف أيقونة "المزيد" غير الواضح (مشكلات مشابهة مثل أيقونة تنقل الهمبرجر)

البديل ج 👇

البديل C = تنقل ثابت في التطبيق (وإزالة شريط الأدوات الموجود في المقالة)

الإيجابيات:

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

السلبيات:

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

2)صنع الأيقونات: ما هي المعلومات التي تتوقعها عند النقر على كل من الرموز الثلاثة أدناه؟ يرجى توضيح أفكارك.

البديل أ: أيقونة الجرس 🔔
البديل ب: أيقونة البريد الوارد 📥
البديل ج: أيقونة الشخص 👤

نفكر في التمييز بين أنواع الإشعارات لخدمة سياق الجوال بصورة أفضل. ماهي الإشعارات التي تحظي بالأولوية لديك؟

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

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

6)ما هي الخصائص الوظيفية الجديدة التي تفضلها لعرض الإشعارات؟ يرجى ترتيب الأفكار التالية حسب الأولوية:

أ) طريقة سريعة لتصفية الإشعارات وفقاً للغة الويكي (مثلاً: ويكيبيديا السويدية أو ويكيبيديا الكورية)
ب) طريقة سريعة لتصفية الإشعارات حسب المشروع (مثل ويكيبيديا وكومنز وويكي داتا)
ج) طريقة سريعة لتصفية الإشعارات حسب النوع (مثلاً عرض الإشارات فقط)
د) تصنيف الإشعارات (مثلاً إذا تلقى شخص ما الكثير من "الشكر" لتعديل مقال، فهل يجب وضعه في مجموعة)
هـ) خاصية البحث عن كل من الإشعارات الجديدة والمؤرشفة
و) تفضيلات إشعارات أكثر كفاءةً، مثل التحديد الدقيق للإشعارات التي تتلقاها (انظر السؤال رقم 7 أدناه)
ز) إشعارات لقائمة المراقبة
ح) التمرير القابل للتخصيص لليسار أو لليمين (على سبيل المثال: Gmail ← الإعدادات ← الإعدادات العامة ← إجراءات تمرير البريد)
ط) سهولة الوصول إلى الإشعارات المؤرشفة

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

يرجى الاطلاع على الشاشة أدناه للتعرُّف على شكلها الحالي:

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

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

9) نخطط حالياً لإدراج واجهة للتفاعلات السريعة / الردود الافتراضية بعد النقر على حقل "الرد" المذكور أعلاه. سترى في الشاشة أدناه أحد الاختبارات التي تمثل مفهوم التفاعلات السريعة. نحن لا نخطط لاستخدام الرموز التعبيرية ولكننا نود بدلاً من ذلك الاستفادة من العبارات الشائعة، كالنماذج التي لدينا للترحيب بالوافدين الجدد بطرق مختلفة، أو كيفية اختيار المسئولين للأسباب الشائعة لحظر شخص ما. هل يمكنك ذكر بعض الردود أو العبارات الشائعة التي تستخدمها عند التفاعل مع المحررين الآخرين على الويكي؟

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

أ) نعم، أرغب في رؤية هذه الخاصية الوظيفية.

ب) لا، لا أحب هذه الخاصية الوظيفية.

ج) لا أكترث.

Results

We received feedback from an English Wikipedia editor, Arabic Wikipedia editor, and Indonesian Wikipedia editor.

1) Variant A is the winner The first question we wanted to understand which icon was better for discoverability. Our Arabic and English users chose A (Bell Icon top right) as their first choice, and our Indonesian user chose A as their second choice. B (top right overflow menu) was the first choice for the Indonesian user, the second for the English Wikipedia editor and the third choice for the Arabic user. C (Bottom navigation) was ranked second, and the last choice for our Indonesian and English Wikipedia user.

2) Bell Icon is the winner

All three users associate the bell icon for notifications. The inbox was understood as a link to messages. The person iconography was associated with a profile, user page or ping.

3) We are going ahead with our assumptions made in T288064, as the consistent notifications that were prioritized by respondents were: mentions, talk page messages, email from other users, edit reverts and user right changes.

4) All respondents were in favor of the idea of having mentions separately and that mentioned they would appreciate some sort of grouping within the 'All' tab

   The idea of separating the notification types on the Android app is a good one. The information is presented in an understandable and efficient way but the other notifications might be jumbled up under 'All'.
  Quotes from respondents:
That's an excellent idea. However, it would be nice to separate some of the notifications into several categories. The 'All' section is still confusing.
   I think separating notifications is a good idea, but having All might bury important notifications inside, like what's happening with FB, even with the iconography used. Mentions might be merged with emails to give more sense

Our thoughts:* Grouping could make it easy to miss notifications, so we will see how filtering addresses the organization challenge

5) Two users prefer mentions first and all secondarily. One user prefer all first. To reduce risk we will have 'All' first and review metrics around people clicking on mentions.

Answers:

   “I would prefer all notifications as the default tab. If I had to organize my notification home center, I would have tabs for each notification type and a button/text to 'view all notifications' which would remove/hide the tabs and just show all the notifications in a list.”
   “I suggest adding the 'Edits' section in the notification. This section contains notifications about edit reverts, page links, thanks, and translation. For the default tab, I prefer mentions because when admins give warnings, users can see them instantly.”
   “I'd like to see Mentions and emails merged under one name and then All. But in the All, I want to be able to distinguish easily the list of notifications, maybe use a slightly different color variation for the background + the icon.”

6) Filtering by type: Ranking (point scale from 1-9)

   D (22 points): Grouping of notifications (e.g. if someone received several “Thanks” for an article edit, should it be grouped) [Grouping by Mentions].
   C (21 points):** Filtering by type [action item for design]
   B (17 points):** Filter by project, task created: T288068
   E (14 points):** Search for new notifications: Yes. Search for archived notifications: No (as technically not ready / out of scope)
   H (13 points):** Customizable swipe left and right gestures~~ (No, since design feedback from experienced Android users advocated for one swipe gesture [Mark as read]
   A (12 points):** Filter by language, task created (T288068)
   F (11 points):** Better preferences, task created (T287477)
   G (11 points):** Notifications for Watchlist (Not now, as technically not ready / out of scope)
   I (11 points):** Easy access to archived notifications. New designs have been improved and it’s easy to access it

7) Page links was the only thing mentioned as missing, and it has been added in the designs (T287477) 8) One user said: More context is needed for edit reverts or article talk. Otherwise people are ok with the suggestion 9) "Thank you". "I'll fix that", "I agree", "Thanks for pointing that out" "Well done" "Very good point, it will be updated" (Task created: T288105) 10) People would like to see notification reminders (V2 option)

Research Questions

   When asking a user to check their notifications, in the app, where do they click?
   What flows and actions do users expect when they have push turned on vs. those that have it turned off?
   What are the expectations of what a user will see if they click a bell vs. an inbox and what are the tradeoffs for consolidation?
   Do users believe elements of the user talk page should be in the notification center?

=الشريحة المستهدفة للحصول على التغذية الراجعة

نرحب بآراء جميع محرري ويكيبيديا الحاليين والمحتملين.

غير أننا نهتم بشكل خاص بمعرفة كيف يمكن أن تؤثر أدواتنا على:

محرري ويكيبيديا الإنجليزية في الهند من ذوي الإعاقات البصرية
محرري ويكيبيديا الهندية
محرري ويكيبيديا العربية والفرنسية في المغرب ومصر وجمهورية الكونغو الديمقراطية ومالي
محرري ويكيبيديا الإنجليزية في نيجيريا
محرري ويكيبيديا الإندونيسية
محرري ويكيبيديا اليابانية من الإناث وغير محددي الجنس

اختيرت المجموعات المذكورة أعلاه وفقاً لبحث أجراه الفريق في وقت سابق من هذا العام حول كيفية توافق الجماهير الحالية ومجالات النمو المحتملة مع مخرجات استراتيجية مؤسسة ويكيميديا.