larlet-fr-david-cache/cache/2020/f354723323c0ad6e282ed65e6f316cf5/index.md

title: La facilité d’utilisation des logiciels open source
url: https://write.as/troll/la-facilite-dutilisation-des-logiciels-open-source
hash_url: f354723323c0ad6e282ed65e6f316cf5

<p><em>Écrit en décembre 2002</em></p>

<blockquote><p>Liens vers l'article original: <a href="https://firstmonday.org/article/view/1018/939" rel="nofollow">https://firstmonday.org/article/view/1018/939</a>  ( Traduit en français grâce à DeepL )</p></blockquote>

<h2 id="introduction">Introduction</h2>

<p>Les communautés open source ont développé avec succès de nombreux logiciels. La plupart de ces logiciels sont utilisés par des utilisateurs et utilisatrices avancés, dans le développement de logiciels ou dans le cadre d'une infrastructure informatique plus large. Bien que l'utilisation des logiciels libres se développe, les utilisateurs lamda d'un ordinateur n'interagissent pratiquement qu'avec des logiciels propriétaires. Cette situation s'explique par de nombreuses raisons, dont l'une est la perception que les logiciels libres sont moins utilisables. Ce document examine comment le processus de développement des logiciels libres influence l'utilisabilité et propose des méthodes d'amélioration de la convivialité qui sont appropriées pour le développement de logiciels communautaires sur Internet.</p>

<p>Une interprétation de ce sujet peut être présentée comme la rencontre de deux paradigmes différents:</p>
<ul><li><p>le développeur-utilisateur de logiciel libre qui utilise le logiciel et contribue à son développement</p></li>

<li><p>la conception centrée sur l'utilisateur qui tente de combler le fossé entre les développeurs et les utilisateurs par des techniques spécifiques (ingénierie de l'utilisabilité, conception participative, ethnographie, etc.)</p></li></ul>

<p>En effet, toute la logique qui sous-tend l'approche de la conception centrée sur l'utilisateur dans le cadre de l'interaction humain-machine (IHM) souligne que les développeurs de logiciels ne peuvent pas concevoir facilement pour des utilisateurs types. À première vue, cela suggère que les communautés de développeurs de logiciels libres n'atteindront pas facilement l'objectif de remplacer les logiciels propriétaires sur le bureau de la plupart des utilisateurs (Raymond, 1998). Cependant, comme nous l'expliquons dans ce document, la situation est plus complexe et il existe diverses approches possibles: attitudinales, pratiques et technologiques.</p>

<p>Dans ce document, nous passons d'abord en revue les preuves existantes de la facilité d'utilisation des logiciels libres (OSS). Nous décrivons ensuite les façons dont les caractéristiques du développement des logiciels libres influencent le logiciel. Enfin, nous décrivons comment les techniques d'IHM existantes peuvent être utilisées pour tirer parti des communautés en réseau distribué afin de résoudre les problèmes d'utilisabilité.</p>

<h2 id="y-a-t-il-un-problème-de-convivialité-des-logiciels-libres">Y a-t-il un problème de convivialité des logiciels libres ?</h2>

<p>Les logiciels libres ont acquis une réputation de fiabilité, d'efficacité et de fonctionnalité qui a surpris de nombreuses personnes dans le monde du génie logiciel. L'internet a facilité la coordination des développeurs bénévoles du monde entier pour produire des solutions libres qui sont leaders du marché dans leur secteur (par exemple, le serveur web Apache). Toutefois, la plupart des utilisateurs de ces applications sont relativement avancés sur le plan technique et l'utilisateur lambda d'un ordinateur de bureau utilise généralement des logiciels propriétaires commerciaux standard (Lerner et Tirole, 2002). Il existe plusieurs explications à cette situation : inertie, interopérabilité, interaction avec les données existantes, assistance aux utilisateurs, décisions d'achat organisationnelles, etc. Dans le présent document, nous nous intéressons à une explication possible : le fait que (pour la plupart des utilisateurs potentiels) les logiciels libres sont moins faciles à utiliser.</p>

<p>L'utilisabilité est généralement décrite en termes de cinq caractéristiques : facilité d'apprentissage, efficacité d'utilisation, mémorisation, fréquence et gravité des erreurs et satisfaction subjective (Nielsen, 1993). L'utilisabilité est distincte de l'utilité du logiciel (si celui-ci peut remplir une certaine fonction) et d'autres caractéristiques telles que la fiabilité et le coût. Les logiciels, tels que les compilateurs et les éditeurs de code, qui sont utilisés par les développeurs ne semblent pas représenter un problème d'utilisabilité important pour les logiciels libres. Dans la discussion qui suit, nous nous concentrons sur les logiciels (tels que les traitements de texte, les clients de messagerie électronique et les navigateurs web) qui s'adressent principalement à l'utilisateur lambda.</p>

<p>Le fait qu'il y ait des problèmes de convivialité avec les logiciels libres n'est pas significatif en soi ; tous les logiciels interactifs ont des problèmes. La question est la suivante : comment les logiciels libres produits par un processus de développement ouvert se comparent-ils aux autres approches ? Malheureusement, il n'est pas facile d'organiser une expérience contrôlée pour comparer les autres approches d'ingénierie ; cependant, il est possible de comparer des tâches similaires sur des logiciels existants produits dans des environnements de développement différents. La seule étude dont nous ayons connaissance qui effectue une telle comparaison est celle d'Eklund et al. (2002), qui utilise Microsoft Excel et StarOffice (cette comparaison particulière est rendue plus problématique par le passé propriétaire de StarOffice).</p>

<p>Il existe de nombreuses différences entre les deux logiciels qui peuvent influencer ces comparaisons, par exemple le temps de développement, les ressources de développement, la maturité du logiciel, l'existence antérieure de logiciels similaires, etc. Certains de ces facteurs sont caractéristiques des différences entre le développement de logiciels libres et le développement commercial, mais le grand nombre de différences rend difficile la détermination de ce que devrait être une “comparaison équitable”. En fin de compte, le test du logiciel par l'utilisateur, comme dans le cas d'Eklund et al. (2002), doit être le test décisif. Cependant, comme l'a montré le projet Mozilla (Mozilla, 2002), il peut falloir plusieurs années pour qu'un projet open source atteigne la comparabilité et les comparaisons négatives prématurées ne doivent pas être considérées comme indicatives de l'ensemble de l'approche. En outre, la nature publique du développement de logiciels libres signifie que les premières versions sont visibles, alors que la distribution de logiciels commerciaux embryonnaires est généralement limitée.</p>

<p>Il existe une rareté d'études publiées sur la convivialité des logiciels libres, outre Eklund et al. (2002) ; nous n'avons connaissance que d'études sur GNOME (Smith et al., 2001), Athena (Athena, 2001) et Greenstone (Nichols et al., 2001). Les caractéristiques des projets open source mettent l'accent sur un développement continu et progressif qui ne se prête pas aux études expérimentales formelles traditionnelles (bien que la culture puisse jouer un rôle, comme nous le verrons dans la section suivante).</p>

<p>Bien qu'il existe peu d'études formelles sur la convivialité des logiciels libres, plusieurs suggèrent que la convivialité des logiciels à source ouverte est un problème important (Behlendorf, 1999 ; Raymond, 1999 ; Manes, 2002 ; Nichols et al., 2001 ; Thomas, 2002 ; Frishberg et al., 2002) :</p>

