Outils pour utilisateurs

Outils du site


public:specs_ergonomie

Principes ergonomiques de TXM

On suit les principes habituels, comme ceux de Libre Office.

On les implémente dans le cadre des deux toolkit d'UI que nous utilisons :

Ergonomie fonctionnelle

Paramètres des commandes et valeurs par défaut des paramètres dans les préférences de TXM

  • Systématiser l'interface combinant l'affichage des résultats d'une commande [en bas] avec un formulaire de saisie de tout ou partie de ses paramètres [en haut] (pour pouvoir régler les résultats finement ou recalculer avec des variations). Le formulaire de paramètres doit être escamotable pour ne pas gêner la lecture des résultats.
    → toutes les boites de dialogue de saisie de paramètres modales affichées avant le lancement d'une commande doivent disparaitre en étant refondues dans les formulaires de paramètres associés aux fenêtres de résultats
    → c'est la version portail qui a cette UI la plus aboutie et systématisée. Il faudrait s'en inspirer pour redesigner dans la RCP puis systématiser
    • il faudra trouver un moyen d'accéder rapidement à des préférences par défaut associées à un paramètre en cours de saisie (pour s'épargner d'avoir à resaisir ce paramètre systématiquement).

Historique des requêtes

  • Les requêtes réussies sont enregistrées par corpus.
    → il faut charger les historiques de saisie de requêtes à partir de ces sauvegardes au démarrage de TXM
    → le chargement des historiques peut se faire à la demande : c'est-à-dire seulement quand un corpus est utilisé pour la première fois dans la session
    → le mécanisme de “clôture” ou “gel” d'un corpus doit permettre de limiter les chargements d'historiques au démarrage
    → on peut créer une préférence “nombre maximum de requêtes à charger dans les historiques de saisie” (comme pour l'historique des commandes BASH)
    → on peut créer une préférence “nombre maximum de requêtes à sauvegarder dans l'historique” (comme pour l'historique des commandes BASH)

Pagination et mise en pages

  • Pagination des résultats : tous les résultats doivent être affichés en contrôlant leur présentation. On part du principe que tous les résultats en forme de tableau sont paginés par défaut, l'utilisateur pouvant choisir de ne pas paginer.
    • pagination verticale :
      → il reste à paginer les résultats de : spécificités, spécificités d'index, table lexicale, cooccurrents
    • pagination horizontale : pour les tableaux, il faut paginer horizontalement (notamment pour l'affichage des tables lexicales comportant beaucoup de parties)
      → tous les tableaux restent à paginer horizontalement
  • Mise en page des résultats : les résultats doivent utiliser le maximum d'espace visuel alloué.
    • les résultats en forme de liste doivent s'étendre horizontalement en étant mis en forme avec plusieurs colonnes. On peut commencer par un nombre de colonnes fixe (dont le nombre est modifiable par l'utilisateur)
      → toutes les listes restent à mettre en page sous forme de colonnes multiples : lexique, index, cooccurrents

Politique des chaînes de caractères des tooltips des boutons, des entrées de menus et des messages de logs

  • une commande ouvrant une pop up doit se terminer par des points de suspension, ex. “Open…”, indiquant qu'elle ne sera pas exécutée directement, c'est à dire sans confirmation
  • privilégier l'infinitif pour les tool tips des boutons, ex. : “Rétablir la vue initiale”, “Supprimer l'élément sélectionné”
  • dans les logs
    • en anglais, privilégier le participe présent lors de l'annonce d'un début de processus, ex. “Loading corpora…”, “Creating partition…”
    • en français, privilégier la forme nominative, ex. “Chargement du corpus…”, “Création de la partition…”
    • en anglais, utiliser le prétérit lors de l'annonce de la fin d'un processus, ex. “Corpora loaded.”, “Partition created.”
    • en français, utiliser la forme adjectivale ou participe passé lors de l'annonce de la fin d'un processus, ex. “Corpus chargé.”, “Partition créée.” ou “Le corpus a été chargé.”, “La partition a été créée.”
    • TODO: définir une règle pour le démarquage des noms d'objets, quote ou double quote, en EN et FR ? Ex. : Le fichier “fichier.png” a été chargé. OU Le fichier 'fichier.png' a été chargé.

Exploitation des résultats (export/sauvegarde/impression/transfert/copie)

  • Il faut convenir d'une politique d'UI homogène pour la gestion des flux de résultats
    → l'UI de sauvegarde et d'export des tables lexicales est à finaliser
    → il faut créer des entrées de menu contextuel pour tous les raccourcis de Tout sélectionner et Copier de lignes de résultats (ainsi que Control-X/Couper, Control-F/Chercher voire Control-S/Sauver, etc.)
    → il faut mettre en place une politique de sauvegarde de résultats sous forme d'image en fonction des usages ultérieurs : manipulation bitmap dans Writer ou vectorielle dans Inkscape (le driver SVG actuel pose problème pour la retouche)
    → il faut mettre en place une politique d'impression de résultats
    → si les résultats commencent à s'enregistrer systématiquement dans un fichier dans un répertoire commun, il faut documenter ce répertoire (nom des fichiers, contenu)
    → on pourrait convenir de résultats à recharger au lancement : soit sous forme intensive (→ recalcul à la volée), soit sous forme extensive (rechargement de résultats qui ont éventuellement été édités - c'est-à-dire pour lesquels on ne peut pas se contenter du recalcul à la volée)
  • voir également les spécs NOTEBOOK/JOURNAL & PUBLICATION

Ergonomie de l'Interface Graphique Utilisateur (GUI)

Accès aux outils

1) Les accès doivent être déployés de façon symétrique sur tous les modes d'accès principaux (hors liens hypertextes, etc.) :

  • A) menu principal
  • B) barre d'outils
  • C) menu contextuel
  • D) raccourcis clavier

La liste des entrées doit être identique pour tous les modes d'accès.

L'ordre de la liste des entrées doit être identique pour tous les modes d'accès.

Les groupes d'entrées doivent être identiques pour tous les modes d'accès.

1.1) Certains accès peuvent ne pas être saturés :

  • par exemple on peut ne pas créer des raccourcis clavier pour toutes les commandes (pour celles ne justifiant pas un accès “électrique”)
  • si un accès n'est pas fourni, il doit être justifié

1.2) On peut limiter le nombre d'entrée d'un menu

Dans les logiciels LibreOffice, Gimp et Blender, on trouve entre 10 et 30 entrées max.

* tant qu'on n'arrive pas à 20 entrées on met tout

2) les accès aux outils les plus utilisés doivent être situés dans les zones les plus accessibles des moyens d'accès :

  • A) au début des menus déroulants
  • B) au début des barres d'outils
public/specs_ergonomie.txt · Dernière modification : 24/05/2023 16:35 de slh@ens-lyon.fr