Reading/Web/Desktop Improvements/fr

Notre interface pour ordinateurs de bureau a évolué dans le temps. Cependant, depuis l’introduction de l'habillage Vector (le design par défaut du site), la plupart de ces changements ont été conduits par des bénévoles et sont seulement disponibles sous forme de prototypes, gadgets, scripts utilisateur et habillages conçus par des bénévoles. Nous pensons qu’il est temps de prendre certaines de ces idées pour qu’ils deviennent accessibles par défaut. Pendant les deux prochaines années, l’équipe Web des lecteurs va rechercher et développer des améliorations de l’expérience sur ordinateur de bureau à partir d’études et des outils existants. Nos objectifs sont de rendre les wikis Wikimedia plus accueillants pour les nouveaux lecteurs et contributeurs, et plus faciles et rapide à utiliser pour tous (à la fois les contributeurs nouveaux et les plus anciens).

Ce projet est au stade des discussions. Il n’y a aucun plan de réalisation. Nous avons besoin de votre collaboration et de retours réflexifs sur les aspects essentiels du problème, ainis que vos idées sur la conception initiale plus bas.

Comment vous pouvez aider
Vos commentaires: veuillez prendre le temps de lire ces détails et ces sous-pages, et de partager vos commentaires sur la page de discussion en ce qui concerne les idées et les propositions que nous avons collectés jusqu'à présent - Comment pourraient-elles être ensuite améliorées ? Quelles considérations importantes ne sont actuellement pas documentées ?

Recherche et idées : Modifiez la section « Phase 1 : Idées de conception » ci-dessous, pour ajouter de nouvelles idées, des notes, des liens vers des discussions passées, des liens vers des gadgets/scripts existants, des liens vers de bons patrons de conception à considérer, etc.

Test individuel : Une fois le développement commencé, nous rendrons le travail en cours disponible directement via une nouvelle option d'habillage dans les préférences. Vous pourrez individuellement activer et tester les changements.

Wikis complets : Nous sommes également à la recherche de wikis qui seraient intéressés pour aider dans des tests globaux, comme changer localement l’interface par défaut pour les utilisateurs connectés. Si vous pensez que votre communauté pourrait être intéressée, n’hésitez pas à nous poser toutes vos questions, puis débutez une discussion localement, et une fois qu’un consensus local est établi, ajoutez un lien vers cette discussion sur la page de discussion.

Les commentaires et idées plus longs sont les bienvenus sur la page de discussions, dans n’importe quelle langue.

May 2020: First deployment - officewiki and testwiki
This Monday we deployed the first visual change of the improved version of the desktop skin on our first production wikis - Officewiki (used internally by the WMF) and Testwiki (for general testing purposes). On these wikis, you will notice a reconfiguration of the project logo which is the first portion of our improved header. You can also turn the updated skin version on and off from the sidebar and your user preferences. In the next couple of weeks, we will also be deploying a collapsible sidebar for these wikis, followed by a deployment of these changes to our full set of test wikis.

We have also introduced a query string parameter using which you can see the state of the Vector skin on any wiki by adding the parameter ?useskinversion=2 to the url. Example: Paris on French Wikipedia

Subscribe to our Newsletter and check the previous updates.

Constats problématiques

 * 1) Les wikis Wikimedia ne sont pas accueillants
 * Les sites des wikis Wikimedia pour le bureau ne constituent pas une expérience accueillante ou familière pour les nouveaux lecteurs. Ils ne correspondent pas aux attentes créées par le web moderne et nos autres plateformes (les applications Android et iOS ainsi que le site web mobile). Il se sent désorienté et déconnecté à cause de la navigation organisée au hasard et des liens d’interface. De ce fait, les lecteurs et les rédacteurs ont moins confiance dans les wikis de Wikimedia, et ont moins de chances d’explorer les wikis de Wikimedia et finissent par utiliser nos sites moins qu’ils ne le feraient autrement (c’est-à-dire une diminution de la rétention).
 * 1) Les wikis Wikimedia ne sont pas faciles à utiliser
 * Les lecteurs (en particulier les nouveaux lecteurs) ne sont pas en mesure d’exécuter intuitivement des fonctions de base telles que le changement de langue, la recherche de contenu ou le réglage des paramètres de lecture. De plus, il y a beaucoup d'éléments qui détournent de l'attention du contenu qui les intéresse. Les nouveaux contributeurs sont confrontés à un obstacle similaire; une interface peu accueillante ou intuitive et encombrée. Il leur est difficile d’accomplir les tâches de base nécessaires à l’apport de contributions, telles que la création d’un compte, l’ouverture de l’éditeur ou l’apprentissage de l’utilisation de pages spéciales à des fins de modération (par exemple, des pages d’historique pour détecter et corriger le vandalisme). Tous les utilisateurs peuvent avoir des problèmes avec les sites qui ne sont pas correctement réactifs, ce qui entraîne des problèmes comme un contenu très large ou un contenu très étroit (en fonction de la taille de l'écran et de la fenêtre). En maintenant le statu quo, nous empêchons les personnes désireuses de contribuer de pouvoir le faire (biais d'expérience).
 * 1) Il n’est pas facile de comprendre le modèle des wikis Wikimedia
 * Actuellement, un très faible pourcentage des lecteurs comprennent comment les wikis Wikimedia fonctionnent. Notre interface ne souligne pas les mécanismes internes du site d’une manière intuitive. De nombreux lecteurs ne sont pas au courant que le contenu qu’ils sont en train de lire est écrit par des bénévoles et fréquemment mis à jour, ou qu’ils pourraient y contribuer aussi.