<blockquote><p>“Si cette [conception de bureau et d'application] était principalement un problème technique, le résultat ne serait guère mis en doute. Mais ce n'est pas le cas ; c'est un problème de conception ergonomique et de psychologie des interfaces, et les hackers ont toujours été mauvais dans ce domaine. En d'autres termes, si les hackers peuvent être très bons pour concevoir des interfaces pour d'autres hackers, ils ont tendance à être mauvais pour modéliser les processus de pensée des autres 95% de la population suffisamment bien pour écrire des interfaces que J. Random Utilisateur-Final et sa tante Tillie seront prêts à acheter”. (Raymond, 1999)</p>

<p>“Traditionnellement, les utilisateurs de logiciels libres sont des experts, des adopteurs précoces et sont presque synonymes du pool de développement. Avec l'arrivée des logiciels libres sur le marché, un nouvel accent est mis sur l'utilisabilité et la conception d'interfaces, Caldera et Corel visant explicitement le bureau général avec leurs distributions Linux. Il est peu probable que les utilisateurs non experts soient attirés par le code source disponible et ils sont plus susceptibles de choisir les produits OSS sur la base du coût, de la qualité, de la marque et du support”. (Feller et Fitzgerald, 2000)</p></blockquote>

<p>Raymond énonce le message central de la conception centrée sur l'utilisateur (Norman et Draper, 1986) : les développeurs ont besoin d'une aide externe spécifique pour répondre aux besoins de l'utilisateur moyen. La communauté IHM a développé plusieurs outils et techniques à cette fin : méthodes d'inspection de l'utilisabilité, directives d'interface, méthodes de test, conception participative, équipes interdisciplinaires, etc. (Nielsen, 1993). L'attention croissante accordée à la convivialité dans les cercles du logiciel libre (Frishberg et al., 2002) laisse penser qu'elle pourrait passer par une phase similaire à celle des logiciels propriétaires dans les années 1980.</p>

<p>À mesure que les utilisateurs de logiciels devenaient plus hétérogènes et moins expérimentés techniquement, les producteurs de logiciels ont commencé à adopter des méthodes centrées sur l'utilisateur pour s'assurer que leurs produits étaient adoptés avec succès par leurs nouveaux utilisateurs. Alors que de nombreux utilisateurs continuent à avoir des problèmes avec les applications logicielles, les spécialistes en IHM employés par les entreprises ont considérablement amélioré l'expérience des utilisateurs.</p>

<p>Comme la base d'utilisateurs de logiciels libres s'élargit pour inclure de nombreux non-développeurs, les projets devront appliquer les techniques d'IHM (Interactions Humains-Machines) s'ils souhaitent que leurs logiciels soient utilisés sur le bureau de l'utilisateur lambda. Il est prouvé récemment (Benson et al., 2002 ; Biot, 2002) que certains projets de logiciels libres adoptent des techniques issues de travaux propriétaires antérieurs, comme les directives explicites sur les interfaces utilisateur pour les développeurs d'applications (Benson et al., 2002).</p>

<p>Il est difficile de donner une réponse définitive à la question : existe-t-il un problème d'utilisabilité des logiciels libres ? L'existence d'un problème ne signifie pas nécessairement que toutes les interfaces de logiciels libres sont mauvaises ou que les logiciels libres sont condamnés à avoir des interfaces difficiles à utiliser, mais simplement que les interfaces devraient et peuvent être améliorées. Les opinions de plusieurs commentateurs et les actions des entreprises, telles que l'implication de Sun dans GNOME, suggèrent fortement qu'il y a un problème, bien que la littérature académique (par exemple Feller et Fitzgerald, 2002) soit largement silencieuse sur la question (Frishberg et al. (2002) et Nichols et al. (2001) sont les principales exceptions). Cependant, afin de proposer des approches d'IHM qui correspondent aux caractéristiques pratiques et sociales des développeurs (et des utilisateurs) de logiciels libres, il est nécessaire d'examiner les aspects du processus de développement qui peuvent avoir un impact négatif sur l'utilisabilité.</p>

<h2 id="utilisabilité-et-développement-de-logiciels-libres">Utilisabilité et développement de logiciels libres</h2>

<blockquote><p>“Ils n'aiment pas faire les trucs ennuyeux pour les gens stupides !” (Sterling, 2002)</p></blockquote>

<p>Pour comprendre l'utilité des logiciels libres actuels, nous devons examiner le processus actuel de développement des logiciels. C'est un truisme de la conception centrée sur l'utilisateur que les activités de développement se reflètent dans le système développé. En nous inspirant largement de deux sources principales (Nichols et al., 2001 ; Thomas, 2002), nous présentons ici un ensemble de caractéristiques du processus de développement des logiciels libres qui semblent contribuer au problème de la faible utilisabilité. En outre, certaines caractéristiques partagées avec le secteur commercial contribuent à expliquer pourquoi si l'utilisabilité des logiciels libres n'est pas pire que celle des systèmes propriétaires, elle n'est pas non plus meilleure.</p>

<p>Cette liste de caractéristiques ne se veut pas complète mais sert de point de départ pour aborder ces questions. Nous notons qu'il semble y avoir des difficultés importantes à “prouver” si plusieurs de ces hypothèses sont correctes.</p>

<h4 id="les-développeurs-ne-sont-pas-des-utilisateurs-finaux-typiques">Les développeurs ne sont pas des utilisateurs finaux typiques</h4>

<p>C'est un point clé de Nielsen (1993), partagé avec les développeurs de systèmes commerciaux. Sensibiliser les étudiants en informatique aux questions d'utilisabilité, c'est, d'après notre expérience, principalement les aider à essayer de voir l'utilisation de leurs systèmes à travers les yeux d'autres personnes différentes d'eux-mêmes et de leurs pairs. En fait, pour beaucoup de produits OSS plus avancés, les développeurs sont effectivement des utilisateurs, et ces produits ésotériques avec des interfaces qui seraient inutilisables par un groupe d'utilisateurs moins qualifiés techniquement sont parfaitement adaptés à leur public d'élite. En effet, il peut y avoir une certaine fierté à créer un produit sophistiqué avec une interface puissante, mais difficile à apprendre. La maîtrise d'un tel produit est difficile et légitime donc l'appartenance à une élite qui peut alors se distinguer des “lusers” [1]. Selon Trudelle (2002), “le produit [un navigateur Web] devrait cibler les personnes qu'ils [les contributeurs de logiciels libres] considèrent comme des novices ignorants”.</p>

<p>Cependant, lorsque l'on conçoit des produits pour des utilisateurs moins techniques, tous les problèmes d'utilisation traditionnels se posent. Dans l'étude de Greenstone (Nichols et al., 2001), les conventions communes de la ligne de commande, telles qu'une commande réussie ne donnant aucun retour d'information, ont semé la confusion chez les utilisateurs. L'utilisation des termes “man” (de la ligne de commande Unix), en référence au système d'aide, et “regexp” (expression régulière) dans l'interface GNOME sont des exemples typiques de la terminologie des développeurs présentée aux utilisateurs finaux (Smith et al., 2001).</p>

<p>L'approche OSS ne permet pas d'améliorer l'utilisabilité pour l'utilisateur final parce qu'il y a “le mauvais type d'yeux” qui regardent, mais ne voient pas les problèmes d'utilisabilité. D'une certaine manière, le problème relativement nouveau de l'utilisabilité des logiciels libres reflète le problème qui s'est posé précédemment avec le développement de systèmes commerciaux : au départ, la plupart des applications étaient conçues par des experts en informatique pour d'autres experts en informatique, mais au fil du temps, une proportion croissante du développement de systèmes a été destinée à des non-experts et les problèmes d'utilisabilité sont devenus plus importants. La transition vers des applications non spécialisées dans les produits OSS suit une trajectoire similaire, quelques années plus tard seulement.</p>

<p>La principale différence entre les deux approches est la suivante : le développement de logiciels commerciaux a reconnu ces problèmes et peut employer des experts en IHM spécifiques pour “rééquilibrer” la composition historique de leurs équipes et les priorités de développement qui en découlent en faveur des utilisateurs (Frishberg et al., 2002). Cependant, le développement de logiciels dirigé par des bénévoles n'a pas la possibilité d'engager les compétences manquantes pour garantir que l'équipe de développement dispose d'une expertise en conception centrée sur l'utilisateur. En outre, dans le développement commercial, il est plus facile de s'assurer que les experts en IHM disposent de l'autorité suffisante pour promouvoir les intérêts des utilisateurs.</p>

<h4 id="les-experts-en-ergonomie-ne-s-impliquent-pas-dans-les-projets-de-logiciels-libres">Les experts en ergonomie ne s'impliquent pas dans les projets de logiciels libres</h4>

<p>Des preuves anecdotiques suggèrent que peu de personnes ayant une expérience de l'utilisation sont impliquées dans des projets de logiciel libre ; l'une des “leçons apprises” dans le projet Mozilla (Mozilla, 2002) est de “s'assurer que les concepteurs d'interface utilisateur engagent la communauté du logiciel libre” (Trudelle, 2002). L'Open Source tire ses origines et sa force d'une culture de hacker (O'Reilly, 1999). Cette culture peut être extrêmement accueillante pour d'autres hackeurs, qui traversent confortablement les nations, les organisations et les fuseaux horaires via l'internet. Cependant, elle peut être moins accueillante pour les non-hackers.</p>

<p>Une bonne conception de l'ergonomie s'appuie sur une variété de cultures intellectuelles différentes, y compris, mais sans s'y limiter, la psychologie, la sociologie, la conception graphique et même les études théâtrales. Les équipes de conception pluridisciplinaires peuvent être très efficaces, mais nécessitent des compétences particulières pour les initier et les maintenir. Par conséquent, les équipes de logiciels libres existantes peuvent tout simplement manquer de compétences pour résoudre les problèmes d'utilisabilité et même de compétences pour faire appel à des “étrangers” pour les aider. Les stéréotypes concernant les faibles compétences sociales des hackers ne sont pas à prendre pour un gospel, mais le maintien d'équipes de conception multidisciplinaires réparties n'est pas sans importance.</p>

<p>En outre, les compétences et les attitudes nécessaires pour être un membre efficace et productif d'un projet OSS peuvent être relativement rares. Avec un grand nombre de candidats hacker-développeurs intéressés à s'impliquer, les projets OSS disposent de diverses méthodes pour écarter ceux qui possèdent les meilleures compétences et leur donner progressivement plus de contrôle et de responsabilité. Il se peut que la même chose s'applique aux participants potentiels à l'ergonomie, ce qui implique qu'un nombre important de recrues potentielles en ergonomie est nécessaire pour procéder au processus de tri. Si c'est le cas, cela ajoute au problème de la pénurie de compétences en matière d'utilisabilité.</p>

<p>Il existe plusieurs explications possibles à la participation minimale ou à la non-participation des personnes chargées de l'IHM et de l'ergonomie dans les projets de logiciel libre :</p>
<ul><li><p>Il y a beaucoup moins d'experts en ergonomie que de hackers, donc il n'y en a tout simplement pas assez pour tout le monde.</p></li>

<li><p>Les experts en ergonomie ne sont pas intéressés ou incités par l'approche OSS comme le sont de nombreux pirates.</p></li>

<li><p>Les experts en ergonomie ne se sentent pas les bienvenus dans les projets de logiciels libres.</p></li>

<li><p>Inertie : traditionnellement, les projets n'ont pas besoin d'experts en ergonomie. La situation actuelle de nombreux programmeurs techniquement compétents et de peu d'experts en ergonomie dans les projets OSS n'est qu'un artefact historique.</p></li>

<li><p>Il n'y a pas de masse critique d'experts en ergonomie pour que les incitations à l'excellence et les possibilités de recrutement puissent fonctionner.</p></li></ul>

<h4 id="les-incitations-dans-les-logiciels-libres-fonctionnent-mieux-pour-l-amélioration-des-fonctionnalités-que-pour-l-utilisabilité">Les incitations dans les logiciels libres fonctionnent mieux pour l'amélioration des fonctionnalités que pour l'utilisabilité</h4>

<p>Les développeurs de logiciels libres ne sont-ils tout simplement pas intéressés par la conception de meilleures interfaces ? Comme la plupart des travaux sur les projets de logiciels libres sont volontaires, les développeurs travaillent sur les sujets qui les intéressent et cela peut très bien ne pas inclure de fonctionnalités pour les utilisateurs novices. L'importance des mesures incitatives dans la participation aux logiciels libres est bien reconnue (Feller et Fitzgerald, 2002 ; Hars et Ou, 2001). Il s'agit notamment de gagner le respect des pairs et de relever le défi intrinsèque de s'attaquer à un problème difficile. L'ajout de fonctionnalités ou l'optimisation du code offrent la possibilité de montrer ses talents de hacker à d'autres hackers. Si les participants à l'OSS perçoivent les améliorations de l'utilisabilité comme étant moins importantes, moins stimulantes ou simplement moins intéressantes, ils sont moins susceptibles de choisir de travailler dans ce domaine. La nature volontaire de la participation a deux aspects : le choix de participer ou non et le choix de travailler sur un problème parmi un grand nombre d'autres dans le cadre d'un projet. Avec de nombreux défis concurrents, les problèmes d'utilisabilité peuvent être évincés.</p>

<p>Une version encore plus extrême de ce cas est que le choix de la mission d'un projet de logiciel libre entier peut être plus biaisé en faveur des systèmes que des applications [2]. “La quasi-totalité des projets de logiciel libre les plus connus et les plus réussis semblent avoir été lancés par quelqu'un qui avait un besoin technique auquel la technologie propriétaire (ou logiciel libre) disponible ne répondait pas” [3]. Raymond fait référence à la motivation de “solutionner un besoin personnel” (Raymond, 1998). Il est clair que les initiateurs techniquement compétents des projets de logiciels libres sont plus susceptibles d'avoir un besoin personnel d'applications très avancées, de boîtes à outils de développement ou d'améliorations de l'infrastructure des systèmes qu'une application qui se trouve également répondre aux besoins d'un utilisateur moins sophistiqué sur le plan technique.</p>

<blockquote><p>“Du point de vue d'un développeur, la résolution d'un problème d'utilisabilité peut ne pas être une expérience enrichissante, car la solution peut ne pas impliquer un défi de programmation, une nouvelle technologie ou des algorithmes. Les avantages de la résolution d'un problème d'utilisabilité peuvent également consister en une légère modification du comportement du logiciel (même si elle peut entraîner une amélioration considérable du point de vue de l'utilisateur). Ce changement de comportement peut être subtil et ne pas correspondre aux types de contributions habituelles des développeurs, comme l'ajout de fonctionnalités ou la correction de bogues”. (Eklund et al., 2002)</p></blockquote>

<p>La motivation “solutionner un besoin personnel” crée une différence significative entre le développement de logiciels libres et le développement de logiciels commerciaux. Le développement de systèmes commerciaux vise généralement à répondre aux besoins d'un autre groupe d'utilisateurs. La motivation est de gagner de l'argent en vendant des logiciels aux clients, souvent des clients qui sont prêts à payer précisément parce qu'ils n'ont pas les compétences de développement elles-mêmes. La saisie des besoins de ces clients en matière de logiciels est reconnue comme un problème difficile dans le domaine du génie logiciel et des techniques ont donc été développées pour tenter de le résoudre. En revanche, de nombreux projets de logiciels libres ne disposent pas de processus formels de saisie des exigences, ni même de spécifications formelles (Scacchi, 2002). Ils s'appuient plutôt sur des exigences comprises par des individus ou des communautés étroitement liées au départ. Ces exigences sont étayées par des “informalismes” et illustrées par le code de projet OSS en évolution qui incarne, même s'il ne les exprime pas clairement, les exigences.</p>

<p>Le rapport avec la convivialité est que cela implique que les logiciels libres sont, d'une certaine manière, plus égoïstes que les logiciels fermés (CSS). Une démangeaison personnelle implique de concevoir des logiciels pour ses propres besoins. Les exigences explicites sont donc moins nécessaires. Au sein d'un logiciel libre, ces exigences sont ensuite partagées avec une communauté de même sensibilité et l'outil individuel est affiné et amélioré pour le bénéfice de tous – au sein de cette communauté. En revanche, un projet CSS peut être conçu pour être utilisé par une communauté présentant des caractéristiques différentes et où il existe une forte incitation à consacrer des ressources à certains aspects de la convivialité, en particulier à l'apprentissage initial, afin de maximiser les ventes (Varian, 1993).</p>

<h4 id="les-problèmes-d-utilisation-sont-plus-difficiles-à-spécifier-et-à-distribuer-que-les-problèmes-de-fonctionnalité">Les problèmes d'utilisation sont plus difficiles à spécifier et à distribuer que les problèmes de fonctionnalité</h4>

<p>Les problèmes de fonctionnalité sont plus faciles à spécifier, à évaluer et à modulariser que certains problèmes de convivialité. Ce sont autant d'attributs qui simplifient la résolution décentralisée des problèmes. Certains problèmes de convivialité (mais pas tous) sont beaucoup plus difficiles à décrire et peuvent imprégner tout un écran, une interaction ou une expérience utilisateur. Les patchs incrémentaux pour les bogues d'interface peuvent être beaucoup moins efficaces que les patchs incrémentaux pour les bogues de fonctionnalité. La résolution du problème peut nécessiter une révision majeure de toute l'interface – ce qui n'est évidemment pas une petite contribution au travail de conception en cours. Impliquer plus d'un concepteur dans la conception de l'interface, en particulier s'ils travaillent de manière autonome, entraînera une incohérence dans la conception et donc une diminution de la convivialité globale. De même, l'amélioration d'un aspect de l'interface d'une partie de l'application peut nécessiter un examen attentif des conséquences de ce changement pour la cohérence globale de la conception. On peut comparer cette situation à la fixation progressive des fonctionnalités d'une application modulaire de haute qualité. L'intérêt de la modularisation est que les effets sont locaux. Un remaniement substantiel (et hautement souhaitable) peut se produire tout au long du projet en cours tout en restant invisible pour les utilisateurs. Cependant, de nombreux changements d'interface ont une portée mondiale en raison de leurs effets de cohérence.</p>

<p>La modularité des projets OSS contribue à l'efficacité de l'approche (O'Reilly, 1999), leur permettant de contourner la loi de Brooks [4]. Différentes parties peuvent être échangées et remplacées par des modules supérieurs qui sont ensuite incorporés dans la version suivante. Toutefois, un critère de succès majeur pour la facilité d'utilisation est la cohérence de la conception. De légères variations dans l'interface entre les modules et les différentes versions de modules peuvent irriter et semer la confusion, et gâcher l'expérience globale de l'utilisateur. Leur nature inévitablement publique signifie que les interfaces ne se prêtent pas à la boîte noire qui permet certains types d'améliorations progressives et distribuées.</p>

<p>Nous devons noter que les projets de logiciels libres permettent de résoudre certaines catégories de problèmes d'utilisation. Une approche populaire de la conception d'interfaces OSS est la création de “skins” : des configurations d'interfaces alternatives qui affectent considérablement l'apparence générale de l'application, mais qui ne modifient pas la nature de la dynamique d'interaction sous-jacente. Une approche connexe est l'internationalisation du logiciel, où la langue de l'interface (et les icônes spécifiques à la culture) est traduite. Les deux approches se prêtent à l'approche modulaire du logiciel libre, tandis qu'une tentative de résoudre des problèmes d'interaction plus profonds par une re-conception des ensembles de séquences d'interaction ne se décompose pas aussi facilement en un projet gérable. La raison de cette différence est que le traitement des problèmes d'interaction plus profonds peut avoir des implications non seulement sur l'ensemble de l'interface, mais aussi entraîner des exigences de modification de différents éléments de fonctionnalité.</p>

<p>Une autre catégorie importante de succès en matière d'utilisabilité des logiciels libres se situe au niveau de l'installation des logiciels (principalement GNU/Linux). Même les experts techniques ont eu des difficultés à installer les premières versions de GNU/Linux. Le projet Debian (Debian, 2002) a été lancé pour créer une meilleure distribution qui facilite l'installation, et d'autres projets et entreprises ont poursuivi cette tendance. De tels projets résolvent un problème d'utilisabilité, mais d'une manière compatible avec le développement traditionnel de logiciels libres. En effet, un ensemble complexe d'opérations manuelles est automatisé, créant ainsi une boîte noire pour l'utilisateur final qui ne souhaite pas explorer davantage. Bien entendu, comme il s'agit d'un projet open source, la boîte noire est ouverte, vérifiable et modifiable pour ceux qui ont la volonté et la compétence d'enquêter.</p>

<h4 id="la-conception-pour-la-facilité-d-utilisation-devrait-vraiment-avoir-lieu-avant-tout-codage">La conception pour la facilité d'utilisation devrait vraiment avoir lieu avant tout codage</h4>

<p>D'une certaine manière, il est surprenant que le développement des logiciels libres soit si réussi, étant donné qu'il enfreint de nombreuses règles établies du génie logiciel conventionnel. Les projets bien gérés sont censés être soigneusement planifiés à l'avance, en saisissant les besoins et en spécifiant clairement ce qui doit être fait avant de commencer le codage. En revanche, le logiciel libre semble souvent impliquer un codage aussi précoce que possible, en s'appuyant sur une révision constante pour affiner et améliorer la conception globale émergente : “votre communauté de développeurs naissante doit avoir quelque chose de fonctionnel et de testable pour jouer avec” (Raymond, 1998). De même, l'étude de Scacchi (2002) n'a pas trouvé “d'exemples d'activités d'élicitation, d'analyse et de spécification des exigences formelles du type de celles suggérées par les manuels de génie logiciel”. Trudelle (2002) note que le fait de sauter une grande partie de l'étape de conception avec Mozilla a entraîné un travail de conception et d'exigences dans les rapports de bogue, après la distribution des premières versions.</p>

<p>Cette approche semble fonctionner pour certains types d'applications, et dans d'autres cas, il peut y avoir un plan clair ou une vision partagée entre le coordinateur du projet et les principaux participants. Cependant, une bonne conception d'interface fonctionne mieux en étant impliquée avant que le codage n'ait lieu. S'il n'y a pas de planification collective préalable, même pour le codage, il n'est pas possible de prendre en compte les questions d'interface dès la conception. La planification des logiciels libres est généralement effectuée par l'initiateur du projet, avant que le groupe le plus important ne soit impliqué [5]. Nous supposons que si les membres d'un projet de logiciel libre peuvent partager une forte vision de la fonctionnalité prévue (ce qui permet de contourner la planification préalable traditionnelle du génie logiciel), ils ont souvent une vision commune beaucoup plus faible de l'interface prévue. À moins que l'initiateur ne possède des compétences importantes en matière de conception d'interactions, des aspects importants de l'utilisabilité seront négligés jusqu'à ce qu'il soit trop tard. Comme pour beaucoup des questions que nous soulevons, cela ne veut pas dire que le CSS réussit toujours, ou même fréquemment, à faire les choses correctement. Nous voulons plutôt examiner les obstacles potentiels au sein des pratiques existantes en matière de logiciels libres, qui pourraient alors être levés.</p>

<h4 id="les-projets-à-source-ouverte-manquent-de-ressources-pour-entreprendre-un-travail-de-haute-qualité-sur-la-convivialité">Les projets à source ouverte manquent de ressources pour entreprendre un travail de haute qualité sur la convivialité</h4>

<p>Les projets OSS sont volontaires et fonctionnent donc avec de petits budgets. Il n'est pas possible d'employer des experts externes tels que des auteurs techniques et des graphistes. Comme indiqué précédemment, il peut y avoir actuellement des obstacles à l'apport de telles compétences au sein de l'équipe de développement volontaire de logiciels libres. Les laboratoires d'utilisation et les expériences détaillées à grande échelle ne sont tout simplement pas économiquement viables pour la plupart des projets OSS. La discussion sur la liste de diffusion KDE Usability (KDE Usability, 2002) a envisagé de demander aux laboratoires d'utilisabilité de donner du temps pour mener des études avec des équipements de pointe.</p>

<p>L'activité récente en matière d'utilisabilité dans plusieurs projets de logiciels libres a été associée à la participation d'entreprises, par exemple Benson et al. (2002), bien qu'il semble probable qu'elles investissent moins que les grands développeurs de logiciels propriétaires. À moins que les ressources consacrées à l'utilisabilité des logiciels libres ne soient augmentées ou que d'autres approches ne soient étudiées (voir ci-dessous), l'utilisabilité des logiciels libres continuera d'être entravée par les limitations des ressources.</p>

<h4 id="les-logiciels-commerciaux-établissent-l-étalon-de-sorte-que-les-logiciels-libres-ne-peuvent-que-rattraper-leur-retard">Les logiciels commerciaux établissent l'étalon de sorte que les logiciels libres ne peuvent que rattraper leur retard</h4>

<p>Indépendamment du fait que les logiciels commerciaux offrent une bonne utilisabilité, leur prédominance écrasante dans les applications destinées à l'utilisateur final crée une inertie distincte en ce qui concerne la conception d'interfaces innovantes. Afin de rivaliser pour être adoptées, les applications de logiciels libres semblent suivre les idées d'interface des marques leaders. Ainsi, le composant de feuille de calcul de Star Office, Calc, testé par rapport à Microsoft Excel dans (Eklund et al., 2002) a été délibérément développé pour fournir une interface similaire afin de faciliter l'apprentissage du transfert. En conséquence, il a dû suivre les idées de conception de l'interface d'Excel, qu'elles aient pu être améliorées ou non.</p>

<p>Il ne semble pas y avoir de raison impérative pour laquelle ce conservatisme devrait prévaloir, si ce n'est la nécessité perçue de rivaliser en incitant les utilisateurs actuels de CSS à passer à des équivalents directs en open source. Une autre possibilité est que les développeurs de logiciels libres typiques actuels, qui peuvent être extrêmement favorables à l'innovation fonctionnelle, manquent tout simplement d'intérêt pour l'innovation en matière de conception d'interfaces. Enfin, le code sous-jacent d'un système commercial est propriétaire et caché, ce qui oblige tout concurrent de logiciel libre à faire une forme d'ingénierie inverse pour le développer. Cette activité peut inspirer une innovation et une extension importantes. En revanche, l'interface du système est une solution préexistante très visible qui pourrait freiner l'innovation – pourquoi ne pas simplement la copier, sous réserve de modifications mineures pour des raisons de droits d'auteur ? On pourrait s'attendre, en l'absence d'autres facteurs, à ce que les projets open source soient beaucoup plus créatifs et risqués dans leur développement de combinaisons radicalement nouvelles de fonctionnalités et d'interface, puisqu'ils ne subissent pas de pressions financières à court terme.</p>

<h4 id="les-logiciels-libres-ont-encore-plus-tendance-à-gonfler-que-les-logiciels-commerciaux">Les logiciels libres ont encore plus tendance à gonfler que les logiciels commerciaux</h4>

<p>De nombreux types de logiciels commerciaux ont été critiqués pour leur code surdimensionné, consommant des quantités de mémoire et un nombre de cycles de processeur toujours plus importants avec les versions successives des logiciels. Il existe une pression commerciale pour augmenter les fonctionnalités et inciter ainsi les propriétaires actuels à acheter la dernière mise à jour. Naturellement, l'augmentation des fonctionnalités peut sérieusement détériorer la convivialité, car le nombre croissant d'options devient de plus en plus déconcertant, ce qui contribue à masquer le minuscule sous-ensemble de fonctionnalités qu'un utilisateur donné souhaite utiliser.</p>

<p>Il existe des pressions similaires dans le développement de logiciels libres, mais pour des raisons différentes. Compte tenu des intérêts et des motivations des développeurs, il y a une forte incitation à ajouter des fonctionnalités et presque aucune à en supprimer, d'autant plus que cela peut irriter la personne qui a développé la fonctionnalité en question. Pire encore, étant donné que l'estime des pairs est une incitation cruciale à la participation, la suppression d'une fonctionnalité dans l'intérêt de l'utilisateur final crée une forte désincitation à la participation future, peut-être considérée comme pire que le fait de voir son code remplacé par un code que ses pairs ont jugé supérieur. Le responsable du projet, afin de satisfaire les participants volontaires, est susceptible de conserver une fonctionnalité même si elle est déroutante, et à la réception de deux fonctionnalités supplémentaires similaires, de les conserver toutes les deux, créant ainsi des options permettant à l'utilisateur du logiciel de configurer l'application pour utiliser celle qui répond le mieux à ses besoins. De cette manière, le plus grand nombre possible de contributeurs peuvent obtenir un crédit clair pour avoir contribué directement à l'application. Cette tendance suggérée au compromis de conception en “baril de porc” nécessite une étude plus approfondie.</p>

<p>Le processus de “publication précoce et fréquente” peut conduire à l'acceptation de certaines fonctionnalités maladroites. Les gens investissent du temps et des efforts dans leur apprentissage et créent leurs propres solutions pour y faire face. Lorsqu'une nouvelle version améliorée est publiée avec une meilleure interface, les premiers utilisateurs de l'application sont tentés de refuser de s'adapter à la nouvelle interface. Même si elle est plus facile à apprendre et à utiliser que l'ancienne, leur apprentissage de l'ancienne version est désormais un investissement à fonds perdus et il est compréhensible qu'ils ne soient pas disposés à réapprendre et à modifier leurs solutions de contournement. La tentation pour le responsable du projet est de maintenir plusieurs interfaces héritées coordonnées avec la dernière version. Cela plaît aux utilisateurs plus âgés, crée plus de possibilités de développement, conserve les contributions des anciennes interfaces dans la dernière version et ajoute à la complexité du produit final.</p>



<p>Le “gonflement des logiciels” est largement reconnu comme un attribut négatif. Cependant, la décision d'ajouter plusieurs options alternatives à un système peut être considérée comme un bien positif plutôt que comme un compromis peu enviable. Nous supposons que la liberté de choix peut être considérée comme un attribut souhaitable (voire une esthétique de conception) par de nombreux développeurs de logiciels libres. Le résultat final est une application qui offre de nombreuses options de configuration, permettant une personnalisation très sophistiquée par des utilisateurs experts, mais qui peut être déconcertante pour un novice [6]. La mise à disposition de cinq horloges de bureau différentes dans GNOME (Smith et al., 2001) est une manifestation de cette tendance ; une autre est la croissance des interfaces de préférences dans de nombreux programmes OSS (Thomas, 2002).</p>

<p>Ainsi, les applications OSS ont tendance à devenir plus complexes, réduisant leur facilité d'utilisation pour les novices, mais avec cette tendance à rester invisibles pour les développeurs qui ne sont pas des novices et qui apprécient la puissance des applications sophistiquées. Les développeurs experts rencontreront aussi rarement les paramètres par défaut d'une multitude d'options et ne prêteront donc probablement pas beaucoup d'attention à leur sélection minutieuse, alors que les novices vivront souvent avec ces paramètres par défaut. Bien sûr, les applications commerciales gagnent également en complexité, mais il existe au moins certains facteurs qui permettent de modérer cette croissance, notamment le coût de développement des fonctionnalités supplémentaires et certaines pressions dues à une prise de conscience croissante des problèmes d'utilisabilité.</p>

<h2 id="approches-possibles-pour-améliorer-l-utilisation-des-logiciels-libres">Approches possibles pour améliorer l'utilisation des logiciels libres</h2>

<p>Les facteurs ci-dessus visent à expliquer l'état actuel relativement médiocre de l'utilisabilité de nombreux logiciels libres. Cependant, certains facteurs devraient contribuer à une meilleure utilisabilité, bien qu'ils puissent actuellement être compensés par les facteurs négatifs de nombreux projets en cours.</p>

<p>Un facteur positif clé est que certains utilisateurs finaux sont impliqués dans des projets de logiciel libre [7]. Cette participation peut se traduire par l'élaboration des exigences, les tests, la rédaction de la documentation, le signalement des bogues, la demande de nouvelles fonctionnalités, etc. Cela correspond clairement à la position des experts en IHM (Interactions Humain-Machine), par exemple Shneiderman (2002), et présente également des caractéristiques communes avec la conception participative (Kyng et Mathiassen, 1997). Le défi est de savoir comment permettre et encourager une participation beaucoup plus importante des utilisateurs finaux non techniques et des experts en IHM qui ne se conforment pas au stéréotype traditionnel du contributeur de logiciel libre.</p>

<p>Nous décrivons plusieurs domaines dans lesquels nous voyons un potentiel d'amélioration des processus d'utilisabilité dans le développement des logiciels libres.</p>

<h4 id="approches-commerciales">Approches commerciales</h4>

<p>Une méthode consiste à prendre un projet OSS réussi avec des fonctionnalités puissantes et à impliquer les entreprises dans le développement d'une meilleure interface. Il est à noter que plusieurs des développements récents positifs (du point de vue de l'IHM) (Smith et al., 2001 ; Benson et al., 2002 ; Trudelle, 2002) dans le domaine du développement de logiciels libres sont parallèles à la participation de grandes entreprises ayant à la fois une expérience de conception et beaucoup plus de ressources que le projet open source typique mené par des volontaires. Toutefois, les méthodes d'IHM utilisées sont fondamentalement les mêmes que pour les logiciels propriétaires et ne tirent pas parti de la communauté distribuée qui donne au logiciel libre l'avantage perçu dans d'autres aspects du développement. Cela implique-t-il que la seule façon d'atteindre un niveau élevé d'utilisabilité pour l'utilisateur final est d'“envelopper” un projet libre avec une interface développée commercialement ? C'est certainement une approche, et l'Apple OS X en est un bon exemple, tout comme, dans une moindre mesure, les versions commerciales de GNU/Linux (puisqu'elles sont destinées à un marché (légèrement) moins avancé sur le plan technologique). Le modèle Netscape/Mozilla de développement en connaissance de cause offre un autre modèle. Toutefois, comme le fait remarquer Trudelle (2002), il peut y avoir des conflits d'intérêts et des malentendus mutuels entre un partenaire commercial et les développeurs de logiciels libres sur l'orientation du développement de l'interface de manière à ce qu'elle corresponde à leurs intérêts.</p>

