Outils pour utilisateurs

Outils du site


public:specs_dev_rcp:specs_feedback_ui

Communication et Feedback utilisateur

TXM rend compte (feedback) de son activité à travers divers éléments d'interface graphique interactive : zones de status, journaux, fenêtres de résultats, etc.

On va essayer d'utiliser une notion de « canaux de communication » pour définir comment différentes parties de TXM rendent compte de leur activité à différents moments et à différents endroits scrutés par l'utilisateur. Une première idée est de mutualiser les messages générés par les activités de TXM pour alimenter les différents canaux.

Rendre compte de son activité c'est fournir des informations sur le fait que des actions ou des calculs sont en cours ou bien des informations sur des calculs terminés.

Les canaux de communication ont les caractéristiques suivantes :

  • temporalité : au début, à la fin ou pendant une action en cours, éventuellement effacé à partir d'un certain temps
  • zone : les différentes zones listées ci-dessous
  • format : multilignes, ligne longue, ligne courte, éventuellement des couleurs, liens hypertexte, etc.

Temporalité

Le feedback peut être temporaire ou permanent.

Dans le feedback temporaire on peut distinguer le 1) début, 2) pendant et 3) après le calcul.

Le feedback permanent se trouve dans les fenêtres de résultats ou dans les journaux.

Zones

Les « différents endroits scrutés par l'utilisateur » sont les suivants :

  • temporaire
    • zone d'information temporaire dans la barre de statut (en bas à gauche)
    • zone de progression temporaire (en bas à droite)
    • boite de dialogue temporaire de progression (pour les calculs longs)
    • forme temporaire de progression de la souris (pour les calculs longs ou blocant longtemps l'UI)
  • permanent
    • contenu de la console
    • label d'un onglet d'éditeur
    • tooltip au rollover sur un titre d'onglet d'éditeur
    • le contenu d'un éditeur
    • zone d'information permanente dans un éditeur (à généraliser, eg. en bas de l'éditeur ?)
    • label du noeud dans l'arborescence de la vue Corpus
    • tooltip au rollover sur un noeud dans l'arborescence de la vue corpus (il y a un déjà un mécanisme interne de rollover ici qui affiche le label complet d'un noeud lorsqu'il dépasse la zone visible)
    • zone “description” de l'onglet “Général” de la commande Properties
    • le fichier de log de la session TXM

Définitions des messages

Certaines de ces zones sont visibles alors même que certains résultats persistés n'ont pas encore été reconstruits. Par exemple un label de noeud dans la vue Corpus doit afficher quelque chose mais peut ne pas avoir accès à certaines informations du résultat car il n'a pas encore été calculé. Idem pour la barre de statut au clic sur un objet non reconstruit.

NOTES:

  • un objet non encore reconstruit a accès à la valeur de ses paramètres mais pas forcément à d'autres infos liées au résultat du calcul
  • le label d'un noeud dans la vue Corpus et le message dans barre de statut au clic sur un noeud pourraient n'être basés que sur des paramètres de résultats, ce qui nous permettrait d'afficher les mêmes informations pour un objet construits ou non encore reconstruit. Cela peut aussi faire sens au regard de la taille très petite de ces zones

Formats

On se limite à l'affichage sous forme de texte, on ne discute pas d'affichage sous forme de tableau, etc.

Suivant la temporalité et l'espace d'affichage disponible on peut utiliser les formats suivants :

