Open Agile

Pourquoi les logiciels libres ont une convivialité médiocre, et comment faire pour les améliorer. (première partie)

Les applications Open Source et les systèmes d’exploitation sont plus utilisables aujourd’hui qu’ils ne l’étaient il y a encore quelque temps. Mais cela est dû en grande partie à la lenteur des innovations, et du faible niveau de compétition entre les projets et les éditeurs. Les principaux problèmes liés à la méthodologie de conception ne sont toujours pas résolus. Nombre de ces problèmes proviennent des projets logiciels qui sont basés sur le volontariat, pas sur le logiciel libre en particulier.  Les programmes propriétaires réalisés par des « amateurs » sont souvent difficiles à utiliser pour bon nombre des mêmes raisons.  Mais la façon la plus facile d’obtenir des volontaires pour contribuer à un projet de développement est de le rendre open source. Des milliers de personnes travaillent dans le développement de logiciel libre, la plupart de ses développeurs sont bénévoles. C’est donc dans le Logiciel Libre qui emploie des bénévoles pour la réalisation de logiciel que l’on rencontre le plus souvent des problèmes d’utilisation, de conception, de documentation, etc.

Cela nous donne un indice à propos de nos deux premiers problèmes.  1. La faiblesse des incitations à la facilité d’utilisation des applications. Les éditeurs de logiciels propriétaires en général font de l’argent en produisant des logiciels que les gens veulent utiliser. Cela donne une forte incitation pour le rendre plus utilisable (cela ne fonctionne pas toujours : par exemple, Microsoft et Adobe ou le logiciel devient parfois inutilisable ou sans réelle facilité d’utilisation, mais il reste dominant par le biais des effets de réseau et du marketing.)

Avec des projets basés sur le volontariat, toute incitation est beaucoup plus faible. Le nombre d’utilisateurs qui utilise le logiciel n’a rarement de lien avec un apport financier pour les développeurs, et avec les logiciels librement redistribuables, il est de toute façon quasi impossible de compter les utilisateurs qui utilisent réellement l’application. Il existe d’autres mesures incitatives – impressionner des futurs employeurs ou inclure vos logiciels dans un OS populaire.

Solutions : Mettre en place des incitations plus fortes à son utilisabilité. Par exemple, chaque année proposer un prix du design du logiciel libre pourrait aider à faire connaître et à récompenser les développeurs qui réalisent des programmes ergonomiques, avec des interfaces IHM de qualité, etc. Les éditeurs de logiciel pourraient publier des statistiques sur le nombre de leurs utilisateurs qui utilisent leurs applications, et comment ce nombre change au fil du temps. Un système de prime que les gens pourraient verser une somme d’argent en dépôt pour celui qui met en œuvre une amélioration de la convivialité. Les éditeurs peuvent choisir de ne pas distribuer uniquement que des applications « Open Source », mais aussi une variante de l’application, avec une meilleure ergonomie et des améliorations graphiques qui pourraient être un facteur de choix lors de son acquisition.

2. Peu de bons designers. Certains musiciens sont aussi de grands compositeurs, mais la plupart ne le sont pas. Certains développeurs sont aussi de grands designers, mais la plupart ne le sont pas. Développement et design de l’interface IHM sont des compétences distinctes, et des personnes compétentes dans les deux domaines à la fois sont rares. Il est donc important d’avoir des designers dédiés, mais peu de projets Logiciels Libres le font. Certains spécialistes de l’utilisabilité sont employés par des éditeurs de logiciel libre, tels que Mozilla et Canonical (ne pas s’étonner ensuite de leur popularité). Mais ils ne sont pas nombreux, et les designers bénévoles qualifiés sont encore difficiles à trouver.

Solutions : Fournir du matériel de formation accessible aux développeurs, aux concepteurs et aux bénévoles, afin d’améliorer le niveau global de la conception et du design. Encourager les communautés qui permettent de collaborer entre développeurs et spécialistes de l’ergonomie et du design. Encourager dans les projets de logiciel libre d’avoir un responsable du produit (en terme fonctionnel), un responsable du design des interfaces, un spécialiste pour rédiger l’aide en ligne, et un ingénieur qualité, ces personnes étant distincts.

Mais pourquoi y a-t-il une pénurie de bénévoles qui ont des qualités de concepteurs ou de design ? Ce qui nous amène au troisième problème.

3. Les suggestions de design ou d’ergonomie ne sont pas souvent pas les bienvenues. Le Logiciel libre a une longue et saine tradition de « show me the code ». Mais lorsque quelqu’un signale un problème d’ergonomie, cette tradition se transforme en « Envoi ton patche », ce qui est inutile puisque la plupart des designers/concepteurs ne sont pas des développeurs. Trouver des spécialistes de l’utilisabilité pour obtenir de l’aide reste un sujet difficile dans le monde Open Source.