<h4 id="les-approches-technologiques">Les approches technologiques</h4>

<p>Une approche pour remédier au manque de compétences humaines en matière d'IHM consiste à automatiser l'évaluation des interfaces. Ivory et Hearst (2001) présentent un examen complet des techniques d'évaluation de la convivialité automatisée et notent plusieurs avantages de l'automatisation, notamment la réduction des coûts, l'augmentation de la cohérence et la réduction du besoin d'évaluateurs humains. Par exemple, l'outil Sherlock (Mahjan et Shneiderman, 1997) a automatisé la vérification de la cohérence visuelle et textuelle dans une application en utilisant des méthodes simples telles que la concordance de tout le texte dans l'interface de l'application et des mesures telles que la densité des widgets. Les applications dont l'interface peut être facilement séparée du reste du code, comme Mozilla, sont de bons candidats pour de telles approches.</p>

<p>Une approche intéressante pour comprendre le comportement des utilisateurs est l'utilisation d'“agents d'attente” (Hilbert et Redmiles, 2001) qui permettent aux développeurs de placer facilement et explicitement leurs attentes en matière de conception dans le cadre d'une application. Lorsqu'un utilisateur fait quelque chose d'inattendu (et déclenche l'agent d'attente), des informations sur l'état du programme sont collectées et renvoyées aux développeurs. Il s'agit d'une extension de l'instrumentation des applications, mais qui se concentre sur l'activité de l'utilisateur (comme l'ordre dans lequel un utilisateur remplit un formulaire) plutôt que sur les valeurs des variables du programme. Une instrumentation étendue a été utilisée par les développeurs de logiciels à code source fermé comme élément clé de l'amélioration des programmes (Cusmano et Selby, 1995).</p>

<h4 id="participation-des-universitaires">Participation des universitaires</h4>

<p>Il est à noter que certains des travaux décrits précédemment sont issus de l'enseignement supérieur (Athena, 2001 ; Eklund et al., 2002 ; Nichols et al., 2001). Dans ces cas, des classes d'étudiants impliqués dans l'IHM ont participé à des études sur les logiciels libres ou les ont organisées. Ce type d'activité est en fait un cadeau aux développeurs de logiciels, bien que l'objectif principal soit pédagogique. L'intérêt de pratiquer les compétences et de tester la compréhension conceptuelle sur des problèmes authentiques plutôt que sur des exercices inventés est évident.</p>

<p>Le modèle proposé est qu'un individu, un groupe ou une classe apporte bénévolement son soutien en suivant le modèle OSS, mais en impliquant des aspects de toute combinaison d'analyse de la convivialité et de conception : études d'utilisateurs, études sur le lieu de travail, exigences de conception, expériences contrôlées, analyse formelle, esquisses de conception, prototypes ou suggestions de code réel. Afin de soutenir ce type de participation, certaines modifications peuvent être nécessaires au logiciel de soutien OSS, comme indiqué ci-dessous.</p>

<h4 id="impliquer-les-utilisateurs-finaux">Impliquer les utilisateurs finaux</h4>

<p>La base de données de bogues de Mozilla, Bugzilla, a reçu plus de 150'000 rapports de bogues au moment de la rédaction du présent document. La plupart de ces rapports concernent la fonctionnalité (plutôt que la convivialité) et ont été fournis par des utilisateurs et des développeurs techniquement sophistiqués :</p>

<blockquote><p>“Les rapports de nombreux utilisateurs sont également inhabituels ; ma règle de base habituelle est que seulement 10% des utilisateurs ont une idée de ce que sont les groupes de discussion (et la plupart d'entre eux se cachent 90% du temps), et que bien moins de 1% des utilisateurs de mozilla ne signalent jamais un bogue. Cela signifierait que nous n'avons jamais vraiment de nouvelles de 90 % des utilisateurs, à moins que nous fassions un effort pour les atteindre”. [8]</p></blockquote>

<p>En général, la plupart des membres [d'une communauté open source] sont des membres passifs. Par exemple, environ 99 % des personnes qui utilisent Apache sont des utilisateurs passifs (Nakakoji, 2002).
L'une des raisons de la non-participation des utilisateurs est que l'acte de contribuer est perçu comme trop coûteux par rapport aux bénéfices éventuels. Le temps et les efforts nécessaires pour s'inscrire à Bugzilla (un pré-requis pour le signalement des bogues) et comprendre son interface Web sont considérables. La langue et la culture incarnées par l'outil sont elles-mêmes des obstacles à la participation de nombreux utilisateurs. En revanche, les outils de signalement de pannes de Mozilla et de Microsoft Windows XP sont simples à utiliser et ne nécessitent aucun enregistrement. En outre, ces outils font partie de l'application et ne nécessitent pas qu'un utilisateur saisisse séparément des informations sur un site web.</p>

<p>Nous pensons que les incidents d'utilisation intégrés signalés par les utilisateurs sont un bon candidat pour résoudre les problèmes d'utilisation dans les projets de logiciel libre. En d'autres termes, les utilisateurs signalent les cas où ils ont des problèmes pendant qu'ils utilisent une application. Les recherches existantes sur les IHM (Hartson et Castillo, 1998 ; Castillo et al., 1998 ; Thompson et Williges, 2000) ont montré, à petite échelle, que le signalement par les utilisateurs est efficace pour identifier les problèmes d'utilisabilité. Ces outils de compte rendu font partie d'une application, sont faciles à utiliser, dépourvus de vocabulaire technique et peuvent renvoyer des informations objectives sur l'état du programme en plus des commentaires des utilisateurs (Hilbert et Redmiles, 2000). Cette combinaison de données objectives et subjectives est nécessaire pour faire des inférences causales sur les interactions des utilisateurs dans les techniques de convivialité à distance (Kaasgaard et al., 1999). En plus de ces rapports initiés par l'utilisateur, les applications peuvent inciter les utilisateurs à contribuer en fonction de leur comportement (Ivory et Hearst, 2001). Kaasgaard et al. (1999) notent qu'il est difficile de prévoir comment ces fonctionnalités supplémentaires affectent l'utilisation principale du système.</p>

<p>Une autre méthode pour faire participer les utilisateurs consiste à créer des tests d'utilisabilité à distance qui peuvent être réalisés par n'importe qui à tout moment. Les résultats sont rassemblés sur l'ordinateur de l'utilisateur et renvoyés aux développeurs. Tullis et autres (2002) et Winckler et autres (1999) décrivent tous deux cette approche pour les tests d'utilisabilité des sites web ; une fenêtre de navigateur séparée est utilisée pour guider l'utilisateur à travers une séquence de tâches dans la fenêtre principale. Scholtz (1999) décrit une méthode similaire pour les sites web dans la fenêtre principale du navigateur – en fait, dans le cadre de l'application. Les comparaisons entre les études en laboratoire et les études à distance de sites Web indiquent que les taux d'achèvement des tâches par les utilisateurs sont similaires et que le nombre plus important de participants à distance compense le manque d'observation directe de l'utilisateur (Tullis et al., 2002 ; Jacques et Savastano, 2001).</p>

<p>Ces deux approches permettent aux utilisateurs de contribuer à des activités de convivialité sans avoir à apprendre de vocabulaire technique. Elles s'intègrent également bien dans l'approche OSS : elles permettent une participation en fonction de l'expertise du contributeur et tirent parti des forces d'une communauté dans un environnement distribué en réseau. Bien que ces techniques perdent le contrôle des études d'utilisabilité en laboratoire, elles gagnent en authenticité dans la mesure où elles sont fermement ancrées dans l'environnement de l'utilisateur (Thomas et Kellogg, 1989 ; Jacques et Savastano, 2001 ; Thomas et Macredie, 2002).</p>

<p>Pour promouvoir davantage la participation des utilisateurs, il devrait être possible de suivre facilement les conséquences d'un rapport, ou d'un résultat de test, auquel un utilisateur a contribué. La nature publique des discussions sur les bogues de Bugzilla permet d'atteindre cet objectif pour les développeurs, mais une version plus simple serait nécessaire pour les utilisateurs moyens afin qu'ils ne soient pas submergés par des détails de bas niveau. Shneiderman [9] suggère que les utilisateurs pourraient être financièrement récompensés pour de telles contributions, par exemple par des remises sur les achats futurs de logiciels. Cependant, dans le contexte du logiciel libre, l'utilisateur pourrait s'attendre à recevoir des informations telles que “Vos quatre rapports récents ont contribué à la correction du bogue X qui est reflété dans la nouvelle version 1.2.1 du logiciel”.</p>

<h4 id="créer-une-infrastructure-de-discussion-sur-l-utilisabilité">Créer une infrastructure de discussion sur l'utilisabilité</h4>

<p>Pour les bogues fonctionnels, un outil tel que Bugzilla fonctionne bien pour aider les développeurs, mais présente des interfaces complexes à d'autres contributeurs potentiels. Si nous souhaitons que de tels outils soient utilisés par les gens de l'IHM, alors ils peuvent avoir besoin d'une interface alternative légère qui s'éloigne de certains détails de bas niveau. En particulier, les systèmes qui sont construits sur des systèmes de gestion de code peuvent facilement devenir trop centrés sur des éléments textuels.</p>

<p>Au fur et à mesure de la réception des rapports d'utilisateurs et des résultats des tests de convivialité, il faut structurer, analyser, discuter et agir. Une grande partie des discussions sur la convivialité est de nature graphique et pourrait être mieux prise en charge par des fonctionnalités de croquis et d'annotation ; il est à noter que certaines discussions sur les bogues de Mozilla incluent des représentations textuelles (“art ASCII”) des éléments d'interface proposés. Hartson et Castillo (1998) passent en revue diverses approches graphiques pour le signalement des bogues, y compris des vidéos et des captures d'écran qui peuvent compléter les méthodes textuelles prédominantes. Par exemple, une application pourrait éventuellement inclure une capture d'écran avec un rapport de bogue ; l'image résultante pourrait alors être annotée dans le cadre d'une discussion en ligne. Bien que ces changements puissent sembler mineurs, une leçon essentielle de la recherche sur l'utilisabilité est que les détails comptent et qu'un petit effort supplémentaire suffit à dissuader les utilisateurs de participer (Nielsen, 1993).</p>

<h4 id="fragmenter-l-analyse-et-la-conception-de-l-utilisabilité">Fragmenter l'analyse et la conception de l'utilisabilité</h4>

<p>Nous pouvons envisager divers nouveaux types de participation à l'utilisabilité légère, qui peuvent être comparés aux contributions expérimentales et d'analyse plus substantielles décrites ci-dessus pour la participation universitaire ou commerciale. Un utilisateur final peut fournir volontairement une description de ses propres expériences, peut-être idiosyncrasiques, avec le logiciel. Une personne ayant une certaine expérience de l'utilisabilité peut soumettre son analyse. En outre, un tel contributeur pourrait mener une étude sur les utilisateurs avec un échantillon de la taille d'un, puis la rapporter. Il est souvent surprenant de constater la quantité d'informations sur la convivialité qui peut être extraite d'un petit nombre d'études (Nielsen, 1993).</p>

<p>De la même manière que les travaux de développement de logiciels libres réussissent à fragmenter la tâche de développement en sous-unités gérables, les tests d'utilisabilité peuvent être fragmentés en faisant participer de nombreuses personnes dans le monde entier, chacune réalisant une seule étude d'utilisateurs et combinant ensuite les résultats globaux pour l'analyse. La coordination de nombreuses petites études parallèles nécessiterait un support logiciel adapté, mais elle ouvre une nouvelle façon d'entreprendre le travail d'utilisabilité qui correspond bien à la nature distribuée du développement des logiciels libres. Les travaux sur l'utilisabilité à distance (Hartson et al., 1996 ; Scholtz, 2001) suggèrent fortement que la distribution nécessaire des travaux est réalisable ; des travaux supplémentaires sont nécessaires pour coordonner et interpréter les résultats.</p>

<h4 id="impliquer-les-experts">Impliquer les experts</h4>

<p>L'un des points clés pour impliquer les experts en IHM sera l'examen des incitations à la participation. Nous avons noté les problèmes d'une masse critique de pairs, et une légitimation de l'importance des questions d'utilisabilité au sein de la communauté du logiciel libre afin que les compromis de conception puissent être discutés de manière productive. Une question relativement mineure est la réduction des coûts de la participation due aux problèmes d'articulation de l'utilisabilité dans un support essentiellement textuel, et diverses solutions ont été proposées. Nous supposons que pour certains experts en ergonomie, leur participation à un projet de logiciel libre sera problématique dans les cas où les conceptions et les améliorations qu'ils proposent se heurtent au travail de développement traditionnel centré sur la fonctionnalité. Comment peut-on résoudre ce problème ? Une articulation claire de l'analyse de l'utilisabilité sous-jacente, une sorte de justification de la conception, peut aider. En l'absence de telles explications, le danger est qu'un expert en ergonomie isolé soit marginalisé.</p>

<p>Un autre type de rôle pour un expert en ergonomie peut être celui de défenseur de l'utilisateur final. Cela peut impliquer l'analyse des contributions de l'utilisateur final, la création d'une version condensée, peut-être filtrée par la propre compréhension théorique de l'expert pour répondre aux préoccupations des développeurs qui craignent que les rapports soient biaisés ou non représentatifs. L'expert s'engage alors dans le débat sur la conception au nom des utilisateurs finaux, en essayant de rectifier le problème du développement traditionnel de logiciels libres en ne faisant que solutionner les problémes personnels des développeurs, et non ceux des utilisateurs visés. Comme pour la création d'incitations visant à promouvoir la participation des utilisateurs finaux, les conséquences sur l'évolution de la conception des interactions des experts en ergonomie devraient être enregistrées et facilement traçables.</p>

<h4 id="éducation-et-évangélisation">Éducation et évangélisation</h4>

<p>De la même manière que les organisations de développement de logiciels commerciaux ont dû apprendre que l'utilisabilité était une question importante qu'elles devaient prendre en compte et qui pouvait avoir un impact significatif sur les ventes de leur produit, les projets de logiciels libres devront être convaincus qu'il vaut la peine de s'informer sur les bonnes techniques de développement de l'utilisabilité et de les mettre en pratique. L'incitation à augmenter les ventes ne sera généralement pas pertinente, et il faudra donc adopter d'autres approches pour faire valoir l'utilité du produit. Nickell (2001) suggère que les développeurs préfèrent que leurs programmes soient utilisés et que “la plupart des hackers trouvent que l'acquisition d'une base d'utilisateurs est un facteur de motivation pour le développement d'applications”.</p>

<p>La création d'une infrastructure technologique permettant de faciliter la participation des experts en ergonomie et des utilisateurs finaux sera insuffisante sans une infrastructure sociale équivalente. Ces nouveaux venus dans les projets de logiciels libres devront se sentir accueillis et valorisés, même si (en fait parce que) ils n'ont pas les compétences techniques des hackers traditionnels. Les références aux “novices ignorants” et aux “utilisateurs”, ainsi que certains des arguments en ligne les plus vitupérants, devront être réduites et, si elles ne sont pas éliminées, au moins déplacées vers des domaines technologiques spécifiques désignés. Au-delà de la simple tolérance d'une plus grande diversification de l'équipe de développement, il serait intéressant d'explorer les conséquences de certains projets de logiciel libre sollicitant activement l'aide de ces groupes. Comme pour diverses entreprises multidisciplinaires, notamment l'intégration de psychologues dans la conception d'interfaces commerciales et d'ethnographes dans des projets de travail coopératif assisté par ordinateur, il faut veiller à ce que les participants puissent se parler de manière productive (Crabtree et al., 2000).</p>

<h2 id="discussion-et-travaux-futurs">Discussion et travaux futurs</h2>

<p>Nous ne voulons pas laisser entendre que le développement des logiciels libres a complètement ignoré l'importance d'une bonne utilisabilité. Des activités récentes (Frishberg et al., 2002 ; Nickell, 2001 ; Smith et al., 2001) suggèrent que la communauté du logiciel libre est de plus en plus sensibilisée aux questions d'utilisabilité. Le présent document a identifié certains obstacles à la convivialité et a examiné comment ceux-ci sont et peuvent être levés. Plusieurs des approches décrites ci-dessus reflètent directement les problèmes identifiés précédemment ; essayez l'évaluation automatisée lorsqu'il y a un manque d'expertise humaine et encouragez divers types de participation des utilisateurs finaux et des experts en convivialité pour rééquilibrer la communauté de développement en faveur des utilisateurs moyens. Si le développement traditionnel des logiciels libres consiste à résoudre un besoin personnel, l'utilisabilité consiste à être conscient et à se préoccuper des problèmes des autres.</p>

<p>Un examen plus approfondi des questions exposées dans le présent document pourrait prendre différentes formes. L'un des grands avantages du développement de logiciels libres est que son processus est, dans une large mesure, visible et enregistré. Une étude des archives des projets (en particulier ceux qui ont une forte composante de conception d'interfaces comme GNOME, KDE et Mozilla) permettra de vérifier les affirmations et les hypothèses avancées ici, ainsi que de découvrir une compréhension plus riche de la nature des discussions actuelles sur l'utilisabilité et des travaux de développement. Voici quelques exemples de questions : Comment les experts en IHM participent-ils avec succès aux projets de logiciels libres ? certains types de problèmes d'utilisabilité figurent-ils de manière disproportionnée dans les discussions et les efforts de développement ? et qu'est-ce qui distingue les projets de logiciels libres particulièrement innovants dans leurs fonctionnalités et leurs conceptions d'interface ?</p>

<p>Les approches décrites dans la section précédente doivent faire l'objet d'un examen plus approfondi et même d'une expérimentation pour voir si elles peuvent être utilisées dans des projets de logiciels libres, sans perturber les facteurs qui rendent le développement traditionnel de logiciels libres centré sur les fonctionnalités si efficace. Ces approches ne sont pas nécessairement limitées aux logiciels libres ; plusieurs d'entre elles peuvent être appliquées à des logiciels propriétaires. En effet, les idées issues de l'ingénierie de l'utilisabilité à rabais et de la conception participative sont nées du développement de meilleurs logiciels propriétaires. Cependant, elles peuvent être encore plus appropriées pour le développement de logiciels libres dans la mesure où elles s'appuient sur les points forts d'une communauté de développeurs bénévoles qui discutent ouvertement.</p>

<p>La plupart des recherches sur les IHM se sont concentrées sur les activités préalables à la publication qui informent la conception et relativement peu sur les techniques postérieures à la publication (Hartson et Castillo, 1998 ; Smilowitz et al., 1994). Il est intéressant de noter que la conception participative est un domaine à part entière alors que l'utilisation participative est généralement rapidement dépassée par les manuels IHM. Ainsi, le développement de logiciels libres ne doit pas se contenter de rattraper le retard pris par le monde commercial, mais peut potentiellement innover en explorant la manière d'impliquer les utilisateurs finaux dans la reconception ultérieure. Plusieurs appels ont été lancés dans la littérature (Shneiderman 2002 ; Lieberman et Fry, 2001 ; Fischer, 1998) pour que les utilisateurs participent activement au développement de logiciels au-delà des activités de conception standard centrées sur l'utilisateur (telles que les tests d'utilisablilité, l'évaluation des prototypes et l'observation du travail sur le terrain). Il est à noter que ces commentaires semblent ignorer que cette participation a déjà lieu dans les projets de logiciels libres.</p>

<p>Raymond (1998) commente que “le débogage est parallélisable”, nous pouvons ajouter à cela que les rapports, les analyses et les tests d'utilisabilité sont également parallélisables. Cependant, certains aspects de la conception de l'utilisabilité ne semblent pas être aussi facilement parallélisables. Nous pensons que ces questions devraient faire l'objet de recherches et de développements futurs, afin de comprendre comment elles ont fonctionné dans des projets réussis et de concevoir et tester des mécanismes technologiques et organisationnels pour améliorer la parallélisation future. En particulier, les travaux futurs devraient chercher à examiner si les questions identifiées dans ce document sont de nature historique (c'est-à-dire qu'elles découlent de l'ascendance particulière du développement du logiciel libre) ou si elles sont nécessairement liées au modèle de développement du logiciel libre.</p>

