Wikimedia Apps/Team/Android/Communication/UsertestingJuly2021/fr

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

Contexte

L’équipe d’Android s’efforce d’améliorer les systèmes de communication dans l’application Android. À l’heure actuelle, nous prenons en charge toutes les notifications et alertes dans l’application Android.

Cependant, lorsque les utilisateurs sont dans l’application, il leur est difficile de trouver les notifications. Nous prévoyons de les rendre plus visibles.

Notre mise à jour de juillet 2021/septembre 2021 permettra de trouver plus facilement les notifications dans l'application et de les rendre plus visibles sur l'écran de verrouillage. D'ici décembre 2021, nous créerons une boîte de réception et une interface intuitives dans le centre de notifications en tenant compte des éléments du système Android.

De juillet 2021 à décembre 2021, nous nous concentrerons sur les utilisateurs connectés ayant apporté au moins une modification. Nous nous appuierons sur nos travaux préliminaires des mois précédents pour améliorer la prise de connaissance des alertes pour les utilisateurs déconnectés au début de l’année 2022. Nous prévoyons d'explorer les expériences d'intégration des outils de communication pour les utilisateurs déconnectés afin de les aider à les trouver. Cela viendra s’ajouter à d'autres renforcements positifs et flux d'intégration pour les utilisateurs connectés.

Avant d'apporter d'autres changements au traitement des notifications et messages dans l'application, nous voulons comprendre les placements, les fonctionnalités et les flux de travaux intuitifs pour nos utilisateurs. Cette page de projet rassemble les recherches initiales sur les utilisateurs. Nous demandons aux participants de nos recherches de commenter cette page de discussion avec leurs réponses au protocole ci-dessous ou de nous envoyer un e-mail à l’adresse suivante : android-support@wikimedia.org.

Questions de recherche

  • Lorsqu’on demande à un utilisateur de consulter ses notifications dans l’application, où clique-t-il ?
  • Découvrir si les différents points d’entrée présentés pour les notifications sont faciles à trouver
  • Quels flux et actions les utilisateurs ayant activé les notifications push attendent-ils par rapport à ceux qui les ont désactivées ?
  • Que s’attend à voir un utilisateur lorsqu’il clique sur une cloche plutôt que sur une boîte de réception et quels sont les inconvénients d’avoir un seul ensemble de notifications à la place?
  • Les utilisateurs pensent-ils que des éléments de la page de discussion de l’utilisateur devraient se trouver dans le centre de notifications?

Protocole

1) Découvrabilité : imaginez que vous ouvrez votre application Wikipédia pour consulter vos notifications. Quelle version de l’application vous indique le plus clairement la présence d’une nouvelle notification ? Veuillez décrire l’endroit où vous appuyez sur l’écran pour accéder à vos notifications. Veuillez classer les variantes ci-dessous en fonction de la facilité avec laquelle vous trouvez l’icône/bouton de notification.

Variante A 👇

Variante A = cloche de notification dans la barre d’application (il s’agit de la recommandation actuelle en matière de conception)

Avantages :

  • Le positionnement peut être appliqué à l’ensemble de l’application
  • Homogénéité avec les autres plateformes (bureau, mobile)

Inconvénients :

  • Le champ de recherche est plus petit
  • Les onglets et notifications peuvent prêter à confusion

Variante B 👇

Variante B = Ajout d’un élément de liste de notifications au menu de débordement

Avantages :

  • Il s’agit simplement d’un autre élément de menu dans le menu de débordement
  • Possibilité de développer avec des liens (par exemple, la liste de suivi, le profil d’utilisateur, l’historique ou les notifications)

Inconvénients :

  • Les notifications sont cachées derrière une icône « Plus » qui manque de clarté (mêmes problèmes que pour un menu à tiroir)

Variante C 👇

Variante C = une navigation homogène dans l’application (et suppression de la barre d’outils dans l’article)

Avantages :

  • Une navigation homogène dans l’application, les utilisateurs savent toujours trouver ce qu’ils cherchent
  • Le menu « Plus » (dans le coin supérieur droit) n’afficherait que les éléments liés à ce que vous regardez (par exemple, le lien de partage, ajouter à la liste de suivi, voir la page de discussion, voir l’historique des modifications pour un article)

Inconvénients :

  • Un menu « Plus » gonflé dans la vue de l’article (en haut à droite), similaire à Chrome sur Android. Est-ce que tout cacher est une bonne architecture de l’information ?
  • Nous hésitons à poursuivre cette approche, car nous avons apporté de grosses améliorations à la vue des articles d’après les tests d’utilisabilité

2) Iconographie : quelles informations attendez-vous en appuyant sur chacune des trois icônes ci-dessous ? Veuillez décrire vos pensées.


3) Pour mieux répondre à un contexte mobile, nous envisageons de faire la distinction entre les types de notification. D’après vous, quelles notifications sont prioritaires ?