De plus, la variété d’expériences qui existent entre nos différents produits (interface pour ordinateur de bureau, applis et web mobile) rend difficile pour les lecteurs de connaitre les liens entre nos produits et de les associer avec le contenu lui-même. Cela crée un manque d’unité dans le concept des sites Wikimedia.

Résumé par public :

Objectifs
Voici les objectifs que nous visons :


 * rendre plus facile pour les lecteurs de se concentrer sur le contenu ;
 * améliorer l’accès aux actions quotidiennes (par exemple la recherche, le changement de langue, la modification) ;
 * mettre les choses à des endroits logiques et pratiques ;
 * augmenter la cohérence de l’interface avec les autres plateformes (web mobile et applis) ;
 * éliminer les encombrements ;
 * anticiper une croissance future.

Contraintes
Voici une liste de choses que nous voulons expressément garder en tête :


 * ne pas toucher au contenu – aucun travail ne sera effectué dans la mise en page des modèles ou du contenu des pages elles-mêmes ;
 * ne supprimer aucune fonctionnalité – les choses peuvent être déplacées, mais tous les éléments de navigation et autres fonctionnalités actuellement disponibles par défaut resteront ;
 * pas de changement drastique de la disposition — nous allons prendre une approche évolutive pour les changements et voulons que le site continue de rester familier aux lecteurs et contributeurs.

Calendrier
Voici le calendrier approximativement imaginé, susceptible d’évoluer en fonction de notre progression :


 * Phase 1 : mai – septembre 2019 : investigation et études pour déterminer où nous pouvons créer de la valeur et sur quoi se concentrer.
 * Phase 2 : juillet – novembre 2019 : développement des priorités, esquisses et prototypage des idées, début des discussions.
 * Phase 3 : octobre 2019 – janvier 2020 : test utilisateur en continu et perfectionnement du design.
 * Phases 4 et + : à déterminer.
 * Phase 4: January 2020 - May 2020: Prototype feedback and iteration. Building out first features - new header and collapsible sidebar
 * Phase 5: May 2020 - July 2020: Prototype, user test, and ship at least 4 features to test wikis
 * Phase 6+: July 2020 - TBD: Continuing with feature sequence

Mesures
Ci-dessous, une ébauche des mesures essentielles que nous souhaitons réaliser durant ce projet. Au fur et à mesure que nous définissons les changements que nous voulons réaliser avec plus de précision, nous reprendrons et étendrons cette liste.

Améliorer l’intérêt pour nos publics actuels, mesuré à travers :


 * les interactions :
 * augmenter les recherches par session de 5 % au cours du projet,
 * augmenter le changement de langue par projet de 5 % au cours du projet ;
 * l’affinité :
 * avoir des retours pour le site avec des sentiments plus positifs et chaleureux (à travers les enquêtes et tests des utilisateurs),
 * augmenter le sentiment de confiance et de crédibilité (mesuré à travers les enquêtes et les tests des utilisateurs).

Feature Sequence
This is a summarized overview of the features we are considering adding or iterating on throughout the course of the project. A more detailed list is available on a separate page - we encourage looking through that page for more information. As we go through with design, requirements gathering, and user testing for each feature, we will also publish a separate page per feature with more detail. These will be linked from the title of the feature.


 * 1) New Header
 * 2) Collapsible Sidebar
 * 3) Moving language links to the article title bar
 * 4) Sticky site and article headers
 * 5) User Menu
 * 6) Improved search
 * 7) Improved language switching
 * 8) Table of contents
 * 9) Article tools
 * 10) General aesthetic refinements