<h2 id="conclusion">Conclusion</h2>

<p>L'amélioration de l'utilisabilité des logiciels libres ne signifie pas nécessairement que ces logiciels remplaceront les logiciels propriétaires sur le bureau ; de nombreux autres facteurs entrent en jeu, comme l'inertie, le soutien, la législation, les systèmes existants, etc. Toutefois, l'amélioration de l'utilisabilité est une condition nécessaire à une telle diffusion. Nous pensons que ce document est la première discussion détaillée de ces questions dans la littérature.</p>

<p>Lieberman et Fry (2001) prévoient que “l'interaction avec les logiciels bogués sera une activité coopérative de résolution de problèmes entre l'utilisateur final, le système et le développeur”. Pour certains développeurs de logiciels libres, c'est déjà vrai, l'extension de cette situation à (potentiellement) tous les utilisateurs finaux du système marquerait un changement significatif dans les pratiques de développement de logiciels.</p>

<p>Il existe de nombreuses techniques IHM qui peuvent être adoptées facilement et à moindre coût par les développeurs de logiciels libres. En outre, plusieurs approches semblent particulièrement bien adaptées à une communauté d'utilisateurs et de développeurs en réseau distribué. Si les projets à source ouverte peuvent fournir un cadre simple permettant aux utilisateurs de fournir des informations non techniques sur les logiciels aux développeurs, ils peuvent alors tirer parti de l'éthique participative et la promouvoir parmi leurs utilisateurs.</p>