multi-lignes, les lignes peuvent être longues

  • une seule ligne longue
  • une seule ligne courte
  • le texte peut éventuellement être enrichi :
    • couleurs (eg les consoles Eclipse utilisent des couleurs pour distinguer les différents types de messages)
    • liens hypertexte (eg les tooltip d'Eclipse permettent de cliquer sur des liens hypertextes)

Les canaux de communication

TXM 0.7.9

TXM 0.8.0

Les zones :

  • Vue corpus (Vue RCP)
    • titre
    • tooltip
  • Barre de Status
  • Fenêtre (Editeur RCP)
    • titre
    • tooltip
    • résultat
  • Console
  • JobHandler

Les canaux :

  • aucune implémentation de canal

TXM 0.8.1

Les zones/canaux :

  • Vue corpus (Vue RCP)
    • titre
    • tooltip
  • Barre de Status
  • Fenêtre (Editeur RCP)
    • titre
    • tooltip
    • résultat
  • Console
  • ProgressDialog : zone bloquant toutes les interactions avec l'UI
  • JobHandler : zone temporaire mise en avant (possibilité de mise en arrière plan, ou l'inverse)

Messages de début&fin de calcul : #2717

Utilisation des méthodes de nommage des résultats par zones :

  • Vue corpus (Vue RCP)
    • titre : TXMResult.getShortName()
    • tooltip : TXMResult.getFullName()
  • Barre de Status : ne rien afficher (la zone sera rétablie dans une version ultérieure)
  • Fenêtre (Editeur RCP)
    • titre : TXMResult.getShortName()
    • tooltip : TXMResult.getDetails()
    • résultat : TXMResult.getShortName()
  • Console :
    • TXMResult.getAncestorShortName()
  • ProgressDialog et JobHandler
    • titre : TXMResult.getParentShortName()
    • tache : TXMResult.getParentShortName()

Définition des méthodes de nommage des résultats (TXMResult) :

  • getShortName : affiche le nom simple, sans contexte de l'objet
    • affiche le nom choisi par utilisateur (si il est réglé TXMResult.getUserName())
    • sinon affiche les paramètres principaux de calcul (ceux présentés par défaut dans la barre d'outil des éditeurs)
      • on distingue donc pour chaque commande
        • paramètres principaux (affichés dans la toolbar des éditeurs)
        • paramètres secondaires (accessibles depuis une zone déroulante)
    • exemples :
      • une table lexicale calculée avec la propriété “frlemma”, fmin=2 et vmax=200 → “@frlemma”
      • une table lexicale calculée avec la propriété “frlemma”, fmin=10 et vmax=2000 → “@frlemma” (pas de distinction d'après les paramètres)
    • note : pour pouvoir différencier les 2 tables il faudrait alors rendre le paramètre fmin principal
  • getFullName : affiche le nom complet, incluant le type du résultat suivi de tous ses paramètres (principaux suivis de secondaires ?) réglés (par l'UI de paramètres ou par des valeurs par défaut)
    • exemple de forme : @frlemma fmin=5 fmax=1000 vmax=2000
  • getParentShortName : affiche le nom simple de la parenté suivi du nom simple
    • on n'affiche pas les ancêtres non affichés (cachés)
    • le caractère séparateur pourrait être une préférence TXM ?
    • exemple de forme : Partition/@frlemma
  • méthodes de debug :
    • getAncestorShortName : affiche toute la parenté suivi du nom simple
      • exemple de forme : VOEUX/SubCorpus/Partition/@frlemma
    • getAncestorFullName : affiche toute la parenté suivi du nom complet
    • exemple de forme : VOEUX/SubCorpus/Partition/@frlemma fmin=5 fmax=1000 vmax=2000
  • getDetails : affiche le type du résultat suivi de tous ses paramètres en détails, sur plusieurs lignes
  • getUserName : affiche le nom choisi par l'utilisateur ou celui généré automatiquement (ex: Partition, Subcorpus)

TXM 0.8.2

TXM 0.8.1 + ce qui suit

Utilisation des méthodes de nommage des résultats par zones :

  • Barre de Status :
    • affiche les détails sur une ligne du résultat sélectionné dans la vue corpus avec TXMResult.getSimpleName()

TXM 0.8.3

TXM 0.8.2 + ce qui suit

Utilisation des méthodes de nommage des résultats par zones :

  • Barre de Status :
    • affiche un message d'ouverture des résultats depuis la vue corpus ou depuis une commande. Est effacé une fois le résultat affiché
      • message : “Opening” + TXMResult.getSimpleName() + “…”

TXM suivants

  • voir Gestion des messages pour + de spécifications.
  • quel rôle ont les niveau de logs INFO,WARNING, SEVERE etc ?
    • doit-on créer des niveaux qui déclenche une boite de dialogue ?
    • SLH:
      l'interprétation des niveaux de logs me semble encore très difficile et complexe à mettre en oeuvre :
        - est il vraiment nécessaire d'ajouter un niveau de log supplémentaire pour un besoin d'ouverture de boite de dialogue ? quitte à brouiller un peu plus la sémantique des niveaux de logs dans leur ensemble
        - est-ce que les sémantiques des erreurs provoquant actuellement l'ouverture d'une boite de dialogue (si l'option est activée) sont homogènes, et donc interprétables par l'utilisateur comme un groupe homogène, ou pas ?
        - y-a-t-il une description de référence des sémantiques des niveaux de log ? (que je puisse formuler notamment dans le manuel utilisateur)
      - actuellement l'option d'ouverture d'une boite de dialogue n'est pas active par défaut : est-ce qu'il faut qu'elle devienne active par défaut pour que les messages du Media Player puissent s'afficher dans une boite ? pour moi le problème Media Player doit avoir une boite ouverte systématiquement, ça ne doit pas dépendre d'une option
public/specs_dev_rcp/specs_feedback_ui.txt · Dernière modification : 07/09/2022 10:38 de matthieu.decorde@ens-lyon.fr