Master
Reference
The Black Square Problem. Analyse et développement d'un logiciel dédié
WAEGER, Sébastien
Abstract
Le Black Square Problem est un exercice réalisé dans le domaine du design. Ce dernier demande un haut niveau de cognition, ce qui peut impliquer des problématiques lorsqu'il est réalisé informatiquement. Cette étude s'intéresse à ces problématiques et en tient compte par la création d'un logiciel dédié. Six étudiants de la Webster University suivant un cours de design ont participé à cette étude, deux dans le cadre d'une analyse concurrentielle et quatre lors d’un test utilisateur du logiciel dédié. Le logiciel est développé sur le framework Electron avec pour principaux langages de programmation le JavaScript et HTML/CSS. Ce dernier a été développé en se basant sur l'analyse des besoins et les préconisations de la littérature quant à l'ergonomie, les modèles d'acceptation utilisateur et de dynamique d'affect. Les tests utilisateurs sur le logiciel dédié ont montré une évaluation générale plus élevée que la moyenne dans les dimensions mesurées de facilité d'utilisation, facilité d'apprentissage, utilité et satisfaction. Un logiciel, dédié et réduit des fonctionnalités [...]
WAEGER, Sébastien. The Black Square Problem. Analyse et développement d’un logiciel dédié. Master : Univ. Genève, 2017
Available at:
http://archive-ouverte.unige.ch/unige:96280
Disclaimer: layout of this document may differ from the published version.
1 / 1
The Black Square Problem – Analyse et développement d’un logiciel dédié
MÉMOIRE REALISE EN VUE DE L'OBTENTION DE LA MAITRISE UNIVERSITAIRE EN SCIENCES ET TECHNOLOGIES DE L'APPRENTISSAGE ET DE LA FORMATION
PAR Sebastien Waeger
DIRECTEUR DE MEMOIRE Kalliopi Benetos
JURY
Daniel Schneider Mattia Fritz
GENEVE, le 2 Juin 2017
UNIVERSITE DE GENEVE
FACULTE DE PSYCHOLOGIE ET DES SCIENCES DE L'EDUCATION
ii
Un grand merci à Kalli, ma directrice de mémoire, pour ses conseils, sa lecture et l’accueil dans sa classe au sein de la Webster University.
A Pedro, mon partenaire, pour son soutien infaillible même lorsque je rêvais de carrés, mais aussi pour ses relectures, ses tests du logiciel et sa patience.
A Ariane et Roger, mes parents, pour leur support tout au long de ce master et des années précédentes
A Alexandra pour nos échanges et nos partages, ainsi que pour les innombrables virgules.
Et enfin, à Messieurs Thalès et Pythagore qui ont grandement facilité la rotation de tous ces carrés.
iii
I. Résumé
Le Black Square Problem est un exercice réalisé dans le domaine du design. Ce dernier demande un haut niveau de cognition, ce qui peut impliquer des problématiques lorsqu'il est réalisé informatiquement. Cette étude s'intéresse à ces problématiques et en tient compte par la création d'un logiciel dédié. Six étudiants de la Webster University suivant un cours de design ont participé à cette étude, deux dans le cadre d'une analyse concurrentielle et quatre lors d’un test utilisateur du logiciel dédié. Le logiciel est développé sur le framework Electron avec pour principaux langages de programmation le JavaScript et HTML/CSS. Ce dernier a été développé en se basant sur l'analyse des besoins et les préconisations de la littérature quant à l'ergonomie, les modèles d'acceptation utilisateur et de dynamique d'affect. Les tests utilisateurs sur le logiciel dédié ont montré une évaluation générale plus élevée que la moyenne dans les dimensions mesurées de facilité d'utilisation, facilité d'apprentissage, utilité et satisfaction. Un logiciel, dédié et réduit des fonctionnalités superflues, est donc plus adapté à une utilisation spécifique à un cadre précis.
Mots-clés : Design graphique ; Black Square Problem ; Développement de logiciel ; Electron
iv
II. Table des matières
The Black Square Problem – Analyse et développement d’un logiciel dédié ... i
I. Résumé ... iii
II. Table des matières ... iv
1 Introduction ... 1
2 Cadre théorique... 3
2.1 Création, cognition et affect ... 3
2.2 Acceptation utilisateur ... 5
2.3 Expérience utilisateur ... 6
2.4 Critères ergonomiques ... 6
2.5 Charte de design ... 8
2.6 Evaluation d’interface ... 9
3 Problématique et hypothèses ...11
4 Méthode et développement ...12
4.1 Public cible ...12
4.2 Etat de l’art ...12
4.3 Analyse des besoins ...12
4.4 Choix du langage de programmation ...13
4.5 Charte de design ...14
4.6 Méthodologie de codage et développement ...15
4.7 Tests utilisateurs ...17
5 Résultats de l’analyse des besoins ...19
5.1 Cas d’utilisation et analyse des besoins ...19
6 Résultats du développement ...22
6.1 Choix du langage de programmation ...22
6.2 Icônes et fonctionnalités liées ...22
6.3 Curseurs et fonctionnalités liées ...24
6.4 Palette de couleur ...24
v
6.5 Front-End ...26
6.6 Back-End ...29
7 Résultats des tests utilisateurs ...32
7.1 Tests utilisateurs ...32
7.2 Remédiations ...34
8 Discussion ...37
9 Bibliographie ...41
10 Annexes...43
10.1 Annexe 1 : Questionnaire USE (Lund, 2001) ...43
10.2 Annexe 2 : Grille d'entretien ...45
10.3 Annexe 3 : Cas d'utilisation ...46
10.4 Annexe 4 : Table des mots réservés en français et en anglais ...51
10.5 Annexe 5 : Résultats détaillés aux questionnaires USE ...52
1
1 Introduction
« La vision implique plus que voir ou être montré » (Dondis, 1974). Cette citation illustre bien le principe de la communication visuelle. Comment transmettre une émotion à travers un design graphique? Quelles sont les règles implicites qui font qu’un design est agréable à regarder ou va simplement intéresser l’utilisateur? Des études empiriques ont tenté de répondre à ce type de questions, démontrant par exemple que les notions d’équilibre, de contraste et d’unité notamment, sont importantes (Kimball, 2013). La problématique réside cependant dans le fait que, ces dernières sont uniquement des notions. Comment ces notions peuvent-elles être enseignées à quelqu’un qui souhaite apprendre la communication visuelle?
La communication visuelle n’est donc pas une « science » régie par des lois et des règles définies, gravées dans la roche. Elle dépend, entre autre, de l’appréciation et de la sensibilité de celui qui regarde. La communication visuelle n’est par conséquences pas innée. Cet art requiert une acquisition de compétences, ce qui peut se faire uniquement à travers l’entraînement.
Comprendre le type de connaissances et les processus cognitifs à l’origine de la capacité de communiquer par le visuel, permet de connaitre le meilleur moyen d’acquérir les compétences nécessaires pour communiquer avec les médias visuels. Un modèle permettant de classifier les connaissances pourrait être utilisé dans cette démarche. En 1956, Benjamin Bloom propose une classification des niveaux d’acquisition, en hiérarchisant et segmentant les objectifs éducationnels principaux présents en pédagogie. Selon la taxonomie de Bloom révisée (Anderson et al., 2000), aborder les concepts du design et comprendre certaines relations pouvant être tissées entre eux, sont des connaissances pouvant être qualifiées comme des connaissances de type conceptuelles. Le processus de création, quant à lui, peut être désigné comme itératif (Mayeux, 2016), provenant du latin iter signifiant chemin. Ceci implique, que lors d’une création, un chemin est emprunté, pouvant amener la personne qui le suit à se poser des questions sur sa réalisation, par exemple « Comment ce que je crée va être interprété ? ». Une autre dimension émerge donc au sein de ce processus, l’acquisition de connaissances de type métacognitives, toujours selon la taxonomie de Bloom révisée. Les processus cognitifs pouvant être associés à cette réalisation sont l’inférence et la création, processus considérés comme activité cognitives de haut niveau.
En 1991, Wilde & Wilde proposent une série d’exercices permettant d’entrainer les notions de communication visuelle, dans leur ouvrage intitulé Visual Literacy (Wilde, 1991). Ces exercices se présentent majoritairement sous la forme d’un brainstorming, qui doit être réalisé par l’apprenant. L’apprenant se voit confier une tâche, se rapportant à un concept du design ou de la communication visuelle et doit réaliser plusieurs compositions différentes sur le sujet
2
choisi. Parmi les exercices proposés se trouve par exemple le Black and White Problem, consistant à travailler sur les espaces négatifs. Le but de celui-ci, est de réaliser une composition en noir et blanc, en dessinant uniquement les espaces vides entourant l’objet. Un autre exemple d’exercice est le Circle, Square, triangle problem, consistant à entrainer la simplicité, c’est-à-dire transmettre un maximum de sens avec des figures les plus minimalistes possibles. Ce dernier consiste à créer des designs simples à partir d’une forme, un cercle, un carré ou un triangle.
Ce mémoire quant à lui, se focalise sur le tout premier exercice présenté par Wilde & Wilde (1991), le Black Square Problem. Cet exercice, en apparence simple, consiste à réaliser des compositions à l’aide de quatre carrés noirs uniquement. Le but est de dessiner une image graphique exprimant au mieux un mot, ou une émotion. Le challenge est de réussir à transformer ces carrés, « formant une palette limitée pour exprimer divers mots […], en les étendant à un langage plus compréhensif grâce aux principes du design » [traduction libre]
(Wilde, 1991). Cet exercice est initialement prévu pour être réalisé sous format papier.
Cependant, les designers travaillant sur ordinateur dès le début de leur formation, la modalité papier laisse souvent la place à la réalisation de cet exercice sous sa version numérique. Les problématiques pouvant en découler vont être discutées dans ce mémoire. Un logiciel dédié à la réalisation de cet exercice est aussi développé afin de tenter de répondre aux problématiques abordées.
Figure 1 : Exemple de composition réalisée dans le cadre de l'exercice du Black Square Problème, tirée de l’ouvrage Visual Literacy (Wilde, 1991)
3
2 Cadre théorique
Lorsqu'un utilisateur emploie un logiciel, il existe une série de variables pouvant jouer un rôle dans le fait que l'utilisateur apprécie son expérience, et que le logiciel lui apporte ce dont il a besoin. Dans le cadre étudié ici, l'utilisateur est aussi un apprenant. Il doit acquérir des compétences demandant un niveau de cognition élevé, en réalisant une composition répondant au Black Square Problem (Anderson et al., 2000). Pour que cette tâche produise un résultat utile et intéressant, l'apprenant doit être maintenu dans un équilibre entre cognition et affect (Isen, Daubman, & Nowicki, 1987).
Afin de garantir que cet équilibre ne soit pas perturbé, il faut éviter à l'apprenant de rencontrer des obstacles, des incidents, ou encore qu'il doive faire face à des réactions inattendues de la part du logiciel (Bastien & Scapin, 1995). Si un de ces cas venait à apparaitre, l'utilisateur entrerait alors dans un état d'affect négatif, déséquilibrant la relation cognition-affect (D’Mello
& Graesser, 2012). Ceci a pour effet d'axer la cognition de l'apprenant sur des activités annexes et parallèles, comme par exemple en accordant une partie de son attention à l'utilisation de l'outil. Cette attention ne peut, dès lors, plus être assignée à la tâche qui devrait être réalisée (Spering, Wagener, & Funke, 2005). Même si ce climat propice à l'apprentissage est maintenu, cela ne garantit pas que l'apprenant utilise le logiciel. L'utilisation et la réutilisation provient d'une variable appelée acceptation du logiciel par l'utilisateur (Davis, Bagozzi, & Warshaw, 1989). Cette dernière est influencée par l'expérience utilisateur, combinaison des deux composantes suivantes. Tout d'abord, une composante rationnelle, qui est représentée par la facilité d'utilisation du logiciel, mais aussi son utilité perçue. Ensuite, une composante émotionnelle, qui est la satisfaction de l'utilisateur (Davis et al., 1989).
Si ces points sont pris en compte lors du développement du logiciel dédié à la réalisation de l'exercice du Black Square Problem, l'effet sera le suivant : l'utilisateur a la possibilité de focaliser ses ressources cognitives sur la réalisation de sa tâche, car le logiciel n'agit pas en tant que barrière à la réalisation de sa tâche, mais comme un facilitateur à l'exécution.
2.1 Création, cognition et affect
Chaque apprentissage, quel qu’il soit, requiert des conditions favorables, afin qu’il puisse se dérouler de manière optimale. Ces conditions, dans le cadre d’une activité cognitive de haut niveau tel que la création d’une composition (Anderson et al., 2000), comprennent un état d’équilibre, dans lequel cognition et affect sont dans une conjoncture stable (D’Mello &
Graesser, 2012). Cet état d’équilibre, ses perturbations potentielles ainsi que leurs conséquences, ont été mis en relation au sein d’un même modèle, présenté dans la Figure 2.
4
Figure 2 : Modèle observé des dynamiques de l'affect dans une tâche de cognition élevée (D’Mello & Graesser, 2012)
Ce modèle postule que l’apprenant, qui se trouve dans un état d’équilibre propice à l’apprentissage, peut subir un déséquilibre cognitif ainsi que de la confusion. Ces derniers surviennent lorsque l’apprenant fait face à des anomalies, des obstacles aux buts, des contradictions ou encore des impasses. Si l’apprenant est en mesure de résoudre le problème qui se présente à lui, afin de revenir dans un état d’équilibre, c’est une simple gêne qui aura été occasionnée. Cependant, si la problématique ne peut pas être surmontée, voire même que d’autres obstacles s’y ajoutent, alors l’apprenant rentrera dans un affect de valence négative, la frustration. Cet état persistant peut même amener l’étudiant à un décrochage de la tâche.
La valence de l’affect, lorsqu’elle est négative, a donc un effet sur la performance. Certains chercheurs se sont intéressés à comprendre quels sont les conséquences de la valence de l’affect sur la cognition. Des expériences ont par exemple été menées sur l’influence d’un affect positif sur des tâches de résolution de problèmes faisant appel à de la créativité (Isen et al., 1987). Au cours de ces dernières, l’affect positif était induit par les chercheurs en montrant aux participants de courts films comiques, en leur offrant des boissons et de la nourriture, ou encore des petits cadeaux. Les résultats de ces tâches ont été comparés avec ceux obtenus sur des participants n’ayant pas subi d’induction d’affect, mais aussi avec une induction d’affect négatif. La comparaison de ces trois différentes modalités a démontré une corrélation entre la valence de l’affect et les résultats obtenus sur les tâches de résolution de problèmes faisant appel à la créativité, les participants de la modalité induction positive ayant des moyennes significativement plus élevées. D’autres études ont confirmé ces résultats (Spering et al., 2005), démontrant que les émotions négatives chez un apprenant, ont tendance à axer sa cognition sur la recherche et l’utilisation de l’information. Ces activités parallèles vont alors
5
avoir tendance à utiliser les ressources cognitives, qui ne peuvent donc plus être appliquées à une tâche de création de composition par exemple.
La relation entre affect et résolution de problème demandant de la créativité laisse penser qu’il est primordial de maintenir l’apprenant dans un état et un climat positif, concernant la création de logiciel lié à la réalisation d’un exercice de création de composition. Pour maintenir cet état et ce climat positif, il y a des points importants qui doivent être pris en compte lors de la réalisation dudit logiciel. Par exemple, l’acceptation utilisateur, permet à l’apprenant d’aborder le logiciel positivement, suivant le modèle d’acceptation de la technologie. Les obstacles provenant du logiciel ou encore l’ergonomie de ce dernier, influencent négativement les émotions de l’apprenant, s’il rencontre des incidents critiques, selon le modèle de D’Mello &
Graesser.
2.2 Acceptation utilisateur
Lorsque le sujet de l’acceptation utilisateur est abordé, il est courant d’entendre qu’un logiciel doit être « intuitif » et « facile à utiliser ». Ces deux notions présentent tout de même une problématique, elles sont trop imprécises. Cela ne permet pas d’en déduire des informations utiles pour la compréhension de l’acceptation utilisateur (Blair-Early & Zender, 2008). Mais quelles sont donc les variables qui influencent cette acceptation ? Comment assurer une bonne expérience à l’utilisateur, afin que celui-ci utilise le logiciel ? Le premier critère qui influencera l’utilisateur est la perception d’utilité, en d’autres termes, si l’utilisateur croit que le logiciel va pouvoir l’aider à réaliser la tâche qu’il veut effectuer. Le second critère ayant un effet sur l’utilisateur, est la perception de la facilité d’utilisation. L’utilisateur va implicitement mesurer la quantité d’effort qu’il doit fournir pour pouvoir utiliser le logiciel dans sa tâche (Davis, 1989). Le modèle TAM (Technology Acceptance Model) a permis de mettre en corrélation l’influence de ces deux variables, avec l’intention d’utiliser un système (Davis et al., 1989).
Cette articulation, exposée dans la Figure 3 met en évidence la relation entre perception d’utilité et intention utilisation.
Figure 3: Modèle d'acceptation de la technologie (Davis et al., 1989)
6
Une étude sur la validation d’un questionnaire (Davis, 1989) permettant de mesurer la perception d’utilité et la perception de facilité d’utilisation, a mis l’emphase sur le lien significatif entre certains paramètres et ces facteurs. Par exemple, le fait de pouvoir accomplir plus de travail (coeff. sat. = .91 sur l’utilité), de pouvoir l’accomplir plus rapidement (coeff. sat. = .79 sur l’utilité), l’effort à fournir pour être habile (coeff. sat. = .88 sur la facilité d’utilisation) ou encore l’effort mental durant l’utilisation (coeff. sat. = .76 sur la facilité d’utilisation). Cette étude ayant validé les caractéristiques psychométriques du questionnaire, il est alors possible de considérer les paramètres mesurés comme des axes pour le développement de logiciel.
2.3 Expérience utilisateur
En plus de l’utilité et de la facilité d’utilisation, il existe un autre critère non négligeable qui doit peser dans la balance du développement de logiciel : la satisfaction (Lund, 2001). Ces trois axes représentent ce qui pourrait être qualifié d’expérience utilisateur. Les normes ISO pour les interactions homme-système, définissent l’expérience utilisateur comme « la perception et les réponses d’une personne résultant de l’utilisation ou de l’utilisation anticipée d’un produit, système ou service » [traduction libre] (« User experience », 2016). Dès lors, l’utilisation d’un logiciel ou système n’est plus uniquement pragmatique et rationnelle, mais se dote d’une composante émotionnelle ressentie et anticipée par l’utilisateur.
Lund propose en 2001 le questionnaire USE (Usefulness, Satisfaction & Ease of use) permettant d’évaluer à la fois les composantes rationnelles et émotionnelles liées à l’utilisation d’un logiciel (Lund, 2001). Cette proposition regroupe les items les plus significatifs (sélection selon alpha de Cronbach) d’autres études réalisées séparément sur chacun des paramètres composant le USE. Selon l’auteur, ce questionnaire n’a pas été développé comme outil de diagnostic design ou ergonomique, mais comme méthode de priorisation des problématiques.
En addition, il devient aussi intéressant de chercher à comprendre, lors du développement, quels aspects du design d’un logiciel influenceraient les réponses aux items de ce questionnaire.
2.4 Critères ergonomiques
La notion d’utilité perçue d’un logiciel peut en réalité provenir de deux composantes. Il y a tout d’abord une part provenant du contexte, « le logiciel est-il adapté au besoin ?». La seconde part provient de l’utilité perçue lors de l’utilisation du logiciel et de ses fonctionnalités. Cette seconde composante est celle retrouvée dans la satisfaction et la facilité d’utilisation. Afin d’agir sur ces paramètres, il existe notamment une liste de critères ergonomiques initialement créés pour l’évaluation de l’ergonomie d’une interface homme-machine (Bastien & Scapin, 1993). Ces critères, mis en place par Bastien et Scapin, peuvent aussi être utilisés comme lignes directrices lors de la création et du développement de logiciel, afin de garantir, par
7
exemple, une homogénéité dans l’interface et les actions, un bon guidage des utilisateurs ou encore une réduction de la charge de travail nécessaire pour réaliser une tâche.
Tableau 1: Synthèse des critères ergonomiques (Bastien & Scapin, 1993)
En sus de ces critères, synthétisés dans le Tableau 1, les auteurs fournissent une justification pour chacun d’eux. Un certain nombre de recommandations émerge, en accord avec les modèles et théories précédemment mentionnés. Par exemple, le guidage, « facilitant l’apprentissage et l’utilisation du logiciel » joue un rôle capital dans le critère « facilité d’apprentissage » dans la théorie d’acceptation et d’utilisabilité. La lisibilité, quant à elle, est justifiée par la performance, car cette dernière est « accrue lorsque la présentation des informations à l’écran tient compte des caractéristiques cognitives et perceptive des utilisateurs ». La lisibilité, au sens de Bastien et Scapin, est donc en lien directe avec la réduction de la charge cognitive due à l’interface (Reeves et al., 2004), libérant ainsi des ressources pouvant être redirigée sur la tâche de création de composition.
Guidage Moyens mis en œuvre pour conseiller, orienter, informer et conduire l'utilisateur lors de ses interactions
Incitation Moyens mis ne œuvre pour la réalisation d'une action spécifique Groupement / Distinction Organisation visuelle des informations comprenant la localisation et le
format des informations
Feedback immédiat Réponse de l'interface conséquente à l'action de l'utilisateur Lisibilité Présentation de l'information bridant ou favorisant la lecture.
Notamment le format d'écriture, polices ou encore couleurs Charge de Travail Eléments de l'interface réduisant la charge perceptive ou mnésique Brièvté Limiter la lecture et le nombre d'étapes à franchir sur des éléments
individuel. Concision et actions minimales
Densité informationnelle Réduction de la charge perceptive pour un ensemble d'éléments Contrôle explicite Limitation des ambiguïtés et des erreurs
Actions explicites Relation entre le fonctionnement du l'application et les actions des utilisateurs
Contrôle utilisateur Contrôle du déroulement par l'utilisateur. Anticipation des actions et options appropriées
Adaptabilité Capacité du système à réagir selon le contexte, selon l'utilisateur Flexibilité Moyen mis à disposition des utilisateurs pour personnaliser l'interface Prise en compte de
l'expérience de l'utilisateur
Moyens mis en œuvre pour respecter le niveau d'expérience de l'utilisateur
Gestion des erreurs Moyens permettant d'éviter, réduire et corriger les erreurs Protection contre les erreurs Moyen permettant de détecter ou prévenir les erreurs d'entrée de
données ou commandes
Qualité des messages d'erreur Pertinence, facilité et exactitude des messages d'erreur
Correction des erreurs Moyens mis à disposition de l'utilisateur pour corriger ses erreurs Homogénéité / Cohérence Conservation des choix de conception dans des contextes identiques Signifiance des codes et
dénomination Adéquation entre l'objet et l'information
Compatibilité Accord entre les caractéristiques des utilisateurs et des tâches
8
2.5 Charte de design
Il existe des principes permettant de réaliser un bon design. Le terme « bon », dans ce contexte, fait référence à un design d’interface utilisateur, maintenant une certaine cohérence graphique et comportementale, tout en gardant en point de mire les critères ergonomiques.
Ces principes de design sont résumés dans des guidelines, proposées en par Hobart en 1995, qui, si elles sont respectées, permettent d’éviter les principales erreurs de design (Hobart, 1995). Ces guidelines peuvent être utilisées comme une méthode de création du fonctionnement (prototypage), antécédente à la création du logiciel en lui-même (programmation).
Un des premiers principes proposés est la gestion des icônes. Il est important que ces dernières reflètent des fonctions ou des informations, tout en maintenant une sémiotique non équivoque (Peraya, 1998). Les guidelines suggèrent de réaliser un tableau représentant les icônes, leurs fonctions et leurs sens.
Les mots, au même titre que les images, peuvent être porteurs d’une polysémie. Afin de conserver la clarté dans les interactions avec l’utilisateur, ils doivent être choisis avec précaution. Pour ce faire, Hobart conseille de créer une liste de mots réservés, qui dans le cadre d’une interface adaptative multilingue (personnalisation de la langue de l’interface) doit être traduite. Lors de la création, ces mots devront être utilisés en évitant d’utiliser, par exemple, des synonymes, afin de marquer la consistance.
Dans une même approche de consistance, le « look & feel » doit aussi être analysé. La palette de couleur, l’utilisation de couleurs identiques pour des éléments identiques, sont des points qui doivent être pris en compte lorsque l’interface est pensée.
Enfin, Hobart propose le Tableau 2 concernant l’utilisation des contrôles. Ces derniers sont les éléments visuels qui vont permettre à l’utilisateur d’interagir avec le logiciel. Le type de contrôle relatif au type d’action, ainsi que le nombre maximum de choix, sont décrits afin de garantir « une haute productivité, un taux d’erreur faible et un haut niveau de satisfaction » [traduction libre] (Hobart, 1995).
9
Tableau 2 : Guidelines pour l'utilisation des contrôles (Hobart, 1995)
Ces guidelines, en accord avec l’approche présentée au niveau de critères ergonomiques, proposent finalement la réalisation de cas d’utilisation. Ces derniers représenteront la globalité des interactions que l’utilisateur pourrait avoir avec le logiciel. Une fois décrits, ils seront une aide à la programmation, mais aussi au maintien de la cohérence et de l’ergonomie du logiciel.
2.6 Evaluation d’interface
Une fois un logiciel réalisé, il faut être en mesure de pouvoir vérifier que chacun des axes inhérents au développement a été respecté. Comme mentionné au chapitre 2.4, une grille de critères ergonomique peut être utilisée pour l’évaluation de l’interface d’un logiciel (Bastien &
Scapin, 1992, 1993). Une étude réalisée en 1995 par les créateurs de cette grille (Bastien &
Scapin, 1995), a démontré que seulement trois utilisateurs permettaient de faire apparaitre un peu plus de 80% des problèmes ergonomiques existant, comme le montre la Figure 4.
Figure 4 : Proportion moyenne de problèmes ergonomiques non découverts en fonction du nombre d'évaluateurs (Bastien & Scapin, 1995)
10
En addition, une autre étude a mis en avant trois niveaux de gravité lorsqu’un utilisateur rencontre un problème lors d’évaluation ergonomiques (Doubleday, Ryan, Springett, &
Sutcliffe, 1997). Ces niveaux de gravité, résumés et explicités dans le Tableau 3, pourront permettre par exemple, de prioriser les remédiations à effectuer.
Tableau 3 : Niveaux de gravité relatifs à un problème ergonomique (Doubleday et al., 1997)
Additionnés à la fréquence d’apparition desdits problèmes, le design du logiciel pourra être repensé afin de couvrir au mieux les besoins et les actions des utilisateurs.
Critique Empêche ou décourage l'achèvement de la tache
Sérieux Ralentit et force l'utilisateur à chercher une autre solution Léger Agace mais n'empêche pas la poursuite de la tâche
Gravité du problème
11
3 Problématique et hypothèses
L’exercice du Black Square Problem peut être réalisé selon plusieurs modalités. Initialement le choix était portée sur une version papier et crayon pour la réalisation d’une composition. La problématique principale de cette modalité vient de la difficulté à pouvoir modifier la composition. Une seconde méthode consisterait à utiliser du papier découpé. Cette méthode présente l’avantage de faciliter l’orientation et le placement des carrés, cependant les questions de modification de taille et de précision restent insolvables. L’utilisation de la troisième modalité, numérique, s’impose assez aisément grâce à ses nombreux avantages.
La personne réalisant la composition à plus de liberté, elle peut modifier sa composition, changer les tailles de ses carrés ou encore les déplacer, le tout sans altérer la notion de précision. Cette liberté prend une place importante au sein du processus itératif qu’est la création. Dès lors, la composition peut être construite.
Avec l’utilisation de la modalité numérique, de nouvelles problématiques tendent à apparaître.
Par exemple, l’utilisation d’un logiciel demande un certain apprentissage. Si l’interface de ce dernier n’est pas optimale, elle peut provoquer une certaine surcharge cognitive chez l’utilisateur ainsi qu’une perturbation de l’équilibre fragile affect-cognition, ce qui pourrait avoir comme conséquences de déplacer l’attention de la tâche vers l’outil, tout en réduisant la créativité requise à la création de composition. La question qui se pose alors est la suivante : L’utilisation d’une interface dédiée peut-elle réduire les interférences à l’acquisition de compétences en communication visuelle, développées dans l’exercice du Black Square Problem ? C’est à cette question que ce mémoire tentera de répondre, au travers du développement et du test d’un logiciel dédié.
12
4 Méthode et développement
4.1 Public cible
Le logiciel pour la réalisation de l’exercice du Black Square Problem développé dans le cadre de ce mémoire, s’adresse aux personnes voulant apprendre la communication visuelle. Ce public cible est assez vaste et peut comprendre des personnes de tous âges ou provenances, dès lors qu’ils entreprennent l’apprentissage de la communication visuelle. Les niveaux d’aise à l’utilisation d’un ordinateur peuvent aussi être variables. Les notions de communications visuelles sont apprises très tôt dans la formation de designer, car celles-ci sont une sorte de prérequis pour les futures apprentissages. L’aise informatique est donc dépendantes des expériences et pratiques précédent l’entrainement et le développement de ces nouvelles capacités.
4.2 Etat de l’art
Un état de l'art a été effectué, afin de comparer quelques logiciels pouvant être utilisés pour réaliser la tâche du Black Square Problem. Afin de comparer ces logiciels, ils ont été ouverts sans qu'aucun paramétrage particulier n'ait été effectué. Les informations récupérées au cours de cet état de l’art sont résumées dans le Tableau 4. Le nombre de barres d'outils à l'ouverture a été compté (entre 6 et 10). Le nombre de fonctionnalités présentes à l'écran a aussi été compté, nombre compris entre 30 et 80 fonctionnalités. Enfin, les possibilités de cacher les barres d'outils ou de personnaliser les fonctionnalités présentes à l'écran ont été étudiées.
Tableau 4 : Résumé des fonctionnalités visibles par défaut sur cinq logiciels
4.3 Analyse des besoins
Sur le marché, il existe un grand nombre de logiciels permettant de faire du dessin. Ces logiciels pourraient tous être utilisés pour réaliser l’exercice du Black Square Problem.
L’analyse des besoins, comme état de l’art, commence donc par une analyse de l’utilisation
13
d’un logiciel déjà existant, pour réaliser l’exercice (Brinck, Gergle, & Wood, 2001). Cette démarche permet de faire émerger des problématiques liées à l’utilisation d’un logiciel non- dédié. Une approche qualitative telle que cette dernière peut, par exemple, mettre en évidence quelles peuvent être les causes d’un déséquilibre affect-cognition. Ce déséquilibre est celui décrit au sein du modèle de dynamique de l’affect proposé par D’Mello & Graesser (2012).
L’analyse des besoins fait aussi fonction d’analyse de l’activité. Parmi la multiplicité des fonctionnalités pouvant être disponibles dans les logiciels dits concurrents, toutes ne sont pas utiles ou facilitantes pour la réalisation de l’exercice du Black Square Problem. L’observation de la réalisation de l’exercice à l’aide de logiciels déjà existants, permet donc de comprendre quels sont les besoins en termes de fonctionnalités.
Au sein de la Webster University, un cours de design graphique est dispensé chaque semestre. Les participants aux tests décrits dans cette méthodologie sont tous des étudiants suivant cette option au sein de la faculté. Deux étudiants de la Webster University qui suivent ce cours ont été les participants de cette analyse. Dans le cadre de leur cursus au sein de la faculté, l’exercice du Black Square Problem leur a été proposé. Ces derniers devaient créer deux compositions, représentant un principe de design abordé en cours et une composition représentant une émotion. Ils ont utilisé les ordinateurs fournis par l’université et avaient le libre choix du logiciel utilisé pour la réalisation de l’exercice. La procédure de ce test utilisateur s’est déroulée selon la description faite au chapitre 4.7.
4.4 Choix du langage de programmation
Une fois les problématiques liées aux logiciels existants mises en emphase et les premières fonctionnalités de bases isolées, le langage de programmation doit être défini. Cette démarche permet de réaliser une analyse de faisabilité, en fonction des premières contraintes et en tenant compte de la charge du travail à réaliser. Trois solutions potentielles sont présentées ici, avec une analyse rapide des avantages et inconvénients.
C++ et librairie graphique SDL
Cette solution présente un avantage majeur, elle permet au programmateur de tout créer de lui-même. Le contrôle sur l’environnement est maximum. La problématique réside dans le fait qu’il faut réaliser une interface graphique complète à partir de la librairie SDL par exemple, ce qui demande du temps et des ressources considérables. De plus, ce type de langage demande l’utilisation d’un compilateur et fournit donc des exécutables. L’accès ou la distribution du logiciel peuvent donc être un peu complexes.
14 Visual C#
Cette solution présente l’avantage de proposer, à la manière d’un outil auteur, une interface graphique préprogrammée, dotées d’un certain nombre d’éléments, comme par exemples les contrôles. Tout comme la solution précédente, celle-ci requiert l’utilisation d’un compilateur, et présente des contraintes encore plus fortes quant à la distribution, de par son développement réalisé par Microsoft.
Electron et JavaScript
Electron est un Framework code source ouvert, permettant le développement des logiciels.
Ce dernier utilise l’interface graphique de Google Chrome, package natif du Framework. Cette interface graphique permet d’utiliser des technologies web tel que HTML, CSS et JavaScript.
Le back-end utilise Node, interprète permettant d’utiliser le langage JavaScript sans navigateur web, pour une application de bureau par exemple (« Electron », s. d.). Tout comme un outil auteur, le programmateur peut profiter des éléments proposés nativement par HTML, comme par exemple les contrôles. L’inconvénient de cette solution, provient des limitations graphiques imposées par l’utilisation de HTML/CSS.
4.5 Charte de design
Les guidelines pour la conception d’interface (Hobart, 1995) enseignent des principes permettant d’éviter les erreurs de design. Ces principes sont résumés au sein d’une charte de design qui doit être réalisée avant de commencer la programmation. Cette charte, couplée à l’analyse des besoins, donne lieu à une première création, qu’est une liste des cas d’utilisation du futur logiciel. Cette dernière comprend les actions détaillées qui seront effectuées par les utilisateurs.
La seconde étape consiste à créer une table des icônes. Certaines des icônes représentent des fonctionnalités, plus ou moins complexes, tandis que d’autres auront un sens sémiologique, représentant par exemple un objet. Chacune de ces icônes doit être créée, décrite et associée à ce qu’elle représente dans un tableau. Cette méthode permet d’éprouver la sémiologie des icônes, afin d’éviter toute ambiguïté une fois insérées dans le contexte du logiciel (Peraya, 1998).
Au même titre que les icônes, le curseur de la souris est appelé à représenter une fonctionnalité, ou du moins signifier à l’utilisateur la possibilité d’une action à un moment ou emplacement donné. Le pointeur de la souris étant le principal point d’interaction entre l’utilisateur et l’interface, il est primordial que les changements de curseurs soient homogènes et aient un sens. Pour ce faire, un tableau doit être réalisé, décrivant précisément la fonction de chaque type de curseur.
15
Le dernier point, concernant l’aspect graphique de la charte de design, est un tableau contenant la palette de couleurs utilisées. Ce tableau permet de garantir une homogénéité de l’interface au niveau du rendu visuel. De plus, cette table est un aide à la réalisation des feuilles de style CSS.
Finalement, afin de garantir une homogénéité dans les termes utilisés, les guidelines réalisées par Hobart préconisent la création d’une table de mots réservés. Cette table permet d’éviter l’utilisation de termes différents pour signifier une même idée, ce qui augmente la cohérence interne du logiciel (Bastien & Scapin, 1993).
4.6 Méthodologie de codage et développement
Le choix du langage de programmation est présenté au chapitre 6.1. La méthodologie de codage, expliqué au sein de ce chapitre, intervient après le choix du langage, étant donné que ce dernier peut influencer l’approche utilisée pour la programmation.
Le développement du logiciel est séparé en deux phases distinctes. La première consiste à réaliser le front-end, c’est-à-dire la partie visible du logiciel, son interface. Cette phase est réalisée selon les principes du flat design, soit une approche graphique minimaliste (absence d’ornement, d’effets 3D), avec du contenu textuel concis et en utilisant des formes simples (Patricia Nadeau, 2016). Ceci a pour effet de faciliter l’utilisabilité de l’interface, mais aussi de la rendre responsive, c’est-à-dire adaptable à divers tailles d’écran. La grande majorité du front-end est réalisée à partir des technologies web HTML et CSS. Le rendu visuel et fonctionnel de cet interface est testé tout au long de son développement, afin d’en garantir les bons rendus et fonctionnements.
La seconde phase de développement est la réalisation du back-end. Cette phase comprend la réalisation des interactions visuelles ne pouvant pas être réalisées au travers du CSS, la programmation de tous les algorithmes de mouvement de carrés, les actions de chacun des contrôles, et la gestion de fichiers. Les fonctionnalités mises en place lors de la création du back-end, sont celles qui sont décrites au travers de l’analyse des besoins, mais aussi des cas d’utilisation. Ces actions et cas d’utilisation sont décrits en français, à la manière d’un algorithme, pour être ensuite « traduits » sous forme de fonctions informatiques. Chaque fonctionnalité est séparée en procédures ou fonctions, elles-mêmes segmentées en sous- procédures ou sous-fonctions. Le but de cette segmentation est de fournir un codage optimisé, dans lequel chaque petite fonction peut être réutilisée au besoin, mais aussi testée de manière individuelle avant d’être agrégée au sein d’une fonctionnalité plus importante. Les fonctions ou procédures sont testées au fur et à mesure du développement, de même pour les fonctionnalités. Les « outils de développement » standards de Google Chrome ainsi que des
16
variables espionnes sont utilisées pour le débogage. Le back-end est réalisé dans le langage JavaScript.
Le Framework Electron requiert une intégration particulière. Comme le montre la Figure 5, il y’a un script prénommé « Main.js » qui va jouer le rôle d’administrateur. Ce dernier, fournit par le Framework, va faire appel aux librairies de fonctions spécifiques permettant la gestion de fenêtre, dans laquelle Chromium va être lancé, Chromium étant un navigateur web. Dans cette fenêtre Chromium, le script va charger le document HTML indiqué, qui sera mis en forme grâce aux feuilles de style (CSS). Les interactions utilisateurs prennent alors naissance dans le JavaScript développé pour apporter des modifications visuelles sur le HTML.
Figure 5 : Architecture schématisée de l'intégration du Framework Electron
Lorsque le logiciel est ouvert, une procédure d’initialisation est lancée, comme le montre la Figure 6. Cette procédure lis le fichier d’initialisation contenant les attributs initiaux des carrés lors de l’ouverture du logiciel. Cette procédure créé aussi les variables de travail qui seront mises à jour tout au long de l’utilisation du logiciel. Une fois l’initialisation réalisée, le logiciel entre alors dans une phase d’attente d’une action de la part de l’utilisateur.
Figure 6 : Architecture schématisée du fonctionnement du logiciel
17
Une fois qu’une action est lancée par l’utilisateur, une boucle de traitement s’initie. Au cours de cette dernière, le logiciel analyse si l’évènement doit être traité ou non. Si ça n’est pas le cas, alors le logiciel retourne dans sa phase d’attente. Cependant si l’évènement doit être traité, alors le logiciel initie les procédures et fonctions associées à ce dernier. Si cet évènement engendre une modification des variables de travail, alors ces dernières sont mises à jour et l’interface graphique aussi. Dans les deux cas, le logiciel revient alors dans sa phase d’attente du prochain évènement.
4.7 Tests utilisateurs
Une fois le logiciel terminé, ce dernier doit être testé sur un échantillon de population du public cible. Ces tests permettent de recueillir des informations sur la qualité du développement tout en tentant de répondre à la question de recherche. Il permet aussi de relever les remédiations potentielles qui pourraient être effectuées dans le logiciel, afin qu’il puisse répondre au mieux, aux besoins du public cible.
Quatre étudiants de la Webster University qui suivent le cours d’introduction au design ont été les participants de ce test utilisateur. Dans le cadre de leur cursus au sein de la faculté, l’exercice du Black Square Problem leur était proposé. Ces derniers devaient créer deux compositions, représentant un principe de design abordé en cours et une composition représentant une émotion. Les quatre participants ont utilisé les ordinateurs fournis par l’université, sur lesquels, le logiciel développé dans le cadre de ce mémoire, avait préalablement été installé. Les participants devaient réaliser leurs deux compositions en présence du chercheur, qui pouvait les inviter à verbaliser certaines de leurs actions.
Une fois les deux compositions terminées, les participants se sont vu administrer le questionnaire USE (Lund, 2001). Ce questionnaire, disponible en Annexe 1, permet de mesurer des données psychométriques relatives à l’expérience utilisateur. Ce questionnaire comprend 18 questions, portant sur l’utilité, la facilité d’utilisation, la facilité d’apprentissage et la satisfaction. Chaque item est noté sur une échelle de Likert à 7 points allant de « fortement désaccord » à « fortement d’accord ». Ces mesures s’inscrivent aussi notamment dans le cadre du modèle d’acceptation de la technologie (Davis et al., 1989). Ce modèle étant utilisé comme axe de développement afin de garantir l’utilisation du logiciel, les données récoltées permettent de mettre en avant la cohérence entre l’approche utilisée au cours du développement et le résultat lors de l’utilisation du logiciel.
Chaque participant a pris ensuite part à un court entretien individuel. La durée de l’entretien a été fixée entre 5 et 10 minutes. Chacun d’entre eux a été enregistré, afin de pouvoir être analysé par la suite. La méthode choisie a été l’entretien semi-dirigé, selon la grille disponible en Annexe 2. Le but de cette discussion était de savoir comment le participant avait vécu la
18
réalisation de l’exercice, d’un point de vue technique et émotionnel. Il a été par exemple demandé au participant si, à un moment donné, le logiciel n’a pas réagi comme il s’y attendait et ce qu’il a ressenti à ce moment précis. Cette démarche s’inscrit dans le modèle de D’Mello
& Graesser sur le ressenti et les causes de la perte de l’équilibre affect-cognition (D’Mello &
Graesser, 2012). Cela permet aussi de revenir sur des observations qui ont été faites durant la phase de réalisation, afin d’obtenir de plus amples informations sur des problèmes ergonomiques potentiels, afin de pouvoir conduire des remédiations (Bastien & Scapin, 1993;
Doubleday et al., 1997).
19
5 Résultats de l’analyse des besoins
5.1 Cas d’utilisation et analyse des besoins
L’analyse des besoins a été réalisée sur deux étudiants. Les logiciels choisis par ces derniers pour réaliser l’exercice étaient Microsoft Office Word et Adobe Photoshop. Les deux étudiants avaient déjà eu l’occasion de réaliser l’exercice du Black Square Problem par le passé.
L’utilisateur de Microsoft Office Word était en possession d’une sorte de canevas, délimitant l’espace de travail sur lequel la composition devait être créée. Grâce à un jeu de superposition de formes, les carrés dessinés dans l’espace de travail, mais qui le dépassent, sont partiellement masqués. Ce participant avait déjà réalisé l’exercice du Black Square Problem
« une vingtaine de fois » selon ses dires. Le canevas, dont il était en possession, lui avait été fourni par son précédent enseignant, qui l’avait réalisé afin de faciliter l’exercice. Le participant avait donc choisi de réaliser l’exercice sur le logiciel Microsoft Office Word afin de profiter de ce canevas, mais aussi de son expérience précédente sur l’utilisation du logiciel. Pour réaliser la tâche de création de composition, le participant a opté pour une stratégie par essai. Il a commencé par déposer ses quatre carrés, puis les a bougés, tournés et changé de taille afin de réaliser plusieurs essais pouvant correspondre à ce qu’il cherchait à exprimer. Cette approche pourrait correspondre à la définition de la sérendipité, soit « l’art de trouver sans chercher en usant de sagacité » (« sérendipité — Wiktionnaire », s. d.). Le participant commente et explique sa méthode en disant « je joue avec pendant les 10 premières minutes.
Comme ça je peux avoir le processus créatif. Je ne suis pas naturellement créatif. J’essaye donc de laisser couler mon processus créatif depuis le début ». Quand il lui est demandé s’il a une idée de ce qu’il veut réaliser au moment où il commence sa composition, le participant mentionne « j’essaye de trouver quelque chose qui fonctionne par rapport à ce que j’ai posé ».
L’utilisateur d’Adobe Photoshop avait, lui aussi, déjà réalisé à plusieurs reprises, l’exercice du Black Square Problem. Ses premiers essais avaient été réalisés sur le logiciel Microsoft Office Word, puis a changé pour un logiciel « plus adapté au design graphique, comme Adobe Photoshop » car « il contient plus de fonctionnalités ». Le participant mentionne qu’il a acquis six ans d’expérience sur le logiciel. Ce sont ces arguments qui ont motivé son choix de logiciel.
Le participant a opté pour une stratégie par essai pour réaliser la tâche de création de composition. Il a commencé par déposer ses quatre carrés, puis les a déplacés en mentionnant « essayer de se rapprocher de ce que j’ai dans la tête ». Il apparaît que ce participant a une idée générale de sa composition, mais que cette dernière évolue au cours de la réalisation.
Un premier besoin peut être mis en évidence grâce à ces observations. Les participants semblent toujours commencer par placer les quatre carrés. A ce propos, un des participant
20
commente « la première chose que je fais toujours quand je réalise cet exercice, je place les carrés quelque part ». Le fait de pré-placer les carrés dans le logiciel dédié, de façon neutre, permettrait donc de réduire le nombre d’actions à effectuer. De plus, ces actions ne semblent pas avoir de plus-value au sein de l’exercice, leur réduction aura donc pour conséquence de réduire la charge cognitive. En addition ceci devrait influencer positivement la facilité d’utilisation.
Durant la réalisation de l’exercice, un point apparait très vite : dessiner des carrés et les maintenir carrés lors du changement de taille. La vérification de la taille se fait d’abord par une approche visuelle, puis elle est vérifiée au niveau des cotations, dans les deux logiciels. La fonctionnalité permettant de garder les proportions en appuyant sur la touche « shift » lors des changements de taille, ne semble pas être intuitivement utilisée. L’utilisateur de Microsoft Office Word a notamment tenté de rendre une de ses formes carrée au travers des paramètres et n’a pas réussi. Il s’est même vue dans l’obligation de la supprimée pour en recréer une nouvelle, faute de réussir à utiliser la fonctionnalité du logiciel. Lorsqu’il est interrogé sur son ressenti il admet avoir été « très frustré par la situation » et doit fournir un effort supplémentaire pour surmonter le problème, conformément au modèle des dynamiques de l’affect (D’Mello &
Graesser, 2012). Une première problématique émerge donc de cette observation. Dans le cadre d’un logiciel dédié, étant donné la spécification de l’exercice sur l’utilisation de carrés, lorsque l’utilisateur effectue un changement de taille, les proportions carrées doivent être nativement conservés.
Un second point commun à l’utilisation des deux logiciels est la précision. Les utilisateurs placent leurs carrés puis, visuellement essayent de voir s’ils sont alignés ou distribués comme ils le devraient. Dans le cas de Adobe Photoshop, des règles sont utilisées afin de faire un alignement final, tandis que dans le cas de Microsoft Office Word, des calculs sont effectués pour la vérification. La première approche, très empirique, prend du temps à la réalisation et reste imprécise, tandis que la seconde étape de vérification demande beaucoup d’actions ou de ressources cognitives. Lors des entretiens ceci se confirme, les étudiants mentionnant que
« le logiciel pourrait être utilisé pour l’alignement » ou encore « le logiciel peut faire l’alignement plus facilement ». Il apparait alors que l’existence de fonctions d’alignement ou distribution est connue mais que ces dernières ne sont pas trouvées dans le logiciel et non- utilisées. Ceci correspond à un problème d’incitation et de guidage (Bastien & Scapin, 1993).
Un des besoins d’un logiciel dédié est donc de mettre à disposition ces fonctions, de manière visible, en d’autres mots, les rendre accessibles. Afin d’augmenter les possibilités de précision, tout en laissant aux utilisateurs l’opportunité d’utiliser une approche de placement initiale plus empirique, une des solutions serait de créer une grille qui peut être affichée sur la zone de travail.
21
Que cela soit dans le cas de la taille ou dans le cas de la position, les participants semblent accorder de l’importance à la vérification de ces variables de manière chiffrée. Laisser une place dans l’interface pour l’affichage des propriétés du/des carrés répondrait à ce besoin.
Finalement, il existe certains besoins relatifs à la gestion de fichiers. L’utilisateur doit être en mesure d’enregistrer son travail d’ouvrir un fichier sur lequel il a précédemment travaillé ou encore réaliser des exports sous format image.
Un dernier besoin notable provient de l’exercice du Black Square Problem lui-même. Huit compositions doivent être effectuées, à la manière d’un brainstorming puis une de ces composition est choisie comme composition finale (Wilde, 1991). L’utilisateur doit pouvoir changer aisément d’essai de composition sans avoir à créer un nouveau fichier pour chacune d’entre elle. Un fichier de type Black Square est donc un ensemble de huit compositions.
Ces besoins et le fonctionnement général du logiciel ont été décrits sous la forme de cas d’utilisation, disponibles en Annexe 3. Par exemple, six différents cas d’alignement ont été retenus. Quatre cas d’alignement par les extrémités (alignement en haut, en bas, à gauche ou à droite) et deux cas d’alignement par le centre (centrer verticalement ou horizontalement).
Voici, pour illustration, la description du cas de l’alignement horizontal par le centre :
« Si l'utilisateur a sélectionné deux carrés ou plus et qu'il clique sur le bouton "Alignement horizontal au centre", les carrés sont déplacés afin que tous aient leurs centres alignés sur une ligne horizontale, correspondant au centre moyen des carrés sélectionnés »
Les résultats présentés dans ce chapitre sont donc le point de départ pour le cœur de ce mémoire, le développement du logiciel dédié.
22
6 Résultats du développement
6.1 Choix du langage de programmation
Parmi les solutions présentées au chapitre 4.4, la solution sélectionnée pour la réalisation de ce mémoire de développement est la solution Electron et JavaScript. Cette solution présente quelques limitations graphiques imposées par l'utilisation de HTML/CSS. Cependant, dans le cadre des besoins mis en avant par l’analyse, ces limitations n’ont pas d’influence sur le résultat visé par ce mémoire.
6.2 Icônes et fonctionnalités liées
Selon la définition proposée pour la création des guidelines, un point important est de réaliser une table contenant les icônes utilisées dans le logiciel et de leur associer une fonctionnalité afin de garantir la cohérence et la sémiotique (Hobart, 1995; Peraya, 1998).
Le Tableau 5 présente les icônes relatives à l’interface générale et à la gestion des fichiers.
Dans ce dernier, plusieurs icônes ont été utilisées car elles font partie d’une convention. Par exemple, la disquette représentant la fonction de sauvegarde, est une convention utilisée depuis de nombreuses années, et ce, dans beaucoup de logiciels. Cette dernière représente, de manière analogique, la fonction par l’objet physique utilisée lorsque les disquettes étaient encore en vigueur. La logique est identique en ce qui concerne l’ouverture d’un nouveau fichier (icône représentant un dossier) et la création d’un nouveau document (icône représentant une feuille blanche). L’icône créée pour les messages d’information et les feedback de sauvegarde possède, quant à elle, un registre sémiotique plus symbolique. Cette dernière est composée de la lettre « i » pour information, sur un fond bleu, couleurs représentant les informations dans la signalétique. Enfin, les icônes permettant d’afficher ou masquer le menu sont représentées par des têtes de flèches, indiquant la direction du mouvement.
Tableau 5 : Icône relatives à l'interface générale et la gestion de fichiers
23
Les icônes relatives aux alignements et aux distributions, présentées dans le Tableau 6, sont légèrement plus complexes, car les fonctionnalités qu’elles représentent le sont elles aussi.
L’exemple des cas d’alignement reste toujours identique, faisant gagner le tout en homogénéité. Deux iconèmes, représentant les carrés qui vont voir leurs propriétés changées par la fonctionnalité, sont articulés par une ou plusieurs flèches rouges indiquant le déplacement. La flèche indique le point de départ avant mouvement et le point d’arrivée après mouvement. Un repère visuel bleu a été ajouté, représentant l’axe sur lequel les carrés seront finalement alignés. De par le contexte, les iconèmes composant ces icônes revêtent un caractère homomorphe étant donné que les formes travaillées au sein du logiciel sont toujours des carrés.
Tableau 6 : Icônes relatives aux alignements et distributions
Les icônes représentant les fonctionnalités de distribution ont une sémiotique similaire à celles des icônes d’alignement. La différence majeure vient du fait que, ce ne sont plus deux iconèmes qui les composent, mais trois. Cela répond au fait qu’il faut, pour réaliser une distribution, au moins trois éléments sélectionnés.
Dans le Tableau 7 sont présentées les icônes relatives à l’explorateur de fichiers. Ces dernières reprennent des conventions telles que l’icône de dossier présentée précédemment.
En ce qui concerne les autres types de document, il est courant de voir un iconème représentant une feuille blanche avec une inclusion d’un second iconème représentant le type de document. Dans le cas des images, un paysage bleu a été choisi, tandis que dans les cas des fichiers de type « Black Square » ce sont des carrés noirs superposés qui ont été choisis.
Ces choix se rapportent respectivement à une analogie d’une photo et d’une composition sur le thème du Black Square Problem.
24
Tableau 7 : Icônes relatives à l'explorateur de fichiers
6.3 Curseurs et fonctionnalités liées
Le pointeur de la souris étant le principal point d’interaction entre l’utilisateur et l’interface, ce dernier est traité selon le même principe que n’importe quelle icône. Des pointeurs standards sont déjà existants sur tous les systèmes d’exploitation, mais il est important de définir quelle fonctionnalité est associée à chacun d’eux. Le Tableau 8 présente un récapitulatif des curseurs choisis, ainsi que les fonctionnalités associées. Il est à noter qu’un curseur non-standard au HTML/CSS a dû être créé pour la fonctionnalité de rotation. Cette dernière est représentée par deux flèches formant un cercle et rappelant un mouvement de rotation. Ce curseur s’inscrit dans la continuité de la double flèche orientée, indiquant un mouvement diagonal, conventionnellement utilisé lors d’un changement de taille.
Tableau 8 : Récapitulatif des curseurs utilisés et leurs fonctions associées
6.4 Palette de couleur
Le choix des couleurs a été réalisé avant la création du front-end afin de garantir son homogénéité et sa cohérence lors de la création (Bastien & Scapin, 1993; Hobart, 1995). Le Tableau 9 récapitule les couleurs utilisées et leurs contextes. La colonne nommée
« interaction » explicite l’apparition des couleurs, si celles-ci sont issues d’un changement graphique dû à une interaction de la part de l’utilisateur, en mentionnant le type interaction.
25
Tableau 9 : Couleurs du logiciel et utilisations associées
Il est important de noter que, les carrés qui sont travaillés dans le logiciel étant noirs, la zone de travail dans laquelle ils apparaissent a pris pour couleur le blanc. Ce choix est celui du contraste, c’est-à-dire que ces deux couleurs sont celles qui sont le plus contrastées dans tout le logiciel. En effet, la raison de l’utilisation du logiciel étant la réalisation d’une composition à base de carrés noirs, il est important que l’emplacement réservé à cela soit mis en évidence.
26
6.5 Front-End
Figure 7 : Fenêtre principale du logiciel dédié au Black Square Problem
Le front-end ou interface du logiciel, a été créé de manière à être en partie responsive (adaptative). La configuration visible dans la Figure 7 est celle qui apparaît lorsque le logiciel est ouvert. Les quatre carrés sont placés de façon « neutre ». Ils sont placés à équidistance les uns par rapport aux autres et sont tous de taille identique. La langue par défaut est le français.
Comme le montre la Figure 8, le front-end est séparé en cinq zones distinctes.
La zone A, représente le menu général. Au travers de ce menu, l’utilisateur peut changer la langue grâce à une boîte de choix et peut aussi appeler la fenêtre d’aide. Les fonctionnalités présentées ici, sont définies par des standards, soit la possibilité de se référer à une aide et avoir une interface adaptative à la langue
préférentielle de l’utilisateur. Figure 8 : Fenêtre principale séparée en frames
27
La zone B, est le menu relatif aux fonctionnalités du logiciel. Il comprend les boutons permettant la gestion de fichiers, mais aussi les alignements et les distributions. La gestion de fichiers répond aux besoins standards d’un logiciel avec interface utilisateur. Dans ce menu, les fonctionnalités d’alignements et distributions sont mises en avant, car l’analyse de besoin a montré que, si l’accessibilité de ces fonctions n’était pas évidente, ces dernières n’étaient pas utilisées. Ce menu peut être caché à l’aide de la flèche placée en dessous. Cette option laisse la possibilité de garder le menu à l’écran ou focaliser uniquement l’espace de travail.
Le but de cette fonctionnalité est de laisser la possibilité à l’utilisateur de se focaliser uniquement sur sa composition, en réduisant les interférences dues au logiciel.
La zone C est la zone de travail principale. C’est dans cette partie-ci que l’utilisateur peut créer sa composition. Cette dernière, tout comme le canevas de l’utilisateur de Microsoft Office Word, est le seul endroit dans lequel les carrés vont apparaître. Tout ce qui dépasse de cette zone est caché aux yeux de l’utilisateur.
La zone D à une double utilisation. Elle est à la fois une zone d’information, composée de contrôles textes permettant d’afficher les valeurs des attributs du ou des carrés sélectionnés.
Ces mêmes attributs peuvent être changés au travers de ces contrôles. Cette zone comprend aussi des boutons permettant de changer les plans des carrés, mais aussi un bouton pour afficher ou masquer la grille ainsi qu’en changer le pas. Grâce à cette zone, l’utilisateur est en mesure de vérifier les cotations des carrés de manière chiffrée, qui semblait prendre une grande importance lors de l’analyse des besoins. De plus, la possibilité de faire apparaître une grille, permet à l’utilisateur de réaliser une approche initiale empirique de la création, tel que constaté précédemment, mais en y ajoutant un peu plus de précision. Ceci dans le but de réduire le temps et les ressources investies dans la vérification des cotations.
Enfin, la zone E représente les onglets. Elle permet à l’utilisateur de naviguer d’un essai de composition à un autre et ces derniers sont numérotés de 1 à 8. Cette fonctionnalité est définie par la tâche du Black Square Problem, soit un brainstorming de huit compositions et un choix final d’une de celles-ci.
Afin que l’utilisateur puisse aussi jouir des fonctionnalités standards utiles à la gestion de fichiers, un explorateur de dossier a été créé. L’interface de ce dernier, présentée en Figure 9 peut apparaître lorsque l’utilisateur effectue un enregistrement ou lorsqu’il ouvre un fichier.
Ces fenêtres secondaires, de tailles fixées, contiennent un menu déroulant permettant de naviguer dans l’arborescence des fichiers et dossiers, des boutons permettant d’effectuer l’action désirée ainsi qu’un bouton d’annulation. Deux contrôles sont aussi présents, une boite de choix pour l’extension du fichier et un champ texte pour le nom du fichier. Dans le cas de
28
la fenêtre secondaire pour l’ouverture du fichier, le contrôle texte est bloqué à l’écriture afin que l’utilisateur ne puisse que choisir un fichier existant.
Figure 9 : Fenêtres secondaires comprenant un explorateur de fichiers permettant d'enregistrer un fichier (gauche) ou d'ouvrir un fichier (droite)
La dernière fenêtre secondaire composant le front-end est la fenêtre d’aide, présentée en Figure 10. Cette fenêtre ne permet aucune interaction avec l’utilisateur, excepté le menu déroulant facilitant la lecture. Cette partie de l’interface comprend une explication des fonctionnalités principales du logiciel, soit les interactions avec les carrés, mais aussi le fonctionnement détaillé des alignements et distributions.
Figure 10 : Fenêtre secondaire comprenant une aide contextuelle