<p>Raymond (1998) a proposé que “si l'on a suffisamment de yeux, tous les bogues sont superficiels”. La communauté traditionnelle du logiciel libre peut ne pas être le bon type d'yeux pour voir les bogues d'utilisation. Cependant, il se peut qu'en encourageant une plus grande implication des experts en ergonomie et des utilisateurs finaux, il soit possible que, si l'on dispose de suffisamment de rapports d'expérience utilisateur, tous les problèmes d'ergonomie soient peu profonds. En engageant davantage les utilisateurs types dans le processus de développement, les projets de logiciels libres peuvent créer une communauté de développement en réseau qui peut faire pour l'utilisabilité ce qu'elle a déjà fait pour la fonctionnalité et la fiabilité.</p>

<h2 id="about-the-authors">About the Authors</h2>

<p>David M. Nichols is a lecturer in the Department of Computer Science at the University of Waikato, Hamilton, New Zealand.
E-mail: dmn@cs.waikato.ac.nz
Direct comments to dmn@cs.waikato.ac.nz</p>

<p>Michael B. Twidale is an associate professor in the Graduate School of Library and Information Science (GSLIS) at the University of Illinois at Urbana-Champaign.
E-mail: twidale@uiuc.edu</p>

<h2 id="acknowledgements">Acknowledgements</h2>

