Wikimedia Apps/Team/Android/Communication/UsertestingJuly2021/hi
बैकग्राउंड
Android टीम, Android ऐप में कम्युनिकेशन प्रणालियों को बेहतर बनाने के लिए काम कर रही है। हम वर्तमान में Android ऐप में सभी नोटिफिकेशन और अलर्ट का समर्थन करते हैं।
हालाँकि, जब उपयोगकर्ता ऐप में होते हैं तो नोटिफिकेशन खोजना आसान नहीं होता है। हम उन्हें देखने और खोजने की प्रक्रिया को और आसान बनाना चाहते हैं।
हमारा जुलाई 2021-सितंबर 2021 अपडेट, ऐप में नोटिफिकेशन खोजना और लॉक स्क्रीन पर उन्हें सरलता से देखने को आसान बना देगा। दिसंबर 2021 तक, हम Android सिस्टम एलिमेंट की प्रणालियों को ध्यान में रखते हुए नोटिफिकेशन होम सेंटर में एक सहज और सरल इनबॉक्स और इंटरफेस बनाएंगे।
जुलाई 2021 से दिसंबर 2021 तक हम उन लॉग-इन उपयोगकर्ताओं पर ध्यान केंद्रित करेंगे जिन्होंने कम से कम एक एडिट किया होगा। हम 2022 की शुरुआत में लॉग-आउट उपयोगकर्ताओं के लिए अलर्ट देखने को सरल बनाने के लिए पहले के महीनों में किए गए अपने शुरू के काम को आगे बढ़ाएंगे। हम लॉग आउट किए गए उपयोगकर्ताओं के लिए कम्युनिकेशन टूल में ऑनबोर्डिंग के समय जानकारी डालने के तरीकों को खोज रहे हैं - जिससे उपयोगकर्ताओं को नोटिफिकेशन देखने में आसानी हो। यह लॉग-इन किए गए उपयोगकर्ताओं के लिए अन्य पॉजिटिव रिइंफोर्समेंट और ऑनबोर्डिंग वर्कफ़्लो के अलावा होगा।
ऐप में नोटिफिकेशन और मैसेजिंग में और बदलाव करने से पहले, हम ऐप में अपने उपयोगकर्ताओं के लिए सहज प्लेसमेंट, फीचर्स और वर्कफ्लो को समझना चाहते हैं। यह प्रोजेक्ट पेज उपयोगकर्ता के बारे में शुरुआती रिसर्च जमा करता है। हमारी रिसर्च में भाग लेने वाले पार्टिसिपेंट से हम इस डिस्कशन टॉक पेज पर नीचे दिए गए प्रोटोकॉल पर कमेंट करने या अपने विचारों को हमें android-support@wikimedia.org पर ईमेल करने के लिए कहते हैं।
रिसर्च के प्रश्न
- जब किसी उपयोगकर्ता को ऐप में अपने नोटिफिकेशन देखने के लिए कहते हैं तो वे कहाँ क्लिक करते हैं?
- इस बारे में पता करें कि नोटिफिकेशन दिखाने के लिए दी गई जगह कितनी आसानी से खोजी जा सकती हैं (उन्हें ढूंढना कितना आसान है)
- पुश नोटिफिकेशन को बंद करने की तुलना में चालू करने पर उपयोगकर्ता किस फ्लो और चीजों की आशा करते हैं?
- इनबॉक्स की तुलना में घंटी पर क्लिक करने पर उपयोगकर्ता क्या देखने की आशा करते हैं और इसके बजाय नोटिफिकेशन का सिर्फ एक सेट होने की क्या खामियाँ हैं?
- क्या उपयोगकर्ताओं को लगता कि यूजर टॉक के कुछ हिस्सों को नोटिफिकेशन सेंटर में होना चाहिए?
प्रोटोकॉल
1) खोजे जाने की योग्यता: कल्पना कीजिए कि आपने अपने नोटिफिकेशन देखने के लिए अपना विकिपीडिया ऐप खोला है। ऐप का कौन सा संस्करण आपको यह अच्छे से दिखाता है कि आपके पास नये नोटिफिकेशन हैं? कृपया बताएं कि आप अपने नोटिफिकेशन देखने के लिए स्क्रीन पर कहाँ टैप करेंगे। नोटिफिकेशन आइकन/बटन को ढूंढने की सहजता के आधार पर, कृपया नीचे दिए गए वेरिएंट को रैंक करें।
वेरिएंट A 👇
वेरिएंट A = एप्लिकेशन बार में नोटिफिकेशन की घंटी (यह वर्तमान डिजाइन रिकमेंडेशन है)
फायदे:
- इसमें पूरे ऐप के लिए पोजिशनिंग लागू की जा सकती है
- अन्य प्लेटफार्मों (डेस्कटॉप, मोबाइल) से मेलजोल
नुकसान:
- सर्च का फील्ड छोटा हो जाता है
- टैब्स और नोटिफिकेशन गुमराह कर सकते हैं
वेरिएंट B 👇
वेरिएंट B = ओवरफ्लो मेनू में नोटिफिकेशन आइटम जोड़ा गया है
फायदे:
- यह ओवरफ्लो मेनू में एक और आइटम है
- लिंक के साथ इसका विस्तार किया जा सकता है, जैसे वॉचलिस्ट, उपयोगकर्ता प्रोफ़ाइल, इतिहास या नोटिफिकेशन
नुकसान:
- नोटिफिकेशन एक अस्पष्ट "अधिक" आइकन के पीछे छिप जाते हैं (हैमबर्गर नेविगेशन आइकन के जैसी परेशानियाँ)
वेरिएंट C 👇
वेरिएंट C = एक कंसिस्टेंट ऐप नेविगेशन (और आर्टिकल में टूलबार को हटना)
फायदे:
- पूरे ऐप में एक कंसिस्टेंट नेविगेशन, उपयोगकर्ताओं को हमेशा पता होता है कि चीजों को कहाँ खोजना है
- "अधिक" मेनू (ऊपर दाईं ओर) आप जिस चीज को देख रहे हैं केवल उससे संबंधित आइटम दिखाएगा (जैसे शेयर लिंक, वॉचलिस्ट में जोड़ें, टॉक पेज देखें, लेख के लिए एडिट इतिहास देखें)
नुकसान:
- आर्टिकल व्यू में एक अलग दिखने वाला "अधिक" मेनू (ऊपर दाईं ओर), Android पर Chrome के जैसा - क्या सब कुछ छिपा देना अच्छा इनफॉरमेशन आर्किटेक्चर है?
- इस दृष्टिकोण को अपनाने में हमें संकोच है क्योंकि हमने यूजेबिलिटी के परीक्षणों के आधार पर आर्टिकल व्यू में बड़े सुधार किए हैं
2) आइकनोग्राफी: नीचे दिए गए तीन आइकनों में से हर एक पर टैप करते समय आप किस जानकारी की अपेक्षा करेंगे? कृपया अपने विचार बताएं।
-
वेरिएंट A: बेल आइकनोग्राफी 🔔 -
वेरिएंट B: इनबॉक्स आइकनोग्राफी 📥 -
वेरिएंट C: व्यक्ति आइकनोग्राफी 👤
.png){kind=icon}
.png){kind=icon}
.png){kind=icon}
3) मोबाइल उपयोगकर्ताओं को बेहतर सर्विस देने के लिए हम इन दोनों के बीच अंतर करने का सोच रहे हैं notification types। आप किन नोटिफिकेशन को सबसे जरूरी मानेंगे?
4) नीचे दी गई स्क्रीन, नोटिफिकेशन के प्रकारों को अलग करने के विचार को दर्शाती है। "ऑल" मौजूदा स्थिति की तरह सभी नोटिफिकेशन को एक ही स्थान पर दिखाएगा। ‘मेंशन’, यूजर टॉक पेजों से संबंधित नोटिफिकेशन और अन्य यूजर्स द्वारा टॉक पेजों पर आपके यूजर नेम को टैग करने वाले नोटिफिकेशन दिखाएगा। Android ऐप पर Wikipedia में नोटिफिकेशन को इस तरह से अलग करने की इस कांसेप्ट के बारे में आपके क्या विचार हैं? क्या जानकारी को इस तरह से प्रस्तुत किया गया है जो आपको सहज और अच्छे से समझने लायक लगती है?
5) ऊपर दिए गए उदाहरण को देखते हुए, क्या आप अपने 'ऑल' नोटिफिकेशन को या 'मेंशन' को डिफ़ॉल्ट टैब के रूप में देखना पसंद करेंगे? इसके अलावा, क्या कोई और तरीका है जिससे आप अपने नोटिफिकेशन होम सेंटर को अलग कर सकते हैं?
6) नोटिफिकेशन व्यू के लिए आप किस नई कार्यक्षमता की सराहना करेंगे? कृपया निम्नलिखित विचारों को प्राथमिकता के आधार पर रैंक करें:
- A) विकी की भाषा द्वारा नोटिफिकेशन को फ़िल्टर करने का एक सहज तरीका (जैसे स्वीडिश Wikipedia, कोरियाई Wikipedia)
- B) प्रोजेक्ट द्वारा नोटिफिकेशन को फ़िल्टर करने का एक सहज तरीका (जैसे Wikipedia, Commons, Wikidata)
- C) नोटिफिकेशन को प्रकार के आधार पर फ़िल्टर करने का एक सहज तरीका (उदाहरण के लिए केवल ‘मेंशन’ दिखाएं)
- D) नोटिफिकेशन को ग्रुप करना (उदाहरण के लिए यदि किसी को आर्टिकल संपादन के लिए कई "थैंक्स" प्राप्त हुए हैं तो क्या इन्हें ग्रुप किया जाना चाहिए)
- E) नये और आर्काइव किए गए नोटिफिकेशन, दोनों के लिए खोज कार्यक्षमता
- F) बेहतर नोटिफिकेशन प्रीफरेंस, उदाहरण के लिए इस चीज में सुधार करना की आपको कौन से नोटिफिकेशन मिलते हैं, (नीचे प्रश्न #7 देखें)
- G) वॉचलिस्ट के लिए नोटिफिकेशन
- H) कस्टमाइज किए जाने वाले एक्शन जैसे कि बाएं स्वाइप करें / दाएं स्वाइप करें (उदाहरण: Gmail → सेटिंग्स → सामान्य सेटिंग्स → Mail स्वाइप एक्शन)
- I) आर्काइव किए गए नोटिफिकेशन तक आसान पहुँच
7) ऐप का वर्तमान संस्करण निम्नलिखित नोटिफिकेशन को सक्षम/अक्षम करने का सुझाव देता है: सिस्टम, माइलस्टोन, धन्यवाद, रिवर्ट, टॉक पेज, लॉगिन और मेंशन। क्या नोटिफिकेशन के और कोई प्रीफरेंस हैं जो आपको लगता है कि वर्तमान में ऐप में नहीं हैं?
यह देखने के लिए कि आज यह कैसा दिखता है, कृपया नीचे दी गई स्क्रीन देखें:
8) वर्तमान में हम उपयोगकर्ता के नोटिफिकेशन प्राप्त करने पर ऐप में फ्लो को ऑप्टिमाइज कर रहे हैं। विचार यह है कि लोगों को बिना भटकाए सही जगह पर ले जाया जाए। हम नोटिफिकेशन प्राप्त करने के तुरंत बाद मैसेज का जवाब देने का एक आसान तरीका प्रदान करने की भी योजना बना रहे हैं। नीचे दी गई छवियों में, आपको एक स्थिर चीज के साथ नोटिफिकेशन के अलग उदाहरण दिखाई देंगे: एक उत्तर फ़ील्ड, सीधे उस उपयोगकर्ता से संपर्क करने के लिए जिसने किसी टॉक पेज पर संदेश भेजा है या किसी संपादन को वापस किया है। नोटिफिकेशन प्राप्त करने के बाद उत्तर/प्रतिक्रिया देने के इस तरीके के बारे में आपके क्या विचार हैं? क्या आपको ऐसा लगता है कि प्रस्तुत की गई जानकारी उत्तर देने के लिए पर्याप्त होगी या आप 'अधिक जानकारी की आवश्यकता है' का चयन करेंगे?
-
एक उपयोगकर्ता ने आपके या किसी अन्य उपयोगकर्ता के टॉक पेज पर एक मैसेज छोड़ा है। उत्तर देने का फील्ड आपको आसानी से नोटिफिकेशन को टैप करके उसका उत्तर देने का मौका देता है। -
नीचे एक उत्तर फ़ील्ड सुनिश्चित करता है कि आप वापसी के संबंध में प्रश्न पूछ सकते हैं। -
नोटिफिकेशन को टैप करने से उपयोगकर्ता तत्काल उत्तर विकल्प के साथ आर्टिकल के बारे में बात कर सकते हैं।
9) हम वर्तमान में उपरोक्त "रिप्लाई" फ़ील्ड को टैप करने के बाद सहज प्रतिक्रियाओं / डिफ़ॉल्ट उत्तरों के लिए एक इंटरफ़ेस शामिल करने पर विचार कर रहे हैं। नीचे दी गई स्क्रीन में, आप सहज प्रतिक्रियाओं की कॉन्सेप्ट को दर्शाने के एक तरीके को देखेंगे। हम इमोजी का उपयोग नहीं करना चाहते हैं बल्कि इसके बजाय सामान्य वाक्यांशों का लाभ उठाना चाहते हैं। जैसे कि हमारे पास विभिन्न तरीकों से नए लोगों का स्वागत करने के लिए टेम्प्लेट हैं या व्यवस्थापक किसी को ब्लॉक करने के लिए सामान्य कारण कैसे चुन सकते हैं। विकी पर अन्य संपादकों के साथ बातचीत करते समय आपके द्वारा उपयोग किए जाने वाले कुछ सामान्य उत्तर या वाक्यांश क्या हैं?
10) हम वर्तमान में यह सुनिश्चित करने के लिए काम कर रहे हैं कि Wikipedia ऐप के अंदर और बाहर महत्वपूर्ण Wikipedia नोटिफिकेशन दिखाई दें। हम नोटिफिकेशन रिमाइंडर के बारे में विचार कर रहे हैं (उदाहरण के लिए नोटिफिकेशन को पढ़ने के रूप में चिह्नित किए जाने तक उत्तर भेजने के बारे में साप्ताहिक नोटिफिकेशन रिमाइंडर प्राप्त करें)। नोटिफिकेशन रिमाइंडर उपयोगकर्ता सेटिंग्स के माध्यम से बदले जा सकेंगे। कृपया इस प्रस्तावित कार्यक्षमता के बारे में अपने विचार चुनें।
A) हाँ, मुझे यह कार्यक्षमता अच्छी लगेगी।
B) नहीं, मुझे यह कार्यक्षमता पसंद नहीं है।
C) मुझे कोई फर्क नहीं पड़ता।
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?
प्राथमिक फ़ीडबैक ऑडियंस
हम सभी मौजूदा और संभावित Wikipedia संपादकों के फ़ीडबैक का स्वागत करते हैं।
इसके अलावा, हम विशेष रूप से यह जानने में रुचि रखते हैं कि हमारे टूल संभावित रूप से इन्हें कैसे प्रभावित करते हैं:
- भारत में अंग्रेजी Wikipedia संपादक जिन्हें कम दिखाई देता है
- हिंदी Wikipedia संपादक
- मोरक्को, मिस्र, DR कांगो और माली में अरबी और फ्रेंच Wikipedia संपादक
- नाइजीरिया में अंग्रेजी Wikipedia संपादक
- इंडोनेशियाई Wikipedia संपादक
- महिला और नॉन-बाइनरी जापानी Wikipedia संपादक
इस वर्ष की शुरुआत में टीम द्वारा की गई रिसर्च के आधार पर इन समूहों को चुना गया है। रिसर्च का विषय यह तय करना था कि WMF उत्पाद रणनीति के साथ वर्तमान दर्शक और संभावित विकास क्षेत्र कैसे मेल खाते हैं।