4) L'écran ci-dessous permet de visualiser l'idée de séparation des types de notifications. « Tout » répertorierait toutes les notifications au même endroit, comme aujourd'hui. « Mentions » répertorierait les notifications liées aux pages de discussion de l'utilisateur et aux autres utilisateurs qui mentionnent votre nom d'utilisateur dans les pages de discussion. Que pensez-vous de ce concept de séparation des notifications dans l'application Wikipédia sur Android ? Les informations sont-elles présentées d'une manière qui vous semble efficace ou compréhensible ?

Maquette des mentions séparées des autres notifications

5) En regardant l’illustration ci-dessus, préférez-vous voir « Toutes » vos notifications ou « Mentions » comme onglet par défaut ? Avez-vous une autre idée de séparation du centre de notifications ?


6) Quelle nouvelle fonctionnalité pour la vue des notifications aimeriez-vous ? Veuillez classer les idées suivantes par ordre de priorité :

  • A) Un moyen rapide de filtrer les notifications par langue du wiki (par exemple, Wikipédia en suédois, Wikipédia en coréen)
  • B) Un moyen rapide de filtrer les notifications par projet (par exemple, Wikipédia, Commons, Wikidata)
  • C) Un moyen rapide de filtrer les notifications par type (par exemple, n’afficher que les mentions)
  • D) Regroupement des notifications (par exemple, si quelqu’un a reçu plusieurs « Merci » pour une modification d’article, faut-il les regrouper ?)
  • E) Fonction de recherche pour les notifications nouvelles et archivées
  • F) Meilleures préférences de notification, par exemple en affinant les notifications que vous recevez (voir la question n° 7 ci-dessous)
  • G) Notifications pour la liste de suivi
  • H) Actions de balayage à gauche/droite personnalisables (exemple : Gmail → Paramètres → Paramètres généraux → Actions de balayage dans le courrier)
  • I) Accès facile aux notifications archivées

7) La version actuelle de l’application permet d’activer/désactiver les notifications suivantes : système, jalon, merci, revenir à une version précédente, page de discussion, connexion et mentions. D’après vous, manque-t-il des préférences de notification dans l’application ?

Veuillez consulter l’écran ci-dessous pour voir son apparence actuelle :

Vue actuelle de l’écran des préférences de notification

8) Nous sommes en train d’optimiser les flux lorsque les utilisateurs reçoivent une notification. L’idée est de mener les gens facilement au bon endroit. Nous prévoyons également de fournir un moyen facile de répondre aux messages juste après la réception d’une notification. Dans les images ci-dessous, vous verrez différents exemples de notifications avec une constante : un champ de réponse pour contacter directement l’utilisateur qui a envoyé un message sur une page de discussion ou qui a annulé une modification. Que pensez-vous de cette façon de répondre/réagir après la réception d’une notification ? Avez-vous l’impression que les informations présentées sont suffisamment utiles pour offrir une réponse ou auriez-vous besoin de plus d’informations ?


9) Nous prévoyons actuellement d'intégrer une interface pour les réactions rapides/réponses par défaut après avoir appuyé sur le champ « Répondre » susmentionné. Dans l'écran ci-dessous, vous verrez l'une des explorations représentant le concept de réactions rapides. Nous ne prévoyons pas d'utiliser des émoticônes, nous aimerions tirer parti des phrases courantes de la même façon que nous avons différents modèles pour accueillir les nouveaux arrivants ou que les administrateurs peuvent choisir des raisons courantes pour bloquer quelqu'un. Quelles sont les réponses ou phrases que vous utilisez couramment lorsque vous interagissez avec d'autres éditeurs sur Wiki ?

Un exemple de la fonction de réaction rapide. Ce n’est pas l’aspect que nous verrions.

10) Nous nous efforçons actuellement de faire en sorte que les notifications importantes de Wikipédia soient vues à l'intérieur et à l'extérieur de l'application Wikipédia. Nous étudions la possibilité d'envoyer des rappels de notification (par exemple, recevoir des rappels de notification hebdomadaires à propos d'une annulation jusqu'à ce que la notification soit marquée comme lue). Les rappels de notification seront modifiables dans les paramètres d'utilisateur. Que pensez-vous de cette fonction éventuelle ?

A) Oui, j’aimerais beaucoup voir cette fonction.

B) Non, je n’aime pas cette fonction.

C) Cela m’indiffère.

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?

Principale cible des commentaires

Les commentaires de tous les éditeurs actuels et potentiels de Wikipédia sont les bienvenus.

Cependant, nous sommes particulièrement intéressés de connaître l’influence potentielle de nos outils sur :

  • Les éditeurs de Wikipédia en anglais pour l’Inde avec une déficience visuelle
  • Les éditeurs de Wikipédia en hindi
  • Les éditeurs de Wikipédia en arabe et en français pour le Maroc, l’Égypte, la République démocratique du Congo et le Mali
  • Les éditeurs de Wikipédia en anglais pour le Nigéria
  • Les éditeurs de Wikipédia en indonésien
  • Les éditeurs femmes et non binaires de Wikipédia en japonais

Les groupes ci-dessus ont été sélectionnés en fonction des recherches menées par l’équipe au début de l’année sur la façon dont les publics actuels et les zones de croissance potentielles s’alignent sur la stratégie de produit de WMF.