CA, planes selection widget with more than 3 plans
In TXM 0.8.3 and before, only 3 plans were available -> a combo was OK
With more plans, the combo might contain à lot of elements (5 axes -> 10 planes, 6 -> 15, 7 -> 17...)
Solutions
- A :
keep the combo but sort the plan by sum(weight(axis1)) , weight(axis2)) - B :
use 2 Spinner (+/-), one for each axis to select- see if FactoMineR and TXM code allow d1 > d2
-
C : [SLH] use 2 pull-down menus, X axis (horizontal) & Y axis (vertical), to select the factors to display in the plane
- each pull-down menu contains the list of all factors
- behavior
-
if the user selects the same factor in the two pull-down menus the selection is rejected and set back to the previous selection- Finally, the interface still works and being able to select the same axis is useful to work on one axis at a time
-
if (factor# of X axis < factor# of Y axis) the selection is rejected and set back to the previous selection(?)
-
- remarks: pull-down menu entries can contain info (like inertia gain in FactoShiny, see link below)
Discussion
- A : is more conservative
- maybe don't show plans with very low weight
- B : is more understanding (but needs good controls verifications to work)
- C can be found in other software UI and can be familiar to the user, eg in FactoShiny https://raw.github.com/juba/explor/master/resources/screencast_0.3.gif
- B&C : allow easy change plan when only one axis is changed
- Bonus : animate the points&labels during transition ?
Keep solution C
Validation test
- Compute a CA on VOEUX/loc
- try combinaison 1,3 -> check informations panels
- try combinaison 1,1 -> check informations panels
- -> check informations panels
Activity
changed milestone to %TXM 0.8.4
added tool::ca type::specs labels
added status::draft label
removed type::specs label
removed status::draft label
added type::feature label
added status::feedback label
- Resolved by Sébastien Jacquot
0.8.4 (2024-11-12 07h05) Ubuntu 20.04
Globalement OK :
- remarque : par rapport à ce que décrit le ticket, je n'ai pas rencontré d'obstacles pour mettre en abscisse un axe de rang moindre (ex. plan 4 x 3)
-
bug rencontré en demandant le plan 1x1, en demandant l'affichage des coordonnées c1 et en triant sur la colonne de ces coordonnées : longue stacktrace commençant par "java.lang.NumberFormatException: For input string: "1)" under radix 3" (et le tri n'est pas bon). Problème analogue pour 4x4.
- Stacktrace :
java.lang.NumberFormatException: For input string: "1)" under radix 3 at java.base/java.lang.NumberFormatException.forInputString(Unknown Source) at java.base/java.lang.Integer.parseInt(Unknown Source) at org.txm.ca.core.functions.CA.getData(CA.java:1390) at org.txm.ca.core.functions.CAInfos.getData(CAInfos.java:357) at org.txm.ca.rcp.editors.ColsRowsInfosEditor$4.compare(ColsRowsInfosEditor.java:210) at org.eclipse.jface.viewers.ViewerComparator.lambda$0(ViewerComparator.java:206) at java.base/java.util.TimSort.countRunAndMakeAscending(Unknown Source) at java.base/java.util.TimSort.sort(Unknown Source) at java.base/java.util.Arrays.sort(Unknown Source) at org.eclipse.jface.viewers.ViewerComparator.sort(ViewerComparator.java:206) at org.eclipse.jface.viewers.StructuredViewer.getSortedChildren(StructuredViewer.java:1035) at org.eclipse.jface.viewers.AbstractTableViewer.internalVirtualRefreshAll(AbstractTableViewer.java:645) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:620) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:610) at org.eclipse.jface.viewers.StructuredViewer.lambda$2(StructuredViewer.java:1459) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1398) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1359) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1459) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:526) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1418) at org.txm.rcp.editors.TableUtils.packColumns(TableUtils.java:450) at org.txm.rcp.editors.TableUtils.packColumns(TableUtils.java:430) at org.txm.rcp.editors.TableLinesViewerComparator$1.widgetSelected(TableLinesViewerComparator.java:179) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:252) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
- Stacktrace :
Edited by Matthieu Decorde - Last reply by Matthieu Decorde
removed status::à tester label
added status::à préciser label
mentioned in commit cc10b5b8
- Resolved by Sébastien Jacquot
The specification asks explicitly in solution C to reject the selection of two identical axes. Could you motivate why you want to develop this?
- Last reply by Matthieu Decorde
added status::à tester label and removed status::à préciser label
- Resolved by Sébastien Jacquot
Je ne comprends pas ce que doivent faire les deux combos box. En l'état il semble y avoir un comportement bizarre. Cela remet le dernier axe mais une seule fois seulement. Si je comprends bien la recette :
- un plan avec les mêmes axes est rejeté ? mais que doivent faire les combo box ?
- on interdit que le # d'axe X soit supérieur à l'axe Y ? Si c'est le cas ça ne fonctionne pas
- par ailleurs, est-ce normal que le changement d'axe provoque un recalcul direct malgré qu'on ne soit pas en auto-compute ? à mon sens ça ne devrait pas
Edited by Sébastien Jacquot - Last reply by Sébastien Jacquot
@sheiden Est-ce que tu pourrais nous donner ton avis sur le comportement actuel ?
Si une valeur invalide est sélectionnée dans l'une des deux combo box X ou Y alors la valeur précédente est re-sélectionnée automatiquement.
Je pensais que c'était une bonne idée mais à l'usage je trouve ça confus. On dirait que l'UI bug alors que non.
En l'état j'aurais bien envie de remettre comme avant, à savoir, laisser toutes les combinaisons possibles puis, si besoin, faire un ticket pour faire mieux. Par exemple, lors de la sélection dans une combo box, supprimer les valeurs invalides de l'autre combo box.
Comme ces paramètres sont de type 'semi-auto-compute', le fait de sélectionner dans les combo met à jour l'affichage directement. Or, si l'affichage ne change pas, pour moi ça veut dire clairement que la sélection ne 'sert à rien' ou 'a été refusée'. Et d'ailleurs en ouvrant le combo on voit que la valeur n'a pas changé. Donc je ne vois pas de côté confus. On pourrait ajouter un message d'erreur ou de refus dans la console, mais ça me semblerait too much.
En fait n'y a qu'un seul cas qui me gêne le plus : celui où c'est deux fois le même axe sélectionné car l'UI des plans n'est pas faite pour cela. Peut-être la gestion de ce cas précis pourrait amener une UI plus claire pour toi ?
Je ne sais pas si c'est visible dans le GIF mais on voit par exemple le "5" repasser en "1" ce qui me fait plutôt penser à un bug d'UI qu'à une valeur non valide.
Oui, le plan se met à jour aussi directement sur Windows.
Edited by Sébastien JacquotVoilà un exemple Eclipse sinon de valeur invalide : la valeur reste + message d'erreur :
Mais bon on est dans un environnement de page de préférences et pas dans un éditeur.
De plus, on ne propose pas de valeur invalide, là c'est l'utilisateur qui rentre lui-même une valeur invalide.
Edited by Sébastien JacquotNul n'est sensé ignorer la doc quand il utilise un outil a fortiori scientifique et pas trivial comme TXM et l'AFC.
Par ailleurs, la métaphore des double-combos a des limites. Si on avait gardé l'UI mono-combo précédente on n'aurait pu ne publier que les associations d'axes que l'on souhaite et on n'aurait pas eu ce problème.
Comme je l'ai dit, il y a potentiellement 2 raisons pour lesquelles on souhaite ne pas accepter certaines valeurs.
La première (1) est parce que l'UI n'est pas faite pour le cas de 2 fois le même axe. Une autre UI est en cours de définition pour cela et autant prendre les devants pour l'utiliser.
Si on supprime les contraintes de la deuxième raison (2) on va passer d'un nombre quasi-quadratique de refus possibles (n x n) à nettement moins : n refus pour n axes voire 2 x n possibilités de refus car on peut choisir depuis deux combos à la fois.
Donc je propose de retirer la contrainte (2) et ça devrait aller beaucoup mieux en termes de perception : il n'y a plus que les cas où les axes sont identiques qui posent problème. Donc l'utilisateur percute facilement la chose (même s'il ne percute pas la raison). Et je pense que dans ce cas il n'est pas nécessaire de faire des mises en évidence pour des refus pour axes identiques.
Sur le fond, les contraintes de type (2) sont des hypothèses motivées pour des raisons ergonomiques sensées être une aide à l'utilisateur - pas une contrainte. Elles n'ont pas été assez discutées/éprouvées. Il y a de fortes chances qu'il faille changer l'UI si on cherche à les implémenter un jour. C'est à dire ne plus utiliser deux combos comme ça.
Ok pour la suppression des autres contraintes. On pourrait aussi mettre à jour les listes des combo box mais comme c'est un peu compliqué c'est pour cela que je proposais de faire un ticket "faire mieux" pour une prochaine version. La doc n'empêche pas un mauvais feedback UI. Je ne crois pas avoir vu une seule fois un exemple de combo box qui rebouge tout seul (c'était d'ailleurs ma suggestion à la base mais je pense que c'est finalement une mauvaise idée).
Edited by Sébastien JacquotJ'adore la proposition de @mdecorde ca rend trop bien en +
removed status::à tester label