Solution: Mettre en place des processus pour que des spécialistes de l’ergonomie ou du design contribuent à des projets. Par exemple, le concepteur pourrait publier les spécifications sur le site Web du projet et invité à donner sont avis sur un blog, wiki, ou liste de diffusion. Le concepteur peut répondre avec courtoisie aux suggestions sur la conception/ergonomie/design (même les plus étranges). Le responsable du projet pourrait mettre en place une sorte d’outil de suivi pour poser des suggestions et les retours sur l’utilisation du produit. Au lieu d’un outil de suivi d’anomalie en lecture seule qui ne donne que des informations sur le code – ce qui rend plus facile à affiner, à approuver ou refuser, et de mettre des priorités (sous la forme de bénéfice pour l’application) sur la mise en œuvre des suggestions de conception de la même manière que les rapports d’anomalies.

Pourquoi les développeurs réagissent différemment aux propositions sur la facilité d’utilisation qu’aux propositions techniques ?

4.L’usuabilité est difficile à mesurer. Certaines qualités du logiciel sont facilement et précisément mesurables : elle ne fonctionne pas pour tout le monde, les performances, si une fonction est techniquement correcte, si une anomalie apparait au milieu d’une fonction, etc.

Mais ce sont les éléments les plus importants pour la qualité et pour l’adoption du logiciel qui sont les plus difficiles à mesurer : le logiciel est-il réellement utile, est qu’il rend le service attendu, son utilisation est-elle facile ou complexe, la mise à disposition des fonctions est-elle réfléchi ou simplement « entassé » dans le logiciel, est-ce qu’il ce comporte comme les gens s’y attendent, qu’elle proportion des gens réussissent à l’utiliser sans assistance, avec quelle rapidité il l’utilise, quel et le niveau de satisfaction après l’avoir utilisé, etc.

Ces qualités concernant l’interactivité avec les utilisateurs peuvent souvent être mesurées dans des tests d’utilisateur. Mais cela prend des heures ou des jours que les bénévoles ne sont pas disposés à dépenser. Les tests utilisateurs sont de qualité moyenne, prenant en compte les grands problèmes, mais en laissant les concepteurs sans preuve tangible pour persuader les développeurs de corriger les petits problèmes. Même si le problème est identifié, une solution doit être proposée et cela nécessite de nouveaux tests.

Sans test fréquent d’utilisateur, les projets communautaires comptent sur le retour d’information subjectif de personnes qui ont consacré un peu de temps et qui les adresse sur la liste de diffusion du projet. Mais ce que ces gens disent peut ne pas être représentatif de la réalité même de leur propre comportement, et encore moins du comportement des utilisateurs en général.

Solutions : Promouvoir des tests utilisateurs à petite échelle qui peuvent être réalisés par des bénévoles. Développer et promouvoir la capture d’écran, enregistrement vidéo, wideframes et d’autres logiciels qui rend les tests plus faciles à exécuter. Réaliser des tests à la fin des itérations sur des périmètres plus restreints que sur l’ensemble de l’application. Encourager les développeurs à faire confiance au retour des utilisateurs sur les résultats de tests plus que sur l’opinion des uns et des autres. Expliquer les choix de conception que les procédures de test ne peuvent pas couvrir. Expliquer vos choix et ce qui a amené à les faire.

Le manque de designer, à son tour, contribue à trois problèmes culturels dans les projets de logiciel libre.

5. Codé avant de concevoir. Le logiciel a tendance à être beaucoup plus utilisable s’il est, au moins approximativement, conçu avant que le code soit écrit.  L’IHM souhaité pour une application ou pour une fonctionnalité peut affecter le modèle de données, le choix des algorithmes, l’ordre dans lequel les opérations sont effectuées, le besoin de paralléliser les opérations, le format de stockage de données sur le disque, et même l’architecture de l’application dans son ensemble. Mais faire des wireframe (maquette d’interface statique), des spécifications et des prototypes semble ennuyeux pour un développeur, pour lui tout commence au moment du codage – il se soucie de l’interface plus tard.

Mais plus il y a de code écrit, plus il est difficile de corriger un problème de conception – ce qui engendre que les développeurs, essayeront de vous convaincre qu’il y a pas de problème, que cela pourra être corrigé dans une prochaine version, que ce n’est pas réellement un problème. Et si finalement, ils le corrigent, les utilisateurs devront réapprendre à utiliser l’interface, ce qui pourrait les frustrer et les encourager à envisager des programmes concurrents.

Solution : Faire travailler en binômes un designer et un développeur quand vous voulez développer un nouveau projet ou une nouvelle fonctionnalité. Mettre en place une culture du logiciel libre ou la conception passe en premier lieu, et le code en second.