<p>We would like to thank several people for valuable discussions and comments about this topic: Damon Chaplin, Dave Dubin, Ian Murdock, Havoc Pennington, Walt Scacchi, Matthew Thomas, Stuart Yeates, the GSLIS writing group at UIUC, the HCI Group in the Department of Computer Science at the University of Waikato and many people who commented via Slashdot.</p>

<p>#<a href="https://write.as/troll/tag:Notes" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Notes</span></a></p>
<ol><li>Raymond and Steele, 1991, p. 364.</li>
<li>Feller and Fitzgerald, 2002, p. 114.</li>
<li>Feller and Fitzgerald, 2002, p. 139.</li>
<li>Feller and Fitzgerald, 2002, p. 85.</li>
<li>Feller and Fitzgerald, 2002, p. 101.</li>
<li>Nielsen, 1993, p. 12.</li>
<li>Feller and Fitzgerald, 2002, p. 93; Raymond, 1998.</li>
<li>A Bugzilla comment at <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=89907#c14" rel="nofollow">http://bugzilla.mozilla.org/show_bug.cgi?id=89907#c14</a>.</li>
<li>Shneiderman, 2002, p. 29.</li></ol>

<h2 id="references">References</h2>

<p>Athena, 2001. “Usability Testing of Athena User Interface,” MIT Information Systems, at <a href="http://web.mit.edu/is/usability/aui/" rel="nofollow">http://web.mit.edu/is/usability/aui/</a>, accessed 28 November 2002.</p>