Processus de recherche et de conception
Remarque générale : notre processus n’est pas particulièrement strict. Il est librement basé sur les bonnes pratiques en matière de recherche et de conception, cependant il est aussi relativement récent et flexible, en ce sens que nous nous engageons dans des activités ad hoc et des explorations lorsqu’elles semblent appropriées. Alors que nous avons dessiné le processus de recherche et de conception en trois phases ci-dessous, en pratique les phases se recoupent. De plus, il ne semble pas y avoir pour le moment une façon évidente de distinguer les activités de recherche de celles de conception (elles sont interdépendantes), nous en discutons donc ensemble.

Phase 1. Investigation, étude, déterminer où nous pouvons créer de la valeur, où se concentrer (mai 2019 – septembre 2019)

 * Page principale : sous page « Recherche et création : phase 1 »

Nous avons commencé en considérant l’expérience par défaut sur les ordinateurs de bureau (donc avec Vector) en nous demandant : de quelle manière peut-on améliorer cela ? Quelles possibilités avons-nous de modifier l’interface pour améliorer l’expérience pour tous les lecteurs et contributeurs ? Comment la modifier pour permettre aux gens de faire plus facilement ce qu’ils veulent ? Comment peut-on créer un environnement de lecture plus agréable ? Bien sûr, pendant la réflexion autour de ces questions, nous avons gardé en tête les contraintes du projet. Parmi les activités d’étude et de conception que nous avons commencées afin d’approfondir ces questions, il y a eu :


 * comprendre l’histoire de notre interface pour ordinateur de bureau ;
 * lire des études de Wikipédia précédentes conduites par la Wikimedia Foundation ou par d’autres instituts d’étude ou des particuliers ;
 * discussions au sein de notre équipe pour développer une compréhension partagée du projet et susciter des idées
 * Winter, Timeless et autres refontes de Wikipedia ;
 * lectures à propos des refontes et mises à jour d’autres grands sites web (Reddit, Twitter, etc.) ;
 * réalisation d’un audit d’autres grands sites web pour tester et glaner des éléments structurels communs.

Le résultat de la phase 1 a été : une meilleure compréhension de l’interface pour les ordinateurs de bureau et une proposition de zones cibles à améliorer. Nous n’avions pas de critères stricts de définition d’une zone cible. D’une manière générale, il s’agissait d’une idée d’amélioration que nous pouvions faire, bien qu’à des niveaux variés de spécificités, tels que : une expérience de lecture plus sobre ou la facilité pour changer de langue. Les zones cibles proposées sont :


 * la création d’un environnement plus ciblé et « tranquille » pour la lecture, en consolidant voire en masquant des liens de navigation y compris :
 * la navigation principale de la barre latérale,
 * les outils pour les articles,
 * les outils de l’utilisateur ;
 * le changement de langue ;
 * la recherche ;
 * la navigation dans l’article / le sommaire.

Des idées supplémentaires, plus spécifiques à des fonctionnalités sont aussi venues : des préférences de lecture (par exemple le mode sombre), un bouton partager, un bouton Modifier plus large, ajouter un bouton Nouvel article (pour les wikis plus petits), rendre plus évident comment s’impliquer, des statistiques d’article, un résumé des activités.

Phase 2. Développement des zones cibles, dessin et prototypage des idées, début des discussions (juillet 2019 – novembre 2019)

 * Page principale : sous page « Étude et conception : phase 2 »

Les activités de recherche et les conversations de la phase 1 nous ont aidés à mieux comprendre le paysage dans lequel nous travaillions (à savoir, l’interface de bureau). Cela nous a également aidés à développer des domaines de concentration potentiels à approfondir (tout en restant ouverts aux nouvelles idées). Notre prochain objectif consistait à approfondir un peu plus les domaines d’intervention en faisant des croquis, des prototypes et, plus important encore, des conversations avec la communauté. Les activités de recherche et de conception comprenaient :


 * comprendre les travaux, recherches et expériences passées dans les domaines d’intervention respectifs
 * obtenir des données d'utilisation générales sur les domaines d'intervention respectifs
 * esquisser et prototyper les premières idées pour faciliter les conversations
 * formuler des hypothèses précoces
 * interviews d'utilisateurs et autres commentaires sur Wikimania
 * commentaires de la communauté via MediaWiki (bientôt disponible)
 * entretiens d'utilisateurs avec des nouveaux arrivants et des lecteurs occasionnels (bientôt disponible)
 * Test utilisateur sur usertesting.com (bientôt disponible)

Le résultat de la phase 2 comprendra : les réactions aux sketches concernant les améliorations spécifiques de l'interface dans les domaines de l'objectif fixé, une précision (par exemple plus argumentée et contenant des informations) sur la façon de choisir les améliorations utiles de continuer, une proposition sur l'odre à adopter pour l'implémentation des améliorations.