6. Trop de cuisiniers. En l’absence de designer, les nombreux participants à un projet s’efforcent de contribuer à la conception de l’IHM, de la transition entre les pages, etc., indépendamment de ce qu’ils connaissent sur le sujet. Et plusieurs personnes à la conception et à la fabrication de l’IHM conduisent à toutes sortes d’incohérences, aussi bien dans la vision que dans le détail. La qualité de la conception de l’IHM est inversement proportionnelle au nombre de designers.

Solution : Les projets doivent avoir un responsable du design, qui prend en compte les différentes suggestions, et travaille avec les développeurs pour décider de ce qui est réalisable. Plus les spécifications seront détaillées et les grandes lignes directrices connues plus elles réduisent les erreurs potentielles durant la phase de développements.

7. Oubliez les idées préconçues. En l’absence d’une conception précise du designer qui donne son identité au logiciel, de nombreux développeurs pensent que ce que fait Microsoft ou Apple est la bonne manière de faire du design. Parfois, cela est vrai, mais parfois ce ne l’est pas. En imitant les mêmes desseins, les développeurs de Logiciels Libres répètent les mêmes erreurs, ils pérennisent ainsi l’idée qu’il n’y pas de meilleurs modèles que les solutions propriétaires.

Solution : Encourager le design innovant par le biais de prix et autres formes de publicité. Mettre à jour les guides du designer, le cas échéant, tenir compte des expériences de conception réussie.

Les autres raisons de l’existence de mauvaise ergonomie/design/convivialité indépendamment de la présence de designer.

Gratter où ça gratte. Les développeurs bénévoles travaillent sur des projets et des fonctionnalités qui les intéressent, ce qui signifie habituellement qu’ils vont utiliser le logiciel pour leur propre besoin. Ils sont les développeurs, mais également les utilisateurs. Un logiciel qui est censé avoir un périmètre à usage général finit par trop souvent devenir spécifique, complexe et très geek. Les fonctionnalités nécessaires pour les novices ou les non-techniques – tels que l’assistant de configuration, l’outil de reporting, la configuration du profil – sera négligé ou voir totalement inexistant. (Je ne vous parle de la documentation…)

Solutions : Mettre en place une culture de la simplicité, en mettant en place des design très légers, ne pas ajouter des ergonomies ridiculement complexes (compter le nombre de clic et de transition, pour chercher à les réduire systématiquement par deux), appliquer la règle des 80/20 dans la présentation des fonctions. Encourager les volontaires et les développeurs à demander à leurs amis et leurs familles d’utiliser le logiciel, s’inspirer des problèmes (pour ne pas les refaire) que les autres applications peuvent avoir quand vous les utilisez. (un exemple sur mon blog, le bouton ajouté est en haut, le bouton validé est en bas de la page, je suis obligé de faire tout défiler pour valider un nouvel ajout)

8.Laisser les idées se flétrir. Beaucoup de petits détails qui améliorent l’interface de l’application ne sont pas passionnants à réaliser.  Les détails comme la création d’une fenêtre de taille plus appropriée et sa position à sa première apparition, un focus sur un contrôle précis par défaut quand une fenêtre s’ouvre, affiner les messages d’erreur et un autre texte qui peut améliorer la compréhension, ou faire une barre de progression qui refléter plus fidèlement les progrès d’ensemble. Parce que ces choses ne sont pas passionnantes ou satisfaisantes, les années passent souvent avant qu’elles ne soient corrigées. Cela donne aux utilisateurs une impression générale de mauvaise conception (et un rejet de l’application), et qui à son tour, peut décourager les spécialistes de l’utilisabilité/ergonomie de contribuer aux projets.

Solution : Lors de la planification des corrections d’anomalies, prendre en compte combien de temps ils vont prendre, éventuellement, planifier rapidement les corrections mineures, ainsi les corrections sont corrigées vélocement. Faire participer les concepteurs d’interfaces dans ce calendrier, pour se prémunir contre les défauts de la facilité, « c’est juste une question d’UI ».

9. Apaiser les personnes avec des options. Dans tous les projets avec des contributeurs multiples, il arrive parfois que tout le monde ne soit pas d’accord sur des questions de conception. Lorsque les participants sont des salariés, généralement ils continuer à travailler, même s’ils sont en désaccord avec la conception. Mais avec des bénévoles, il est beaucoup plus probable que le mainteneur du projet accorde pour apaiser un contributeur d’ajouter un paramètre de configuration pour un comportement spécifique. Le nombre, l’obscurité, et la trivialité de ces préférences finissent par perdre les utilisateurs ordinaires.

Solution : les responsables des projets doivent avoir une culture de la simplicité (du 80/20). Il faut orienter le développement sous une forme modulaire (par composant), pour pouvoir retirer facilement une fonction, des options qui ne sont pas nécessaires à tous et permettent d’alléger l’interface. Diffusé le code peut aider à calmer la pression, en permettant d’adapter le code pour retirer des options qui ne sont pas nécessaires ou pour proposer des variantes du logiciel avec le comportement qu’ils veulent.