Quelques idées de R&D sur la V5

Feature request
1

Bonjour,

Suite à une démonstration de la V5, on m’a remonté quelques améliorations possibles :

  • Persister le paramétrage des tableaux croisés (préférence d’affichage) par utilistateur (ex : afficher les sous totaux). Si on se déconnecte, on perd les préférences d’affichage sur le tableau croisé.

  • Processus IHM : Afficher toutes les étapes du process à gauche et surligner l’étape sur laquelle on est. Actuellement, les étapes sont affichées suite à l’avancement du workflow IHM.

  • Modification en masse : Pouvoir personnaliser le message dans le bandeau vert par objet métier pour rajouter du contenu

  • Pourvoir figer l’entête sur les Vues (page d’accueil)

2

Merci pour ton retour,

  1. TC : on a beaucoup des demandes sur le sujet
  • enregistrer/nommer ses paramétrages (positions des axes, graphique…)
  • pouvoir les resélectionner et les mettre sur un dashboard
  • éviter d’avoir 2 fois le total si pas d’axe colonne
  1. Processus IHM : je n’ai pas bien compris le besoin
  • il s’agirait d’afficher l’historique des états (state-model) comme les étapes d’un processus/screenflow ?
  • c’est un graph/arbre, seul l’historique réalisé est une liste chainée.

  1. La modification en masse : par construction c’est en masse et pas par ligne, donc à étudier pour avoir des messages unitaires et pas juste un volume de mises à jour réussie / nb total.

  2. Figer l’entête de vue : cette notion n’existe pas, merci de préciser le cas d’usage

  • Zone fixe dans un vue ? à gérer par du CSS dans votre template de vue
  • ou avoir une zone sub-header dans tous les écrans ?
3

Sur 2) je pense qu’on parle des processus (pas des state models) qui empilent les étapes passées à gauche de l’écran => ce que tu indique ne serait éventuellement envisageable que pour les cas particuliers des processus inconditionnellement linéaires (ex: le screen flow hyper basique de la demo), or dans le cas général un processus peut avoir des branches/étapes conditionnelles, des splits/joins, etc. => le parcours n’est donc pas prédictible

4
  1. Process road ok je vois
  • un process ou un state modèle c’est un graph orienté de transitions, on pourrait l’afficher sous forme d’arbre ou de graphique SVG depuis l’activité begin/état initial => end/états terminaux
  • La “linéarité” peut aussi se modéliser comme un parcours “nominal” du graph, et les autres étapes comme des “options” ou des “exceptions” = il faudra typer les étapes pour guider l’affichage ou modéliser une position x,y…
  • et aussi choisir le rendering du "process road = none / breadcrumb / history / overview