<p>Brian Behlendorf, 1999. “Open source as a business strategy,” In: M. Stone, S. Ockman, and C. DiBona (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O'Reilly &amp; Associates, pp. 149-170, and at <a href="http://www.oreilly.com/catalog/opensources/book/brian.html" rel="nofollow">http://www.oreilly.com/catalog/opensources/book/brian.html</a>, accessed 28 November 2002.</p>

<p>Calum Benson, Adam Elman, Seth Nickell, and Colin Z. Robertson, 2002. “GNOME Human Interface Guidelines 1.0,” The GNOME Usability Project, at <a href="http://developer.gnome.org/projects/gup/hig/1.0/" rel="nofollow">http://developer.gnome.org/projects/gup/hig/1.0/</a>, accessed 10 October 2002.</p>

<p>Sebastien Biot, 2002. “KDE Usability — First Steps,” KDE Usability Project, at <a href="http://usability.kde.org/activity/testing/firststeps/" rel="nofollow">http://usability.kde.org/activity/testing/firststeps/</a>, accessed 28 November 2002.</p>

<p>José C. Castillo, H. Rex Hartson, and Deborah Hix, 1998. “Remote Usability Evaluation: Can Users Report Their Own Critical Incidents?” Proceedings of the Conference on Human Factors on Computing Ssytems (CHI'98): Summary. New York: ACM Press, pp. 253-254.</p>

<p>Andy Crabtree, David M. Nichols, Jon O'Brien, Mark Rouncefield, and Michael B. Twidale, 2000. “Ethnomethodologically Informed Ethnography and Information System Design,” Journal of the American Society for Information Science, volume 51, number 7, pp. 666-682. <a href="http://dx.doi.org/10.1002/(SICI)1097-4571(2000)51:7" rel="nofollow">http://dx.doi.org/10.1002/(SICI)1097-4571(2000)51:7</a>666::AID-ASI83.0.CO;2-5</p>

<p>Michael A. Cusmano and Richard W. Selby, 1995. Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. New York: The Free Press.</p>

<p>Debian, 2002. Debian GNU/Linux, at <a href="http://www.debian.org" rel="nofollow">http://www.debian.org</a>, accessed 28 November 2002.</p>

<p>Susanne Eklund, Michal Feldman, Mary Trombley, and Rashmi Sinha, 2002. “Improving the Usability of Open Source Software: Usability Testing of StarOffice Calc,” presented at the Open Source Meets Usability Workshop, Conference on Human Factors in Computer Systems (CHI 2002), Minneapolis, Minn., at <a href="http://www.sims.berkeley.edu/~sinha/opensource.html" rel="nofollow">http://www.sims.berkeley.edu/~sinha/opensource.html</a>, accessed 28 November 2002.</p>

<p>Joseph Feller and Brian Fitzgerald, 2002. Understanding Open Source Software Development. London: Addison-Wesley.</p>

<p>Joseph Feller and Brian Fitzgerald, 2000. “A Framework Analysis of the Open Source Software Development Paradigm,” In: W.J. Orlikowski, P. Weill, S. Ang, H.C. Krcmar, and J.I. DeGross (editors). Proceedings of the 21st Annual International Conference on Information Systems, Brisbane, Queensland, Australia, pp. 58-69.</p>

<p>Gerhard Fischer, 1998. “Seeding, Evolutionary Growth and Reseeding: Constructing, Capturing and Evolving Knowledge in Domain-Oriented Design Environments,” Automated Software Engineering, volume 5, number 4, pp. 447-464. <a href="http://dx.doi.org/10.1023/A:1008657429810" rel="nofollow">http://dx.doi.org/10.1023/A:1008657429810</a></p>

<p>Nancy Frishberg, Anna Marie Dirks, Calum Benson, Seth Nickell, and Suzanna Smith, 2002. “Getting to Know You: Open Source Development Meets Usability,” Extended Abstracts of the Conference on Human Factors in Computer Systems (CHI 2002). New York: ACM Press, pp. 932-933.</p>

<p>Alexander Hars and Shaosong Ou, 2001. “Working for Free? — Motivations of Participating in Open Source Projects,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press, pp. 2284-2292.</p>

<p>H. Rex Hartson and José C. Castillo, 1998. “Remote Evaluation for Post-Deployment Usability Improvement,” Proceedings of the Conference on Advanced Visual Interfaces (AVI'98). New York: ACM Press, pp. 22-29.</p>

<p>H. Rex Hartson, José C. Castillo, John Kelso, and Wayne C. Neale, 1996. “Remote Evaluation: The Network as an Extension of the Usability Laboratory,” Proceedings of the Conference on Human Factors in Computing Systems (CHI'96). New York: ACM Press, pp. 228-235.</p>

<p>David M. Hilbert and David F. Redmiles, 2001. “Large-Scale Collection of Usage Data to Inform Design,” In: M. Hirose (editor). Human-Computer Interaction — INTERACT'01: Proceedings of the Eighth IFIP Conference on Human-Computer Interaction, Tokyo, Japan, pp. 569-576.</p>

<p>David M. Hilbert and David F. Redmiles, 2000. “Extracting Usability Information from User Interface Events,” ACM Computing Surveys, volume 32, number 4, pp. 384-421. <a href="http://dx.doi.org/10.1145/371578.371593" rel="nofollow">http://dx.doi.org/10.1145/371578.371593</a></p>

<p>Melody Y. Ivory and Marti A. Hearst, 2001. “The State of the Art in Automated Usability Evaluation of User Interfaces,” ACM Computing Surveys, volume 33, number 4, pp. 470-516. <a href="http://dx.doi.org/10.1145/503112.503114" rel="nofollow">http://dx.doi.org/10.1145/503112.503114</a></p>

<p>Richard Jacques and Herman Savastano, 2001. “Remote vs. Local Usability Evaluation of Web Sites,” In: J. Vanderdonckt, A. Blandford, and A. Derycke (editors). Proceedings of Joint AFIHM-BCS Conference on Human Computer Interaction (IHM-HCI'2001), volume 2. Toulouse: Cépaduès-Editions, pp. 91-92.</p>

<p>KDE Usability, 2002. KDE Usability Project, at <a href="http://usability.kde.org" rel="nofollow">http://usability.kde.org</a>, accessed 28 November 2002.</p>

<p>Morten Kyng and Lars Mathiassen (editors), 1997. Computers and Design in Context. Cambridge, Mass.: MIT Press.</p>

<p>Josh Lerner and Jean Tirole, 2002. “Some Simple Economics of Open Source,” Journal of Industrial Economics, volume 50, number 2, pp. 197-234. <a href="http://dx.doi.org/10.1111/1467-6451.00174" rel="nofollow">http://dx.doi.org/10.1111/1467-6451.00174</a></p>

<p>Henry Lieberman and Christopher Fry, 2001. “Will Software Ever Work?” Communications of the ACM, volume 44, number 3, pp. 122-124. <a href="http://dx.doi.org/10.1145/365181.365236" rel="nofollow">http://dx.doi.org/10.1145/365181.365236</a></p>

<p>Rohit Mahjan and Ben Shneiderman, 1997. “Visual and Text Consistency Checking Tools for Graphical User Interfaces,” IEEE Transactions on Software Engineering, volume 23, number 11, pp. 722-735. <a href="http://dx.doi.org/10.1109/32.637386" rel="nofollow">http://dx.doi.org/10.1109/32.637386</a></p>

<p>Stephen Manes, 2002. “Linux Gets Friendlier,” Forbes (10 June), pp. 134-136.</p>

<p>Mozilla, 2002. Mozilla Project, at <a href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>, accessed 28 November 2002.</p>

<p>Kamiyo Nakakoji, Yasuhiro Yamamoto, Yoshiyuki Nishinaka, Kouichi Kishida, and Yunwen Ye , 2002. “Evolution Patterns of Open-Source Software Systems and Communities,” Proceedings of the Workshop on Principles of Software Evolution, International Conference on Software Engineering. New York: ACM Press, pp. 76-85.</p>

<p>David M. Nichols, Kirsten Thomson, and Stuart A. Yeates, 2001. “Usability and Open Source Software Development,” In: E. Kemp, C. Phillips, Kinshuck, and J. Haynes (editors). Proceedings of the Symposium on Computer Human Interaction. Palmerston North, New Zealand: SIGCHI New Zealand, pp. 49-54.</p>

<p>Seth Nickell, 2001. “Why GNOME Hackers Should Care about Usability,” GNOME Usability Project, at <a href="http://developer.gnome.org/projects/gup/articles/why_care/" rel="nofollow">http://developer.gnome.org/projects/gup/articles/why_care/</a>, accessed 28 November 2002.</p>

<p>Jacob Nielsen, 1993. Usability Engineering. Boston: Academic Press.</p>

<p>Donald A. Norman and Stephen W. Draper (editors), 1986. User Centered System Design: New Perspectives on Human-Computer Interaction. Hillsdale, N.J.: Lawrence Erlbaum Associates.</p>

<p>Tim O'Reilly, 1999. “Lessons from Open-Source Software Development,” Communications of the ACM, volume 42, number 4, pp. 32-37. <a href="http://dx.doi.org/10.1145/299157.299164" rel="nofollow">http://dx.doi.org/10.1145/299157.299164</a></p>

<p>Eric S. Raymond, 1999. “The revenge of the hackers,” In: M. Stone, S. Ockman, and C. DiBona (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O'Reilly &amp; Associates, pp. 207-219, and at <a href="http://www.oreilly.com/catalog/opensources/book/raymond2.html" rel="nofollow">http://www.oreilly.com/catalog/opensources/book/raymond2.html</a>, accessed 28 November 2002.</p>

<p>Eric S. Raymond, 1998. “The Cathedral and the Bazaar,” First Monday, volume 3, number 3 (March), at <a href="http://firstmonday.org/issues/issue3_3/raymond/" rel="nofollow">http://firstmonday.org/issues/issue3_3/raymond/</a>, accessed 28 November 2002.</p>

<p>Eric S. Raymond and Guy L. Steele, 1991. The New Hacker's Dictionary. Cambridge, Mass.: MIT Press.</p>

<p>Walt Scacchi, 2002. “Understanding the Requirements for Developing Open Source Software Systems,” IEE Proceedings — Software, volume 148, number 1, pp. 24-39. <a href="http://dx.doi.org/10.1049/ip-sen:20020202" rel="nofollow">http://dx.doi.org/10.1049/ip-sen:20020202</a></p>

<p>Jean Scholtz, 2001. “Adaptation of Traditional Usability Testing Methods for Remote Testing,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press.</p>

<p>Jean Scholtz, 1999. “A Case Study: Developing a Remote, Rapid, and Automated Usability Testing Methodology for On-Line Books,” Proceedings of the 32nd Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press.</p>

<p>Ben Shneiderman, 2002. Leonardo's Laptop: Human Needs and New Computing Technologies. Cambridge, Mass.: MIT Press.</p>

<p>Elissa D. Smilowitz, Michael J. Darnell, and Alan E. Benson, 1994. “Are we Overlooking Some Usability Testing Methods? A Comparison of Lab, Beta, and Forum Tests,” Behaviour &amp; Information Technology, volume 13, numbers 1 &amp; 2, pp. 183-190.</p>

<p>Suzanna Smith, Dave Engen, Andrea Mankoski, Nancy Frishberg, Nils Pedersen, and Calum Benson, 2001. “GNOME Usability Study Report,” Sun GNOME Human Computer Interaction (HCI), Sun Microsystems, Inc., at <a href="http://developer.gnome.org/projects/gup/ut1_report/report_main.html" rel="nofollow">http://developer.gnome.org/projects/gup/ut1_report/report_main.html</a>, accessed 28 November 2002.</p>

<p>Bruce Sterling, 2002. “A Contrarian Position on Open Source.” presented at the O'Reilly Open Source Convention, Sheraton San Diego Hotel and Marina (22-26 July), San Diego, Calif., at <a href="http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html" rel="nofollow">http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html</a>, accessed 28 November 2002.</p>

<p>John C. Thomas and Wendy A. Kellogg, 1989. “Minimizing Ecological Gaps in Interface Design,” IEEE Software, volume 6, number 1, pp. 77-86. <a href="http://dx.doi.org/10.1109/52.16905" rel="nofollow">http://dx.doi.org/10.1109/52.16905</a></p>

<p>Matthew Thomas, 2002. “Why Free Software Usability Tends to Suck,” at <a href="http://mpt.phrasewise.com/discuss/msgReader$173" rel="nofollow">http://mpt.phrasewise.com/discuss/msgReader$173</a>, accessed 28 November 2002.</p>

<p>Peter Thomas and Robert D. Macredie, 2002. “Introduction to the New Usability,” ACM Transactions on Computer-Human Interaction, volume 9, number 2, pp. 69-73. <a href="http://dx.doi.org/10.1145/513665.513666" rel="nofollow">http://dx.doi.org/10.1145/513665.513666</a></p>

<p>Jennifer A. Thompson and Robert C. Williges, 2000. “Web-based Collection of Critical Incidents during Remote Usability Evaluation,” Proceedings of the 14th Triennial Congress of the International Ergonomics Association and the 44th Annual Meeting of the Human Factors and Ergonomics Society (IEA 2000/HFES 2000), Santa Monica: Human Factors and Ergonomics Society, volume 6, pp. 602-605.</p>

<p>Peter Trudelle, 2002. “Shall We Dance? Ten Lessons Learned from Netscape's Flirtation with Open Source UI Development,” presented at the Open Source Meets Usability Workshop, Conference on Human Factors in Computer Systems (CHI 2002), Minneapolis, Minn., at <a href="http://www.iol.ie/~calum/chi2002/peter_trudelle.txt" rel="nofollow">http://www.iol.ie/~calum/chi2002/peter_trudelle.txt</a>, accessed 28 November 2002.</p>

<p>Tom Tullis, Stan Fleischman, Michelle McNulty, Carrie Cianchette, and Margaret Bergel, 2002. “An Empirical Comparison of Lab and Remote Usability Testing of Web Sites,” presented at the Usability Professionals Association Conference (July), Orlando, Fla.</p>

<p>Hal R. Varian, 1993. “Economic Incentives in Software Design,” Computational Economics, volume 6, numbers 3-4, pp. 201-217.</p>

<p>Marco A.A. Winckler, Carla M.D.S. Freitas, and José Valdeni de Lima, 1999. “Remote Usability Testing: A Case Study,” In: J. Scott and B. Dalgarno (editors). Proceedings of the Conference of the Computer Human Interaction Special Interest Group of the Ergonomics Society of Australia (OzCHI'99), Wagga Wagga, New South Wales, Australia, pp. 193-195.</p>

<h2 id="editorial-history">Editorial history</h2>

<p>Paper received 9 December 2002; accepted 24 December 2002.</p>