Phase 3. Suite des tests utilisateurs et affinage de l'architecture (octobre 2019 – janvier 2020)
La phase 3 consistera en un cycle de tests supplémentaires des idées spécifiques issues de la phase 2, puis l'affinage de nos conceptions en réponse à ce que nous apprenons. Certaines choses doivent potentiellement être testées en tant que bêta sur des wikis réels. Nous travaillerons à identifier ces éléments et à déterminer comment nous prévoyons de les tester en version bêta (c.-à-d. Quelles données nous allons surveiller et quelles décisions nous allons prendre en fonction du comportement que nous observons).

Le résultat de la phase 3 comprendra : l'architecture presque terminée (bien que nous laissons habituellement de la place pour les itérations supplémentaires durant l'implémentation) et un plan de ce que nous voulons apprendre lorsque nous porterons des éléments en bêta, ainsi que les décisions/modifications que nous devrons adopter, sur la base de ces informations.

Phase 1 : Idées de conception
Quelques unes des nombreuses idées qui ont été suggérées sont ci-dessous. N’hésitez pas à ajouter des idées importantes et des liens dont vous avez connaissance :


 * À L’ATTENTION des contributeurs : modifiez bien la version en anglais pour ajouter des idées et liens, ou ajoutez un commentaire sur la page de discussion. Ne vous souciez pas des balsies « tvar » si vous ne les comprenez pas, nous les ajouterons après-coup.

Focusing on the content, distinguish content from user-interface
Se concentrer sur le contenu, distinguer le contenu de l’interface utilisateur
 * Sections de la barre latérale escamotables
 * Exemples : Wikipedia en hébreu, ...
 * Étude : Étude du projet opérabilité sur le masquage des liens de langues,Maquettes du projet opérabilité sur les sections escamotables dans la barre latérale
 * Barre latérale escamotable
 * Exemples : Habillage large (script d’enwiki), Cacher la barre latérale de Vector (script d’enwiki), barre latérale de l’habillage Timeless (disposition adaptative)…
 * Barre latérale flotante
 * Exemples : FloatSide (script d’enwiki)…
 * Tabs in sidebar to organise all the tools and navigation: 1) TOC, 2) Site navigation, 3) Tools (for editing, page info, gadgets), 4) Bookmarks (feature request)
 * The tab icons serve also to collapse/reveal the sidebar.
 * TOC in sidebar: fixed to the screen, separately scrolled.
 * Example: WikiWand
 * Pin-able infobox: show a pin icon in top-right corner of the infobox. When pushed, pin the infobox on the right side of the screen in a column that stays on-screen and scrolls on its own, similar to the sidebar on the left.
 * Collapsible article sections: see at the bottom of the WikiWand page + add a short scrolling effect.
 * Responsive width
 * Responsive content (enwiki/mw gadget), 3 column CSS (personal css),

Easier access to everyday actions
Un accès plus facile aux actions quotidiennes
 * En-tête collant avec la recherche, la table des matières, les liens d'édition
 * Exemples: FloatHead (script enwiki), FloatHead (un autre script enwiki), Floater (script enwiki), Winter (prototype historique), Timeless (habillage alternatif), ...
 * Recherche: wiki ergonomique
 * Changement de langue plus visible (déplacer le sélecteur de langue en haut de la page)
 * Exemples: habillage Timeless à 1325px ou plus et à 1085px ou plus fin, ...
 * Entêtes de tableau collants
 * Exemples: Gadget-StickyTableHeaders (gadget enwiki)
 * Retourner tout en haut de la page
 * Exemples : Bouton Remonter en haut (script de enwiki)
 * Paragraph (¶) symbols on headings: visible only when hovering, next to the edit icon, to easily copy links to sections.

Putting things in logical and useful places
Mettre les choses dans des endroits logiques et utiles
 * Menu utilisateur consolidé (par exemple, réduire des éléments tels que « Déconnexion », « Préférences » et « Bêta » dans un menu déroulant)
 * Exemples : Barre personnelle compacte
 * Préférences pour les utilisateurs déconnectés
 * Exemples : Paramètres d'accessibilité/préférences (T91201), ...
 * Déplacement des actions d'un article de la barre latérale à l'intérieur de l'article
 * Exemples : Winter, habillage Timeless à 1085px ou plus mince, ...
 * Naviguez facilement dans les articles - chargez le contenu de la page à l'aide de JavaScript en arrière plan sans charger la page entière
 * Exemples : RevisionSlider, une extension permettant de naviguer facilement dans les diffs ; Wikipedia hebdo.